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.
Looking at Cryptopals in particular it's not ideal that you need to get through dozens of other exercises before you finally email off to the authors and start to run into problems concerning today's fan favourites like Elliptic curve DH.
I'm at home even more than usual now (for obvious reasons) but even then I suspect I will get distracted before I get as far as say, Challenge 42 which is - though still relevant and I get that it makes sense to drum that in - ancient history by today's standards, let alone Set 8.
As a result Cryptopals feels like it recapitulates history from the point where the authors got into the industry and so may unintentionally mislead. I remember your surprise when it turned out Microsoft hadn't done the necessary checks for a curve based signature algorithm and so they'd actually been shipping code that would accept bogus signatures. My instinct is that Cryptopals challenges would be more effective (but might make some people involved less comfortable) if they rearranged some of the 21st century attacks on those "fan favourite" algorithms into earlier sets instead of accumulating them in Set 8.
I dunno maybe this is like complaining that my school maths textbook (first written in the 1940s I swear I'm not that old) assumes you'll use log tables rather than a calculator. But the Cryptopals challenge site clearly doesn't seem to think it's a historic artefact, so it shouldn't act like one.
Thank you, it's unlikely I'll get that far (yesterday I wanted to do six things, it is now 0240 and I am starting the first one...) but even if I don't end up using it somebody else might.
Sets 1-6 of Cryptopals were a blog post that I wrote in 2010. At the time, I was enmeshed in a series of Twitter arguments with a security industry personality who shall remain nameless, and was concerned that if I simply published the blog post, I'd be arming that person with a large series of buzzwords that could be deployed in Twitter slapfights without any real comprehension of how this stuff worked.
So, instead, I chunked the post out into sets of 8 challenges which we delivered to all comers via email, on the condition that you had to complete the previous set and return your code to us before receiving the next set. Obviously, my (at the time) Twitter nemesis wasn't going to put the time in to write the code to break repeating-key XOR, let alone BB'98.
The challenges were successful far beyond what I could have predicted. Maciej Cegłowski wrote a blog post about them† that hit the front page here; we got flooded with requests, which we kept up with with a Twitter scoreboard, and made donations to charity when people made it through all 6 sets. There are working professional crypto engineers who got their start with the challenges --- not our intent at all, but I'll take it. I'm most proud of the fact that we've amassed what I believe to be the world's largest collection of Bleichenbacher padding oracle exploits, in every conceivable programming language, including several people made up just to do them.
All this is to say that getting people to whatever you think is "relevant" cryptography by today's standards was never the point. In fact: that's pretty close to the opposite of the point; I wrote the blog post as internal training for our team at Matasano, who needed to know how to break cryptography as it exists in the real world, not just the cryptography people think is the best, most relevant in use today. And, suffice it to say, no matter how distractable you might be, a very clear understanding of how the BB'98 attack actually defeats RSA is important for a working crypto engineer; probably more important than a lot of modern stuff. Bleichenbacher aside, though, really what you're seeing is a snapshot of au courant crypto attacks from 2010. Away from the libsodium world we live in now, CBC and unauthenticated encryption were quite common, and you still had to convince developers to fix them.
No argument from me, though; Set 8 is the best of them. I had nothing to do with it; that was all Sean Devlin. He released them one at a time on Twitter as a fundraiser for the Great Slate back in the 2018 election cycle. Nobody's making you send your homework back to me to see Sean's modern crypto set; you can just skip to it and do those challenges; they're online already, just not on that site (we don't work at NCC anymore, haven't for years, and they own the website).
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.
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.
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
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
I've compiled the numbers on my benchmark page, 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!
I won't apologise for mentioning Monocypher here and there. I work on it on my free time, I pay for the servers, I make no money from it, and I genuinely believe it fills a legitimate niche.
One way I make sure I perfectly understand the maths I'm messing with, is by not messing with the maths I don't understand. It's a simple rule, which I have broken once. Big mistake[1], won't do it again. Also, I've been at it for over 3 years, I've learned a few things[2,3].
Finally, I do believe I was engaging with the conversation. My first point was that as great as Cryptopals might be, it's not the only way to learn crypto. On the contrary, it would seem the takeway is that nope, you definitely should not roll your own crypto. I get the point about safety, but this feels somewhat counter productive. That and the stark contrast with other domain. I don't hear "don't roll your own compiler", "don't roll your own file format"… even though they're often as safety critical as cryptography itself.
Thomas' reaction is true, but it's not useful. Yet another way of saying "don't roll your own crypto", because well, it can hurt your users if you screw up. No kidding. But he seems to ignore the opportunity cost, so I pointed that out.
Then Thomas subtly suggested that my work is worth nothing. Not what I'd call "engaging with the conversation". That rubbed me the wrong way.
A bit of context may be warranted: the scalarmult error he was referring to I quickly patched and publicly disclosed back in 2018[1]. The reactions[4,5] it elicited where a bit more hostile than is usually tolerated here. It's not just the mockery (I did screw up), it's the willingness to asses something they hardly even looked at.
