Re: Javascript Cryptography Considered Harmful

On Sep 22, 2011, at 11:05 AM, David Dahl wrote:

> 
> 
> ----- Original Message -----
>> From: "John Kemp" <john@jkemp.net>
>> To: "David Dahl" <ddahl@mozilla.com>
>> Cc: "Henry Story" <henry.story@bblfish.net>, public-identity@w3.org
>> Sent: Wednesday, September 21, 2011 9:33:35 PM
>> Is the private key private to the client or to origin A? Is the server
>> merely instructing the client on which key (generated based on
>> instruction from the server) to use when encrypting data sent to its
>> own origin? In other words is the server asking the client to use
>> origin A's key to encrypt data from the client to origin A?
>> 
> 
> The private keys are always private to the client for the origin per origin.

OK - so in this case it is slightly different than SSL/TLS (without client-cert auth) in that the client (not the server) has the private key.

> For every site you use with DOMCrypt you will have a unique set of keys. The script has no access to them. The only time you handle any kind of key material is when the keypair is created, and even then you are only handed back the public key.
> 
>> I think the gist of the Matasano blog post (this is my interpretation
>> anyway) is that you can given them (Javascript developers) these
>> things and it doesn't solve the essential problem of trust between
>> client and server. In other words, it is still possible for an MITM to
>> make the client believe it is interacting with a trustworthy entity,
>> in which case, the encryption part itself is very much less useful.
>> Or, at least, it is no more useful than SSL/TLS.
> 
> Indeed. DOMCrypt is not a solution guaranteeing trust between browsers and web servers. That is a non-goal.

As mentioned, I think the point of the Matasano blog post is that some false sense of security will be given that because we suddenly have Javascript crypto, we can solve some problem in Web security that is not already solved by SSL/TLS encryption (and I think the post hints that this problem is related to MITM attacks - for which encryption *should* be useful - right?) 

What I am still struggling to understand is the set of problems that are solved by JS crypto that are not already solved by SSL/TLS? One item seems to be that the client could now encrypt data separate from the act of "authentication" via an SSL/TLS client certificate?

MITM with an attacker is (as both you and Dave Raggett have mentioned) conspicuously not solved by these proposals. I do think it would be "dangerous" for anyone to assume that it was. 

- John

> 
> Cheers,
> 
> David
>

Received on Thursday, 22 September 2011 15:37:53 UTC