7 ms·

Cryptopals strikes me as a very good way of scaring people from not only inventing, but also implementing their own crypto. It seems it's primary effect is to m

Cryptopals strikes me as a very good way of scaring people from not only inventing, but also implementing their own crypto. It seems it's primary effect is to make people confident enough to repeat the "don't roll your own crypto" mantra to anyone who would listen. Some people however don't really have a choice. "Just Libsodium" doesn't work on anything smaller than a Raspberry-Pi, or pretty much any embedded system out there. There are alternatives out there (shameless plug: https://monocypher.org https://monocypher.org), but sometimes your only choice is to code and optimise it yourself. Sometimes, your only reasonable choice is to implement your own crypto. And I can tell from experience, a few weeks of full time learning is enough to not shoot yourself in the foot. The trick is to learn the right things (not everybody can spend a few weeks with Dan Boneh), but if you limit yourself to simple primitives like Chacha20 and Curve25519, it's not that hard. (Fun fact: I did not spend a few weeks with Dan Boneh, and I did shoot myself in the foot once.) Because let's be honest: you don't need to know all the attacks to protect yourself from them. What you need to know is the relevant classes of attacks, and how to void them. For instance, all timing attacks are stopped if your code runs in constant time (which in practice mostly means without secret-dependent branches and without secret-dependent indices).

api 6y ago
> Cryptopals strikes me as a very good way of scaring people from not only inventing, but also implementing their own crypto Paradox alert: the person who knows enough about crypto to fear implementing it is the person I want implementing the crypto I am using. So if the effect of such education is to discourage you, that means the crypto is left to the clueless to implement.
zeroxfe 6y ago
Thanks, I agree with almost all of this. I didn't mean to imply that Cryptopals is how you become a cryptographer, just that it's a fantastic way to get down and dirty with cryptography, and learn a ton. These challenges are not easy, and you need some programming sophistication to get through them, since most of them require you to actually implement well-known primitives and algorithms (like Diffie-Hellman, RSA, DSA, PRNGs, etc.) And to do that correctly, you end up studying a _lot_ of side material. You do come out of the other end learning about various classes of attacks, but not necessarily how to avoid them -- that depends entirely upon your intellectual curiosity. :-)
beefhash 6y ago
> "Just Libsodium" doesn't work on anything smaller than a Raspberry-Pi, or pretty much any embedded system out there. There are alternatives out there And the same author provides a solution for those systems as well with libhydrogen. Though that doesn't look so super hot anymore given the recent advances on Gimli[1,2,3], but it'll likely still hold up in practice. > but sometimes your only choice is to code and optimise it yourself That is a critical shortcoming of the ecosystem. If you reach that point, you should be hiring a cryptographer/experienced implementer. Your follow-up question might be “Where do the cryptographers come from, then?” and the answer to that is: “PhD programs at universities, ideally”. Curiously, however, many (most?) cryptography libraries that are used in practice appear to be written by people with barely any academic background. We should be working to rectify that one way or another (send the implementers to university or pull more people from theory into implementation practice). > you don't need to know all the attacks to protect yourself from them. What you need to know is the relevant classes of attacks, and how to void them Some attacks, however, can be quite surprising or virtually impossible to mitigate without deep knowledge of the specific problem domain. Are we sure how to mitigate software implementations of EC scalar multiplication against differential power analysis yet? And that's before you get to protocol design, where there are new, mysterious ways to shoot yourself in the foot (use TLS, use TLS, use Noise). [1] https://eprint.iacr.org/2020/561.pdf https://eprint.iacr.org/2020/561.pdf [2] https://eprint.iacr.org/2020/591.pdf https://eprint.iacr.org/2020/591.pdf [3] https://eurocrypt.iacr.org/2020/rump/ec2020rump-paper23-slides-presentation.pdf https://eurocrypt.iacr.org/2020/rump/ec2020rump-paper23-slid...
- loup-vaillant 6y ago
  > Some attacks, however, can be quite surprising or virtually impossible to mitigate without deep knowledge of the specific problem domain. Are we sure how to mitigate software implementations of EC scalar multiplication against differential power analysis yet? This particular attack is not really about ECC, and more about the processor & program you use. One "easy" way to immunize yourself against power analysis is to have your implementation be "constant power". That is, no information must flow from secrets to power. The first step is coming up with hardware with constant-power operations. Then the cryptographic engineer must make sure the power-variable instruction never have secret inputs. That may require compiler support, writing assembly code by hand, or formal analysis. That can be wickedly hard indeed, but it also has little to do with ECC specifically. The deep knowledge required there is about hardware, compilation techniques, formal methods… The only ECC specific part is identifying the secrets, and that's comparatively trivial.
deleted 6y ago
[deleted]
tptacek 6y ago
What's rough about implementing your own crypto is that sometimes you screw it up, as you well know. When you screw up an attack, nobody suffers. Not so for novel implementations of primitives that you provide to others.
- loup-vaillant 6y ago
  There's another side to this coin: while users can be hurt by a buggy implementation, they can also be hurt by the absence of an implementation: they now have to either come up with their own, chose something less than ideal, or give up entirely. For instance, Monocypher is 20 times faster than TweetNaCl at signature & signature verification. On a micro controller where you can't use Libsodium (say Cortex M0), that speed difference is significant. Erasing Monocypher from the face of the Internet would hurt users who could have used the extra speed.
  - tptacek 6y ago
    What good is a signature verification library that's 20 times faster than TweetNacl --- which few use --- if its scalarmult is broken and it incorrectly verifies forged signatures? If correctness isn't a requirement, I can make signature verification take ε cycles.
    - loup-vaillant 6y ago
      Broken implementation are worth nothing, duh. Of course correctness is a requirement. That's is why I took a couple precautions since that little disaster 2 years ago: I stopped using maths I didn't perfectly understand. I imported the Wycheproof tests (which by the way revealed no additional bugs, contrary to what lvh jokingly suggested on Twitter at the time). And a number of other things: https://monocypher.org/quality-assurance/test-suite https://monocypher.org/quality-assurance/test-suite Don't worry, I've learned my lessons, and I do take correctness seriously. Now maybe Not many people use TweetNaCl on embedded chips, but the alternatives often aren't much shinier: https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8725488 https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8725488 I've compiled the numbers on my benchmark page, https://monocypher.org/speed https://monocypher.org/speed but the gist of it is: Monocypher is often much faster than everything else. The only thing that beats it is hand written assembly!
Animats 6y ago
Cryptopals strikes me as a very good way of scaring people from not only inventing, but also implementing their own crypto. Now that's very useful. The real way to learn cryptography is to go through the National Cryptologic School at the National Security Agency in Maryland. They used to start everyone out with paper and pencil cryptanalysis. They classically emphasized that most cyphers are broken because someone made an error in key management. (See Venona). That's probably still the case. "No new cypher is worth looking at unless it comes from someone who has already broken a very hard one" - Friedman.

api 6y ago

> Cryptopals strikes me as a very good way of scaring people from not only inventing, but also implementing their own crypto Paradox alert: the person who knows enough about crypto to fear implementing it is the person I want implementing the crypto I am using. So if the effect of such education is to discourage you, that means the crypto is left to the clueless to implement.

zeroxfe 6y ago

Thanks, I agree with almost all of this. I didn't mean to imply that Cryptopals is how you become a cryptographer, just that it's a fantastic way to get down and dirty with cryptography, and learn a ton. These challenges are not easy, and you need some programming sophistication to get through them, since most of them require you to actually implement well-known primitives and algorithms (like Diffie-Hellman, RSA, DSA, PRNGs, etc.) And to do that correctly, you end up studying a _lot_ of side material. You do come out of the other end learning about various classes of attacks, but not necessarily how to avoid them -- that depends entirely upon your intellectual curiosity. :-)

beefhash 6y ago

> "Just Libsodium" doesn't work on anything smaller than a Raspberry-Pi, or pretty much any embedded system out there. There are alternatives out there And the same author provides a solution for those systems as well with libhydrogen. Though that doesn't look so super hot anymore given the recent advances on Gimli[1,2,3], but it'll likely still hold up in practice. > but sometimes your only choice is to code and optimise it yourself That is a critical shortcoming of the ecosystem. If you reach that point, you should be hiring a cryptographer/experienced implementer. Your follow-up question might be “Where do the cryptographers come from, then?” and the answer to that is: “PhD programs at universities, ideally”. Curiously, however, many (most?) cryptography libraries that are used in practice appear to be written by people with barely any academic background. We should be working to rectify that one way or another (send the implementers to university or pull more people from theory into implementation practice). > you don't need to know all the attacks to protect yourself from them. What you need to know is the relevant classes of attacks, and how to void them Some attacks, however, can be quite surprising or virtually impossible to mitigate without deep knowledge of the specific problem domain. Are we sure how to mitigate software implementations of EC scalar multiplication against differential power analysis yet? And that's before you get to protocol design, where there are new, mysterious ways to shoot yourself in the foot (use TLS, use TLS, use Noise). [1] https://eprint.iacr.org/2020/561.pdf https://eprint.iacr.org/2020/561.pdf [2] https://eprint.iacr.org/2020/591.pdf https://eprint.iacr.org/2020/591.pdf [3] https://eurocrypt.iacr.org/2020/rump/ec2020rump-paper23-slides-presentation.pdf https://eurocrypt.iacr.org/2020/rump/ec2020rump-paper23-slid...

loup-vaillant 6y ago
> Some attacks, however, can be quite surprising or virtually impossible to mitigate without deep knowledge of the specific problem domain. Are we sure how to mitigate software implementations of EC scalar multiplication against differential power analysis yet? This particular attack is not really about ECC, and more about the processor & program you use. One "easy" way to immunize yourself against power analysis is to have your implementation be "constant power". That is, no information must flow from secrets to power. The first step is coming up with hardware with constant-power operations. Then the cryptographic engineer must make sure the power-variable instruction never have secret inputs. That may require compiler support, writing assembly code by hand, or formal analysis. That can be wickedly hard indeed, but it also has little to do with ECC specifically. The deep knowledge required there is about hardware, compilation techniques, formal methods… The only ECC specific part is identifying the secrets, and that's comparatively trivial.

deleted 6y ago

[deleted]

tptacek 6y ago

What's rough about implementing your own crypto is that sometimes you screw it up, as you well know. When you screw up an attack, nobody suffers. Not so for novel implementations of primitives that you provide to others.

loup-vaillant 6y ago
There's another side to this coin: while users can be hurt by a buggy implementation, they can also be hurt by the absence of an implementation: they now have to either come up with their own, chose something less than ideal, or give up entirely. For instance, Monocypher is 20 times faster than TweetNaCl at signature & signature verification. On a micro controller where you can't use Libsodium (say Cortex M0), that speed difference is significant. Erasing Monocypher from the face of the Internet would hurt users who could have used the extra speed.
- tptacek 6y ago
  What good is a signature verification library that's 20 times faster than TweetNacl --- which few use --- if its scalarmult is broken and it incorrectly verifies forged signatures? If correctness isn't a requirement, I can make signature verification take ε cycles.
  - loup-vaillant 6y ago
    Broken implementation are worth nothing, duh. Of course correctness is a requirement. That's is why I took a couple precautions since that little disaster 2 years ago: I stopped using maths I didn't perfectly understand. I imported the Wycheproof tests (which by the way revealed no additional bugs, contrary to what lvh jokingly suggested on Twitter at the time). And a number of other things: https://monocypher.org/quality-assurance/test-suite https://monocypher.org/quality-assurance/test-suite Don't worry, I've learned my lessons, and I do take correctness seriously. Now maybe Not many people use TweetNaCl on embedded chips, but the alternatives often aren't much shinier: https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8725488 https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8725488 I've compiled the numbers on my benchmark page, https://monocypher.org/speed https://monocypher.org/speed but the gist of it is: Monocypher is often much faster than everything else. The only thing that beats it is hand written assembly!

Animats 6y ago

Cryptopals strikes me as a very good way of scaring people from not only inventing, but also implementing their own crypto. Now that's very useful. The real way to learn cryptography is to go through the National Cryptologic School at the National Security Agency in Maryland. They used to start everyone out with paper and pencil cryptanalysis. They classically emphasized that most cyphers are broken because someone made an error in key management. (See Venona). That's probably still the case. "No new cypher is worth looking at unless it comes from someone who has already broken a very hard one" - Friedman.