denis bider <ietf-ssh3%denisbider.com@localhost> writes: > But X and K are different in each key exchange. The only way to make > them same would be for both parties to conspire. It doesn't matter if they are different -- a listening entity may be able to use a side channel (e.g., time) to infer wether the parties hashed X or X+1 bytes, which leaks one bit of the secret. > I have suggested solving this by reinterpreting X as an already > encoded K, which may be negative. Well - that has a different issue: > it violates mpint encoding when the first byte of X is zero... > > All things considered, I don't think it really matters which way this > is resolved. Just please make sure to be clear when you specify it. :) > An imprecise specification may lead to problems that manifest in > e.g. 1/256 of key exchanges. Yep. I don't care strongly about this point, but I do share your strong opinion that it has to be clearly specified. Right now I'm inclined to describe exactly what libssh/OpenSSH implements and describe the vulnerability. If implementers are interested in "fixing" this while we go through this process, we have that opportunity. There is no direct backwards compatibility problem to care about, since we are registering a new name. However, implementations will likely need to support both for quite some time, and having the two implementations differ has code maintenance costs. It seems Aris and Damien represent two significant implementations of this, so if they can agree on this, we have a way forward. /Simon > > Simon Josefsson <simon%josefsson.org@localhost> , 11/12/2015 8:50 AM: > denis bider <ietf-ssh3%denisbider.com@localhost> writes: > >> Simon - >> >> >>> A simple approach would be to say that if the MSB is 1, >>> prepend a zero byte. However, the length difference >>> would leak that information. >> >> The length difference might not be much of a problem, since K is never sent. > > It shouldn't be difficult to fingerprint (statistically, over many > connections) if a remote application performs a hash on X bytes or X+1 > bytes. Knowing which leaks the MSB of the derived secret. > > I'm inclined to add a security consideration describing this, and allow > for the potential of a nice conference paper describing how to exploit > this observation. At this point, to fix this (as Damien described) > appear less appealing. > > /Simon
Attachment:
signature.asc
Description: PGP signature