tomaswolf commented on pull request #177: URL: https://github.com/apache/mina-sshd/pull/177#issuecomment-962516623
> If our key (encode()) has the most significant bit set, they close the connection. > > If their key (decode()) has the most significant bit set, we fail to verify their signature. Got it. This is caused by a subtle difference in the DH key exchange. * [RFC 4253](https://datatracker.ietf.org/doc/html/rfc4253#page-22): e and f are written as mpint (so prefixed by a zero byte if the high bit is set). * [RFC 5656](https://datatracker.ietf.org/doc/html/rfc5656#page-9): Q_C and Q_S, which take the place of e and f, are written as octet strings, hence _not_ prefixed with a zero byte, even if the high bit is set. That explains it: Apache MINA sshd implements RFC 4253, but not the modifications for ECDH/XDH from RFC 5656. * when our key has the high bit set, we send 33 bytes, and the server disconnects because that's invalid. * when their key (or our key) has the high bit set, we add extra zero bytes to the data the signature hash is computed over, and thus signature verification always fails. * if neither key has the high bit set, all is fine. The difference is pointed out in [RFC 8731](https://datatracker.ietf.org/doc/html/rfc8731#section-3): > The key exchange procedure is similar to the ECDH method described in Section 4 of [RFC5656], though with a different wire encoding used for public values and the final shared secret. Public ephemeral keys are encoded for transmission as standard SSH strings. RFC 8731, section 3.1, then explains that the shared secret (32 bytes for x25519) is always interpreted as unsigned. (But according to RFC 5656, it's still written as mpint.) Our code writes it as mpint, which prefixes a zero byte if the high bit is set, so that should be fine. With this fixed, KEX using curve25519 works against both the Github and Gitlab daemons. @jvz, is it OK if I push a rebase + follow-up change onto this PR? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
