4 ms·

"""It's essentially a waste of your time.""" Strongly disagree. I'm pretty sure rolling your own crypto will strengthen your understanding of crypto (and poten

by kriro 4y ago

"""It's essentially a waste of your time.""" Strongly disagree. I'm pretty sure rolling your own crypto will strengthen your understanding of crypto (and potential flaws) a lot. Obviously don't use it in production but by all means, do it for the sake of learning. How can this be a waste of time? That's like saying "never implement a search/sort algorithm, just use libraries"...yeah sure use libraries but also implement the stuff to learn.

woodruffw 4y ago
There are a lot of subdomains within cryptography where "rolling your own" will not meaningfully strengthen your understanding of the underlying concept. RSA is really good example of this: you can "implement" RSA in Python in an hour, and your understanding will include some of the mathematical fundamentals (prime generation, modular exponentiation, &c.). What it won't include is why or how each of those fundamentals comes with a laundry list of caveats that can completely break any scheme that uses your particular implementation of RSA. I second the recommendation for cryptopals, as well as all of the resources that Matt Green lists[1]. [1]: https://blog.cryptographyengineering.com/useful-cryptography-resources/ https://blog.cryptographyengineering.com/useful-cryptography...
- simonw 4y ago
  Right, but if you've improved your knowledge of the fundamentals by rolling your own RSA you'll be in a much better position to fully understand detailed articles that explain those caveats.
  - woodruffw 4y ago
    I'm actually skeptical that this is true: there isn't (in my mind) an intuitive bridge between "select two large primes" and "you have to make sure that there are enough different upper bits between p and q or your system is completely hosed." The former is the "direct" understanding of what makes RSA cryptographically sound, and what rolling your own will teach you; the latter is a weird result in number theory. RSA is a particularly easy punching bag in this regard, but I think it's true generally (and is generally becoming more true, as we see increasingly clever sidechannels and oracles). Edit: That being said, I want to moderate my position by saying that I don't think there's anything wrong with playing around with cryptosystems in an attempt to learn them. I do it! I think the risk that people talk about when they say "DRYAC" is that engineers will take their relatively painless experience getting it 10% right in their spare time and think they can get it 100% right without an asymmetric amount of additional effort.
    - willcipriano 4y ago
      The fact this is even a question shows me how many engineers are just cargo culting whatever they hear someone else say. If you can't understand that a toy project has different trade offs than the NSA you really shouldn't be engineering anything, trade offs are the entire job. Nobody is going to spend the time to implement this guide instead of importing a library.
      - woodruffw 4y ago
        I think this is unnecessarily harsh. Most of the people who implement cryptographic systems are professional engineers, and are not otherwise incorrect in evaluating their skillsets or capabilities. The problem isn't cargo culting, but the fact that cryptography is much more subtle and un-engineering-like that the rest of our discipline.

by kriro 4y ago

woodruffw 4y ago

There are a lot of subdomains within cryptography where "rolling your own" will not meaningfully strengthen your understanding of the underlying concept. RSA is really good example of this: you can "implement" RSA in Python in an hour, and your understanding will include some of the mathematical fundamentals (prime generation, modular exponentiation, &c.). What it won't include is why or how each of those fundamentals comes with a laundry list of caveats that can completely break any scheme that uses your particular implementation of RSA. I second the recommendation for cryptopals, as well as all of the resources that Matt Green lists[1]. [1]: https://blog.cryptographyengineering.com/useful-cryptography-resources/ https://blog.cryptographyengineering.com/useful-cryptography...

simonw 4y ago
Right, but if you've improved your knowledge of the fundamentals by rolling your own RSA you'll be in a much better position to fully understand detailed articles that explain those caveats.
- woodruffw 4y ago
  I'm actually skeptical that this is true: there isn't (in my mind) an intuitive bridge between "select two large primes" and "you have to make sure that there are enough different upper bits between p and q or your system is completely hosed." The former is the "direct" understanding of what makes RSA cryptographically sound, and what rolling your own will teach you; the latter is a weird result in number theory. RSA is a particularly easy punching bag in this regard, but I think it's true generally (and is generally becoming more true, as we see increasingly clever sidechannels and oracles). Edit: That being said, I want to moderate my position by saying that I don't think there's anything wrong with playing around with cryptosystems in an attempt to learn them. I do it! I think the risk that people talk about when they say "DRYAC" is that engineers will take their relatively painless experience getting it 10% right in their spare time and think they can get it 100% right without an asymmetric amount of additional effort.
  - willcipriano 4y ago
    The fact this is even a question shows me how many engineers are just cargo culting whatever they hear someone else say. If you can't understand that a toy project has different trade offs than the NSA you really shouldn't be engineering anything, trade offs are the entire job. Nobody is going to spend the time to implement this guide instead of importing a library.
    - woodruffw 4y ago
      I think this is unnecessarily harsh. Most of the people who implement cryptographic systems are professional engineers, and are not otherwise incorrect in evaluating their skillsets or capabilities. The problem isn't cargo culting, but the fact that cryptography is much more subtle and un-engineering-like that the rest of our discipline.