8 ms·

I am not saying that as a defense of Tox. More as a question. Why is KCI a vulnerability? Yes, I understand that the situation is reverse from a normal crypto;

by runn1ng 10y ago

I am not saying that as a defense of Tox. More as a question. 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".

lvh 10y ago
"Screwed" is not a binary thing. Key compromise is not an unrealistic scenario, here are a lot of things that can happen as a consequence. How bad the consequences are matters. 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.
- runn1ng 10y ago
  Thanks for a nice explanation. But I still can't see the functional difference between > "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 :)
  - lvh 10y ago
    It's not a tradeoff, so I don't think there needs to be a hierarchy. You either have that vulnerability or you don't. It gives the attacker significantly more power (instead of only being able to impersonate one person, they get to impersonate an infinitude of them), and there is no downside to preventing the attack.
    - runn1ng 10y ago
      Ooooooh. Now I understand how you mean it. Great.
    - makomk 10y ago
      By design, Tox uses NaCl rather than implementing its own crypto, largely due to all the scary warnings from the crypto community about using NaCl rather than implementing your own crypto. It appears to be impossible to prevent this without abandoning NaCl and doing your own crypto. The supposedly misuse-resistant library that experts have been telling everyone who'll listen to use seems to inevitably create KCI vulnerabilities, and everyone's blaming the people who listened.
      - lvh 10y ago
        You made the same point on GitHub, so I'm unsurprisingly going to give the same answer here :) 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. For example, this clearly states that you're responsible for hashing group elements, which ostensibly the Tox AKE does not do. If you build an AKE, there are other documented aspects of Curve25519 to consider; for example, some AKE protocols require contributory behavior, which means that in Curve25519 you're (exceptionally) required to consider representations of points of low order (see https://cr.yp.to/ecdh.html https://cr.yp.to/ecdh.html). 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.
- grayhatter 10y ago
  With a reused nonce: can you reverse the key used? Decrypt that packet? All the packets with that nonce? All packets?
  - lvh 10y ago
    In the specific case of GCM: you can trivially recover the authentication key, and you can (in realistic circumstances) decrypt the messages for which the once was repeated. That, in turn, means you can recover the keystream for that nonce, key pair, meaning if the peer accepts new messages with the repeated nonce (realistic), you can forge arbitrary messages of the same length of shorter than the longest ciphertext for which the nonce repeated.
    - runn1ng 10y ago
      How cryptographically tested is GCM-SIV? Can it be used today, with the most common crypto-suites? Should it be used?
      - lvh 10y ago
        The authors don't suggest using it for anything. There is at least one more NMR (nonce misuse resistant) cipher in the current round of the CAESAR competition, AEZ. I have my own one built on top of libsodium primitives, called magicnonce. I don't think any of them are sufficiently well-vetted for you to start considering them for general purpose use right now. If you're bothered by nonce reuse, consider a different primitive. While libsodium's secretbox also has serious nonce reuse problems, it doesn't really matter because you can just select it at random.
tptacek 10y ago
"I'm locked out of prod VPN. Can you shoot me a copy of your key pair over secure messenger? We're encrypted and verified, so it should be fine." 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.

by runn1ng 10y ago

lvh 10y ago

"Screwed" is not a binary thing. Key compromise is not an unrealistic scenario, here are a lot of things that can happen as a consequence. How bad the consequences are matters. 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.

runn1ng 10y ago
Thanks for a nice explanation. But I still can't see the functional difference between > "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 :)
- lvh 10y ago
  It's not a tradeoff, so I don't think there needs to be a hierarchy. You either have that vulnerability or you don't. It gives the attacker significantly more power (instead of only being able to impersonate one person, they get to impersonate an infinitude of them), and there is no downside to preventing the attack.
  - runn1ng 10y ago
    Ooooooh. Now I understand how you mean it. Great.
  - makomk 10y ago
    By design, Tox uses NaCl rather than implementing its own crypto, largely due to all the scary warnings from the crypto community about using NaCl rather than implementing your own crypto. It appears to be impossible to prevent this without abandoning NaCl and doing your own crypto. The supposedly misuse-resistant library that experts have been telling everyone who'll listen to use seems to inevitably create KCI vulnerabilities, and everyone's blaming the people who listened.
    - lvh 10y ago
      You made the same point on GitHub, so I'm unsurprisingly going to give the same answer here :) 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. For example, this clearly states that you're responsible for hashing group elements, which ostensibly the Tox AKE does not do. If you build an AKE, there are other documented aspects of Curve25519 to consider; for example, some AKE protocols require contributory behavior, which means that in Curve25519 you're (exceptionally) required to consider representations of points of low order (see https://cr.yp.to/ecdh.html https://cr.yp.to/ecdh.html). 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.
grayhatter 10y ago
With a reused nonce: can you reverse the key used? Decrypt that packet? All the packets with that nonce? All packets?
- lvh 10y ago
  In the specific case of GCM: you can trivially recover the authentication key, and you can (in realistic circumstances) decrypt the messages for which the once was repeated. That, in turn, means you can recover the keystream for that nonce, key pair, meaning if the peer accepts new messages with the repeated nonce (realistic), you can forge arbitrary messages of the same length of shorter than the longest ciphertext for which the nonce repeated.
  - runn1ng 10y ago
    How cryptographically tested is GCM-SIV? Can it be used today, with the most common crypto-suites? Should it be used?
    - lvh 10y ago
      The authors don't suggest using it for anything. There is at least one more NMR (nonce misuse resistant) cipher in the current round of the CAESAR competition, AEZ. I have my own one built on top of libsodium primitives, called magicnonce. I don't think any of them are sufficiently well-vetted for you to start considering them for general purpose use right now. If you're bothered by nonce reuse, consider a different primitive. While libsodium's secretbox also has serious nonce reuse problems, it doesn't really matter because you can just select it at random.

tptacek 10y ago

"I'm locked out of prod VPN. Can you shoot me a copy of your key pair over secure messenger? We're encrypted and verified, so it should be fine." 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.