But the politics meant it doesn't matter in the end. People convinced themselves the NSA backdoored XOR or that the number five is secretly composite or whatever and you can't use logic to fix something like that.
I was aiming, if perhaps badly, at the crypto really, as I'd seen some arguments that we needed it in Linux to run on constrained devices. I don't really have a problem with including it in the kernel to talk to other devices, but I would like to discourage "lightweight" is "better" when we have perfectly fine AES for your desktop needs (someone somewhere will encrypt their disk with it with LUKS for no logical reason).
Yes indeed. The arguments against it are entirely political.
I'm not sure "attack" is helpful in this context. I'm not accusing anyone of attacking anyone else.
As an example, my view that lightweight crypto is largely useless is somewhat political, based on practical concerns. We have working AES accelerators and AES instruction sets in chips today we can exploit and for most of my company's customers, that's absolutely enough. I have a view; others disagree and have interesting counter arguments.
On the arguments quoted, there are multiple modes of the algorithms, and a constrained device is unlikely to transmit multiple gigabytes of data using the 48-bit mode mostly because if it can only cope with the 48-bit mode I'd be skeptical it can transmit multiple gigabits of data at all. ARM pointer authentication can use as little as 3 bits of QARMA, although according to Qualcomm the Linux kernel uses 24-bit PACs. This is entirely fine because the point is to require a low-latency check that is reasonably hard to forge over a short window during which exploitation is possible, not gigabytes of data. This is an example of an actually valid use case of lightweight crypto.
Second argument, AES is 100% broken. Yep. Key recovery over full-round AES. If I present just that fact I could make all kinds of arguments for not using AES, but of course I am neglecting to mention the fact that it only improves things by an order of 4 and that 2^126 computations are still required - impossible for 100 NSAs all joined together - to perform it. The time complexity of the attacks on 70% of Speck48/72's rounds is 2^71.8 so... likewise only a marginal improvement, and this isn't even full-round Speck like the AES attacks.
I wasn't at the standardization meetings, so I can't really speak to that, but if the NSA behaved badly then they probably ought to have known better given the fallout from Snowden. I'm not American and I don't owe them any special deference - I also don't trust them and I'm not advocating you should, either. I'm simply saying that to the best of my knowledge the algorithms seem fine. We've made this tradeoff to trust SHA2 before and to circle back around to the original purpose of this article I would be quite surprised to learn there is a backdoor in SHA2. This is mostly based on the fact that there is a huge motivation, in the form of embarrassing the NSA, to find either weaknesses or a backdoor in any publicly acknowledged NSA algorithm and consequently putting "made in Ft. Meade" on an algorithm is a sure fire way to ensure it gets a lot of cryptanalysis.
Anyway, let's leave it there, we've diverging somewhat from the original topic.