This post’s ID is 7740467050023611001.
B-B-B-B-Bonus round! I know I literally just made a blog post, but I’m hopped up on caffeine and methylphenidate and it is 04:32 in my timezone, so it’s time for some un-asked-for cryptography opinions!
Note that everything here is my personal opinion.
I consider RSA to be a distinctly inelegant cryptosystem as far as classical cryptography goes, and not just because it depends on math so simple I learned it as an afterthought in an undergraduate discrete mathematics course for computer engineering students. Key generation is slow (I work with TPMs extensively in my day job and RSA key generation is one of the few operations that can consistently cause the Linux kernel to stall if it tries waiting on it) and the keys are massive (by classical standards) to attain even a relatively “low” security level. It’s also tricky to implement securely (and often not implemented securely).
The Brainpool curves are a collection of elliptic curves mostly used in Europe for, I’m told, patent reasons. Their parameters were generated using a “nothing-up-my-sleeves” method, whereby a pseudorandom process produced the parameters in a way that verifiably can’t contain a backdoor. This is cool in concept, but the problem with randomly-generated primes as field orders is that you can’t use Solinas reduction for fast modular reduction like you can with the pseudo- and quasi-Mersenne primes used by Curve25519 and the NIST curves. You have to use Barrett or Montgomery reduction. This makes the Brainpool curves significantly slower to use in practice at every security level, which is why I’ve only ever seen them used on TPMs, where you have to comply with government standards (womp-womp).
The fact that I’m an American and have in fact never left North America might also have something to do with it.
This really isn’t that much of an unpopular opinion. I’m just displeased every time I read “we would have used a faster/more secure/simpler algorithm, but were worried about patents or export control”. Cryptography is mathematics. Controlling its spread is anti-intellectual. My opinions on cryptographic implementations are somewhat more nuanced, but I still believe that any specialized techniques used in a cryptographic implementation should not be eligible for patent protection.
I also strongly oppose key escrow, forced decryption, and backdooring for related reasons.
This is a huge one for me specifically. My main hobby these days is cryptography on constrained devices, and if I can’t take a five-minute look at your paper and be able to tell at least what order of magnitude the dynamic memory usage is, that makes everyone’s life harder. This includes:
Related: if you’re going to say “pick an element from this set randomly”, it had better either be blindingly obvious how to do that or you should give me a procedure. Don’t make me join the NIST PQC Forum mailing list to ask; it’s a dark and twisted place.
Even more related: if your numbers for signing, decapsulation, or another process handling secrets are not based on a constant-time implementation, why would you give them at all? And if your algorithm depends on floating-point operations, then you had better have done those measurements with floats implemented entirely in software in constant time (a common problem with Falcon implementations, for example).
It’s often not. Plan around that when writing cryptography implementations that are meant to run on things other than x86-64 and ARM.
I am guilty of this. I’m currently in the planning process of writing soft-multiplication variants of some of the TinyCrypT primitives because not all of the supported platforms have constant-time multiplication.