Why is KCI a vulnerability? Yes, I understand that the situation is reverse from a normal crypto; but still, when your keys are stolen, you are screwed anyway, your messages can be forged, it can lead to MITM, ...
How is that fundamentally so different from KCI. When someone steals your keys, security doesn't apply anymore; how can a threat model include "but what if someone steals the private keys".
Let me illustrate by examples:
Instead of KCI, consider forward secrecy. As long as the secret key is maintained forever, you don't care about forward secrecy. However, we generally agree that forward secrecy is a desirable property. If key compromise doesn't matter, why does Tox bother to get forward secrecy? Because the outcome of key compromise matters.
Instead of GCM, consider with something like CBC+HMAC-SHA256 and GCM-SIV or HS1. All take some added data per encryption in addition to a key: either a nonce or an IV. In the case of GCM, a nonce being reused is catastrophic failure: trivial forgeries and quite probably ciphertext decryption. With the other ciphersuites, there is some other failure, but nowhere near as bad. Yes, you shouldn't have repeated the nonce, but the problem is that that happens, and the question is how screwed you are when it does. Why do we care about NMR crypto? Because the outcome of nonce reuse matters.
KCI is just another example. Yes, it only matters when something has gone wrong. But there is a functional difference between "the attacker gets to impersonate me" and "the attacker can pretend to be anyone to me" (KCI), just like there's a difference between "the attacker can impersonate me" and "the attacker can decrypt all communications, past and present" (PFS).
Just like PFS, not having KCI-resistance as a property is a choice. There is no downside to having it. So, it is as much of a vuln as not having PFS would be.
> "the attacker gets to impersonate me" and "the attacker can pretend to be anyone to me" (KCI)
Both seem similarly catastrophic to me in a real life scenario. I cannot imagine a scenario when one is OK and one isn't. I don't see the hierarchy.
Also, thanks a lot for mentioning GCM-SIV to me! I like GCM, but the nonce reuse is scary :)
Protocols aren't primitives. Secure primitives certainly do not imply secure protocols (Example: AES is a secure block cipher, but AES-ECB is clearly not a secure way to encrypt messages). Secure protocols mostly imply secure primitives. (Counterexample: a protocol using HMAC-MD5 doesn't have forgery issues even though MD5 is not a secure hash function.)
There are several levels of "homebrew" of "roll-your-own" cryptography:
- Designing your own block ciphers or hash functions. - Designing your own compositions of primitives, like AE or MAC. - Designing your own protocols, like TLS or Noise.
This vulnerability exists on that third level. As a consequence, this isn't a repudiation of NaCl or libsodium. They're excellent libraries. Curve25519 is a DH primitive, and there's no DH vulnerability here. The problem is that it's not an AKE, and that's what you're using it as. The docs clearly enumerate what it does and does not do:
Security model
crypto_scalarmult is designed to be strong as a component of various
well-known "hashed Diffie–Hellman" applications. In particular, it is
designed to make the "computational Diffie–Hellman" problem (CDH) difficult
with respect to the standard base.
crypto_scalarmult is also designed to make CDH difficult with respect to
other nontrivial bases. In particular, if a represented group element has
small order, then it is annihilated by all represented scalars. This feature
allows protocols to avoid validating membership in the subgroup generated by
the standard base.
NaCl does not make any promises regarding the "decisional Diffie–Hellman"
problem (DDH), the "static Diffie–Hellman" problem (SDH), etc. Users are
responsible for hashing group elements.
The claim that libsodium doesn't give you the tools to produce a secure AKE is incorrect. Firstly, you can do a traditional signing key exchanges. Secondly, Noise is a proof from construction; there are implementations of the Noise protocol available on the site, and you'll see that it defines a KCI-secure AKE that you can implement using nothing but NaCl/libsodium.
Finally, as much as I try to draw this conversation away from individuals and towards technical discussion, I hope you'll find that I've tried pretty hard both here and in general to provide constructive contributions, and trying to educate those who'll listen. And, I tell people to consult a cryptographer, although you could do a lot worse than NaCl as a set of solid primitives :)
If a chainsaw does a bad job of cutting an apple, it's not a bad chainsaw.
https://nacl.cr.yp.to/box.html and I assume the relevant quote is The crypto_box function is not meant to provide non-repudiation. On the contrary: the crypto_box function guarantees repudiability. A receiver can freely modify a boxed message, and therefore cannot convince third parties that this particular message came from the sender. The sender and receiver are nevertheless protected against forgeries by other parties. In the terminology of https://groups.google.com/group/sci.crypt/msg/ec5c18b23b11d8..., crypto_box uses "public-key authenticators" rather than "public-key signatures."
Users who want public verifiability (or receiver-assisted public verifiability) should instead use signatures (or signcryption). Signature support is a high priority for NaCl; a signature API will be described in subsequent NaCl documentation.
If people want to discuss security, I'm game. But given the amount of energy I've spent removing the discussion from individuals and bringing it back to technology, I do not have to put up with having a bunch of accusations leveled at me.
The attacker in this scenario not only gets access to message plaintext but can also cause messages to be generated that wouldn't ordinarily be sent.