6 ms·

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 st

by 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
      This whole framing is weird, because you can't spend $0.50 per already-deployed part to upgrade to something that can viably do AES.
      - deleted 1y ago
        [deleted]
    - Taek 1y ago
      1 operation per second would refer to cryptographic signatures. If you are doing Chacha, the speeds are more like 1 mbps. AES is probably closer to 400 kbps. An uncompressed video stream at 240p, 24 frames per second is 60 mbps, not really something an IoT device can handle. And if the video is compressed, decompression is going to be significantly more expensive than AES - adding encryption is not a meaningful computational overhead.
      - HeatrayEnjoyer 1y ago
        If it's compressed you don't need to decompress it first.
        dylan604 1y ago
        on the receiving end.
        yardstick 1y ago
        The device doing the decryption may not be the same device that does the decompression. Eg a small edge gateway could be doing the VPN, while the end device is decoding the video.
        dylan604 1y ago
        A VPN’s encryption is different than a streaming platform’s encryption. The streamer’s encryption is their form of rights management. So the device/app decompressing the video very much is the point of decryption. If not, the rights management is very broken. If the small edge gateway is somehow decrypting the video stream, you’d have a very rogue device that lots of people would be curious to learn more
  - wakawaka28 1y ago
    >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. The monetary cost is most likely not the problem. Tacking on significant additional work is bound to consume more power and generate heat. Tiny devices often have thermal and power limits to consider.
    - adgjlsfhk1 1y ago
      The problem is it isn't significant work. You can perform ChaCha8 on pen and paper in ~30 minutes. It's literally 768 single cycle 32 bit integer operations.
      - wakawaka28 1y ago
        768 single cycle instructions to do WHAT? To encode a few bytes or something? You can't convince me that the cost of cryptography is never prohibitive. Boldly asserting that your idea of "significant work" is universal for all applications isn't going to convince me, nor are weird anecdotes about tangentially related things.
tptacek 1y ago
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 1y ago
  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?
  - tptacek 1y ago
    I'm saying that AES isn't viable a decent-sized chunk of existing embedded hardware, and that the constructions that are viable on those platforms both (1) fall below the security thresholds of front-line mainstream constructions like AES-GCM or Chapoly and (2) would in fact be slower that AES or Chapoly on modern workstation, server, and phone platforms. Hardware capabilities vary widely; there isn't one optimal algorithm that fits (or, in the case of MCUs, is even viable) on every platform. What's worse, efforts to shoehorn front-line mainstream constructions onto MCUs often result in insecure implementations, because, especially without hardware support (like carryless multiplication instructions), it's very difficult to get viable performance without introducing side channels.
  - throw0101a 1y ago
    > When you say "get their asses kicked", you mean in terms of performance right? Depends on what you mean by "performance". It could be latency: high frequency traders (HFTs) could probably be happy if their order data is protected for "only" an hour if it means dropping latency from (e.g.) 42 nanoseconds down to 24. An hour ago for some trading platforms is stale as a decade ago.
ebiederm 1y ago
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.
- Sanzig 1y ago
  Speck? To my knowledge there aren't any serious flaws despite a lot of public cryptanalysis. I think what sank Speck was that it came out a few years after after the Dual_EC_DRBG fiasco and nobody was ready to trust an NSA developed cipher yet - which is fair enough. The NSA burned their credibility for decades with Dual_EC_DRBG.
  - tptacek 1y ago
    I mean, yeah, but also Simon and Speck aren't as good as the new generation of low-footprint designs like Ascon and Xoodyak. We know more about how to do these things now than we did 15 years ago.
    - Sanzig 1y ago
      Makes sense! Also, how does Speck fare in power analysis side channel attacks vs Ascon? My understanding was that was also one of the NIST criteria.
      - tptacek 1y ago
        I am way out of my depth both on power consumption and leakage, but presumable Ascon does better on both counts than Chapoly.
        adgjlsfhk1 1y ago
        Realy ChaCha seems trivially implementable without leaking anything.

by rocqua 1y ago

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
    This whole framing is weird, because you can't spend $0.50 per already-deployed part to upgrade to something that can viably do AES.
    - deleted 1y ago
      [deleted]
  - Taek 1y ago
    1 operation per second would refer to cryptographic signatures. If you are doing Chacha, the speeds are more like 1 mbps. AES is probably closer to 400 kbps. An uncompressed video stream at 240p, 24 frames per second is 60 mbps, not really something an IoT device can handle. And if the video is compressed, decompression is going to be significantly more expensive than AES - adding encryption is not a meaningful computational overhead.
    - HeatrayEnjoyer 1y ago
      If it's compressed you don't need to decompress it first.
      - dylan604 1y ago
        on the receiving end.
        yardstick 1y ago
        The device doing the decryption may not be the same device that does the decompression. Eg a small edge gateway could be doing the VPN, while the end device is decoding the video.
        dylan604 1y ago
        A VPN’s encryption is different than a streaming platform’s encryption. The streamer’s encryption is their form of rights management. So the device/app decompressing the video very much is the point of decryption. If not, the rights management is very broken. If the small edge gateway is somehow decrypting the video stream, you’d have a very rogue device that lots of people would be curious to learn more
- wakawaka28 1y ago
  >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. The monetary cost is most likely not the problem. Tacking on significant additional work is bound to consume more power and generate heat. Tiny devices often have thermal and power limits to consider.
  - adgjlsfhk1 1y ago
    The problem is it isn't significant work. You can perform ChaCha8 on pen and paper in ~30 minutes. It's literally 768 single cycle 32 bit integer operations.
    - wakawaka28 1y ago
      768 single cycle instructions to do WHAT? To encode a few bytes or something? You can't convince me that the cost of cryptography is never prohibitive. Boldly asserting that your idea of "significant work" is universal for all applications isn't going to convince me, nor are weird anecdotes about tangentially related things.

tptacek 1y ago

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 1y ago
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?
- tptacek 1y ago
  I'm saying that AES isn't viable a decent-sized chunk of existing embedded hardware, and that the constructions that are viable on those platforms both (1) fall below the security thresholds of front-line mainstream constructions like AES-GCM or Chapoly and (2) would in fact be slower that AES or Chapoly on modern workstation, server, and phone platforms. Hardware capabilities vary widely; there isn't one optimal algorithm that fits (or, in the case of MCUs, is even viable) on every platform. What's worse, efforts to shoehorn front-line mainstream constructions onto MCUs often result in insecure implementations, because, especially without hardware support (like carryless multiplication instructions), it's very difficult to get viable performance without introducing side channels.
- throw0101a 1y ago
  > When you say "get their asses kicked", you mean in terms of performance right? Depends on what you mean by "performance". It could be latency: high frequency traders (HFTs) could probably be happy if their order data is protected for "only" an hour if it means dropping latency from (e.g.) 42 nanoseconds down to 24. An hour ago for some trading platforms is stale as a decade ago.

ebiederm 1y ago

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.

Sanzig 1y ago
Speck? To my knowledge there aren't any serious flaws despite a lot of public cryptanalysis. I think what sank Speck was that it came out a few years after after the Dual_EC_DRBG fiasco and nobody was ready to trust an NSA developed cipher yet - which is fair enough. The NSA burned their credibility for decades with Dual_EC_DRBG.
- tptacek 1y ago
  I mean, yeah, but also Simon and Speck aren't as good as the new generation of low-footprint designs like Ascon and Xoodyak. We know more about how to do these things now than we did 15 years ago.
  - Sanzig 1y ago
    Makes sense! Also, how does Speck fare in power analysis side channel attacks vs Ascon? My understanding was that was also one of the NIST criteria.
    - tptacek 1y ago
      I am way out of my depth both on power consumption and leakage, but presumable Ascon does better on both counts than Chapoly.
      - adgjlsfhk1 1y ago
        Realy ChaCha seems trivially implementable without leaking anything.