I guess we’ve had quite a few years to improve things.

If you don't have any cycles to spare, you can upgrade to an MCU that does have cycles to spare for less than $0.50 in small batches, and an even smaller price delta for larger batches.

Any device that doesn't use cryptography isn't using it because the manager has specifically de-prioritized it. If you can't afford the $0.50 per device, you probably can't afford the dev that knows his way around cryptography either.

I’m guessing that the chip area of hardware AES is utterly inconsequential compared to all the peripherals you get on a modern micro, but the manufacturers are going to keep charging specialized-applications money for that until we’re all on 32-bit ARMs with multipliers and ChaCha becomes viable.

No, this is not at all true.

Because the field of cryptography advances? You could have made the same argument about Salsa/ChaCha but those are great ciphers. And now we have Ascon which has the same security level but I guess is even faster.

Google needed faster than standard AES cryptography for File-based Encryption on Android Go (low cost) devices: https://tosc.iacr.org/index.php/ToSC/article/view/7360 / https://security.googleblog.com/2019/02/introducing-adiantum...

> If there is not some novel, brand new algorithm that is being employed, the answer is because it is insecure.

Lol that is just not true at all. A major point of discussion when NIST announced the SHA3 finalist being Keccak back in ~2012(?) was that BLAKE1 at the time offered significantly better software performance, which was considered an important practical reality, and was faster than SHA-2 at a higher (but insignificantly so) security margin; their own report admitted as much. The BLAKE1 family is still considered secure today, its internal HAIFA design is very close to existing known designs like Merkle–Damgård, it isn't some radically new thing.

So why did they pick Keccak? Because they figured that SHA-2 was plenty good and already deployed widely, so "SHA-2 but a little faster" was not as compelling as a standard that complimented it in hardware; they also liked Keccak's unique sponge design that was new and novel at the time and allowed AEAD, domain separation, etc. They admit ultimately any finalist including BLAKE would have been a good pick. You can go read all of this yourself. The Keccak team even has new work on more performant sponge-inspired designs, such as their work on Farfalle and deck functions.

The reality is that some standards are chosen for a bunch of reasons and performance is only one of them, though very important. But there's plenty of room for non-standard things, too.

  If the selling point is “faster,” you’d better wonder why that wasn’t the standard already in use.

My desktop CPU has AES in hardware, so it’s fast enough to just run AES.

My phone’s ARM CPU doesn’t have AES in hardware, so it’s not fast enough. ChaCha20 is fast enough, though, and especially with the SIMD support on most ARM processors.

All this paper is saying is that ChaCha20 is not fast enough for some devices, and so folks had to put in intellectual effort to make a new thing that is.

But even further: everyone’s definition for “fast enough” is different. Cycles per byte matters more if you encrypt a lot of bytes.

Or we've had enough "spare" transistors and die space to devote some to crypto, hashing, and checksumming instructions. I remember the splash Sun made when they announced on-die crypto hardware in 2007 (as well as on-die 10 GigE):

* https://en.wikipedia.org/wiki/UltraSPARC_T2

* PDF: https://www.oracle.com/technetwork/server-storage/solaris/do...

Some things must be encrypted well enough so that even if NSA records them now, even 10 years or 20 years later they will not be able to decipher them.

Other things must be encrypted only well enough so that nobody will be able to decipher them close to real time. If the adversaries decipher them by brute force after a week, the data will become useless by that time.

Lightweight cryptography is for this latter use case.

However if we shift the focus to marketing, lightweight works nothing like that in that regard. They use it to imply that the product is fast, lean, to the point, contains nothing unnecessary, has fewer, but solid options, energetic, aspiring. Implying that the other products are heavier, bulkier, cumbersome, bloated, slow, overcumbered, overly complex.

It's already used in for example LDAP, which I don't think anyone scoffs at (well, with regards to the lightweight qualifier), and lightweight software has its own wiki page, implying that the usage of the term wrt/ software is widespread enough to be notable. They write that this means "a computer program that is designed to have a small memory footprint, low CPU usage, overall a low usage of system resources".

All this to write that lightweight conveys a good meaning indeed. About the only widespread negative usage I can think of is when people call others "lightweights", implying that they performed below expectations.

I'd like to see more devices able to pair with NFC, but even that's standardised for Bluetooth, just underused.

https://en.wikipedia.org/wiki/Dual_EC_DRBG