NIST selects ‘lightweight cryptography’ algorithms to protect small devices
nist.gov
nist.gov
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.)
(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.
https://eu.mouser.com/ProductDetail/STMicroelectronics/STM32...
There are probably even cheaper ones
Competitors: https://asecuritysite.com/light
XTEA made it as a competitor but chacha didn’t?
I don’t understand cryptography at all.
I suppose being up to 3.8 times faster with these early implementations is somewhat significant benefit.
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%
On 32 bit the difference is much smaller and SLOWER on the IOT darling ESP32.
This whole thing seems entirely not worth it thb
- 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.
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.
I suppose if Ascon is widely adopted, it'll be worth adding an optimized assembly implementation...
Your 'fixed' package is wild btw. I've been looking for a good 256-bit division algorithm, might have to copy yours. :)
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
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?
Edit because I hit the button too soon: no, wifi devices have enough resources to use better encryption, and do.
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.
It's not always clear in what ways the non-"lightweight" categories are better other than having bigger keys and state.
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.
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.
* https://www.schneier.com/blog/archives/2018/04/two_nsa_algor...
* https://www.schneier.com/blog/archives/2017/09/iso_rejects_n...