Re: Curve25519/448 key agreement for SSH

[denis bider <ietf-ssh3%denisbider.com@localhost>]

> 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.  

I agree, but it does seem like it would really require re-specifying K to be a "string", and just for these particular algorithms.

With regard to compatibility - if there's a standardized name, then for use in Bitvise SSH Server and Client, I am almost certainly going to implement only the standardized name. Folks who care highly about these algorithms are probably not going to have second thoughts about using the latest versions of their software.

Folks who use older versions are typically people who don't care about CBC until it comes up in a security scan... At which point they grudgingly consider upgrading their 10 year old version. :)


----- Original Message -----
From: Simon Josefsson 
Sent: Thursday, November 12, 2015 03:17
To: denis bider 
Cc: ietf-ssh%netbsd.org@localhost ; djm%mindrot.org@localhost 
Subject: Re: Curve25519/448 key agreement for SSH

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