Damien Miller <djm%mindrot.org@localhost> writes: > 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. Ah, right. The shared secret is never encoded on the wire though, but I suppose the same concern applies internally before hashing. >> 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. To change K from mpint to string we would need to update RFC 5656. I now believe we should describe what libssh/OpenSSH implements, and add a security consideration around a potential secret MSB side-channel leak caused by the length difference. /Simon
Attachment:
signature.asc
Description: PGP signature