Lightweight Cryptography Standardization Process: NIST Selects Ascon | Hacker News Reader

Lightweight Cryptography Standardization Process: NIST Selects Ascon

csrc.nist.gov

33 pointsespadrine10 comments

Congrats on the Ascon team for taking another win after CAESAR! I also thought the Keccak Team's (SHA-3) Xoodoo permutation was also quite clever, and a great optimization over SHA-3.

Ascon Lightweight Authenticated Encryption & Hashing

https://ascon.iaik.tugraz.at/

I'm a little skeptical of the need for lightweight symmetrical ciphers. AES is accelerated on a wide variety of hardware and supports 256-bit keys (which are actually secure against quantum search). The efficient algorithms for Ascon require 64-bit words for the linear diffusion and bit-slicing the S-boxes is only as efficient as machine word size. What is this actually aimed at? Is there a large chunk of 64-bit (or even 32-bit, maybe) microcontrollers that can't do AES efficiently? RAM constraints are the only other thing I can imagine since Ascon has short round constants but that seems unlikely for >=32-bit processors.

One aspect is to have a lightweight AEAD; AES is only a block cipher. The closest comparison would be AES-GCM.

NIST has been testing the algorithms on ATmega328P in software, with specific comparisons to AES-GCM, where Ascon was twice as fast[0]. They also study hardware designs for various fabs; there was a study also giving significantly better results there[1].

> supports 256-bit keys (which are actually secure against quantum search)

(Small note here: this topic is a bit more complex than this, since Grover’s algorithm does not have a constant gate factor with respect to the number of key bits. 128-bit keys already require a number of gates that is unrealistic for a quantum computer to have, similar to expecting a classical computer to have over a quettabyte of RAM.)

[0]: https://csrc.nist.gov/csrc/media/Presentations/2022/update-o...

[1]: https://cryptography.gmu.edu/athena/LWC/SCA_Evaluation_and_B...

Is there that much overhead in using a general block cypher to build a stream cypher?

The issue is that for most authenticated modes, you have to run the block cipher twice in some manner, once to encrypt and once to authenticate. OCB is an exception but I don't know what its status is these days; and, iirc, it still has to do some finite field arithmetic which can be slow in software.

From an industry standpoint, I think you are right in that most off the shelf microcontrollers have AES acceleration built-in, and that won't change anytime soon.

Ascon, depending on the implementation, requires far less logic gates than AES to implement in hardware and requires less power, which would be an eventual cost savings.

I think most importantly though is that by not going with an ARX-based design (Addition, Rotation, XOR), it's much easier for cryptographers to perform cryptanalysis, which is what the Keccak team attributes to why it took so long to find vulnerabilities with algorithms like MD5.

https://keccak.team/2017/not_arx.html

Very cool! Ascon is a nice algorithm that allows a single primitive to be used for many use cases. It is also flexible and allows nice tradeoffs between performance and resources.

Is this seen as a replacement/competitor for ChaCha20 that has NIST approval? Trying to figure out the impact here.

No, this is a lightweight block cipher, requiring low resources. ChaCha20 is a stream cipher based around 64 bit operations and a large internal state. Ascon is more a replacement to AES equipped with a authenticated encryption mode (AEAD even). (Yes, technically Ascon also has 64 bit operations, but crucially not addition.)

ChaCha20 is an ARX construction. Ascon is Sponge construction (more akin to Keccak and all its versions and friends).

Reply on news.ycombinator.com