Re: Curve25519/448 key agreement for SSH

Simon Josefsson <[email protected]> Thu, 12 Nov 2015 10:17:36 +0100
Newsgroups	gmane.ietf.secsh
Message-ID	<[email protected]>
denis bider <[email protected]> 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 <[email protected]> , 11/12/2015 8:50 AM:
> denis bider <[email protected]> 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
signature.asc (application/pgp-signature, 472 B)