Does anyone who's been following these IoT encryption standards think that new algorithms are truly needed? Considering that even the most trivial embedded devices these days get powerful microcontrollers and megabytes of RAM -- often running a full operating system! -- is there any perceptible gain with one of these unknown lightweight algorithms compared to using a well-known and standard algorithm like AES?
I took a look at the performance tests of AES vs NSA's Simon/Speck done by the CryptoLUX group at the University of Luxembourg[1]. They have so much data comparing different scenarios, processors, and implementation versions that it's difficult to summarize the trade-offs. But my brief look at AES vs Simon/Speck on an 8-bit Atmel AVR processor is that the difference in code size and RAM are in the hundreds of bytes (bytes, not megabytes) and AES performance might be approximately equal (if AES is implemented with large code size and RAM) or up to 10-15 times slower (if implemented with small code size and RAM).
Seriously, embedded software these days is so bloated (just like in web development), and processors and RAM are so over-provisioned, and encryption is such a minuscule part of the tasks of a system that I wonder if using a standard algorithm like AES would make a perceptible difference to anybody.
It's too late to update my original comment, but here are the fastest 128-bit key implementations of AES, Simon, and Speck for the AVR processor according to the CryptoLUX group at the University of Luxembourg:
The differences look insignificant. Code size and RAM requirements are in bytes (not megabytes). In fact, AES might be faster than Simon because the AES encrypts a 128-byte block whereas both Simon and Speck encrypt a 64-byte block; therefore you'd have to encrypt two Simon blocks to get the equivalent of one AES encryption.
It depends on the application. If your IoT thing is plugged into wall power then yeah, you can just use a more powerful chip. If your device is running off of a button cell and needs to last for at least a year then you have to be a lot more conscious of cpu cycles and memory size.
Sensor nets often operate in conditions like that. You don't want to have to change the batteries on something attached to a Zebra any more than absolutely necessary.
Concur completely. My cow-worker located a little package called Tiny-AES * that weighs in at 1848 bytes of code and under 300 bytes of RAM for AES-128 CBC with 128 bit blocks targeting a Cortex M0+ (IAR 8.20.2 EWARM and high optimization).
If companies want every toaster and hair dryer connected to the Internet, they better damn well be sure they are secured. Any performance hit is a small price to pay.
hundreds of bytes is a lot on AVRs. 1 millisecond is a lot on AVRs.
I'd have to go look at their data myself, because AES is slow even compared to ChaCha20, and these algorithms are significantly more lightweight than that.
STM32 unit cost is lower than most AVRs. And dev is just C as well. Also NXP do Cortex M0 parts for $0.45!
AVRs are pretty hard to use when you hit one of the numerous hardware and peripheral walls. synchronous timers are killing me this week which lead me to switch to a PIC part.
> Considering that even the most trivial embedded devices these days get powerful microcontrollers and megabytes of RAM -- often running a full operating system!
Try $0.30 or cheaper with only 1KB ROM and 32-bytes of RAM. (Not kbytes. I said bytes).
----------
The "smallest processors" and "most trivial embedded devices" are just that: incredibly trivial and incredibly small. These are still useful, especially because they use less power than the passive-draw of most components.
When you need basically a voltage-monitor, an inaccurate clock, and a tiny bit of logic, these tiny chips are quite useful.
Sure, but in the context of the conversation, we were talking about Internet of Things devices. How likely is it that you'll choose that 6- or 8-pin IC to make an Internet connection? I'm not saying it's impossible, but you're going to need a lot of support ICs; if you're making an Internet-enabled device you're probably not going to pick the tiniest microcontroller.
Besides, that microcontroller has either 512 or 1024 bytes of flash program memory. That's not enough space to run any of the lightweight encryption algorithms (well, maybe, Simon, but you wouldn't have space to do anything else!).
Lots of low power/radios/IoT whatever chips already come with hardware AES support. If a new standard emerges, that will get a hardware implementation, too.
I took a look at the performance tests of AES vs NSA's Simon/Speck done by the CryptoLUX group at the University of Luxembourg[1]. They have so much data comparing different scenarios, processors, and implementation versions that it's difficult to summarize the trade-offs. But my brief look at AES vs Simon/Speck on an 8-bit Atmel AVR processor is that the difference in code size and RAM are in the hundreds of bytes (bytes, not megabytes) and AES performance might be approximately equal (if AES is implemented with large code size and RAM) or up to 10-15 times slower (if implemented with small code size and RAM).
Seriously, embedded software these days is so bloated (just like in web development), and processors and RAM are so over-provisioned, and encryption is such a minuscule part of the tasks of a system that I wonder if using a standard algorithm like AES would make a perceptible difference to anybody.
[1] https://www.cryptolux.org/index.php/FELICS_Block_Ciphers_Det...