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.
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).
† https://blog.pinboard.in/2013/04/the_matasano_crypto_challen...
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.
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!
As a marketing message, hearing that you believe you “perfectly understand” the math involved doesn’t fill me with confidence.
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.
[1] https://monocypher.org/quality-assurance/disclosures
[2] http://loup-vaillant.fr/tutorials/fast-scalarmult
[3] http://loup-vaillant.fr/tutorials/cofactor