Re: Curve25519/448 key agreement for SSH
denis bider <[email protected]>
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <[email protected]> |
Regarding the check, it seems to me that SSH has an advantage over TLS, in that it includes hashes of negotiation content in the key exchange. Therefore, perhaps SSH is not as vulnerable to attacks of this type (such as the Triple Handshake attack in TLS). It still seems a better practice to check than not to check, though, just in case foresight is not 20/20. Surely, if the value is zero, the other party is sabotaging the key exchange (chances of this occurring randomly are astronomically close to zero). If the other party is sabotaging key exchange, it's doing this for some reason. I'm not sure that we need to know the reason in order to refuse to cooperate. ----- Original Message ----- From: Simon Josefsson Sent: Wednesday, November 18, 2015 14:39 To: [email protected] Subject: Re: Curve25519/448 key agreement for SSH This is another update, clarifying the encoding issue a bit further and improving language (thank you Denis). https://tools.ietf.org/html/draft-josefsson-ssh-curves-02 A discussion on CFRG came up recently about checking for the all-zero shared secret. Does anyone know if libssh or OpenSSH (or anyone else) performs this check? Not doing that has apparently led to real security problems. For more background, see: http://thread.gmane.org/gmane.ietf.irtf.cfrg/6228 Thoughts on whether we should add a MUST to require checking the derived secret for the all-zero value? /Simon