NIST selects ‘lightweight cryptography’ algorithms to protect small devices(nist.gov)
nist.gov
NIST selects ‘lightweight cryptography’ algorithms to protect small devices
https://www.nist.gov/news-events/news/2023/02/nist-selects-lightweight-cryptography-algorithms-protect-small-devices
71 comments
Your link redirects to a random Wikipedia if the referrer is HN.
I got Freddy the Pig. https://en.m.wikipedia.org/wiki/Freddy_the_Pig
Link with no referrer: https://noreferrer.cc/?https://codahale.com/the-joy-of-duple...
Joan Daemen even lost twice in one competition! Subterranean 2.0, another Duplex, didn't make it past round 2.
Why is it good that he lost?
They are joking about it, because he used to win. There's nothing good or bad about him losing.
I’m not a crypto expert, but you can get 8 bit Atmel / Microchip AVRs with AES units on them (for example), are “special” lightweight algorithms actually needed, or should we just be encouraging the use of MCUs with suitable accelerators for proven algorithms?
They're not just optimized to "fit" into small devices, but also for handling things like ultra-small messages, which is a common requirement in RF protocols.
AES can handle ultra small messages just fine and a hash's security is based off of its length.
AES-what? AES is a block transform. Ascon is an AEAD construction.
They're also expensive. At least last time I priced them out, they cost more than the radio and MCU.
I was thinking of on chip accelerator units / peripherals, like the AVR Xmega AES example, rather than external chips.
Afaik these LWCs are supposed to also be easier to implement in HW (=smaller die area/gate count), but I'm also wondering is the difference really meaningful especially with current manufacturing tech? I imagine there are limits on die size reductions where the returns really start diminishing very quickly.
Most microcontrollers are done on as large nodes as possible to reduce cost, so probably?
A brief search on Mouser seems to indicate that The AVR Xmega costs roughly 2.5 times as much as other 8 bit MCUs from Atmel with comparable amounts of flash/RAM -- are there other "selling point" on-chip perpiherals significantly contributing to that cost?
Generally a lot more stuff than the average AVR, so (IIRC) you have a multi level interrupt controller, a DMA unit, more adaptable clock / power configuration, and just more of things like UARTS and ADCs (which tended to have more features) and so on[1]. It feels more like an AVR core bolted onto something nearer to the “everything and a kitchen sink” peripheral set you get with a 32 bit ARM MCU. The projects I worked on weren’t particularly super cost sensitive though, so I’m perhaps a bit isolated from the “every cent matters” level.
(Also, you’d probably just use one of those 32 bit ARM chips nowadays).
[1] I don’t have an encyclopaedic knowledge of the AVR range and haven’t looked at in a couple of years, so I’m sure some of the advanced stuff is available on Mega models.
(Also, you’d probably just use one of those 32 bit ARM chips nowadays).
[1] I don’t have an encyclopaedic knowledge of the AVR range and haven’t looked at in a couple of years, so I’m sure some of the advanced stuff is available on Mega models.
cheapest one I found with AES is ~$1.5
https://eu.mouser.com/ProductDetail/STMicroelectronics/STM32...
There are probably even cheaper ones
https://eu.mouser.com/ProductDetail/STMicroelectronics/STM32...
There are probably even cheaper ones
You can also get crypto coprocessors to accelerate such operations, without switching platforms or sacrificing for example power usage.
Ascon specs, reference code and benchmarks: https://ascon.iaik.tugraz.at
Competitors: https://asecuritysite.com/light
Competitors: https://asecuritysite.com/light
I’m really surprised to not see Chacha/Poly on that list as an AEAD.
XTEA made it as a competitor but chacha didn’t?
I don’t understand cryptography at all.
XTEA made it as a competitor but chacha didn’t?
I don’t understand cryptography at all.
Chapoly isn't a lightweight design; it's a conventional design. Gimli is, I think, Bernstein's lightweight design (or the core of it).
This site compares the lwc finalists to chachapoly https://rweather.github.io/lwc-finalists/performance_avr.htm...
I suppose being up to 3.8 times faster with these early implementations is somewhat significant benefit.
I suppose being up to 3.8 times faster with these early implementations is somewhat significant benefit.
What is expected security margin? Chacha20 is many orders of magnitude more than impossibly strong, cf. AES which is as safe as needed and not safer.
This is in the paper.
The currently best cryptanalytic attacks on the Ascon authenticated encryption (excluding misuse scenarios) can recover the secret key with a time complexity of about 2 104 only if the initialization is reduced to 7 of 12 rounds, which corresponds to a security margin of 42%
The currently best cryptanalytic attacks on the Ascon authenticated encryption (excluding misuse scenarios) can recover the secret key with a time complexity of about 2 104 only if the initialization is reduced to 7 of 12 rounds, which corresponds to a security margin of 42%
There's an attack on 128-bit Salsa7 with time complexity 2^109, and an attack on 128-bit ChaCha6 with 2^107.
...on 8 bit.
On 32 bit the difference is much smaller and SLOWER on the IOT darling ESP32.
This whole thing seems entirely not worth it thb
On 32 bit the difference is much smaller and SLOWER on the IOT darling ESP32.
This whole thing seems entirely not worth it thb
I don't understand "lightweight" encryption. Either it's secure, and then it would make sense to use it for everything due to the lower resource consumption, or it can be broken. What am I missing here?
- Time/space tradeoffs, to enable use on limited memory devices. Large block and keys sizes and Lists are undesirable, even if more cycles are required.
- Time/margin tradeoffs: if the attacker can only meaningfully attack in the next 24 hours, do you need margin to protect against all of AWS crunching for a million years? Or would you like the computation done in a tenth the time?
- Architectural properties, such as the susceptibility to differential power analysis: maybe you will risk that more via a LUT in exchange for lower power.
- As you increase the number of rounds, algorithms tend to get stronger. But some algorithms have E.g. good avalanche properties for many fewer rounds.
The tiniest devices are things like RFID chips.
- Time/margin tradeoffs: if the attacker can only meaningfully attack in the next 24 hours, do you need margin to protect against all of AWS crunching for a million years? Or would you like the computation done in a tenth the time?
- Architectural properties, such as the susceptibility to differential power analysis: maybe you will risk that more via a LUT in exchange for lower power.
- As you increase the number of rounds, algorithms tend to get stronger. But some algorithms have E.g. good avalanche properties for many fewer rounds.
The tiniest devices are things like RFID chips.
It might make tradeoffs that make it unacceptable in other situations, particularly ones that are focused on being resource constrained in some way.
For example it could have low RAM usage, but become exponentially slower with message size, so it's fine for encrypting short messages only.
Or it could have a constant overhead somewhere that's fine for an IoT device that sends a report once a day, but not if you wanted to make thousands of connections per second.
Stuff like that, is my naive understanding.
For example it could have low RAM usage, but become exponentially slower with message size, so it's fine for encrypting short messages only.
Or it could have a constant overhead somewhere that's fine for an IoT device that sends a report once a day, but not if you wanted to make thousands of connections per second.
Stuff like that, is my naive understanding.
In fact, in this particular case, the winner is also a general-purpose cipher contender.
Some constraints could be small ram, small messages, very little storage.
If you want a fun little project, try porting ASCON to your language of choice! Shouldn't take more than a couple hours. Here's mine (in Go): https://github.com/lukechampine/ascon
I suppose if Ascon is widely adopted, it'll be worth adding an optimized assembly implementation...
I suppose if Ascon is widely adopted, it'll be worth adding an optimized assembly implementation...
Have got you covered there… https://github.com/ericlagergren/lwcrypto/tree/main/ascon
https://github.com/ascon/ascon-c
I was hoping for a simple piece of C code that did the job under 30 lines ... as usual, it's a forest of implementations.
[EDIT]: for comparison: https://gimli.cr.yp.to/spec.html
I was hoping for a simple piece of C code that did the job under 30 lines ... as usual, it's a forest of implementations.
[EDIT]: for comparison: https://gimli.cr.yp.to/spec.html
Discussed yesterday: https://news.ycombinator.com/item?id=34693629
I'm not that familiar with the IoT ecosystem. What are the use cases for this standard and what are those use cases using instead of this standard at present? IoT implies connected to internet? So they have a full TLS stack? They send everything in the clear? .. They use TDES :)? Or they just use an non-standardized algorithm?
If you buy a $5 wifi-enabled lightbulb, there's a good chance it'll have an ESP32 (which can do most modern SSL) or an ESP8266 (which is short on memory, and so might use SSL with a preshared key, "TLS-PSK")
On the other hand, if $5 devices seem a bit expensive to you, because you think $0.01 parcel labels will be part of the internet of things in the future, I suppose you might be interested in this new NIST algorithm?
On the other hand, if $5 devices seem a bit expensive to you, because you think $0.01 parcel labels will be part of the internet of things in the future, I suppose you might be interested in this new NIST algorithm?
I understand that, but these devices, how will they access the "internet"? They need to talk to a router or other device that is then connected to the internet. What protocol would they use to connect? Or is this for just "near-me area networks" that need to communicate with each other? I never really considered key fobs or pacemakers as IoT devices because they don't actually connect to the internet.
Yes, some IoT devices communicate over WiFi, but others will talk to a gateway or hub over something else, such as BLE or Zigbee. I guess those could be the targets for this.
Pacemakers definitely need security though. Although I don't see why they can't use AES like everything else.
The ESP32-A1S is a fun toy to program with that lib https://github.com/pschatzmann/arduino-audio-tools on that cheap kit: https://docs.ai-thinker.com/en/esp32-audio-kit
For example LoRaWAN uses AES-CTR and AES-CMAC. BLE uses AES-CDC. Both are relatively easy to implement on Cortex M0 and up (which start at 10-30 cents).
Would this be a good candidate for encryption on local Wi-Fi (WPA)?
> The chosen algorithms are designed to protect information created and transmitted by the Internet of Things (IoT), including its myriad tiny sensors and actuators. They are also designed for other miniature technologies such as implanted medical devices, stress detectors inside roads and bridges, and keyless entry fobs for vehicles
Edit because I hit the button too soon: no, wifi devices have enough resources to use better encryption, and do.
Edit because I hit the button too soon: no, wifi devices have enough resources to use better encryption, and do.
The encryption we're talking about with these constructions is quite strong. It'd be interesting to try to articulate what's "better" about the alternative "heavyweight" algorithms you might use instead.
These "lightweight" algorithms aren't just low resource usage, they're tuned for small messages. CAESAR also had a "high-performance" category, for AEADs optimized for large messages and streaming data.
If you're limited to small packets on rare occasions and want to have minimal battery drain (e.g. a battery-powered LoRaWAN-style sensor) a "lightweight" algorithm like Ascon is good. For most "normal" uses a "high-performance" algorithm like AEGIS is good, as are AES-GCM, AES-OCB, AES-GCM-SIV, and ChaCha20-Poly1305. When you'd pick which cipher is rather complicated to answer.
If you're limited to small packets on rare occasions and want to have minimal battery drain (e.g. a battery-powered LoRaWAN-style sensor) a "lightweight" algorithm like Ascon is good. For most "normal" uses a "high-performance" algorithm like AEGIS is good, as are AES-GCM, AES-OCB, AES-GCM-SIV, and ChaCha20-Poly1305. When you'd pick which cipher is rather complicated to answer.
The "lightweight" category is also apparently much better at resisting side channel attacks and is also much easier to do cryptanalysis on.
It's not always clear in what ways the non-"lightweight" categories are better other than having bigger keys and state.
It's not always clear in what ways the non-"lightweight" categories are better other than having bigger keys and state.
This; not many 64 bit MCUs out there, or with SIMD pipelines. Although RISCV could change that.
Sponge cipher is not seekable and as a consequence not parallelizable.
Somewhat confusing, because IoT implies they'd be connected to the internet, no?
I'm wondering how these compare to existing hardware accelerated AES?
[deleted]
Lightweight = NSA-crackable, right?
There are all kinds of different adversary models: these kinds of algorithms are tailored towards IoT or short-term communications use cases, where size and performance on constrained devices are more important than being secure against a nation state for X years.
For example: you may have a “smart” device in your household that indicates whether you’re home or not. You don’t want a passive adversary to be able to snoop its RF traffic, but you also don’t need its traffic to be secure for more than one week. “Lightweight” algorithms are meant to give you formal guarantees around that, while also balancing performance, power consumption, and other interests.
For example: you may have a “smart” device in your household that indicates whether you’re home or not. You don’t want a passive adversary to be able to snoop its RF traffic, but you also don’t need its traffic to be secure for more than one week. “Lightweight” algorithms are meant to give you formal guarantees around that, while also balancing performance, power consumption, and other interests.
More like "lightweight" in terms of code size (or hardware equivalents like FPGA fabric area), RAM requirements, and CPU cycles per byte of encryption/authentication. In some cases this means that a message could be brute forced slightly more quickly. But in practical terms that not a big deal, who cares if someone can crack your code in 2^10 years instead of 2^14.
I think for most crypto, brute force times aren't the biggest concern. What's more potentially an issue is the breakability of the algorithm (is there a way to find the plaintext more efficiently than brute forcing?) and how susceptible the algo's implementations are to things like timing attacks (which can be an issue with s boxes although maybe not as big of a deal as I thought considering the results of the competition).
In terms of NSA conspiracy theories, it would've been more of an issue if the competition had gone towards Simon or Speck (which weren't eligible because they're block ciphers, but there's ways to adapt... I think OCB mode is no longer patent encumbered.
I think for most crypto, brute force times aren't the biggest concern. What's more potentially an issue is the breakability of the algorithm (is there a way to find the plaintext more efficiently than brute forcing?) and how susceptible the algo's implementations are to things like timing attacks (which can be an issue with s boxes although maybe not as big of a deal as I thought considering the results of the competition).
In terms of NSA conspiracy theories, it would've been more of an issue if the competition had gone towards Simon or Speck (which weren't eligible because they're block ciphers, but there's ways to adapt... I think OCB mode is no longer patent encumbered.
No, more tuned for small message sizes, code size, RAM usage, power usage, etc. The security goals are essentially the same as the "high performance" ciphers, but the performance trade-offs are different.
No. Size of algorithm is unrelated to security.
add "at scale" (= IoT edge devices)?
Two algorithms by the were rejected by the ISO folks for an IoT standard a few years ago:
* https://www.schneier.com/blog/archives/2018/04/two_nsa_algor...
* https://www.schneier.com/blog/archives/2017/09/iso_rejects_n...
* https://www.schneier.com/blog/archives/2018/04/two_nsa_algor...
* https://www.schneier.com/blog/archives/2017/09/iso_rejects_n...
SIMON and SPECK weren't in the Lightweight Crypto Competition, and couldn't have been, as neither is an AEAD.
Would you mind rephrasing? I'm confused by your comment.
Missing an important word: "Two algorithms by the NSA were...".
Presumably it helped that Ascon was also a CAESAR finalist.
Ascon is a Duplex Sponge construction, and an extremely good introduction to that concept is here:
https://codahale.com/the-joy-of-duplexes/
(Xoodyak, Coda's preferred Duplex, was a contestant --- Daemen's contestant, in fact.)