[HN Gopher] Lightweight Cryptography Standardization Process: NI...
       ___________________________________________________________________
        
       Lightweight Cryptography Standardization Process: NIST Selects
       Ascon
        
       Author : espadrine
       Score  : 15 points
       Date   : 2023-02-07 14:59 UTC (8 hours ago)
        
 (HTM) web link (csrc.nist.gov)
 (TXT) w3m dump (csrc.nist.gov)
        
       | databroker wrote:
       | [dead]
        
       | irq-1 wrote:
       | Ascon Lightweight Authenticated Encryption & Hashing
       | 
       | https://ascon.iaik.tugraz.at/
        
       | oneng wrote:
       | 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.
        
       | JoachimS wrote:
       | 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.
        
       | benlivengood wrote:
       | 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.
        
         | espadrine wrote:
         | 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...
        
           | UltraViolence wrote:
           | [dead]
        
         | oneng wrote:
         | 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
        
       ___________________________________________________________________
       (page generated 2023-02-07 23:02 UTC)