Re: http+aes

In message <CAP2znoaOUYqGGu+ib3SfsJkX+BWaa2Ce5tUfgHT-qy+hUBTQwQ@mail.gmail.com>
, Ian Hickson writes:

>> I'm sorry, but IMO this is just security-theater, and it represents
>> so terrible handling of key-material that it is deeply irresponsible
>> to even mention it in a standards document, without a lengthy list
>> of caveats and disclaimers.
>
>Could you elaborate on this? In particular, what risks do you believe exist
>here given the scenario this is intended to address and given the list of
>issues to consider already given in the specification?

The major risk is that people understand neither how little privacy
this buys them, nor how trivially easy it is to compromise that
privacy accidentally.

The proffered strawman about copyright protection is not credible:

You cut and paste the link, and anybody who receives it can view
the copyrighted object, and you have no idea who leaked it.

That's pretty much exactly what the Copyright-Monopolies try to
avoid, they want per-licensed-copy unique links, so the can see
who copy&pasted it.

There is no way to salvage this, if you do not strengthen the
key-handling.

If instead of the actual key, you provided the identifier for a
pre-shared key, to be read from local storage on the client machine,
then the link would not work for anybody who didn't have the
pre-shared key in their "secrets" file.  (If you label the keys
individually per licensee, and you can see who tried to leak the
non-working links of you want to.)

That of course means that you need to provide a way to pre-share
the keys, and yes, that means that it will not work "by magic"
without user-involvment, but that is exactly what is necessary to
make this more robust:  You want people to realize that this is
secret key-material, you don't want to, as proposed, not even make
the user aware that it is there in the first place.

Trying to get benefits from crypto while trying to hide the fact
that it is not there, does not work, if people don't know it is
there, they don't know that they have to be careful not to break it.

Another problem is that this scheme does not offer any integrity.

Your malicius CDN could truncate your object and you would never
notice that the last 2 pages of the contract are missing.

Having been through the mill a couple of times myself, I can not
recommend strongly enough, that you try to get at least one
card-carrying cryptographer to go over the key-handling and the
cryptographic operations, before you try to standardize anything
involving a cryptographic algorithm.

Do it right, there are no workable shortcuts in crypto.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Tuesday, 6 March 2012 00:19:12 UTC