5 ms·

> 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

by 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 ago
Good news. We’ve waited so long that AES is pretty damn lightweight now too.
- Sanzig 1y ago
  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 1y ago
    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.
    - adrian_b 1y ago
      SHA-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.
rocqua 1y ago
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 1y ago
  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 1y ago
    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.
    - Sanzig 1y ago
      > 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. Well, no. If you can do 1 AES block per second, that's a throughput of a blazing fast 16 bytes per second. I know that's a pathological example, but I do understand your point - a typical workload on an MCU won't have to do much more than encrypt a few kilobytes per second for sending some telemetry back to a server. In that case, sure: ChaCha20-Poly1305 and your job is done. However, what about streaming megabytes per second, such as an uncompressed video stream? In that case, lightweight crypto may start to make sense.
tptacek 1y ago
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).
- deleted 1y ago
  [deleted]
- adastra22 1y ago
  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.
  - tptacek 1y ago
    "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.
  - wmf 1y ago
    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.
glitchc 1y ago
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.
- theteapot 1y ago
  The environment? As in trees?
- stouset 1y ago
  > 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 1y ago
    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.
    - adgjlsfhk1 1y ago
      The hard part is that anything designed to be breakable in a week is only ~150x away in strength from being broken in an hour. That means you need to be incredibly confident about how strong your algorithm is. It's much easier to eat a little bit of cost such that you think it's invulnerable for thousands of years because that way you don't need to worry about a factor of 2 here and there.
      - staplefire 1y ago
throw0101c 1y ago
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 https://datatracker.ietf.org/doc/html/rfc9150 Lightweight cryptography could be a step between the above zero and the 'heavyweight' ciphers like AES.
corranh 1y ago
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 1y ago
  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
npteljes 1y ago
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" https://en.wikipedia.org/wiki/Cryptography https://en.wikipedia.org/wiki/Cryptography
- yalogin 1y ago
  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 1y ago
    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.
    - yalogin 1y ago
      I hear you, but they could have chosen performant crypto or low power crypto or some variant like that. For many lightweight reminds them of low effort ciphers. I see your point though For me if it comes from NIST, I trust it (even with their past shenanigans) because I know the process they use and also they only produce these standards to be used for federal governent software. So they will do a good job.

by loeg 1y ago

2OEH8eoCRo0 1y ago

> We encourage the use of this new lightweight cryptography standard wherever resource constraints have hindered the adoption of cryptography

cvwright 1y ago

Good news. We’ve waited so long that AES is pretty damn lightweight now too.

Sanzig 1y ago
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 1y ago
  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.
  - adrian_b 1y ago
    SHA-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.

rocqua 1y ago

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 1y ago
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 1y ago
  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.
  - Sanzig 1y ago
    > 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. Well, no. If you can do 1 AES block per second, that's a throughput of a blazing fast 16 bytes per second. I know that's a pathological example, but I do understand your point - a typical workload on an MCU won't have to do much more than encrypt a few kilobytes per second for sending some telemetry back to a server. In that case, sure: ChaCha20-Poly1305 and your job is done. However, what about streaming megabytes per second, such as an uncompressed video stream? In that case, lightweight crypto may start to make sense.

tptacek 1y ago

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).

deleted 1y ago
[deleted]
adastra22 1y ago
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.
- tptacek 1y ago
  "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.
- wmf 1y ago
  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.

glitchc 1y ago

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.

theteapot 1y ago
The environment? As in trees?
stouset 1y ago
> 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 1y ago
  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.
  - adgjlsfhk1 1y ago
    The hard part is that anything designed to be breakable in a week is only ~150x away in strength from being broken in an hour. That means you need to be incredibly confident about how strong your algorithm is. It's much easier to eat a little bit of cost such that you think it's invulnerable for thousands of years because that way you don't need to worry about a factor of 2 here and there.
    - staplefire 1y ago

throw0101c 1y ago

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 https://datatracker.ietf.org/doc/html/rfc9150 Lightweight cryptography could be a step between the above zero and the 'heavyweight' ciphers like AES.

corranh 1y ago

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 1y ago
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

npteljes 1y ago

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" https://en.wikipedia.org/wiki/Cryptography https://en.wikipedia.org/wiki/Cryptography

yalogin 1y ago
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 1y ago
  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.
  - yalogin 1y ago
    I hear you, but they could have chosen performant crypto or low power crypto or some variant like that. For many lightweight reminds them of low effort ciphers. I see your point though For me if it comes from NIST, I trust it (even with their past shenanigans) because I know the process they use and also they only produce these standards to be used for federal governent software. So they will do a good job.