Re: Curve25519/448 key agreement for SSH

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

On Tue, 10 Nov 2015, Simon Josefsson wrote:

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

> I believe this document should document exactly what
> curve25519-sha256%libssh.org@localhost 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
curve25519-sha256%libssh.org@localhost 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.

-d