<div dir="ltr"><div><font color="#500050">"I think they're assuming that the next-layer protocol is insecure and<br> reveals the session key, eg by a timing attack.  They're also assuming<br> that the session key is not hashed at all, and is used in raw EC point<br> form.  They give a formula to break the password right in the paper on<br> pages 1-2.  So you should hash the DH output."</font></div><div><font color="#500050"><br></font></div><div><font color="#500050">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. </font></div><div><font color="#500050"><br></font></div><div><font color="#500050">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.</font></div><div><font color="#500050"><br></font></div><div><font color="#500050">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.</font></div><div><font color="#500050"><br></font></div><div><font color="#500050">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.</font></div><div><font color="#500050"><br></font></div><div><font color="#500050">Therefore the rest of the paper is predicated on a false assumption. There is no "easy" attack. </font></div><div><font color="#500050"><br></font></div><div><font color="#500050">The dubious added value from hashing the DH output may in fact be outweighed by the extra complexity introduced by using hash functions. </font></div><div><font color="#500050"><br></font></div><div><font color="#500050">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.</font></div><div><font color="#500050"><br></font></div><div><font color="#500050">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.</font></div><div><font color="#500050"><br></font></div><div><font color="#500050">Thanks for the insight into what "they" were thinking.</font></div><div><br></div><font color="#500050"><p>Mike</p><p><br></p></font></div>