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.
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.