Re: Curve25519/448 key agreement for SSH

[Damien Miller <djm%mindrot.org@localhost>]

On Tue, 10 Nov 2015, Simon Josefsson wrote:

> Damien Miller <djm%mindrot.org@localhost> 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 curve25519-sha256%libssh.org@localhost protocol: OpenSSH at
least checks for correct zero-padding for mpints with the MSB set.

When OpenSSH first added curve25519-sha256%libssh.org@localhost, I accidentally
messed up this padding and it would cause ~1/128 connections to libssh
to fail :/

IMO it's probably not worth fixing this now; the other kex protocols
have the same problem, and the shared secret is never sent on the wire.

-d