Damien Miller <djm%mindrot.org@localhost> writes: > 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. 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 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. /Simon
Attachment:
signature.asc
Description: PGP signature