Lightweight Cryptography

https://csrc.nist.gov/Projects/Lightweight-Cryptography

128 44 5 years ago

csrc.nist.gov

throw0101a• 5 years ago

The NSA developed some light-weight algorithms that were submitted to the ISO, but they were initially rejected due to lingering suspicions:

* https://techmonitor.ai/techonology/cybersecurity/nsa-ciphers...

* https://en.wikipedia.org/wiki/Simon_(cipher)

* https://en.wikipedia.org/wiki/Speck_(cipher)

The ISO went with PRESENT and CLEFIA for ISO/IEC 29192 ("Information technology - Security techniques - Lightweight cryptography"):

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

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

A bit of a history of that episode:

* https://link.springer.com/chapter/10.1007/978-3-030-10591-4_...

S&S were eventually accepted for ISO 29167.

rdpintqogeogsaa3• 5 years ago

SPECK is a really attractive design for software implementation. The key schedule and the round function are the same, it's an ARX design that lends itself to naturally constant-time implementation. If the design is free of fault and it gets thrown out because of its origin and admittedly questionable public analysis statements, that's rather unfortunate. Alas, it's hard to trust given the backstory, but on the other hand the author(s) might be relying entirely on cryptanalytic techniques and results they're not able to publish for whatever reason.

GTP2• 5 years ago

but on the other hand the author(s) might be relying entirely on cryptanalytic techniques and results they're not able to publish for whatever reason

But this is bad, the best way to ensure that some cryptanalytic technique works is to publish it so every cryptographer in the world can review it.

JoachimS5• 5 years ago

But both algorithms are confidentiality only, not AE. And they need a lot of rounds to provide any real security.

28194608• 5 years ago

Who won the encryption against quantum computer?

0xdeadb00f2• 5 years ago

These are symmetric ciphers. So.. All of them?

JoachimS5• 5 years ago

One thing though is that many lightweight block ciphers only have 128 bit keys. So in a PQ context, they will only provide 64 bit strength. Thus might be ok for short term secrets. But if you are building devices (IoT, SCADA) with long lifetimes, you may need to add a key derivation, key exchange scheme.

hannob2• 5 years ago

You likely mean the nist post quantum competition, which is about public key encryption and signatures.

The answer is noone yet, it's still running. Here's the list of proposals currently in the competition: https://csrc.nist.gov/Projects/post-quantum-cryptography/rou...

marcosdumay5• 5 years ago

Last time I checked, all the computers were growing powerful and crypto was relevant neither for latency nor for power consumption on any device capable of joining a network.

It helps that one of the largest factors on choosing crypto algorithms is speed on both general purpose and specialized hardware.

So, count me in the group of people that don't understand why the NIST is doing this. Will they trade any security guarantee for speed? If so, nobody should ever use one of those algorithms. If not, whatever algorithm wins here would also win a new round of general purpose crypto contest.

tluyben23• 5 years ago

For instance, the devices we make are not powerful enough to use the standard crypto algorithms. So we are looking forward to the results. Security, for us, only has to be guaranteed for a limited time: if it cannot be cracked in a few minutes, it does not matter if it ever does. So we benefit from 'not as secure but secure enough'.

Edit; by not powerful enough, we mean both: too high latency and too much energy drain.

oleganza3• 5 years ago

Would you mind sharing what protocols you are working on that can benefit from a "lightweight cryptography"?

My impression from learning cryptography in the last 8 years is that cryptographic protocols are either exponentially secure, or any tiny weaknesses can be amplified into a complete break.

The only example of secure "intrapolynomial cryptography" [1] is Proof-of-Work, but it also requires work to be expended continuously. Not exactly a scheme for "underpowered devices".

[1] https://nakamotoinstitute.org/intrapolynomial-cryptography/

_3u102• 5 years ago

Why not use RC4?

How resource constrained are you? Doesn’t most of your networking gear have crypto built into it already?

marcosdumay5• 5 years ago

If you create an encryption schema designed to survive a few hours of attack, it will automatically be vulnerable to the attacker negotiating a discount with a CPU manufacturer.

adament• 5 years ago

If you have a need for lightweight cryptography today, why wait for the NIST competition? Ascon is already the primary recommendation in the lightweight category from the CAESAR competition, and now also a finalist in the NIST competition.

Lifelarper• 5 years ago

all the computers

Maybe those machines that don't even spin up a fan with 400 npm dependencies, but billions of of low end embedded devices pumped out annually.

Call me a sceptic but I think the lightcrypto contest is actually something that will benefit society far more than the post-quantum simultaneously underway.

marcosdumay5• 5 years ago

The processing needs of a wifi connection (or any wireless protocol) are overwhelming on dealing with the problems of a radio connection. Unless you are connecting, sending a single package and disconnecting¹, encryption barely registers.

For wired devices things changes a bit. Encryption can be dozens of times more expensive than moving your data around for processing. But if that's a problem, you need to accelerate your encryption in hardware², not to weaken the encryption.

1 - If you are, you are better with some protocol that keeps the encryption setup around between transmissions, not with weaker crypto.

2 - Just like you accelerate the "moving data around" part, because it doesn't go from the network into the main memory for free either.

0xdeadb00f2• 5 years ago

The biggest use case for these algorithms is IoT, and other resource constrained embedded devices. Quite frankly, I'm surprised you didn't consider it seeing as insecure IoT devices have been in the news pretty much since they hit the market.

Embedded devices, especially specialised ones arent poweful enough to operate sufficiently while also providing protection via the current "standard" crypto algorithms.

mindslight• 5 years ago

The problem with Internet of Trash devices isn't a lack of cryptography - it's closed, poorly developed, throw-away software. In comparison to implementing a whole wifi stack, some dedicated hardware for AES is trivial. Given that NSA has been trying to get us to use "lightweight cryptography" for decades (eg 512 bit RSA), this seems quite uncompelling.

Furthermore for even smaller devices without Wifi, the "Internet" of things (where Internet means communicating directly over the WAN rather than to a more-capable local device) won't be compelling until the software situation has been sorted out. For example the best practices for using current Wifi smart plugs is to stick them on their own VLAN with no Internet access, communicating only with a local Home Assistant or whatever. There's no reason they themselves need to be on the WAN.

loeg• 5 years ago

A lot of the problems with IoT devices are things like hardcoded keys or passwords shared across all units. LWC doesn’t fix that kind of design problem. I agree LWC has value but I think most IoT products are less cpu-limited and more engineer-limited.

hannob2• 5 years ago

Pretty much every IoT device uses Wifi, and that doesn't seem to be a problem right now. They all seem to be perfectly capable of speaking WPA2 with AES.

60Vhipx7b4JL• 5 years ago

Every thought about all the things besides personal computers and smartphones?

Embedded applications, energy limited (battery, power harvesting) devices, IoT, other resource constrained devices?

I also doubt that more processing = more security.

wmf2• 5 years ago

Check out the case of storage encryption in smartwatches and very cheap phones. The CPUs do not have AES instructions and doing software AES makes the watch noticeably sluggish. https://lwn.net/ml/linux-crypto/20180806223300.113891-1-ebig...

marcosdumay5• 5 years ago

The question is, are you ok with the encryption being breakable if it makes your watch faster?

Personally, if I'm ok with the encryption being breakable, I'm also ok with not using any encryption at all. I can't imagine a scenario where I would want weak encryption.

Anyway, the way to solve that problem is to get a CPU with AES instructions.

ur-whale• 5 years ago

Can someone point to a resource describing why various candidates got rejected in round 1 and round 2?

Any comments on the decisions or was it just voting without explaining?

rdpintqogeogsaa3• 5 years ago

See NISTIR 8369, available from [0], p. 40 et seq. in particular.

[0] https://csrc.nist.gov/publications/detail/nistir/8369/final

nemo1618• 5 years ago

One nice thing about lightweight crypto is that it's easy to port. Implementing ASCON in Go was pretty fun and only took an hour or two: https://github.com/lukechampine/ascon/blob/master/ascon.go

(Obviously it wouldn't make a ton of sense to use Go if you're resource-constrained, but having a library is worthwhile for compatibility reasons regardless.)

JoachimS5• 5 years ago

One really good thing with the finalist algorithms is that they all provide authenticated encryption. For many IoT systems, authentication and integrity protection is way more important than condidentiality.

Many older lightweight algorithms (or AES) for that matter requires adding either an authentication mode, or another primitive (a hash function used in HMAC for example)

I believe that has led to a problematic proliferation of only having confidentiality protection in too many IoT systems deployed.

These candidates makes it easier for developers to add the security properties their system actually needs.

Lightweight Cryptography

Related Stories