@forest I saw a funny observation someone made on Twitter of flaws in NIST PCQ

"Useful check #1: If I decrypt that, do I get the same message back?"

"Useful check #3: Try flipping a random bit!"

wow

Dat semicolon

What continues to surprise me every day is how many "obvious" bugs are found in important projects. Even ones with lots of funding.

I see how noobs try to get other people to evaluate their inventions. They don't even have the competence to realize that not knowing where to look to see if an algorithm is insecure is a very bad place to start in designing a secure algorithm. Some though have probably been lectured and continue to farm their work out to people who will indulge their laziness.

And people think like "my code is secure until proven otherwise" not "code should never be assumed secure until it receives a lot of scrutiny". But I'm starting to realize this isn't something limited to noobs. "Respected" people often are just as lazy.

For example, when Rivest published Spritz he noted his code was slow but that was only because it was unoptimized. Writing an optimized version of the code was one of those "an exercise left to the reader" type of thing. It's a bad algorithm in terms of design, speed, security, simplicity, and ease of analysis. And it was broken in a few months. It should have been a joke proposal.

At this point I think people designing algorithms should be able to contribute more to their own work than the algorithm description itself. You don't need to be an expert in every field, but I think you should try to teach yourself things like coding or hardware engineering if you're going to venture into another field.

For that reason I respect Bernstein more than Rivest. I think he actually cares about the "trivial" details like software speed and side channels. If a cipher isn't fast (and there's no other justification) then it's less than useful.

Asymmetric crypto is a little different, but I think the expectations of professionalism should be a little higher. And I don't know if the underlying algorithm are actually insecure or not. (Except that embarrassing news where Walnut DSA could be broken in one minute on a laptop.) A freshman computer science student would be lucky to get a C in a homework assignment if their code didn't pass such trivial tests...

Actually. I want to clarify I don't think being a perfect C programmer or a clever software writer is a solution to the problem of C being a landmine. I'd love to rant somewhere else about how bad C is. I actually missed the semicolon for a long time before someone on Twitter spoiled the answer.

What I think is much worse is not testing for decrypt(encrypt(x)) == x. I would write tests to check my functions work forward and backwards if I were writing a base64 conversion, let alone encryption algorithms. To the extent possible with asymmetric encryption, I would hope I would bother with unit tests and randomized sanity checks (like getting the same message back after decryption).

My paranoia and self doubt would nag me at a minimum if I didn't.