hey now dont forget Speck, the cipher so dang great they not only refused any real discussion with cryptographers and linux kernel developers but insisted it be included on a litany of "its classifed" and "we cant tell you" boilerplate.
turns out in 2013 kernel hackers decided to tell the NSA to go pound sand into a rathole while they focused on things like ED25519 because as Bruce
Schneier himself publically stated:
"I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry."
This Schneier "constants" quote is kind of infamous. Notably, he's referring to elliptic curve writ large (the context is a comment on his blog where someone asks why he promotes FFDH over ECDLP-based crypto). He's not saying he no longer trusts the Dual EC constants (he never did, but he also once suggested it was somewhat unlikely to be a backdoor), or even the P-curve constants (which, for the record, I don't think anyone plausibly claims are themselves backdoored). No, he's saying we should all stay in the 1990s with FFDH, which, ironically, involves even more magic parameters.
It would be better if people avoided citing Schneier on curve cryptography, since he spent his career sort of publicly and vocally avoiding elliptic curves. Cryptography is a big discipline; it's not the case that someone with good ideas on, say, block ciphers necessarily has a lot of insight into elliptic curve or lattice cryptography or isogenies or pairings.
There's been a whole bunch of research and some controversy about SIMON and SPECK, the NSA small-footprint ciphers. The problem with backdooring something as simple as SPECK is twofold: you don't have many degrees of freedom, because block ciphers are so simple, and whatever backdoor you come up with has to be "NOBUS" to be practical --- meaning: your backdoor has to work for the NSA, but not for the GRU.
There was a cool paper last year that proposed a NOBUS-like backdoor mechanism for block cipher designs that embedded a susceptibility to linear cryptanalysis into S-boxes (that paper is also notable for a shout-out to yours truly, for writing an HN comment dumb enough to motivate a whole academic paper to refute it) --- this is Tomer Ashur and Raluca Posteuca's thing. So it's been shown that you can introduce a vulnerability --- nowhere nearly as useful as Dual EC, since linear cryptanalysis is annoying to carry out --- but it's still up in the air whether you can really make them NOBUS, because the backdooring work has to survive its own cryptanalysis to prove that up.
At any rate: I kind of doubt there's really anything sketchy about SIMON or SPECK, but it doesn't matter, because nobody is going to use it (having said this on Hacker News we can now be sure that there's a PR to introduce it to Juniper VPN devices, but I stand by it!) and because there are lots of simple low-footprint cipher designs to choose from now.
Yep. I'm just suggesting that it's tricky to evaluate FFDH groups for different applications (for instance, with SRP), and there's less clear guidance about which to use, while with curves the popular curve choices are pretty intensely studied and argued about.
The thing about Speck is a shame if it turns out that it's a good cipher. Speck is trivial to implement, has decent performance and doesn't rely on S-Boxes. It's basically all anyone could ever ask for and a design I can very much appreciate. As a block cipher, it has different trade-offs than the djb ARX ChaCha20, which is a stream cipher.
https://en.wikipedia.org/wiki/Speck_%28cipher%29
turns out in 2013 kernel hackers decided to tell the NSA to go pound sand into a rathole while they focused on things like ED25519 because as Bruce Schneier himself publically stated:
"I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry."
https://en.wikipedia.org/wiki/Curve25519