4 ms·

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

by 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.
    - makomk 10y ago
      The scary warnings from cryptographers specifically pointed people at NaCl's high-level APIs like crypto_box and warned of the dangers of rolling your own compositions of primitives. You can do that just as well or badly with almost any major crypto library, but the point of the NaCl advocacy was to steer inexperienced people away from that towards higher-level constructions. So that's what the Tox developers did: they used the high-level, safe, supposedly misuse resistant crypto_box API's implementation of public-key authenticated encryption. And it blew up in their faces, and then you accused them of incompetently rolling their own crypto because, essentially, they didn't roll their own crypto and the pre-baked version turned out to be horrifically unsuitable for actual use. They do not use crypto_scalarmult directly anywhere, and stuff like hashing group elements is done however DJB felt appropriate when he was writing the high-level composition of primitives.
      - detaro 10y ago
        For context for other readers: https://nacl.cr.yp.to/box.html 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/ec5c18b23b11d82c 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.
      - lvh 10y ago
        You appear to be repeating your argument almost verbatim. I've gone into detail why this doesn't hold. Furthermore, I think you'll find I did not accuse anyone of incompetence, I have merely been explaining the issue repeatedly and in detail kindly and courteously. I refuse to take responsibility for what other people say, and I have continuously and repeatedly offered my services, for free, and literally wrote a book and then gave it away for free. 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.

by runn1ng 10y ago

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.
  - makomk 10y ago
    The scary warnings from cryptographers specifically pointed people at NaCl's high-level APIs like crypto_box and warned of the dangers of rolling your own compositions of primitives. You can do that just as well or badly with almost any major crypto library, but the point of the NaCl advocacy was to steer inexperienced people away from that towards higher-level constructions. So that's what the Tox developers did: they used the high-level, safe, supposedly misuse resistant crypto_box API's implementation of public-key authenticated encryption. And it blew up in their faces, and then you accused them of incompetently rolling their own crypto because, essentially, they didn't roll their own crypto and the pre-baked version turned out to be horrifically unsuitable for actual use. They do not use crypto_scalarmult directly anywhere, and stuff like hashing group elements is done however DJB felt appropriate when he was writing the high-level composition of primitives.
    - detaro 10y ago
      For context for other readers: https://nacl.cr.yp.to/box.html 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/ec5c18b23b11d82c 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.
    - lvh 10y ago
      You appear to be repeating your argument almost verbatim. I've gone into detail why this doesn't hold. Furthermore, I think you'll find I did not accuse anyone of incompetence, I have merely been explaining the issue repeatedly and in detail kindly and courteously. I refuse to take responsibility for what other people say, and I have continuously and repeatedly offered my services, for free, and literally wrote a book and then gave it away for free. 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.