6 ms·
NIST Finalizes 'Lightweight Cryptography' Standard to Protect Small Devices
- saaspirant 1y agoI wonder whether this is backdoored by NSA as well
- jeffrallen 1y agoYup, NIST has no business putting their names on anything cryptographic anymore.
- SV_BubbleTime 1y agoDid I miss something recent? Or are we going back to the DES days?
- 0xfffafaCrash 1y agoWhile not exactly recent, I think most people have Dual_EC_DRBG in mind these days when it comes to NIST and backdoors https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG
- skeezyboy 1y agothey really are shits arent they
- deleted 1y ago[deleted]
- LeGrosDadai 1y agoThere is a lot of cryptanalysis on it: https://eprint.iacr.org/search?q=ASCON https://eprint.iacr.org/search?q=ASCON Furthermore, it is not designed by NIST.
- loeg 1y ago> If lightweight cryptography was a good idea, we’d just call it “cryptography.” https://x.com/matthew_d_green/status/1948476801824485606 https://x.com/matthew_d_green/status/1948476801824485606
- 2OEH8eoCRo0 1y ago> We encourage the use of this new lightweight cryptography standard wherever resource constraints have hindered the adoption of cryptography
- cvwright 1y agoGood news. We’ve waited so long that AES is pretty damn lightweight now too.
- Sanzig 1y agoEh, 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 1y agoKnowing 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.
- adrian_b 1y agoSHA-3 in fast when implemented in hardware. Its slowness in software and quickness in hardware have almost nothing to do with it being sponge-based, but are caused by the Boolean functions executed by the Keccak algorithm, which are easy to implement in hardware, but need many instructions on most older CPUs (but much less instructions on Armv9 CPUs or AMD/Intel CPUs with AVX-512). The sponge construction is not inherently slower than the Merkle–Damgård construction. One could reuse the functions iterated by SHA-512 or by SHA-256 and reorganize them to be used in a sponge-based algorithm, obtaining similar speeds with the standard algorithms. That is not done because for the sponge construction it is better to design a mixing function with a single wider input instead of a mixing function with 2 narrower inputs, like for Merkle–Damgård. Therefore it is better to design the function from the beginning for being used inside a sponge construction, instead of trying to adapt functions intended for other purposes.
- coppsilgold 1y agoThey 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 https://ascon.isec.tugraz.at/specification.html>
- deleted 1y ago[deleted]
- skeezyboy 1y agoi too approve of their choice of cryptographic functions, if not a little miffed they didnt come to me first
- rocqua 1y agoThis 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 1y agoRight, it's a competition to standardize authenticated encryption constructions, not entire cryptosystems.
- LeGrosDadai 1y agoBy 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 1y agoMy 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.
- dvdkon 1y agoA 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.
- LeGrosDadai 1y agoAh, 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.
- brohee 1y ago
- Onavo 1y agoAre 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 1y agoAlso 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 1y agoYou'd change the coin cell in an ESP32 powered garage door fob monthly... Unacceptable to most.
- sowbug 1y agoAny 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 https://github.com/mcer12/Hugo-ESP8266
- le-mark 1y agoWikipedia 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. https://en.m.wikipedia.org/wiki/Ascon_(cipher) https://en.m.wikipedia.org/wiki/Ascon_(cipher)
- 201984 1y agoNo? SHA-256 has only eight 32-bit words of state which is even less than Ascon. BLAKE2s looks the same. https://en.wikipedia.org/wiki/SHA-2 https://en.wikipedia.org/wiki/SHA-2 https://datatracker.ietf.org/doc/html/rfc7693 https://datatracker.ietf.org/doc/html/rfc7693
- adrian_b 1y agoThis 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.
- dchest 1y agoSponges 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.
- anfilt 1y agoWhile 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.
- indolering 1y agoReally glad a sponge function won, they are a big step forward in terms of crypto engineering!
- jeffrallen 1y agos/NIST/NSA/g
- gnubee 1y agoA land shanty is just called a song. It's protective cryptography or not. Binary.
- npteljes 1y ago"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".
- dazhbog 1y agoWhy not use chacha20 or xtea for embedded devices? They are lighter than AES..
- ahoka 1y agoIf 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 1y agoYour 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.
- blessedcavapoo1 1y ago[dead]