Lightweight Cryptography(csrc.nist.gov)
csrc.nist.gov
Lightweight Cryptography
https://csrc.nist.gov/Projects/Lightweight-Cryptography
45 comments
The NSA developed some light-weight algorithms that were submitted to the ISO, but they were initially rejected due to lingering suspicions:
* https://techmonitor.ai/techonology/cybersecurity/nsa-ciphers...
* https://en.wikipedia.org/wiki/Simon_(cipher)
* https://en.wikipedia.org/wiki/Speck_(cipher)
The ISO went with PRESENT and CLEFIA for ISO/IEC 29192 ("Information technology - Security techniques - Lightweight cryptography"):
* https://en.wikipedia.org/wiki/PRESENT
* https://en.wikipedia.org/wiki/CLEFIA
A bit of a history of that episode:
* https://link.springer.com/chapter/10.1007/978-3-030-10591-4_...
S&S were eventually accepted for ISO 29167.
* https://techmonitor.ai/techonology/cybersecurity/nsa-ciphers...
* https://en.wikipedia.org/wiki/Simon_(cipher)
* https://en.wikipedia.org/wiki/Speck_(cipher)
The ISO went with PRESENT and CLEFIA for ISO/IEC 29192 ("Information technology - Security techniques - Lightweight cryptography"):
* https://en.wikipedia.org/wiki/PRESENT
* https://en.wikipedia.org/wiki/CLEFIA
A bit of a history of that episode:
* https://link.springer.com/chapter/10.1007/978-3-030-10591-4_...
S&S were eventually accepted for ISO 29167.
SPECK is a really attractive design for software implementation. The key schedule and the round function are the same, it's an ARX design that lends itself to naturally constant-time implementation. If the design is free of fault and it gets thrown out because of its origin and admittedly questionable public analysis statements, that's rather unfortunate. Alas, it's hard to trust given the backstory, but on the other hand the author(s) might be relying entirely on cryptanalytic techniques and results they're not able to publish for whatever reason.
>but on the other hand the author(s) might be relying entirely on cryptanalytic techniques and results they're not able to publish for whatever reason
But this is bad, the best way to ensure that some cryptanalytic technique works is to publish it so every cryptographer in the world can review it.
But this is bad, the best way to ensure that some cryptanalytic technique works is to publish it so every cryptographer in the world can review it.
The NSA will never do that as it would be tipping their hand about whatever novel technique they reveal. In the past the NSA actually did provide some constants that went into DES and people were suspicious as the constants weren't randomly chosen. Later on it came out that differential cryptanalysis would have broken the original constants but the NSA provided ones were chosen to thwart this. They clearly knew about it well ahead of it being discovered in academia. Then you have the NSA's shady dealings around Dual_EC_DRBG where there was speculation that this might be similar to when the NSA secured DES against publicly unknown advanced cryptanalytic attacks. Of course for Dual_EC_DRBG that wasn't the case, it was a malicious backdoor, nothing more.
The question comes down to "Is this a repeat of DES or Dual_EC_DRBG?" and the NSA has poisoned the well with their previous attack on cryptography standards.
The question comes down to "Is this a repeat of DES or Dual_EC_DRBG?" and the NSA has poisoned the well with their previous attack on cryptography standards.
> the best way to ensure that some cryptanalytic technique works is to publish it so every cryptographer in the world can review it
The best way to ensure that a design is sound, is to publish it, but that is not true of cryptanalysis techniques. They are generally tied to a mathematical proof, so they can be quite confident of their correctness. A design, on the other hand, has an unknown number of ways in which it can fail.
Also, historically, secret cryptanalyses have proved invaluable in warfare; the most famous examples are the techniques used for Enigma, Lorenz SZ42, and the “Purple” Type B Cipher Machine, which allowed reading various crucial messages from the Nazi and Imperial Japan during WWII; had the techniques been published, the ciphers would have been improved.
There is still a very good reason to not like that situation: first, commercial information is much more sizeable and is arguably much more sensitive nowadays, as warfare is shifting to the weakening of the enemies’ economy (look at Russia turning a blind eye or more on the groups behind the Colonial Pipeline hack). Second, the government’s cryptanalysis effort is financed by the people, so it would be reasonable for them to receive its fruits.
The best way to ensure that a design is sound, is to publish it, but that is not true of cryptanalysis techniques. They are generally tied to a mathematical proof, so they can be quite confident of their correctness. A design, on the other hand, has an unknown number of ways in which it can fail.
Also, historically, secret cryptanalyses have proved invaluable in warfare; the most famous examples are the techniques used for Enigma, Lorenz SZ42, and the “Purple” Type B Cipher Machine, which allowed reading various crucial messages from the Nazi and Imperial Japan during WWII; had the techniques been published, the ciphers would have been improved.
There is still a very good reason to not like that situation: first, commercial information is much more sizeable and is arguably much more sensitive nowadays, as warfare is shifting to the weakening of the enemies’ economy (look at Russia turning a blind eye or more on the groups behind the Colonial Pipeline hack). Second, the government’s cryptanalysis effort is financed by the people, so it would be reasonable for them to receive its fruits.
another reason to not like it: if there are out there ciphers which could be broken with such hypotetic tecnique we miss the chance to move away from them/design ciphers that are robust against that tecnique. which is exactly what secret services usually want to have a cryptographic advantage over enemies, but at the same time they endanger everyone else, as also the enemy coukd independently discover that tecnique and start using that against e.g. businesses.
But both algorithms are confidentiality only, not AE. And they need a lot of rounds to provide any real security.
Who won the encryption against quantum computer?
You likely mean the nist post quantum competition, which is about public key encryption and signatures.
The answer is noone yet, it's still running. Here's the list of proposals currently in the competition: https://csrc.nist.gov/Projects/post-quantum-cryptography/rou...
The answer is noone yet, it's still running. Here's the list of proposals currently in the competition: https://csrc.nist.gov/Projects/post-quantum-cryptography/rou...
These are symmetric ciphers. So.. All of them?
One thing though is that many lightweight block ciphers only have 128 bit keys. So in a PQ context, they will only provide 64 bit strength. Thus might be ok for short term secrets. But if you are building devices (IoT, SCADA) with long lifetimes, you may need to add a key derivation, key exchange scheme.
Last time I checked, all the computers were growing powerful and crypto was relevant neither for latency nor for power consumption on any device capable of joining a network.
It helps that one of the largest factors on choosing crypto algorithms is speed on both general purpose and specialized hardware.
So, count me in the group of people that don't understand why the NIST is doing this. Will they trade any security guarantee for speed? If so, nobody should ever use one of those algorithms. If not, whatever algorithm wins here would also win a new round of general purpose crypto contest.
It helps that one of the largest factors on choosing crypto algorithms is speed on both general purpose and specialized hardware.
So, count me in the group of people that don't understand why the NIST is doing this. Will they trade any security guarantee for speed? If so, nobody should ever use one of those algorithms. If not, whatever algorithm wins here would also win a new round of general purpose crypto contest.
> all the computers
Maybe those machines that don't even spin up a fan with 400 npm dependencies, but billions of of low end embedded devices pumped out annually.
Call me a sceptic but I think the lightcrypto contest is actually something that will benefit society far more than the post-quantum simultaneously underway.
Maybe those machines that don't even spin up a fan with 400 npm dependencies, but billions of of low end embedded devices pumped out annually.
Call me a sceptic but I think the lightcrypto contest is actually something that will benefit society far more than the post-quantum simultaneously underway.
The processing needs of a wifi connection (or any wireless protocol) are overwhelming on dealing with the problems of a radio connection. Unless you are connecting, sending a single package and disconnecting¹, encryption barely registers.
For wired devices things changes a bit. Encryption can be dozens of times more expensive than moving your data around for processing. But if that's a problem, you need to accelerate your encryption in hardware², not to weaken the encryption.
1 - If you are, you are better with some protocol that keeps the encryption setup around between transmissions, not with weaker crypto.
2 - Just like you accelerate the "moving data around" part, because it doesn't go from the network into the main memory for free either.
For wired devices things changes a bit. Encryption can be dozens of times more expensive than moving your data around for processing. But if that's a problem, you need to accelerate your encryption in hardware², not to weaken the encryption.
1 - If you are, you are better with some protocol that keeps the encryption setup around between transmissions, not with weaker crypto.
2 - Just like you accelerate the "moving data around" part, because it doesn't go from the network into the main memory for free either.
Check out the case of storage encryption in smartwatches and very cheap phones. The CPUs do not have AES instructions and doing software AES makes the watch noticeably sluggish. https://lwn.net/ml/linux-crypto/20180806223300.113891-1-ebig...
The question is, are you ok with the encryption being breakable if it makes your watch faster?
Personally, if I'm ok with the encryption being breakable, I'm also ok with not using any encryption at all. I can't imagine a scenario where I would want weak encryption.
Anyway, the way to solve that problem is to get a CPU with AES instructions.
Personally, if I'm ok with the encryption being breakable, I'm also ok with not using any encryption at all. I can't imagine a scenario where I would want weak encryption.
Anyway, the way to solve that problem is to get a CPU with AES instructions.
That tradeoff doesn't exist. No one is proposing weak or breakable encryption. Even the fastest "lightweight" finalists provide full 128-bit security.
If they have 128-bit security, what is the difference between that and a normal contest?
I think the difference is that the focus is on finding more efficient ways to provide the same level of security. Existing algorithms are "good enough" performance-wise for mainstream hardware, but there is much room for improvement without tradeoffs.
For instance, the devices we make are not powerful enough to use the standard crypto algorithms. So we are looking forward to the results. Security, for us, only has to be guaranteed for a limited time: if it cannot be cracked in a few minutes, it does not matter if it ever does. So we benefit from 'not as secure but secure enough'.
Edit; by not powerful enough, we mean both: too high latency and too much energy drain.
Edit; by not powerful enough, we mean both: too high latency and too much energy drain.
Would you mind sharing what protocols you are working on that can benefit from a "lightweight cryptography"?
My impression from learning cryptography in the last 8 years is that cryptographic protocols are either exponentially secure, or any tiny weaknesses can be amplified into a complete break.
The only example of secure "intrapolynomial cryptography" [1] is Proof-of-Work, but it also requires work to be expended continuously. Not exactly a scheme for "underpowered devices".
[1] https://nakamotoinstitute.org/intrapolynomial-cryptography/
My impression from learning cryptography in the last 8 years is that cryptographic protocols are either exponentially secure, or any tiny weaknesses can be amplified into a complete break.
The only example of secure "intrapolynomial cryptography" [1] is Proof-of-Work, but it also requires work to be expended continuously. Not exactly a scheme for "underpowered devices".
[1] https://nakamotoinstitute.org/intrapolynomial-cryptography/
That is why NIST is doing this; most IoT I am aware of, including ours, needs a very secure channel, but for a relative short(er) time. So if it takes 6 hours minimum to decrypt it without having the private key, that would be fine for us and most IoT (that I have seen anyway) but bad for most general purpose computing, where you want 'infinite time' security if you can get it. I think it is a different and undervalued market, resulting often in bad security practices because we have no alternatives. The MCUs we use cost cents and are measured in mhz speed and kbs memory. They do have cryptographic co units but those are not very fast either while generic crypto algos tend to demand more and more power to guarantee longer periods of being decrypted by bad actors.
Edit: note that we are using RSA and, lately, Ed25519, but it takes 5-6s for the heaviest Ops and that is simply way too long. It is however secure and it works, so if that is it than that is it, it is just overkill mostly for what we need.
Edit: note that we are using RSA and, lately, Ed25519, but it takes 5-6s for the heaviest Ops and that is simply way too long. It is however secure and it works, so if that is it than that is it, it is just overkill mostly for what we need.
What happens after 6 hours? Let's say I capture all the data from all the sensors and decrypt it with a 24 hr lag. I don't get a real-time info, but i collect all the patterns and whatever long-term data that's accidentally sent out.
The data needs to reach a server within that period (the real period is much shorter: 5 minutes currently, but it might be 1-2 hours in the future); if it comes in after that, the server will find it invalid and drop it. We currently have it completely secure (modern ECC for instance): we have created a hybrid which refreshes a low power latency/power private key using the traditional means which gives us windows long enough to have low latency and lower power usage while ensuring the encryption holds. Something globally accepted would be better obviously. We have many more prototypes of things we evaluated ourselves but need help (if you know someone with these credentials) with just to solve the latency and power consumption issue.
So the server and device securely agree on something like TOTP list (weak keys with expiration date), so intermediate data can be authenticated within those time windows? But if that applies to encryption too, then won't later bruteforced decryption pose a threat?
If you create an encryption schema designed to survive a few hours of attack, it will automatically be vulnerable to the attacker negotiating a discount with a CPU manufacturer.
If you have a need for lightweight cryptography today, why wait for the NIST competition? Ascon is already the primary recommendation in the lightweight category from the CAESAR competition, and now also a finalist in the NIST competition.
There's probably going to be a strong ecosystem pull towards the winner of any NIST competition. Betting on ASCON too early may mean losing out on mainstream library support. Considering “don't roll your own crypto” is still a golden rule, it seems better to leave the issue alone if you at all can until everyone catches up.
Why not use RC4?
How resource constrained are you? Doesn’t most of your networking gear have crypto built into it already?
How resource constrained are you? Doesn’t most of your networking gear have crypto built into it already?
Apart from being broken RC4 requires 256 bytes of state, have a very slow key change operation. And is actually quite slow.
Most modern lightweight ciphers requires much less state (can be stored in registers even), has good key agility. And are faster. So there are numerous technical reasons to not use RC4.
As long as you don't have legacy requirements, don't use RC4.
Most modern lightweight ciphers requires much less state (can be stored in registers even), has good key agility. And are faster. So there are numerous technical reasons to not use RC4.
As long as you don't have legacy requirements, don't use RC4.
Because RC4 is probably the most egregiously broken cipher that has ever been in common use.
And this is actually an interesting line in the sand here.
SPECK is probably fine. It's a pretty ordinary-looking design, if some 25 year old up-and-coming crypto academic proposed this for an application, nobody would freak out about how maybe it's a cunning trick to steal all our data. But because the NSA was involved and wasn't willing to share whatever methods they're currently using to check this was OK that's apparently reason to shoot it down.
And even though RC4 is very broken (unlike SPECK) it'd still actually be a lot of work to attack many practical applications of RC4. One of the strange things the Web gave us is a real application that looks like the outrageously convenient models in a cryptography class. Want one of the participants to repeatedly send a known plaintext using millions of different keys so you can see what that looks like? Javascript! Need to ensure your payload data is right next to the mystery data you need to decrypt? Cookies! Need to convince a participant to connect to your hostile system and decrypt large volumes of data? Embedded images and HTML email! So on the web, you can build a toy demo that breaks RC4, not really in a real time (I guess at a multi-day conference you could do an afternoon session "Preparing to break RC4" and then a morning session the next day "See, it worked") but for most protocols the attack is not practical. Attacks of course, only get better, so, this is not telling anybody to use RC4 but only underscoring how high the bar is here.
Should you use RC4? No. Definitely not. But is the RC4-encryption for the IoT data feed the weakest link in your system today? Almost certainly also no.
SPECK is probably fine. It's a pretty ordinary-looking design, if some 25 year old up-and-coming crypto academic proposed this for an application, nobody would freak out about how maybe it's a cunning trick to steal all our data. But because the NSA was involved and wasn't willing to share whatever methods they're currently using to check this was OK that's apparently reason to shoot it down.
And even though RC4 is very broken (unlike SPECK) it'd still actually be a lot of work to attack many practical applications of RC4. One of the strange things the Web gave us is a real application that looks like the outrageously convenient models in a cryptography class. Want one of the participants to repeatedly send a known plaintext using millions of different keys so you can see what that looks like? Javascript! Need to ensure your payload data is right next to the mystery data you need to decrypt? Cookies! Need to convince a participant to connect to your hostile system and decrypt large volumes of data? Embedded images and HTML email! So on the web, you can build a toy demo that breaks RC4, not really in a real time (I guess at a multi-day conference you could do an afternoon session "Preparing to break RC4" and then a morning session the next day "See, it worked") but for most protocols the attack is not practical. Attacks of course, only get better, so, this is not telling anybody to use RC4 but only underscoring how high the bar is here.
Should you use RC4? No. Definitely not. But is the RC4-encryption for the IoT data feed the weakest link in your system today? Almost certainly also no.
Exactly. Is it broken? Yes.
Am I going to buy a GPU or a wrench to crack a password? Most definitely a wrench.
I honestly do think if the data only has to be protected for a day, just use RC4 (or something similar).
It’s pretty obvious the data is worth nothing if it’s not even worth an extra battery to properly encrypt.
Am I going to buy a GPU or a wrench to crack a password? Most definitely a wrench.
I honestly do think if the data only has to be protected for a day, just use RC4 (or something similar).
It’s pretty obvious the data is worth nothing if it’s not even worth an extra battery to properly encrypt.
At this point you might as well use Speck; at least there’s a chance it works.
Every thought about all the things besides personal computers and smartphones?
Embedded applications, energy limited (battery, power harvesting) devices, IoT, other resource constrained devices?
I also doubt that more processing = more security.
Embedded applications, energy limited (battery, power harvesting) devices, IoT, other resource constrained devices?
I also doubt that more processing = more security.
The biggest use case for these algorithms is IoT, and other resource constrained embedded devices. Quite frankly, I'm surprised you didn't consider it seeing as insecure IoT devices have been in the news pretty much since they hit the market.
Embedded devices, especially specialised ones arent poweful enough to operate sufficiently while also providing protection via the current "standard" crypto algorithms.
Embedded devices, especially specialised ones arent poweful enough to operate sufficiently while also providing protection via the current "standard" crypto algorithms.
The problem with Internet of Trash devices isn't a lack of cryptography - it's closed, poorly developed, throw-away software. In comparison to implementing a whole wifi stack, some dedicated hardware for AES is trivial. Given that NSA has been trying to get us to use "lightweight cryptography" for decades (eg 512 bit RSA), this seems quite uncompelling.
Furthermore for even smaller devices without Wifi, the "Internet" of things (where Internet means communicating directly over the WAN rather than to a more-capable local device) won't be compelling until the software situation has been sorted out. For example the best practices for using current Wifi smart plugs is to stick them on their own VLAN with no Internet access, communicating only with a local Home Assistant or whatever. There's no reason they themselves need to be on the WAN.
Furthermore for even smaller devices without Wifi, the "Internet" of things (where Internet means communicating directly over the WAN rather than to a more-capable local device) won't be compelling until the software situation has been sorted out. For example the best practices for using current Wifi smart plugs is to stick them on their own VLAN with no Internet access, communicating only with a local Home Assistant or whatever. There's no reason they themselves need to be on the WAN.
A lot of the problems with IoT devices are things like hardcoded keys or passwords shared across all units. LWC doesn’t fix that kind of design problem. I agree LWC has value but I think most IoT products are less cpu-limited and more engineer-limited.
Can someone point to a resource describing why various candidates got rejected in round 1 and round 2?
Any comments on the decisions or was it just voting without explaining?
Any comments on the decisions or was it just voting without explaining?
See NISTIR 8369, available from [0], p. 40 et seq. in particular.
[0] https://csrc.nist.gov/publications/detail/nistir/8369/final
[0] https://csrc.nist.gov/publications/detail/nistir/8369/final
One nice thing about lightweight crypto is that it's easy to port. Implementing ASCON in Go was pretty fun and only took an hour or two: https://github.com/lukechampine/ascon/blob/master/ascon.go
(Obviously it wouldn't make a ton of sense to use Go if you're resource-constrained, but having a library is worthwhile for compatibility reasons regardless.)
(Obviously it wouldn't make a ton of sense to use Go if you're resource-constrained, but having a library is worthwhile for compatibility reasons regardless.)
Many older lightweight algorithms (or AES) for that matter requires adding either an authentication mode, or another primitive (a hash function used in HMAC for example)
I believe that has led to a problematic proliferation of only having confidentiality protection in too many IoT systems deployed.
These candidates makes it easier for developers to add the security properties their system actually needs.