It’s absolutely worth it to roll your own crypto if you want to learn from it. I feel like there is almost a stigma against articles like these because we’ve all been conditioned so much to avoid even thinking about it lol.
I did some deep dive into AES and RSA at some point in a distant past, it was a learning experience that to this day allows me to make much better decisions when choosing algorithms.
> It’s absolutely worth it to roll your own crypto if you want to learn from it.
It's essentially a waste of your time. Because of Schneier's Law: "Any person can invent a security system so clever that she or he can't think of how to break it".
The thing that you might learn from, if you put the work in, would be breaking other people's stuff. Ideally you would find something that's actually in use and vulnerable enough that with some time you'll be able to break it, but that's tricky.
I think Thomas Ptacek is wrong about a bunch of stuff when it comes to security (there's presumably some way to find HN back-and-forth between us if you decide you care about that), but he wasn't wrong about the Cryptopals exercises. By the time you're doing Set 2 exercises this is stuff real people, who were getting paid and thought they knew what they were doing, got wrong.
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.
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].
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.
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.
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.
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.
If no one is allowed to roll their own crypto, even just to learn how it works (and not use it for anything), then how does one become one of those exalted crypto experts who is allowed to create the libraries that everyone else who doesn't roll their own crypto uses?
First, break stuff. That's what the Cryptopals exercises are doing, but because in our actual world there's lot of good stuff out there now these exercises provide bad examples† you can break. If, in your hypothetical, there is no good crypto, this will be very easy to do just by taking anything you find in the real world, right?
Now, use what you learned (from breaking stuff) to make something which resists the attacks you learned. Congratulations, you have improved the state of the art. This is how actual experts (not sure any of them are or should be "exalted") did it.
† Bad, but, in many cases, very real. Because people stubbornly will not learn this lesson and keep rolling their own we are still finding broken garbage in the real world it's just becoming gradually rarer.
That is certainly valuable. But, so is actually implementing cryptographic algorithms, in a context where if you make a mistake it doesn't really matter, because it isn't in "production."
Or even if you just want to understand how an algorithm works, implementing it yourself will probably help you understand it more than reading, or finding problems in someone else's implementation.
Cryptography is the easy part of cryptography. You can learn it as a high school student interested in programming and mathematics. I did that in the late 90s, first from Applied Cryptography and then from more advanced books. I implemented a few algorithms back then, and I also wrote a password manager I used until I learned about the existence of better third-party tools.
The real issue is that cryptography is an adversarial field. The human / systems / software aspects are the hard parts. The crypto you wrote yourself doesn't fail because you got the crypto wrong but because your adversary cheats. (I eventually lost interest in cryptography due to the adversarial nature.)
"Roll you own" seems to be interpreted differently in the comments. Absolutely implement existing ciphers/algorithms like AES/RSA/ECC (and various modes of operation/padding) etc. to get a feeling of how they work, and just don't deploy them in production. You'll definitely get a lot from that. Great way to learn while reading the corresponding papers.
What you probably shouldn't do is try to come up with your own encryption scheme/mode of operation/padding scheme and think you've learned something valuable. By all means, try that as well, but know that you've now entered the really dangerous territory.
> It’s absolutely worth it to roll your own crypto if you want to learn from it
No. If you want to "learn from it", the first thing you should do is buy a copy of Bruce Schneier's Applied Cryptography.
Just reading (and fully understanding !) that book will alone put you in a position where you already know more about cryptography than 90% of other people.
If after that you still want to play around with rolling your own crypto, then fine, go for it. But be aware you are very much making your own bed and should be prepared to lie in the inevitable mucky consequences.
For the rest of us, frankly, no matter what your choice of programming language is, there will be at least one if not many more well respected long-established crypto libraries. Most people should just do themselves a favour and just use those libraries.
As the saying goes ... crypto is hard. A tiny, easily overlooked, mistake in your crypto code can have major consequences.
That’s super personal. I am the type of person who learns by doing, much less reading, and I reject not being “allowed” to do it this way. I will of course study the reading material as I go, but “doing while learning” is an absolute necessity for me, as is studying existing codebases. You learn your way, I learn my way, but don’t tell me my way is wrong just because it’s crypto.
I honestly think, as a community, we’re being far too dogmatic about our advice here, and we should recognise that there is value in learning things by example, and that more people having a better understanding of crypto is generally a Good Thing.
Using it in production, of course, is an entirely different matter, but that’s not what I’m contesting.
> don’t tell me my way is wrong just because it’s crypto.
The way where people think they learn cryptography by making their own implementation is, indeed, wrong. Cryptography is about ensuring specific requirements in the face of active adversaries.
Self-implemented crypto misses many well-known caveats, causing them to be easily breakable. As such, it is not reasonable to consider them as something that aims learn about ensuring security properties in the face of active adversaries... but then that effort is not actually teaching about crypto, which is exactly that.
This is also the reason that the established wisdom for learning cryptography is to learn to break systems first. Almost everyone can make a cryptographic system they cannot break. For most folks, that means little. For those skilled at breaking crypto, that carries weight.
But you're approaching it from the wrong perspective: the idea isn't to use the crypto you implement yourself, the idea is to gain a better understanding of how the "magic" works. Of course my hand-rolled RSA/AES crypto is breakable, I know that because that's the default assumption.
It's akin to saying, "you're not allowed to build your own smoke detector because it will be unsafe!". Of course I know that, I want to understand the differences between a photoelectric and ionization smoke detector, how they work in practice, because reading some PDF schematics just doesn't cut it for me.
I honestly don't understand the line of reasoning of all this crypto gatekeeping.
Fun fact: while I was doing my crypto deep dive in 2015, my language of choice being Haskell, I found issues in several libraries, specifically around entropy, and even one library with modulo bias [1]. They were acknowledged and addressed. It was a super fun learning exercise, and seeing all these comments how it's supposedly almost illegal to do this misses the point of people exploring and learning in their own ways.
One of the reasons I want to learn how these things work in detail is that I want to understand the whole stack I’m working with, from top to bottom. As part of my quest to implement an asymmetrical encryption algo, I ended up wondering “how do I create truly random entropy?”, and went down that rabbit hole.
It’s all about intent: my intent is understanding “how does this work?”, “how do I do this the right way?”, not breaking, and that’s how I found these things.
I don’t care about breaking stuff, it’s just not appealing to me. My whole frustration with this discussion is that for some reason, my intentions are not the True Way of the Crypto Experts, and then I’m not allowed to proceed.
It’s such utter nonsense, and this whole discussion made me realise the situation is actually worse than I thought. If these commenters here are representative of the wider crypto community, they’re really a bunch of elitist gatekeepers that cannot understand the difference between being the NSA and a mere mortal trying to learn things in their own way.
Just no. This idea that people are not allowed to learn by doing things and must read huge books first is absurd. The guidelines for learning you gave here are impractical for majority of people who are interested. It is actually good when people are trying to learn about security.
Just about worst thing these absurd rules achieve is that effectively only rule breakers are allowed in.
I also disagree with the “read books instead” stuff. As long as you’re not using your homegrown crypto in production, and more generally as long as you’re not doing stupid things like reusing single-use tokens, why would I care how you choose to spend your learning time? Though if I’m catching these mistakes in pull requests, I might suggest a formal curriculum for the sake of actual software safety.
I see the same problems in internet debates about which programming language to learn first or how to learn programming in general, and a lot of it just doesn’t take into account that learning is a long journey and staying on the path is often more important than taking the fastest or cleanest path. If trying to roll your own stuff is more engaging, great!
> Just no. This idea that people are not allowed to learn by doing things and must read huge books first is absurd.
No, its not absurd.
Sure, I agree, for many things in life you can "learn by doing".
But this is cryptography.
There is no escaping that cryptography IS mathematics and an algorithm built on top of that mathematics.
Unfortunately the only way to learn the theory is by reading and understanding books or academic papers.
Otherwise you are just taking shortcuts based on a summary that someone else has written for you on a short blog or forum post. Which, aside from the fact that you are skipping the detail and hence not really learning, also brings us into the region of trust...
If you have no interest in learning the dry theory behind the cryptography, then you have no business rolling your own crypto. Because if you are not willing to understand the theory then you are going to make serious mistakes.
This is kind of ridiculous. Everyone has to start somewhere whether it is by doing or by reading books. Even crypto experts started by doing at some point. It's not like the person is going to be using their own crypto in production.
> If you have no interest in learning the dry theory behind the cryptography, then you have no business rolling your own crypto.
As someone who wholeheartedly buys into the “thou shalt not roll thine own crypto” mantra, this attitude is just sad. Everyone who wants to has all the business rolling their own crypto for learning purposes, and you have no business telling them they shouldn’t. Stifling this sort of exploration is fundamentally wrong.
First, majority of exploits are not even in math, they are in implementation. Second, as much as math is fun, the claim that you need to start with it is plain absurd.
First thing this mantra does is that we collectively know less a out crypto and security. Second thing it does is that it selects stick-in-ass rule followers away which is exactly contraproductive. And third, it makes us stuck with crappy convoluted code crypto libs had twenty years ago, cause supply of people capable to improve it is not build up.
> If after that you still want to play around with rolling your own crypto, then fine, go for it. But be aware you are very much making your own bed and should be prepared to lie in the inevitable mucky consequences.
I'm very confused. OP was suggesting to roll your own crypto as a learning exercise. What possible consequences could there be? Let alone "murky" ones?
Will your RSA implementation summon an eldritch monster or something?
It is shocking to me how many people in the computer community explicitly tell curious minds not to even try building a crypto protocol.
It isn't enough to say "you'll never get it right for production, please use a framework or library for production". You simply don't want them to even experiment on their own.
I agree with saying "the most effective way to learn cryptography is through books and tools X, Y, Z". But one would imagine that writing a poor hashing algo would open up a door to alternate dimensions by how superstitious some are about it on this site.
It sounds like you didn't read the disclaimer. The first paragraph specifically tells you not to actually use the crypto you roll for anything important.
The purpose of this is to learn how AES works, not to write a library you would actually use.
I did some deep dive into AES and RSA at some point in a distant past, it was a learning experience that to this day allows me to make much better decisions when choosing algorithms.