- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Thu, 3 Sep 2015 21:48:38 +0200
- To: Ian Hickson <ian@hixie.ch>
- Cc: WHATWG <whatwg@whatwg.org>, Philip Jägenstedt <philipj@opera.com>, "henry.story@bblfish.net" <henry.story@bblfish.net>
On 3 September 2015 at 21:27, Ian Hickson <ian@hixie.ch> wrote: > On Thu, 3 Sep 2015, Melvin Carvalho wrote: > > > > > > The post foolip pointed to points out that <keygen> is actually rather > > > insecure (e.g. using MD5). One could argue that _keeping_ <keygen> is > > > actually more harmful to asymetric-key cryptography than removing > > > it... > > > > Im not an expert here, but my understanding from reading some wikipedia > > articles was that a preimage attack on md5 was 2^123. If so, isnt that > > pretty secure? I asked on the blink thread why md5 was thought to be > > insecure, but no one was able to answer, or point to a reference. It > > would be great to understand if there is a feasible attack here. > > Wikipedia's article on MD5 is pretty comprehensive: > > https://en.wikipedia.org/wiki/MD5 Thanks, I have tried to work out the attack from this article, but still dont see how it applies to KEYGEN. The private key never leaves the browser. All that is (optionally) sent to a server is a signed challenge. Using the randomchars field I think was designed to prevent the kind of attack that I think people are imagining. As yet, no one has actually *said* what the attack is. I am assuming people are trying to derive a private key from a signature and public key. It strikes me that this is impossible, even if dealing with a malicious server. But I'd like to understand if this is not the case. > > > > > Looking at: > > > > SignedPublicKeyAndChallenge ::= SEQUENCE { > > publicKeyAndChallenge PublicKeyAndChallenge > > < > http://www.w3.org/html/wg/drafts/html/master/semantics.html#publickeyandchallenge > >, > > signatureAlgorithm AlgorithmIdentifier, > > signature BIT STRING > > } > > > > > > > http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-keygen-element > > That's the W3C's fork of the specification. The relevant spec for this > mailing list is: > > https://html.spec.whatwg.org/multipage/#the-keygen-element > > I wouldn't use the W3C's fork for discussions here because the W3C version > has many subtle differences and it can cause us great confusion when > discussing these issues. > OK, thanks! > > > > There appears to be a field signatureAlgorithm. Does that not suggest > > that switching away from MD5 is future proofed? > > In principle <keygen> itself could have new signature algorithms added. > This of course wouldn't be backwards compatible (in that it wouldn't be > supported by legacy UAs or legacy servers), so it would be no different > than introducing an entirely new feature that didn't suffer from all the > other problems that <keygen> suffers from. > > This is somewhat academic, though. When there are no browser vendors > supporting a particular feature, arguing about how it could be improved > misses the point. That's why we added a warning to the spec. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Thursday, 3 September 2015 19:49:05 UTC