NIST Finalizes 'Lightweight Cryptography' Standard to Protect Small Devices
125 comments
·August 13, 2025loeg
tptacek
I feel like you need to be read in, at least a little bit, into what's going on in cryptography research before you take statements like this at face value, because a lot of pretty serious people work on lightweight cryptography constructions and primitives.
(I'm not dissing Green here; I'm saying, I don't think he meant that statement to be proxied to a generalist audience as an effective summation of lightweight cryptography).
adastra22
There’s a very serious point here. Cryptographers are and always have been deeply concerned with performance. Some of the most skilled low level optimization people I know work on cryptography. It is only relatively recently that computer hardware has gotten powerful enough that cryptography isn’t a serious bottleneck for production systems. In all the recent new crypto standards, a big decision in the whittling down of the finalists was performance.
If someone is telling you that we need a new, faster standard for cryptography, and the selling point is “faster,” you’d better wonder why that wasn’t the standard already in use. If there is not some novel, brand new algorithm that is being employed, the answer is because it is insecure. Or at least that it doesn’t meet the level of security for general use, which took a cryptographer is approximately the same thing.
aseipp
Performance is an evolving target. Meta reported they spend ~0.05% (1 out of every 2000 CPU cycles) on X25519 key exchange within the last year, which is quite significant. If that can be brought down, that's worthwhile. And ongoing research and deployment of PQC will make key exchange even more expensive.
> 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.
conradev
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.
wmf
If the selling point is “faster,” you’d better wonder why that wasn’t the standard already in use.
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.
throw0101a
> It is only relatively recently that computer hardware has gotten powerful enough that cryptography isn’t a serious bottleneck for production systems.
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...
tptacek
"If there is not some novel, brand new algorithm that is being employed, the answer is because it is insecure."
No, this is not at all true.
jona-f
This thread fails to mention that a cipher has to be somewhat hard to compute or someone with a lot of resources can't just brute force it. Therefore you also want an implementation of a given cipher to be as efficient as possible, so that no future improvement lowers the security of your cipher.
ignoramous
> computer hardware has gotten powerful enough that cryptography isn’t a serious bottleneck for production systems ... someone is telling you that we need a new, faster standard for cryptography, and the selling point is “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...
null
rocqua
That feels too reductive.
The point of these primitives is not to trade security for ease of computation. The point is to find alternatives that are just as strong as AES-128 but with less computation. The trade-off is in how long and hard people have tried to break it.
tptacek
That's one of the tradeoffs but the most subtextual of them; the bigger tradeoff is that lightweight constructions are optimized for constrained environments, and outperform only on platforms that don't already do a good job with things like AES. That's the answer for why we wouldn't "just call it cryptography": things that perform well (1) on constrained platforms (2) for the kinds of messages exchanged by constrained platforms will probably tend to get their asses kicked by AES on non-constrained platforms.
Taek
When you say "get their asses kicked", you mean in terms of performance right? Both sets of cryptography are secure under the same set of assumptions, it's just that one is more performant on limited instruction sets and the other is more performant on full featured instruction sets?
mananaysiempre
This is why eSTREAM’s decision to leave MCU-class software essentially unaddressed puzzles me. What do I use on an 8-bit or 16-bit controller with no wide multiplies and no barrel shifter? Before this (which seems fine if not exactly tiny at first glance), there was... Gimli (with the same caveats)? Speck?
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.
thmsths
I am in now way a crypto expert, just someone who enjoys casually reading about it. But in my mind even a security for speed trade off can be worthwhile. Otherwise the alternative is often: no crypto at all because it won't run on that tiny MCU and we don't have the budget for a hardware accelerator.
Taek
Even the tiniest MCU can typically perform more than one cryptographic operation per second. If your MCU has any cycles to spare at all it usually has enough cycles for cryptography.
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.
ebiederm
I am not up to speed on these new algorithms. I still remember there was a light weight cryptography algorithm a few years ago championed by the NSA that had a subtle (possibly deliberate) flaw in it.
When dealing with cryptography it is always necessary to remember cryptography is developed and operates in an adversarial environment.
Sanzig
Speck? To my knowledge there aren't any serious flaws despite a lot of public cryptanalysis. I think what sank Speck was that it came out a few years after after the Dual_EC_DRBG fiasco and nobody was ready to trust an NSA developed cipher yet - which is fair enough. The NSA burned their credibility for decades with Dual_EC_DRBG.
corranh
That would be correct if the question was ‘For a $2000 32-core desktop should we switch to lightweight cryptography’.
The question is should we switch from some ridiculously insecure crappy crypto on a $3 part to this better lightweight crypto implementation.
Yah, we probably should, it’s better than what we had right?
riedel
RFID tags might be rather in the area of $0.03. Other devices might have some hard memory constraints. For other targets it is rather about making hacking a bit more difficult rather that protecting sensitive data against malicious international actors. > Devices that can benefit from its approach include RFID tags, implanted medical devices, and toll-registration transponders attached to car windshields
cvwright
Good news. We’ve waited so long that AES is pretty damn lightweight now too.
Sanzig
Eh, the problem with AES is side channel attacks in software implementations. They aren't necessarily obvious, especially if you're deploying on an oddball CPU architecture.
This standard targets hardware without AES accelerators like microcontrollers. Now, realistically, ChaCha20-Poly1305 is probably a good fit for most of those use cases, but it's not a NIST standard so from the NIST perspective it doesn't apply. Ascon is also a fair bit faster than ChaCha20 on resource constrained hardware (1.5x-3x based on some benchmarks I found online).
stouset
Knowing how much of a dog SHA-3 is due to its sponge construction basis, it’s superficially surprising to me to see a sponge-based LWC algorithm.
I guess we’ve had quite a few years to improve things.
npteljes
Nothing stops us from qualifying "cryptography" with an adjective to refer to a specific part of it, while still referring to full-fledged cryptography. See the Wikipedia article for examples.
"Elliptic Curve Cryptography"
"Post-quantum cryptography"
"Public-key cryptography"
yalogin
Those qualifiers in front of cryptography are very different from lightweight. Lightweight doesn’t convey a good meaning in general and that is the main issue.
I haven’t looked at the lightweight crypto proposals though but if NIST is proposing it I am optimistic. If the proposals from various cryptographers around the world made through all the process it’s pretty good.
npteljes
This is now besides the original point, which was that in cryptography's case, "lightweight" would work like "alternative" works for "alternative medicine".
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.
glitchc
This is facetious. Some protection is better than no protection.
If "every little bit helps" is true for the environment, it's also true for cryptography, and vice versa.
stouset
> Some protection is better than no protection.
No, not really.
Algorithms tend to fall pretty squarely in either the “prevent your sibling from reading your diary” or the “prevent the NSA and Mossad from reading your Internet traffic” camps.
Computers get faster every year, so a cipher with a very narrow safety margin will tend to become completely broken rapidly.
adrian_b
That classification has more steps.
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.
theteapot
The environment? As in trees?
throw0101c
The IETF has published TLS cipher suites with zero cryptography, "TLS 1.3 Authentication and Integrity-Only Cipher Suites":
* https://datatracker.ietf.org/doc/html/rfc9150
Lightweight cryptography could be a step between the above zero and the 'heavyweight' ciphers like AES.
2OEH8eoCRo0
> We encourage the use of this new lightweight cryptography standard wherever resource constraints have hindered the adoption of cryptography
coppsilgold
They chose Ascon which is a good set of same sponge-based cryptographic functions if you don't have hardware acceleration for AES or the CPU resources for chacha20 which is the intention of the standard. The security is 128-bits (comparable to AES-128).
skeezyboy
i too approve of their choice of cryptographic functions, if not a little miffed they didnt come to me first
null
rocqua
This is pretty cool. But IOT tends to fail hard on key agreement. And nothing here solves that. This seems to pretty much require a pre installed key, otherwise the overhead of securely installing a key would probably nullify the advantage of this encryption.
tptacek
Right, it's a competition to standardize authenticated encryption constructions, not entire cryptosystems.
LeGrosDadai
By the same token AES is useless as well, because it doesn't address key exchange. This was not the goal of this standardization process.
rocqua
My point was that AES and SHA are not the reason IOT cryptography is so often broken or missing. Instead its getting the keys onto the system in a halfway secure manner that is the blocking issue.
Hence I'd be a lot more enthusiastic about NIST guidance on these points.
LeGrosDadai
Ah, I see. That's indeed an interesting point. At any rate, IOT cryptography can use this standard as a building point, so it is a step in the right direction anyway.
dvdkon
A pairing system as seen in e.g. Zigbee or BLE seems pretty good to me. Not everyone cares to implement it well and there's still no standard for web-based devices, but it's here and it works.
I'd like to see more devices able to pair with NFC, but even that's standardised for Bluetooth, just underused.
brohee
The world that the algorithm targets is exactly where is this doable. MCUs typically have a protected OTP area that makes it a good place to inject keys right in the factory.
saaspirant
I wonder whether this is backdoored by NSA as well
LeGrosDadai
There is a lot of cryptanalysis on it: https://eprint.iacr.org/search?q=ASCON Furthermore, it is not designed by NIST.
jeffrallen
Yup, NIST has no business putting their names on anything cryptographic anymore.
SV_BubbleTime
Did I miss something recent? Or are we going back to the DES days?
0xfffafaCrash
While not exactly recent, I think most people have Dual_EC_DRBG in mind these days when it comes to NIST and backdoors
null
le-mark
Wikipedia says Ascon has 320 bits of state and uses 5 bit s-boxes. That’s tiny compared to sha-256 or Blake2. One would think a pre image attack would be much more tractable at that scale.
adrian_b
This says very little about the strength of the cipher.
The initial state of ChaCha20 also has only at most 320 unknown bits (512 bits - 128 constant bits - 64 bits of a nonce). Actually you normally also know the counter, so there are only 256 unknown bits.
Of course the actual strength of the cipher cannot exceed the size of the state, but the design strength must be much lower for this cipher. It competes with AES-128, which is designed for an 128-bit strength.
320 bits of state is more than enough for a cipher that must have an 128-bit strength, or even for a cipher designed for a 256-bit strength, like AES-256 or ChaCha20.
201984
No? SHA-256 has only eight 32-bit words of state which is even less than Ascon. BLAKE2s looks the same.
dchest
Sponges divide state into rate (r) and capacity (c). They "absorb" incoming bytes, perform permutation (moving bits around without losing any of them) on the whole state, and "squeeze" out bytes from the rate, while capacity remains hidden.
For the secure hash function, the capacity should be at least twice the target, that is for 128-bit security you need 256 bits of capacity. ASCON hash uses 256 bit capacity and 320-256 = 64 bit rate, so to get a 32-byte hash of a 8-byte string (without padding), you'll need to do at least 4 permutations.
If you can design a secure permutation that permutes 257 bits, you can make a secure, but impractical hash function from it by setting the rate to 1 bit.
For the duplex mode that's used for authenticated encryption, capacity can be lower, because it's keyed -- it's 192 bits in ASCON.
This assumes the permutation of the 320-byte state itself is secure, of course.
ahoka
If these primitives are less resource intensive than what we use today with the same level of security, then why don't we just use these everywhere? If they are not as secure, then why would be use these anywhere?
tracker1
Your front door isn't a hardened steel vault door... I'm assuming you still lock it.
This is a bad analogy, even it it's apt. Only in that an encryption scheme can be technically weaker than another, but still plenty secure. As long as it does the job and hasn't been broken.
For example, part of the spec is simply hashing and packet signing... not necessarily making the packets secret, but authenticating the origin/source. It isn't necessarily about creating the most secure vault in the world, but securing what might otherwise be completely insecure channels of communications/attack. It's also not about a $1000 smart phone, but a micro controller that's a fraction of a dollar on devices that have a total BoM that is very low cost or small.
dazhbog
Why not use chacha20 or xtea for embedded devices? They are lighter than AES..
anfilt
While I know people where a little sceptical of it. I honestly liked the speck cipher that was published.
This cipher is a lot more heavy.
gnubee
A land shanty is just called a song. It's protective cryptography or not. Binary.
npteljes
"Lightweight" here doesn't stop it from proper cryptography. In this case, the qualifier doesn't take away from the original meaning, just focuses it on a subset. Like "public-key cryptography".
Onavo
Are these for garage doors and doorbells? Those devices could definitely use more security (it's not hard to stuff a proper TLS stack in a microcontroller but manufacturers balk at even putting something as cheap as a ESP32 in their BOM).
tptacek
Also for currently-constrained platforms for which hardware updates are infeasible, software updates aren't, and cryptographic security is currently compromised due to lack of availability of appropriate constructions.
brohee
You'd change the coin cell in an ESP32 powered garage door fob monthly... Unacceptable to most.
sowbug
Any remote control's microcontroller would be in deep sleep most of the time, and computationally expensive key exchange would be rare.
I have a few of these ESP-8266 remotes, and battery life is fine. https://github.com/mcer12/Hugo-ESP8266
indolering
Really glad a sponge function won, they are a big step forward in terms of crypto engineering!
jeffrallen
s/NIST/NSA/g
> If lightweight cryptography was a good idea, we’d just call it “cryptography.”
https://x.com/matthew_d_green/status/1948476801824485606