3 ms·

If you feel like throwing "newbie" accusations around, it'd be prudent to back your list of grievances up with more than a single link to crypto.cpp. Chances ar

by eps 5y ago

If you feel like throwing "newbie" accusations around, it'd be prudent to back your list of grievances up with more than a single link to crypto.cpp. Chances are you misread the code, didn't grok what the op was doing, etc. As it stands your comment reads like a common variety abrasive and dismissive gatekeeping... rant, basically, which is unfortunately so popular in crypto circles. Edit - the project does dearly need a crypto spec. "Uses state-of-the-art cryptography algorithm" claim begs to be described to be valid.

rvz 5y ago
> Edit - the project does dearly need a crypto spec. "Uses state-of-the-art cryptography algorithm" claim begs to be described to be valid. It does not need a spec. It just needs to put a small print on "algorithm" and mention that it is using a cryptography library called libsodium. That's it. As for the armchair field marshal cryptographers ranting around and nitpicking "useful projects", they are the same ones who praised Signal for their actual "state-of-the-art cryptography algorithm" for end-to-end encryption until they added a cryptocurrency coin in the messenger. Same with Keybase. At least this project does not have such frivolous features and is only using libsodium like everyone else. It is very easy to give "expert" criticism (constructive or not) on an open source project (since the project is transparent) but it is much harder for the critics to dive in and fix the aforementioned issues themselves. I would have much more respect for those who do both.
- 4684499 5y ago
  > on an open source project (since the project is transparent) Not as transparent since the mobile apps are closed source at the moment.
fulafel 5y ago
Well, it's about 2 screefuls of very simple code. Eg for the PK part, if you ctrl-f for publicKey and remotePublicKey, you see there are no usages that could plausibly be doing public key crypto or PK key generation based on crypto 101 from school. Not sure how to respond about gatekeeping. What do you think would be a good way to write a comment pointing out these kinds of security problems? Or do you think it's unfair to do it at all?
- opheliate 5y ago
  I’m not sure what you mean by there being no public key cryptography here. In the Crypto constructor, a random secret key is generated, and then the generator for Curve25519 is scalar multiplied on the elliptic curve by this secret key to generate a public key. That’s the standard process for X25519 key generation, and it’s what Libsodium does to generate a secret key/public key pair [1]. To establish a shared secret session key, the standard ECDH procedure is used, as seen in Crypto::setRemotePublicKey, where we multiply the other party’s public key by our secret key on curve25519 to establish a shared secret. This shared secret is then used for encryption, since symmetric encryption is generally cheaper + more secure than asymmetric. I absolutely agree that this project needs a more formal cryptographic approach, and should be using a higher level construct (e.g: crypto_secretstream, also from libsodium), but as far as I can tell at first glance, this is a working implementation of X25519. 1: https://github.com/jedisct1/libsodium/blob/7993f5ec5199b6637de6946d001a4e71c05f9ceb/src/libsodium/crypto_box/curve25519xsalsa20poly1305/box_curve25519xsalsa20poly1305.c#L26 https://github.com/jedisct1/libsodium/blob/7993f5ec5199b6637...
  - yvbbrjdr 5y ago
    The reason I "rolled my own" key exchange is that I'd want to use the IETF variant of Chacha20-Poly1305 in my protocol and there doesn't seem to be helper functions for key exchange for this algo.
    - opheliate 5y ago
      Unless I'm misunderstanding you, the crypto_secretstream construction [1] that I (and others) have recommended uses ChaCha20Poly1305-IETF as its symmetric cipher. There wouldn't be a key exchange for this algorithm, since it's symmetric. However, the crypto_kx functions [2] generate a 256 bit shared secret, which should work for a ChaCha20Poly1305 key I believe? 1: https://doc.libsodium.org/secret-key_cryptography/secretstream https://doc.libsodium.org/secret-key_cryptography/secretstre... 2: https://doc.libsodium.org/key_exchange https://doc.libsodium.org/key_exchange
      - 5y ago
dintech 5y ago
I read this as a genuine attempt to assist the developer and protect 3rd parties. If that's gate-keeping, we're in trouble as a society.
yvbbrjdr 5y ago
Will draft a crypto spec if I have time :)
api 5y ago
Crypto people: “programmers really need to get better at using crypto!” Also crypto people: “how DARE ye mere mortal even touch crypto!!!” This doesn’t help. The only people who will listen to “don’t roll your own crypto” are the very people who ought to be learning how to do it. The arrogant types who should never touch crypto will ignore this advice and still write bad crypto. The most effective thing would be to just tell programmers why crypto is hard in ways other code is not. Crypto is hard because you can’t simply unit test for vulnerabilities. “Anyone can write a crypto system they themselves can’t break.” For the majority of code it’s good code if it works and is fast and lacks things like memory safety bugs. For crypto it can work perfectly and still be grossly insecure. The only way to tell is to deeply understand cryptanalysis and do academic mathy stuff. As a result if you use crypto it’s best to write boring conservative crypto and use it the way pro cryptographers suggest. Try to use a peer reviewed library or if you can’t and must implement then try to ape a peer reviewed library exactly. Don’t even try to invent new stuff in crypto unless your understanding is very thorough and don’t use anything new without peer review. Edit: another example of abnormally hard code is distributed databases. They can be unit tested but adequately doing so is extremely difficult. It’s easy to write one that seems to work but loses data at scale or under edge case failure scenarios. Crypto is even worse.

by eps 5y ago

rvz 5y ago

> Edit - the project does dearly need a crypto spec. "Uses state-of-the-art cryptography algorithm" claim begs to be described to be valid. It does not need a spec. It just needs to put a small print on "algorithm" and mention that it is using a cryptography library called libsodium. That's it. As for the armchair field marshal cryptographers ranting around and nitpicking "useful projects", they are the same ones who praised Signal for their actual "state-of-the-art cryptography algorithm" for end-to-end encryption until they added a cryptocurrency coin in the messenger. Same with Keybase. At least this project does not have such frivolous features and is only using libsodium like everyone else. It is very easy to give "expert" criticism (constructive or not) on an open source project (since the project is transparent) but it is much harder for the critics to dive in and fix the aforementioned issues themselves. I would have much more respect for those who do both.

4684499 5y ago
> on an open source project (since the project is transparent) Not as transparent since the mobile apps are closed source at the moment.

fulafel 5y ago

Well, it's about 2 screefuls of very simple code. Eg for the PK part, if you ctrl-f for publicKey and remotePublicKey, you see there are no usages that could plausibly be doing public key crypto or PK key generation based on crypto 101 from school. Not sure how to respond about gatekeeping. What do you think would be a good way to write a comment pointing out these kinds of security problems? Or do you think it's unfair to do it at all?

opheliate 5y ago
I’m not sure what you mean by there being no public key cryptography here. In the Crypto constructor, a random secret key is generated, and then the generator for Curve25519 is scalar multiplied on the elliptic curve by this secret key to generate a public key. That’s the standard process for X25519 key generation, and it’s what Libsodium does to generate a secret key/public key pair [1]. To establish a shared secret session key, the standard ECDH procedure is used, as seen in Crypto::setRemotePublicKey, where we multiply the other party’s public key by our secret key on curve25519 to establish a shared secret. This shared secret is then used for encryption, since symmetric encryption is generally cheaper + more secure than asymmetric. I absolutely agree that this project needs a more formal cryptographic approach, and should be using a higher level construct (e.g: crypto_secretstream, also from libsodium), but as far as I can tell at first glance, this is a working implementation of X25519. 1: https://github.com/jedisct1/libsodium/blob/7993f5ec5199b6637de6946d001a4e71c05f9ceb/src/libsodium/crypto_box/curve25519xsalsa20poly1305/box_curve25519xsalsa20poly1305.c#L26 https://github.com/jedisct1/libsodium/blob/7993f5ec5199b6637...
- yvbbrjdr 5y ago
  The reason I "rolled my own" key exchange is that I'd want to use the IETF variant of Chacha20-Poly1305 in my protocol and there doesn't seem to be helper functions for key exchange for this algo.
  - opheliate 5y ago
    Unless I'm misunderstanding you, the crypto_secretstream construction [1] that I (and others) have recommended uses ChaCha20Poly1305-IETF as its symmetric cipher. There wouldn't be a key exchange for this algorithm, since it's symmetric. However, the crypto_kx functions [2] generate a 256 bit shared secret, which should work for a ChaCha20Poly1305 key I believe? 1: https://doc.libsodium.org/secret-key_cryptography/secretstream https://doc.libsodium.org/secret-key_cryptography/secretstre... 2: https://doc.libsodium.org/key_exchange https://doc.libsodium.org/key_exchange
    - 5y ago

dintech 5y ago

I read this as a genuine attempt to assist the developer and protect 3rd parties. If that's gate-keeping, we're in trouble as a society.

yvbbrjdr 5y ago

Will draft a crypto spec if I have time :)

api 5y ago

Crypto people: “programmers really need to get better at using crypto!” Also crypto people: “how DARE ye mere mortal even touch crypto!!!” This doesn’t help. The only people who will listen to “don’t roll your own crypto” are the very people who ought to be learning how to do it. The arrogant types who should never touch crypto will ignore this advice and still write bad crypto. The most effective thing would be to just tell programmers why crypto is hard in ways other code is not. Crypto is hard because you can’t simply unit test for vulnerabilities. “Anyone can write a crypto system they themselves can’t break.” For the majority of code it’s good code if it works and is fast and lacks things like memory safety bugs. For crypto it can work perfectly and still be grossly insecure. The only way to tell is to deeply understand cryptanalysis and do academic mathy stuff. As a result if you use crypto it’s best to write boring conservative crypto and use it the way pro cryptographers suggest. Try to use a peer reviewed library or if you can’t and must implement then try to ape a peer reviewed library exactly. Don’t even try to invent new stuff in crypto unless your understanding is very thorough and don’t use anything new without peer review. Edit: another example of abnormally hard code is distributed databases. They can be unit tested but adequately doing so is extremely difficult. It’s easy to write one that seems to work but loses data at scale or under edge case failure scenarios. Crypto is even worse.