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.
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.
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.
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%
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.
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.
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'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?
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.
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).
> 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.
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.
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.
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.
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.
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.)