3 ms·

If these were faster than AES and as strong as AES, they would be replacing AES, not only being used for "lightweight devices unable to use AES"

stouset 1y ago
I mean, they are faster and as strong and are gradually replacing it?
- tptacek 1y ago
  Sponges generally? Maybe? LWC constructions not so much?
  - stouset 1y ago
    I thought the “they” being referenced were chacha/salsa.
tptacek 1y ago
They're faster than AES on their target platforms. It really feels like people are just trying to run with this out-of-context Matthew Green quote as if it was an axiom.
throw0101c 1y ago
> If these were faster than AES and as strong as AES […] Not everything needs to be as strong as AES, just "strong enough" for the purpose. Heck, the IETF has published TLS cipher suites with zero encryption, "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.
- thyristan 1y ago
  NULL ciphers in TLS are intended to enable downgrade attacks. Nothing else. Same thing with weaker ciphers. They are a target to downgrade to, if an attacker wishes to break into your connection.
  - Dylan16807 1y ago
    > NULL ciphers in TLS are intended to enable downgrade attacks. Nothing else. Intended... Do any experts think that? Can you cite a couple? Or direct evidence of course. Unless I'm missing a joke.
    - thyristan 1y ago
      Thought this was common knowledge. When TLS1.3 was standardized, it explicitly left out all NULL and weak (such as RC4) ciphers. It also left out all weaker RSA/static-DH key exchange methods, such that easy decryption of recorded communication became impossible. To that the enterprises who would like to snoop on their employees and the secret services who would like to snoop on everyone reacted negatively and tried to introduce their usual backdoors such as NULL ciphers again: https://www.nist.gov/news-events/news/2024/01/new-nccoe-guide-helps-major-industries-observe-incoming-data-while-using https://www.nist.gov/news-events/news/2024/01/new-nccoe-guid... with associated HN discussion https://news.ycombinator.com/item?id=39849754 https://news.ycombinator.com/item?id=39849754 https://www.rfc-editor.org/rfc/rfc9150.html https://www.rfc-editor.org/rfc/rfc9150.html was the one reintroducing NULL ciphers into TLS1.3. RFC9150 is written by Cisco and ODVA who previously made a fortune with TLS interception/decryption/MitM gear, selling to enterprises as well as (most probably, Cisco has been a long-time bedmate of the US gov) spying governments. The RFC weakly claims "IoT" as the intended audience due to cipher overhead, however, that is extremely hard to believe. They still do SHA256 for integrity, they still do all the very complicated and expensive TLS dance, but then skip encryption and break half the protocol on the way (since stuff like TLS1.3 RTT needs confidentiality). So why do all the expensive TLS dance at all when you can just slap a cheaper HMAC on each message and be done? The only sensible reason is that you want to have something in TLS to downgrade to.
      - 1y ago
yardstick 1y ago
Security standards can move extremely slowly when the security of the incumbent algorithm hasn’t been sufficiently compromised, despite better (faster, smaller) alternatives. Tech Politics comes into it.
TJSomething 1y ago
Rijndael (now AES) wasn't even the strongest finalist in the 2001 AES evaluation. It partially won on dint of being faster on contemporary x86 processors than Serpent or Twofish. Nowadays, it's faster on x86-64 processors because there's dedicated silicon for running it. Modern small platforms don't have this silicon and have different performance characteristics to consider. Also, without that dedicated silicon, implementations tend to be vulnerable to side-channel attacks that were unknown at the time.
ifwinterco 1y ago
Most modern processors have hardware support for AES, that's why it's fast. ChaCha is significantly faster when run on the CPU

stouset 1y ago

I mean, they are faster and as strong and are gradually replacing it?

tptacek 1y ago
Sponges generally? Maybe? LWC constructions not so much?
- stouset 1y ago
  I thought the “they” being referenced were chacha/salsa.

tptacek 1y ago

They're faster than AES on their target platforms. It really feels like people are just trying to run with this out-of-context Matthew Green quote as if it was an axiom.

throw0101c 1y ago

> If these were faster than AES and as strong as AES […] Not everything needs to be as strong as AES, just "strong enough" for the purpose. Heck, the IETF has published TLS cipher suites with zero encryption, "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.

thyristan 1y ago
NULL ciphers in TLS are intended to enable downgrade attacks. Nothing else. Same thing with weaker ciphers. They are a target to downgrade to, if an attacker wishes to break into your connection.
- Dylan16807 1y ago
  > NULL ciphers in TLS are intended to enable downgrade attacks. Nothing else. Intended... Do any experts think that? Can you cite a couple? Or direct evidence of course. Unless I'm missing a joke.
  - thyristan 1y ago
    Thought this was common knowledge. When TLS1.3 was standardized, it explicitly left out all NULL and weak (such as RC4) ciphers. It also left out all weaker RSA/static-DH key exchange methods, such that easy decryption of recorded communication became impossible. To that the enterprises who would like to snoop on their employees and the secret services who would like to snoop on everyone reacted negatively and tried to introduce their usual backdoors such as NULL ciphers again: https://www.nist.gov/news-events/news/2024/01/new-nccoe-guide-helps-major-industries-observe-incoming-data-while-using https://www.nist.gov/news-events/news/2024/01/new-nccoe-guid... with associated HN discussion https://news.ycombinator.com/item?id=39849754 https://news.ycombinator.com/item?id=39849754 https://www.rfc-editor.org/rfc/rfc9150.html https://www.rfc-editor.org/rfc/rfc9150.html was the one reintroducing NULL ciphers into TLS1.3. RFC9150 is written by Cisco and ODVA who previously made a fortune with TLS interception/decryption/MitM gear, selling to enterprises as well as (most probably, Cisco has been a long-time bedmate of the US gov) spying governments. The RFC weakly claims "IoT" as the intended audience due to cipher overhead, however, that is extremely hard to believe. They still do SHA256 for integrity, they still do all the very complicated and expensive TLS dance, but then skip encryption and break half the protocol on the way (since stuff like TLS1.3 RTT needs confidentiality). So why do all the expensive TLS dance at all when you can just slap a cheaper HMAC on each message and be done? The only sensible reason is that you want to have something in TLS to downgrade to.
    - 1y ago

yardstick 1y ago

Security standards can move extremely slowly when the security of the incumbent algorithm hasn’t been sufficiently compromised, despite better (faster, smaller) alternatives. Tech Politics comes into it.

TJSomething 1y ago

Rijndael (now AES) wasn't even the strongest finalist in the 2001 AES evaluation. It partially won on dint of being faster on contemporary x86 processors than Serpent or Twofish. Nowadays, it's faster on x86-64 processors because there's dedicated silicon for running it. Modern small platforms don't have this silicon and have different performance characteristics to consider. Also, without that dedicated silicon, implementations tend to be vulnerable to side-channel attacks that were unknown at the time.

ifwinterco 1y ago

Most modern processors have hardware support for AES, that's why it's fast. ChaCha is significantly faster when run on the CPU