Re: Curve25519/448 key agreement for SSH

Simon Josefsson <[email protected]> Tue, 10 Nov 2015 14:08:22 +0100

Newsgroups	gmane.ietf.secsh
Message-ID	<[email protected]>

Damien Miller <[email protected]> writes:

> On Tue, 10 Nov 2015, Simon Josefsson wrote:
>
>> Damien Miller <[email protected]> writes:
>> 
>> >>    the number X are then converted into a big integer k.  This
>> >>    conversion follows the network byte order.  This step differs from
>> >>    [RFC5656].
>> >
>> > Maybe "converted into a big integer k by treating the value X as an
>> > unsigned, network-byte order integer".
>>
>> For Curve448, it appears to lead to 56 byte bigint or sometimes (when
>> msb is 1) a 57 byte bigint with leading zero. Is this a problem? If
>> somebody could observe the size difference, it would leak the MSB. If
>> worth resolving, how to resolve it?
>
> 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.

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.

/Simon

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