4 ms·

Your understanding is correct. Before these leaks and when DH was widespread you could generate your own dhparams file for DH connections, both for sshd and for

Your understanding is correct. Before these leaks and when DH was widespread you could generate your own dhparams file for DH connections, both for sshd and for TLS connections. It was advised to do so in corners that understood what that meant. It's just that many people didn't bother, so the NSA took advantage. The parent comment to yours gets a bit excitable about ed25519 being a prime-rejecting miracle cure. Indeed 2^255-19... is prime. Elliptic curve cryptography still relies on large prime order subgroups for its security and that's not going away until and if quantum computers get good enough to break it. The main advantage of ed25519 is that it is fairly hard to implement badly. No k=3 randomness issues as with ECDSA (you can also use deterministic ECDSA to get this property). Constant time curve constructions. Etc etc. The same team who designed SIMON and SPECK designed SHA2 so, worth thinking about that. My personal opinion is that there's nothing wrong with SIMON and SPECK. However there's also not a lot wrong with AES and so little reason to downgrade to something else in almost all use cases. The reason Germany and Israel kicked them out of ISO was likely entirely politically motivated. I mean if I were them and I'd maybe been stung by some of the Snowden leaks e.g. using weaker crypto, or had lost trust in the NSA, I'd probably do the same. The argument for lightweight crypto is not at all clear. I've heard of people implementing AES in less than 1000 gate equivalents, with the target GE in the NIST lightweight competition being 2000. There is somewhat more justification for lightweight hashing because of say the large internal state size of Keccak not being particularly embedded friendly. But we're talking about super constrained devices here. RFID tags or encrypted flash storage to go with a cortex-m. It's entirely justified to remove SIMON/SPECK from the Linux kernel. To run vanilla Linux you need an MMU, and the cortex-m series of processors that power most embedded stuff don't have one. Even then, they're actually powerful enough to do full TLS anyway if coded properly (bearssl for example).

tialaramex 6y ago
The reason you'd want a super-constrained cheap AXR in Linux isn't because Linux runs on the tiny devices but because Linux talks to the tiny devices. 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.
- zahllos 6y ago
  True true, it does. I'm not sure to what extent it is needed in kernel but I'm sure there are some use cases. 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.
  - dependenttypes 6y ago
    "Political" arguments such as https://twitter.com/tomerashur/status/988696306674630656 https://twitter.com/tomerashur/status/988696306674630656 and https://twitter.com/hashbreaker/status/719889001444839424 https://twitter.com/hashbreaker/status/719889001444839424 ?
    - api 6y ago
      Political doesn't always mean unreasonable. Seems like NSA's behavior was bad.
      - dependenttypes 6y ago
        Sure, but I do not think that "48-bit blocks are a bad idea for encrypting gigabytes of data", "70% of Simon+Speck have been broken", and "the algorithm designers refused to explain the reasoning behind some choices regarding the algorithm and attacked us instead" are political attacks.
        zahllos 6y ago
        We probably have different ideas of what "political" means here. I simply mean that the motivations for dismissing SIMON and SPECK likely have more to do with it being the NSA that proposed them and the Snowden leaks at the time than any particular backdoor in SIMON or SPECK. I am not saying that is a bad thing - it is a line of reasoning and a perfectly valid one. I just think we should be clear that is the reason. 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.

tialaramex 6y ago

The reason you'd want a super-constrained cheap AXR in Linux isn't because Linux runs on the tiny devices but because Linux talks to the tiny devices. 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.

zahllos 6y ago
True true, it does. I'm not sure to what extent it is needed in kernel but I'm sure there are some use cases. 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.
- dependenttypes 6y ago
  "Political" arguments such as https://twitter.com/tomerashur/status/988696306674630656 https://twitter.com/tomerashur/status/988696306674630656 and https://twitter.com/hashbreaker/status/719889001444839424 https://twitter.com/hashbreaker/status/719889001444839424 ?
  - api 6y ago
    Political doesn't always mean unreasonable. Seems like NSA's behavior was bad.
    - dependenttypes 6y ago
      Sure, but I do not think that "48-bit blocks are a bad idea for encrypting gigabytes of data", "70% of Simon+Speck have been broken", and "the algorithm designers refused to explain the reasoning behind some choices regarding the algorithm and attacked us instead" are political attacks.
      - zahllos 6y ago
        We probably have different ideas of what "political" means here. I simply mean that the motivations for dismissing SIMON and SPECK likely have more to do with it being the NSA that proposed them and the Snowden leaks at the time than any particular backdoor in SIMON or SPECK. I am not saying that is a bad thing - it is a line of reasoning and a perfectly valid one. I just think we should be clear that is the reason. 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.