4 ms·

I don't see anything in the code that would stop someone from using 0 as a public key for a x25519 handshake.

dchest 10y ago
To add more: Not only 0, but also some other keys listed here https://cr.yp.to/ecdh.html https://cr.yp.to/ecdh.html which produce all-zero shared key. DJB argues you shouldn't validate public keys except for "some unusual non-Diffie-Hellman elliptic-curve protocols that need to ensure ``contributory'' behavior". So NaCl/TweetNaCl also don't do anything about it. Libsodium, on the other hand, returns an indicator when the shared key is all-zero. One recent example where it was considered a ("low") vulnerability is in the recent wire audit: https://www.x41-dsec.de/reports/Kudelski-X41-Wire-Report-phase1-20170208.pdf https://www.x41-dsec.de/reports/Kudelski-X41-Wire-Report-pha... Therefore, if Bob sends all-zero ratchet public keys, subsequent message keys will only depend on the root key and not on Alice’s ephemeral private keys. A dishonest peer may therefore keep sending degenerate keys in order to reduce break-in recovery guarantees, or force all sessions initiated by a third party to use a same message key, while a network attacker may force the first message keys to a public constant value, for example.
- loup-vaillant 10y ago
  Crap, this is more severe than I anticipated. I'll think about it, and probably change the code and API. That's said, I don't understand why DJB says this is unnecessary for Diffie-Hellman? I mean, an all-zero shared secret sounds pretty bad, doesn't it? Or is it because DJB assumes that if one party decides to publish the communication, it can do so anyway?
  - lvh 10y ago
    Not all AKEs require contributory behavior to guarantee their security properties, but many do. Your suggestion is pretty close to why; if you're using plain scalarmult as opposed to an AKE with fancier properties (say, 3DH, HMQV...) in the context of e.g. box, it's the sender that picks public keys anyway, so they don't care. In the context of most transport encryption, you presumably do want to prevent those keys from being selected by either party. That means either filtering those keys, or, perhaps better, using a fancier AKE like the 3DH in Signal/Noise or HMQV or something.

To add more: Not only 0, but also some other keys listed here https://cr.yp.to/ecdh.html https://cr.yp.to/ecdh.html which produce all-zero shared key. DJB argues you shouldn't validate public keys except for "some unusual non-Diffie-Hellman elliptic-curve protocols that need to ensure ``contributory'' behavior". So NaCl/TweetNaCl also don't do anything about it. Libsodium, on the other hand, returns an indicator when the shared key is all-zero. One recent example where it was considered a ("low") vulnerability is in the recent wire audit: https://www.x41-dsec.de/reports/Kudelski-X41-Wire-Report-phase1-20170208.pdf https://www.x41-dsec.de/reports/Kudelski-X41-Wire-Report-pha... Therefore, if Bob sends all-zero ratchet public keys, subsequent message keys will only depend on the root key and not on Alice’s ephemeral private keys. A dishonest peer may therefore keep sending degenerate keys in order to reduce break-in recovery guarantees, or force all sessions initiated by a third party to use a same message key, while a network attacker may force the first message keys to a public constant value, for example.

loup-vaillant 10y ago
Crap, this is more severe than I anticipated. I'll think about it, and probably change the code and API. That's said, I don't understand why DJB says this is unnecessary for Diffie-Hellman? I mean, an all-zero shared secret sounds pretty bad, doesn't it? Or is it because DJB assumes that if one party decides to publish the communication, it can do so anyway?
- lvh 10y ago
  Not all AKEs require contributory behavior to guarantee their security properties, but many do. Your suggestion is pretty close to why; if you're using plain scalarmult as opposed to an AKE with fancier properties (say, 3DH, HMQV...) in the context of e.g. box, it's the sender that picks public keys anyway, so they don't care. In the context of most transport encryption, you presumably do want to prevent those keys from being selected by either party. That means either filtering those keys, or, perhaps better, using a fancier AKE like the 3DH in Signal/Noise or HMQV or something.