Re: Curve25519/448 key agreement for SSH

Simon Josefsson <[email protected]> Thu, 12 Nov 2015 09:45:46 +0100
Newsgroups	gmane.ietf.secsh
Message-ID	<[email protected]>
Damien Miller <[email protected]> writes:

> On Tue, 10 Nov 2015, Simon Josefsson wrote:
>
>> > AFAIK it might not be possible to resolve without being incompatible
>> > with the deployed [email protected] protocol: OpenSSH at
>> > least checks for correct zero-padding for mpints with the MSB set.
>> 
>> Curve25519 would never have the MSB set, if I understand correctly.  So
>> what is the potential for incompatibility?  Maybe I'm missing something.
>
> That's true of the public values, but not necessarily of the shared
> secret, right? I'd expect the shared secret to have the most
> significant bit set half the time.

Ah, right.  The shared secret is never encoded on the wire though, but I
suppose the same concern applies internally before hashing.

>> I believe this document should document exactly what
>> [email protected] does, otherwise things will be confusing.
>> Unless there is a significant mistake with it, of course, but then
>> people shouldn't be using it at all.
>> 
>> Nobody has implemented Curve448 for SSH so there is no compatibility to
>> think about there.  There has not been a lot of interest from
>> implementers in Curve448 either, since it is slower (no twisted curve).
>> The only argument I can think of for supporting it is that it hedges you
>> against potential new analytical ECC attacks that would affect
>> Curve25519.  But for this work, I believe including Curve448 makes sense
>> since it is what CFRG recommends.
>
> Changing the encoding means changing the exchange hash's last field
> from mpint to string. I argued for this when Aris sent the original
> [email protected] diff to OpenSSH, but didn't think of the
> possible MSB leakage and lost the argument :/
>
> Anyway, to summarise the arguments:
>
> For changing the encoding of K from mpint to string:
>
> - Avoids varying length of K encoding in exchange hash, unlikely leak
>   of MSB via timing channel
> - Easier to implement
>
> Against:
>
> - Inconsistency between curve25519 and curve448 K encoding
> - Inconsistency between curve448 and all the other KEX methods
>
> I honestly don't know whether it is worth fixing it. If I were writing
> SSH protocol v.3 then I'd remove mpints from the wire protocol entirely
> and have each protocol define a canonical string encoding for its
> values.

To change K from mpint to string we would need to update RFC 5656.

I now believe we should describe what libssh/OpenSSH implements, and add
a security consideration around a potential secret MSB side-channel leak
caused by the length difference.

/Simon
signature.asc (application/pgp-signature, 472 B)