Subject: RE: Curve25519/448 key agreement for SSH

From: denis bider <[email-masked]>
Date: Tue, 10 Nov 2015 06:12:05 +0000

Simon, Aris -

thank you for this work. I plan to be implementing this soon, and I appreciate that you're moving ahead with standardization.

With respect to conversion of the binary string X into mpint K, is there a chance that X might have its high bit set?

If it's possible for the high bit to be set, it seems you ought to clarify how that's converted into mpint, given that mpint is signed:

https://www.ietf.org/rfc/rfc4251.txt
      Represents multiple precision integers in two's complement format,
      stored as a string, 8 bits per byte, MSB first.  Negative numbers
      have the value 1 as the most significant bit of the first byte of
      the data partition.  If the most significant bit would be set for
      a positive number, the number MUST be preceded by a zero byte.Besides that, I'm noticing the language could use improvement in places ("this document re-use" -> "this document reuses", "is is" -> "is").

Overall, thank you for moving forward with this, though.

----- Original Message -----
From: Simon Josefsson 
Sent: Monday, November 9, 2015 09:07
To: [email-masked] 
Subject: Curve25519/448 key agreement for SSH

Aris and me have prepared a document describing key agreement using the
CFRG curves for Secure Shell.  As you know, [email-masked]
is already implemented by libssh, OpenSSH, Dropbear, and some others.
This is about putting the description of that into IETF format, and to
add the Curve448 hedge variant chosen by CFRG.  It might not be detailed
enough for independent implementation, but we hope to get there.  Any
review and feedback is welcome.

https://tools.ietf.org/html/draft-josefsson-ssh-curves

/Simon

PS. There is https://tools.ietf.org/html/draft-bjh21-ssh-ed25519 but
that talks about Ed25519 signatures.  The document above is about key
agreement.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Nov 2015 10:30:37 +0100

denis bider <[email-masked]> writes:

> Simon, Aris -
>
> thank you for this work. I plan to be implementing this soon, and I
> appreciate that you're moving ahead with standardization.

Hi Denis.  Excellent!  It would be perfect if someone would attempt
implementation based on this document (and cfrg-curves) and tell us what
is missing, and what could have helped them implement it more quickly.

> With respect to conversion of the binary string X into mpint K, is
> there a chance that X might have its high bit set?
>
> If it's possible for the high bit to be set, it seems you ought to
> clarify how that's converted into mpint, given that mpint is signed:
>

>       a positive number, the number MUST be preceded by a zero byte.

Good point, I believe the document has to discuss the mapping between
binary Curve25519/Curve448 binary strings into mpint's.

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.

For Curve25519 the most-significant bit is always zero though, so this
will never happen.  For Curve448 this seems like a problem.  Is it okay
to prepend a zero byte in SSH big integers even if one is not necessary?
Then a simple approach would be to do nothing for Curve2559 and to
always add a zero byte for Curve448.

> Besides that, I'm noticing the language could use improvement in
> places ("this document re-use" -> "this document reuses", "is is" ->
> "is").

Fixed, thank you.

/Simon

---

From: [email-masked] (Niels Möller)
Date: Fri, 13 Nov 2015 06:25:00 +0100

> byte.  However, the length difference would leak that information.

Note that it's also possible to use some slightly different mapping than
for mpints. Like it's been done in the dsa signature blob since ages;
there the integers are always coded as 20-byte values, no sign bit, and
no normalization if some value happens to get a zero high byte. 

I'm not sure I like that departure from mpint, but I'd like to point out
that it's a possibilty and it's been done before.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.