Re: http+aes

On Tue, 6 Mar 2012, Poul-Henning Kamp wrote:
> 
> 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.

It's not intended that users even know this is being used, so it doesn't 
really matter if they don't understand it.


> 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.

This is not intended for a situation where you do not trust the 
recipients, indeed. There's not really any credible way to give someone 
content that isn't watermarked in some way if you don't trust them. If the 
content _is_ watermarked, then you probably can't usefully cache it in a 
CDN. If you can, then you can do so with this mechanism as well, it's an 
orthogonal concern.


> 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.

Let's be honest, most users have no idea what crypto is, let alone that it 
is there. Even things as critical as TLS as used for HTTPS -- most users 
don't really know what's going on. If we're going to rely on users 
understanding crypto, we might as well give up now.


> 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.

In practice, a CDN would not keep its business if it was damaging the 
content it was caching. This is a substantially different risk than the 
CDN (or a rogue agent within the CDN) just copying the content.

There's no reason this mechanism couldn't be used with other generic 
integrity checking mechanisms, though.


> 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.

This isn't my first barbecue either.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 6 March 2012 01:26:51 UTC