Reflections after the workshop

[John Preuß Mattsson]

Hi,

 

Thanks NIST for an excellent workshop! Some reflections:

 

- I think Paul Crowley's suggestion that NIST should specify TurboSHAKE, Rijndael with 256 bit blocks, and one of the double-deckers is a very good starting point for a discussion. NIST is right now asking for comments on the SHA-3 specifications, I will myself make an official comment that NIST should add TurboSHAKE. I think NIST adding TurboSHAKE is quite uncontroversial.

 

- While adding Rijndael with 256 bit blocks is likely not controversial, adding Simpira is likely quite controversial. I had never heard of Simpira before the workshop, and it was not presented during the workshop. Maybe NIST could arrange a presentation of Simpira, or point to a recording of a presentation? Is Simpira with 256 bit blocks faster than Rijndael with 256 bit blocks on modern x86 processors? How do the security properties compare?

 

- I have not looked into HCTR2 and the double-deckers, but the fact that the author of Adiantum and HCTR2 suggests standardization of a competing suggestion indicates that the double-deckers are very good.

 

Cheers,

John

[Paul Crowley]

On Fri, 6 Oct 2023 at 04:26, John Preuß Mattsson <john.m...@gmail.com> wrote:

- I have not looked into HCTR2 and the double-deckers, but the fact that the author of Adiantum and HCTR2 suggests standardization of a competing suggestion indicates that the double-deckers are very good.

This reflects that the straightforward ways to build an AEAD mode from Adiantum and HCTR2 are not CMT-4. Any wide block cipher proposal today needs to be accompanied by a proposal on how to efficiently build a CMT-4 AEAD mode from it.  Once I figure out a CMT-4 HCTR-based proposal I'll be advocating for it - especially if we get Rijndael-256/256 and so can avoid the birthday bound. In the meantime, docked-double-decker is simple and has attractive security properties, but as proposed it is inherently serial and I think higher performance modes are possible on modern hardware.

[Paul Crowley]

My proposal at the end of the conference was that NIST should announce their intent to standardize:

• Rijndael-256/256
• TurboSHAKE
• Docked-Double-Decker

I think there's a clear need to standardize new primitives. AES's 128-bit pipe means that we are constantly coming up against the birthday bound in everything we build, and doing increasingly complex and inefficient things to work around it. SHAKE can take its place in some but not all circumstances, but it's less efficient than it could be. But running a contest to choose new primitives would require a lot of resources that NIST is loath to devote, as well as taking many years.

The alternative is the "pick a winner" approach: standardize existing primitives that represent a "Schelling point" that a lot of people can agree on as a natural choice. This suggests standardizing variants on existing NIST standards, which has two other advantages:

• Existing cryptanalysis will often be applicable. In the case of TurboSHAKE, as Joan Daemen pointed out, literally all cryptanalysis of SHA-3/SHAKE already attacks reduced-round versions of it, so any observation whatsoever that would count as a publishable observation towards cryptanalysis of TurboSHAKE could be published about SHAKE. In the case of Rijndael-256/256 this is less true, but this proposal has continued to attract cryptanalysis in the decades since it was proposed, eg this 2019 paper claiming the best attack on Rijndael-256/256, breaking 10 of its 14 rounds with 2^244.4 chosen plaintexts, 2^240.1 encryptions, and 2^181.4 blocks of memory.
• These would be short amendments to the existing standards - nearly all the technical work needed to standardize these variants is already done.
• Hardware acceleration instructions should generally apply - eg Shay Gueron points out that existing AES instructions can be used to accelerate Rijndael-256/256

I think 256 bits ought to be enough for anybody. Lily Chen said something like "we made it too small twice, we don't want to make the same mistake again". I actually think it's plausible that 256 bits would be enough for all time. The demand for a wider block arises specifically because of the birthday bound - we need real 128-bit security, so everything has to be 256 bits (ISTR John Kelsey attributed this "double everything" philosophy to Niels Ferguson). The idea of a block cipher that can be dialled to an arbitrary block size is obviously appealing, but I'm not aware of a great deal of work in this area when it comes to primitives that can substitute for an ideal cipher, meaning that the path to a standard would be many many years long.

I'll put off talking about docked-double-decker to a future email!

[sanketh]

Hello,

Perhaps obvious, but I would like to gently push back against the view that "256 bits ought to be enough for anybody." 256-bits is not good enough for building fast, collision-resistant hash functions. It would be nice if we could reuse the same primitive for fast, collision-resistant hashing.

This is not an argument against standardizing Rijndael-256/256, but rather an argument that if we standardize Rijndael-256/256, we might still, down the line, want a wider block cipher (or permutation.)

Best,

Sanketh

--
To unsubscribe from this group, send email to ciphermodes-fo...@list.nist.gov
 
View this message at https://list.nist.gov/ciphermodes-forum
---
To unsubscribe from this group and stop receiving emails from it, send an email to ciphermodes-fo...@list.nist.gov.