[HN Gopher] NIST Finalizes 'Lightweight Cryptography' Standard t...
___________________________________________________________________
NIST Finalizes 'Lightweight Cryptography' Standard to Protect Small
Devices
Author : gnabgib
Score : 48 points
Date : 2025-08-13 20:43 UTC (2 hours ago)
(HTM) web link (www.nist.gov)
(TXT) w3m dump (www.nist.gov)
| loeg wrote:
| > If lightweight cryptography was a good idea, we'd just call it
| "cryptography."
|
| https://x.com/matthew_d_green/status/1948476801824485606
| 2OEH8eoCRo0 wrote:
| > We encourage the use of this new lightweight cryptography
| standard wherever resource constraints have hindered the
| adoption of cryptography
| cvwright wrote:
| Good news. We've waited so long that AES is pretty damn
| lightweight now too.
| rocqua wrote:
| 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.
| thmsths wrote:
| 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 wrote:
| 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.
| tptacek wrote:
| 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 wrote:
| 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?
| ebiederm wrote:
| 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.
| tptacek wrote:
| 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 wrote:
| 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.
| coppsilgold wrote:
| 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).
|
| <https://ascon.isec.tugraz.at/specification.html>
| rocqua wrote:
| 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 wrote:
| Right, it's a competition to standardize authenticated
| encryption constructions, not entire cryptosystems.
| Onavo wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2025-08-13 23:00 UTC)