First, while "playing around with cryptography" may be the only way to learn it, building cryptographic systems is just about the worst way to learn. Professional cryptographers start by cryptanalyzing targets and use that experience to inform their future designs. On the other hand, veteran implementors who have never taken the time to learn how to break crypto turn out protocols and designs that are repeatedly broken. You can see that right now with TLS and the TLS working group, which still hasn't fixed MtE block ciphersuites because veteran implementors can't get it through their heads that MtE is a design flaw.
Don't learn by building. You need to learn by breaking.
Second, more than one project has done the tightrope walk of telling their users "this isn't really safe" but then misleading (innocently or not) non-savvy users into trusting them. One project made it clear that their system wasn't "ready" to defend against nation-state adversaries... but then suggested that maybe it would be good enough for journalists, and even promoted it at an event for teaching journalists cryptography. It was later comically broken.
Be honest with yourself. Crypto doesn't get beta-tested into resiliency. Strong systems start out strong. If you're building something because its your dream to thwart the NSA, don't kid yourself into thinking that you'll get there by first protecting people's Warcraft clans.
Don't learn by building. You need to learn by breaking.
The best way to do this is to do the Matasano crypto challenges. The challenges are designed to get progressively more difficult, and since the goal of most of them is to break something, that means you'll learn how to employ progressively more sophisticated attacks. They're also great for a newbie, because in one challenge you'll implement something that seems impervious to attack, then in the following challenge you'll attack and break it, often via an unexpected attack vector. (The padding oracle attack comes to mind.)
You'll come away with an understanding of AES in ECB CBC and CTR modes; HMAC; timing attacks; attacks on RNGs; attacks on hashes; and a lot more. That's just off the top of my head.
For me, there were a dozen "aha!" moments in the first 30 challenges. Each of those moments now live with me and inform my future decisions. They will also make you much less confident in your ability to design secure cryptosystems, which is good.
Today you've convinced me to start on the Matasano challenges. I completed the Stripe CTF from ~ a year ago and I've been looking for something else to try my hand at that would improve my security knowledge.
You can see that right now with TLS and the TLS working group, which still hasn't fixed MtE block ciphersuites because veteran implementors can't get it through their heads that MtE is a design flaw.
Can't get it through their heads that MtE is a design flaw? You're more generous than I would be. At this point I'd assume that everybody knows that MtE is a design flaw, and anyone designing a protocol which uses MtE has made a deliberate decision to design a weak protocol.
I get that you need to learn how to break software as a major part of the learning process. I also understand that a broken system often can't be fixed, and that if your system breaks you might have to start from scratch. But does one go from becoming an expert at breaking systems to automatically churning out a secure cryptographic system? Or does one become an expert at breaking and then build a bunch of flawed crypto systems, as the learning process continues?
Maybe the process is just counterintuitive, but it seems that no matter how skilled someone might be at breaking systems, that building a sound system on the first try would still be incredibly difficult. I know that crypto systems aren't built iteratively, instead I'm talking about going back to the drawing board each time. Would there be value in that, or would it be a waste of time? I'm not yet an expert (and I am well aware that you are), though I aspire to be one day. Perhaps you would be kind enough to elaborate?
> But does one go from becoming an expert at breaking systems to automatically churning out a secure cryptographic system? Or does one become an expert at breaking and then build a bunch of flawed crypto systems, as the learning process continues?
Both and neither. Once you get really good at breaking cryptosystems, designing them looks very similar. You start with best practices: use sane primitives (or thoroughly vetted components, preferably!) and put them together in known, simple (simple is key) ways. Then you put on your breaking hat and you attempt to violate every constraint. If you find a flaw, then you iterate or redesign. Once you are happy with it, you start showing it to other crypto breakers, until they're happy with it too.
At this point, you have something that would withstand most basic attacks, and you might be ready to put it out into the world. It's still not battle-hardened and ready for uberconfidential data, but it's in a better state than most cryptosystems. As more and more people look at it without owning it, its trustworthiness goes up, and the risk goes down.
Secure cryptosystems don't pop out of nothing; they're iterative, but not in the "I should do a Show HN" sense. It's iterative like writing a poem -- you don't release it one line at a time.
I think we should clarify that building can always be breaking. You can implement a script that automate the breaking process (think fuzzer). I can fire up Python interpreter and start playing around with AES encoding with ECB and then figure "shit, ECB is not semantically secure". I can have a damn vulnerable web app and web server. I can implement them, break them and improve them if I am really that dedicated.
I can also learn by reading standard and read how people implement in projects like Firefox or Chromium. And ask questions. I think we should be careful with the meaning of "learn by breaking" because obviously only a handful of people can really break cryto system. And average developers like me are probably better off just learn and break.
Steps like that are probably my way of getting into security engineering and cryto engineering (at some point). I guess I am a different audience, I am not here to break RSA, I am here to learn how real systems are implementing RSA, TLS and see whether those implementations have flaws or not.
First, while "playing around with cryptography" may be the only way to learn it, building cryptographic systems is just about the worst way to learn. Professional cryptographers start by cryptanalyzing targets and use that experience to inform their future designs. On the other hand, veteran implementors who have never taken the time to learn how to break crypto turn out protocols and designs that are repeatedly broken. You can see that right now with TLS and the TLS working group, which still hasn't fixed MtE block ciphersuites because veteran implementors can't get it through their heads that MtE is a design flaw.
Don't learn by building. You need to learn by breaking.
Second, more than one project has done the tightrope walk of telling their users "this isn't really safe" but then misleading (innocently or not) non-savvy users into trusting them. One project made it clear that their system wasn't "ready" to defend against nation-state adversaries... but then suggested that maybe it would be good enough for journalists, and even promoted it at an event for teaching journalists cryptography. It was later comically broken.
Be honest with yourself. Crypto doesn't get beta-tested into resiliency. Strong systems start out strong. If you're building something because its your dream to thwart the NSA, don't kid yourself into thinking that you'll get there by first protecting people's Warcraft clans.