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.
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 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.
So, if you're a programmer try something like "Cryptopals": https://cryptopals.com/
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.
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...
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.
Someone has to write those libraries.
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.
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.
That's where i've learnt most of my crypto, although it might be more focussed on the breaking than the making part.
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.)
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.
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.
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.
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.
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.
https://github.com/vincenthz/hs-crypto-numbers/commit/bceb54...
This is exactly what the other people in this thread mean when they say "learn by breaking other crypto", assuming you didn't write those libraries.
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.
On a related note, Beldin here just contributed a new entry into cryptopals: the Gatekeeper hash, but only certain people can see the link.
Just about worst thing these absurd rules achieve is that effectively only rule breakers are allowed in.
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!
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.
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 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.
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 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.
The purpose of this is to learn how AES works, not to write a library you would actually use.