7 ms·
NIST selects ‘lightweight cryptography’ algorithms to protect small devices
- transpute 4y agoAscon specs, reference code and benchmarks: https://ascon.iaik.tugraz.at https://ascon.iaik.tugraz.at Competitors: https://asecuritysite.com/light https://asecuritysite.com/light
- SV_BubbleTime 4y agoI’m really surprised to not see Chacha/Poly on that list as an AEAD. XTEA made it as a competitor but chacha didn’t? I don’t understand cryptography at all.
- tptacek 4y agoChapoly isn't a lightweight design; it's a conventional design. Gimli is, I think, Bernstein's lightweight design (or the core of it).
- zokier 4y agoThis site compares the lwc finalists to chachapoly https://rweather.github.io/lwc-finalists/performance_avr.html https://rweather.github.io/lwc-finalists/performance_avr.htm... I suppose being up to 3.8 times faster with these early implementations is somewhat significant benefit.
- GoblinSlayer 4y agoWhat is expected security margin? Chacha20 is many orders of magnitude more than impossibly strong, cf. AES which is as safe as needed and not safer.
- tptacek 4y agoThis is in the paper. The currently best cryptanalytic attacks on the Ascon authenticated encryption (excluding misuse scenarios) can recover the secret key with a time complexity of about 2 104 only if the initialization is reduced to 7 of 12 rounds, which corresponds to a security margin of 42%
- GoblinSlayer 4y agoThere's an attack on 128-bit Salsa7 with time complexity 2^109, and an attack on 128-bit ChaCha6 with 2^107.
- ilyt 4y ago...on 8 bit. On 32 bit the difference is much smaller and SLOWER on the IOT darling ESP32. This whole thing seems entirely not worth it thb
- mtgx 4y agoLightweight = NSA-crackable, right?
- jll29 4y agoadd "at scale" (= IoT edge devices)?
- woodruffw 4y agoThere are all kinds of different adversary models: these kinds of algorithms are tailored towards IoT or short-term communications use cases, where size and performance on constrained devices are more important than being secure against a nation state for X years. For example: you may have a “smart” device in your household that indicates whether you’re home or not. You don’t want a passive adversary to be able to snoop its RF traffic, but you also don’t need its traffic to be secure for more than one week. “Lightweight” algorithms are meant to give you formal guarantees around that, while also balancing performance, power consumption, and other interests.
- api 4y agoNo. Size of algorithm is unrelated to security.
- databroker 4y ago[dead]
- Rebelgecko 4y agoMore like "lightweight" in terms of code size (or hardware equivalents like FPGA fabric area), RAM requirements, and CPU cycles per byte of encryption/authentication. In some cases this means that a message could be brute forced slightly more quickly. But in practical terms that not a big deal, who cares if someone can crack your code in 2^10 years instead of 2^14. I think for most crypto, brute force times aren't the biggest concern. What's more potentially an issue is the breakability of the algorithm (is there a way to find the plaintext more efficiently than brute forcing?) and how susceptible the algo's implementations are to things like timing attacks (which can be an issue with s boxes although maybe not as big of a deal as I thought considering the results of the competition). In terms of NSA conspiracy theories, it would've been more of an issue if the competition had gone towards Simon or Speck (which weren't eligible because they're block ciphers, but there's ways to adapt... I think OCB mode is no longer patent encumbered.
- fredoralive 4y agoI’m not a crypto expert, but you can get 8 bit Atmel / Microchip AVRs with AES units on them (for example), are “special” lightweight algorithms actually needed, or should we just be encouraging the use of MCUs with suitable accelerators for proven algorithms?
- jvanderbot 4y agoThey're also expensive. At least last time I priced them out, they cost more than the radio and MCU.
- fredoralive 4y agoI was thinking of on chip accelerator units / peripherals, like the AVR Xmega AES example, rather than external chips.
- zokier 4y agoAfaik these LWCs are supposed to also be easier to implement in HW (=smaller die area/gate count), but I'm also wondering is the difference really meaningful especially with current manufacturing tech? I imagine there are limits on die size reductions where the returns really start diminishing very quickly.
- Avamander 4y agoMost microcontrollers are done on as large nodes as possible to reduce cost, so probably?
- hra5th 4y agoA brief search on Mouser seems to indicate that The AVR Xmega costs roughly 2.5 times as much as other 8 bit MCUs from Atmel with comparable amounts of flash/RAM -- are there other "selling point" on-chip perpiherals significantly contributing to that cost?
- 4y ago
- throw0101c 4y agoTwo algorithms by the were rejected by the ISO folks for an IoT standard a few years ago: * https://www.schneier.com/blog/archives/2018/04/two_nsa_algorit.html https://www.schneier.com/blog/archives/2018/04/two_nsa_algor... * https://www.schneier.com/blog/archives/2017/09/iso_rejects_nsa.html https://www.schneier.com/blog/archives/2017/09/iso_rejects_n...
- tptacek 4y agoSIMON and SPECK weren't in the Lightweight Crypto Competition, and couldn't have been, as neither is an AEAD.
- jvanderbot 4y agoWould you mind rephrasing? I'm confused by your comment.
- duskwuff 4y agoMissing an important word: "Two algorithms by the NSA were...".
- tptacek 4y agoAt last, Joan Daemen loses a NIST contest. :) Presumably it helped that Ascon was also a CAESAR finalist. Ascon is a Duplex Sponge construction, and an extremely good introduction to that concept is here: https://codahale.com/the-joy-of-duplexes/ https://codahale.com/the-joy-of-duplexes/ (Xoodyak, Coda's preferred Duplex, was a contestant --- Daemen's contestant, in fact.)
- SeanAnderson 4y agoYour link redirects to a random Wikipedia if the referrer is HN.
- tptacek 4y agoI don't know that it's random.
- baby 4y agosomeone got mad at HN lol
- sebsebmc 4y agoRight-click open in incognito works, but definitely annoying
- zx8080 4y agoIt opens wikipedia in private too.
- tedunangst 4y agoI got Freddy the Pig. https://en.m.wikipedia.org/wiki/Freddy_the_Pig https://en.m.wikipedia.org/wiki/Freddy_the_Pig
- jameswryan 4y agoJoan Daemen even lost twice in one competition! Subterranean 2.0, another Duplex, didn't make it past round 2.
- contact9879 4y agoWould this be a good candidate for encryption on local Wi-Fi (WPA)?
- mabbo 4y ago> The chosen algorithms are designed to protect information created and transmitted by the Internet of Things (IoT), including its myriad tiny sensors and actuators. They are also designed for other miniature technologies such as implanted medical devices, stress detectors inside roads and bridges, and keyless entry fobs for vehicles Edit because I hit the button too soon: no, wifi devices have enough resources to use better encryption, and do.
- tptacek 4y agoThe encryption we're talking about with these constructions is quite strong. It'd be interesting to try to articulate what's "better" about the alternative "heavyweight" algorithms you might use instead.
- SAI_Peregrinus 4y agoThese "lightweight" algorithms aren't just low resource usage, they're tuned for small messages. CAESAR also had a "high-performance" category, for AEADs optimized for large messages and streaming data. If you're limited to small packets on rare occasions and want to have minimal battery drain (e.g. a battery-powered LoRaWAN-style sensor) a "lightweight" algorithm like Ascon is good. For most "normal" uses a "high-performance" algorithm like AEGIS is good, as are AES-GCM, AES-OCB, AES-GCM-SIV, and ChaCha20-Poly1305. When you'd pick which cipher is rather complicated to answer.
- bsder 4y agoThe "lightweight" category is also apparently much better at resisting side channel attacks and is also much easier to do cryptanalysis on. It's not always clear in what ways the non-"lightweight" categories are better other than having bigger keys and state.
- contact9879 4y agoI'm not that familiar with the IoT ecosystem. What are the use cases for this standard and what are those use cases using instead of this standard at present? IoT implies connected to internet? So they have a full TLS stack? They send everything in the clear? .. They use TDES :)? Or they just use an non-standardized algorithm?
- michaelt 4y agoIf you buy a $5 wifi-enabled lightbulb, there's a good chance it'll have an ESP32 (which can do most modern SSL) or an ESP8266 (which is short on memory, and so might use SSL with a preshared key, "TLS-PSK") On the other hand, if $5 devices seem a bit expensive to you, because you think $0.01 parcel labels will be part of the internet of things in the future, I suppose you might be interested in this new NIST algorithm?
- contact9879 4y agoI understand that, but these devices, how will they access the "internet"? They need to talk to a router or other device that is then connected to the internet. What protocol would they use to connect? Or is this for just "near-me area networks" that need to communicate with each other? I never really considered key fobs or pacemakers as IoT devices because they don't actually connect to the internet.
- eternityforest 4y agoPacemakers definitely need security though. Although I don't see why they can't use AES like everything else.
- spelunker 4y agoYes, some IoT devices communicate over WiFi, but others will talk to a gateway or hub over something else, such as BLE or Zigbee. I guess those could be the targets for this.
- nick__m 4y agoThe ESP32-A1S is a fun toy to program with that lib https://github.com/pschatzmann/arduino-audio-tools https://github.com/pschatzmann/arduino-audio-tools on that cheap kit: https://docs.ai-thinker.com/en/esp32-audio-kit https://docs.ai-thinker.com/en/esp32-audio-kit
- nsajko 4y agoDiscussed yesterday: https://news.ycombinator.com/item?id=34693629 https://news.ycombinator.com/item?id=34693629
- fhckmsbd 4y ago[flagged]
- nemo1618 4y agoIf you want a fun little project, try porting ASCON to your language of choice! Shouldn't take more than a couple hours. Here's mine (in Go): https://github.com/lukechampine/ascon https://github.com/lukechampine/ascon I suppose if Ascon is widely adopted, it'll be worth adding an optimized assembly implementation...
- barsonme 4y agoHave got you covered there… https://github.com/ericlagergren/lwcrypto/tree/main/ascon https://github.com/ericlagergren/lwcrypto/tree/main/ascon
- ur-whale 4y agohttps://github.com/ascon/ascon-c https://github.com/ascon/ascon-c I was hoping for a simple piece of C code that did the job under 30 lines ... as usual, it's a forest of implementations. [EDIT]: for comparison: https://gimli.cr.yp.to/spec.html https://gimli.cr.yp.to/spec.html
- jaxarbafar 4y agoI'm wondering how these compare to existing hardware accelerated AES?
- deleted 4y ago[deleted]
- jonathanstrange 4y agoI don't understand "lightweight" encryption. Either it's secure, and then it would make sense to use it for everything due to the lower resource consumption, or it can be broken. What am I missing here?
- arlcode 4y agoSome constraints could be small ram, small messages, very little storage.
- myrion 4y agoIt might make tradeoffs that make it unacceptable in other situations, particularly ones that are focused on being resource constrained in some way. For example it could have low RAM usage, but become exponentially slower with message size, so it's fine for encrypting short messages only. Or it could have a constant overhead somewhere that's fine for an IoT device that sends a report once a day, but not if you wanted to make thousands of connections per second. Stuff like that, is my naive understanding.
- angry_octet 4y ago- Time/space tradeoffs, to enable use on limited memory devices. Large block and keys sizes and Lists are undesirable, even if more cycles are required. - Time/margin tradeoffs: if the attacker can only meaningfully attack in the next 24 hours, do you need margin to protect against all of AWS crunching for a million years? Or would you like the computation done in a tenth the time? - Architectural properties, such as the susceptibility to differential power analysis: maybe you will risk that more via a LUT in exchange for lower power. - As you increase the number of rounds, algorithms tend to get stronger. But some algorithms have E.g. good avalanche properties for many fewer rounds. The tiniest devices are things like RFID chips.
- tptacek 4y agoIn fact, in this particular case, the winner is also a general-purpose cipher contender.