On Feb 19, 2015 12:19 PM, "Michael Scott" <<a href="mailto:mike.scott@certivox.com">mike.scott@certivox.com</a>> wrote: > > "I think they're assuming that the next-layer protocol is insecure and > reveals the session key, eg by a timing attack. They're also assuming > that the session key is not hashed at all, and is used in raw EC point > form. They give a formula to break the password right in the paper on > pages 1-2. So you should hash the DH output." > > And that's where I get stuck. I think its actually perfectly fine to use the raw EC point form as a session key, if that's what you want to do, and therefore there is absolutely no need to hash the DH output. > > First assume that the attacker can launch a timing attack against both Alice and Bob, and determine their session keys(as required to apply the formula). Then the attacker can simply use this same talent every time to access their keys, hashed or not, and passively eavesdrop their communication. No need to go after the password. So if the next-layer protocol is insecure we are broken anyway. Its kinda like saying that if we are broken, then we are broken. > > However I do see that hashing effectively firewalls the PAK protocol from the failings of the next layer. In particular if the next layer gives up its session keys, there is no reason that that should reveal the PAK password. But I would maintain that the PAK protocol itself does not require hashing. > > And for this particular attack to have any significance we have to assume that it is not so easy (despite what the authors claim), and that it won't work every time, but it will work at least once, which would be enough to find the password using the "formula". However I think such an attack is in fact impractical. Launch timing or other side channel attacks against both Alice and Bob simultaneously? Get them to encrypt lots of data (enough for a side-channel attack) and transmit it to each-other without noticing that the incoming data decrypts as garbage? I don't think so. > > Therefore the rest of the paper is predicated on a false assumption. There is no "easy" attack. > > The dubious added value from hashing the DH output may in fact be outweighed by the extra complexity introduced by using hash functions. > > But I think you are right. Hashing is just an artefact introduced to get a security proof (as long as you are happy with random oracles). However I would suggest that such a simple protocol hardly needs one, given the amount of scrutiny it has had. > > BTW I would of course hash the EC point along with every other protocol value I could think of, but only on the basis that it does no harm, and you end up with something from which its easier to extract session keys. > > Thanks for the insight into what "they" were thinking. Read the literature on UC and you will find plenty of simple protocols that compose in unexpected ways. To prevent this we use security definitions that modularize protocol design so that an analyst doesn't have to understand the entire design at once but rather each piece in isolation. Sincerely, Watson Ladd > > Mike > > > > _______________________________________________ > Curves mailing list ><a href="mailto:Curves@moderncrypto.org">Curves@moderncrypto.org</a> ><a href="https://moderncrypto.org/mailman/listinfo/curves">https://moderncrypto.org/mailman/listinfo/curves</a> >