Subject: Re: [CFRG] FYI - NIST Fifth Lightweight Cryptography Workshop (virtual)

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 29 Mar 2022 22:28:03 +0000

Again, nice to hear that. Since currently I don’t recall seeing any LWC finalist offering 256-bit keys, this lack is not a disadvantage for Romulus. 

I don’t understand the politics enough to have an opinion about whether one should start discussion with NIST on key length now, or after the decision is announced. 

CAESAR doesn’t have “weight” of the NIST SP or FIPS for (some of) our users, but it’s a good starting point for discussion. 

Regarding the Catch-22 that you brought up, perhaps IETF (or IRTF) RFCs defining Romulus and Deoxys-II could help breaking that circle.

Thanks!

--

V/R,

Uri

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

From: Thomas Peyrin <[email-masked]>
Date: Tuesday, March 29, 2022 at 13:49
To: Uri Blumenthal <[email-masked]>
Cc: Leo Perrin <[email-masked]>, CFRG <[email-masked]>, John Mattsson <john.mattsson=[email-masked]>, Robert Moskowitz <[email-masked]>
Subject: Re: [CFRG] FYI - NIST Fifth Lightweight Cryptography Workshop (virtual)

Hi Uri, 

"Nice to hear that. Any idea (a) when this work would be completed, and (b) whether NIST would accept/augment the current Romulus-M with 256-bit key capability?"

Regarding (a) this work is completed but under submission at the moment. Note that you can directly use 192-bit keys with the current Romulus versions since 64-bit of the tweakey inputs are not used, so you can simply fill them with 64-bit of extra key material. Regarding (b), I guess this would have to be asked directly to the NIST (there is a NIST LWC mailing list), but anyway Romulus is only a finalist at the moment. The decisions for the NIST LWC competition are apparently going to be disclosed in 2022. Maybe a good way to proceed would be that once the NIST LWC results are announced, to start a discussion on how to enable the various properties that you believe the chosen candidate does not have. 

" Deoxys (AFAIK) is not among the NIST LWC finalists, which would make some users shy away from it. I have no power to convince them otherwise (yet? )."

Indeed ! However, I was mentioning Deoxys (I am one of the designers) since it is one of the winners of the CAESAR competition (winner of the security-in-depth portfolio to be more precise).

Regards,

Thomas.

Le mer. 30 mars 2022 à 01:21, Blumenthal, Uri - 0553 - MITLL <[email-masked]> a écrit :

indeed, Romulus-M as stated only supports 128-bit key. You can support 256-bit key in a straightforward way by using a larger tweak version of Skinny, but this is ongoing work :-)

Nice to hear that. Any idea (a) when this work would be completed, and (b) whether NIST would accept/augment the current Romulus-M with 256-bit key capability?

An alternative for you could be Deoxys, there is a MRAE version of Deoxys with 256-bit key: https://thomaspeyrin.github.io/web/assets/docs/papers/Jean-etal-JoC2021.pdf (see Deoxys-II-256 in Table 2). Larger versions of Deoxys-TBC are coming also, so it will be easy to use larger keys for all Deoxys modes. 

Deoxys (AFAIK) is not among the NIST LWC finalists, which would make some users shy away from it. I have no power to convince them otherwise (yet? 😉).

Thanks!

Le mer. 30 mars 2022 à 00:04, Blumenthal, Uri - 0553 - MITLL <[email-masked]> a écrit :

Thomas, yes, exactly. “Better than GCM” is not the level that I’d want to be aiming at.

Unfortunately, I did not see Romulus-M supporting 256-bit key…?

Leo, yes – NIST did not request (or even mention) nonce misuse resistance. Nor did they bother to standardize any nonce misuse-resistant mode at all. I know AES-GCM-SIV was submitted for standardization – but the NIST seems to have dropped the ball on it, and on the whole nonce misuse thing… <Sigh>

Oh well…

--

V/R,

Uri

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

From: Thomas Peyrin <[email-masked]>
Date: Tuesday, March 29, 2022 at 11:37
To: Leo Perrin <[email-masked]>
Cc: Uri Blumenthal <[email-masked]>, CFRG <[email-masked]>, John Mattsson <john.mattsson=[email-masked]>, Robert Moskowitz <[email-masked]>
Subject: Re: [CFRG] FYI - NIST Fifth Lightweight Cryptography Workshop (virtual)

Hi all, 

indeed I think Romulus (full disclosure: I am one of the designers) is the only remaining candidate of the NIST LWC competition that has a version (Romulus-M) that claims full nonce-misuse resistance (confidentiality and authentication). In addition, note that the security notion for Romulus-M is "nonce Misuse-Resistant Authenticated Encryption" (MRAE), which is very different and much stronger than what sponge function candidates from the competition might be offering (most did not claim any). Also, I think "providing better nonce-misuse resistance than GCM" is maybe a too low target for a future standard/deployment and we should aim now for higher robustness such as MRAE.

Since ASCON's nonce-misuse resistance was just mentioned, I would like to warn that there has been a rump session talk at FSE 2022 that seems to show a practical nonce-misuse attack (2^40 computations) on the full scheme.

Regards,

Thomas.

Le mar. 29 mars 2022 à 21:52, Leo Perrin <[email-masked]> a écrit :

Hello everyone,

Obvious conflict of interest: I am a co-author of SPARKLE (one of the finalists).

- most (all?) of their finalists support only 128-bit key;

Sparkle supports 128, 192 and 256 bit keys

- none (?) of their finalists can deal with none reuse/misuse (this is a BIG one for me). Maybe, Romulus has a variant…

It depends what security you want in case of nonce misuse. As far as I can tell, Ascon only suffers issues in terms of confidentiality in case of nonce-misuse, and only potentially so. Since the key is XORed into the state after the initialization and again before squeezing the tag, an adversary cannot forge a tag. Furthermore, in order for the attacker to be able to actually decrypt ciphertexts beyond their first block, they would need to recover the full capacity first. Indeed, the encryption part of the algorithm is not a simple stream cipher, so the keystream cannot simply deduced from a plaintext/ciphertext pair (except for the first block). Even in the nonce-misuse case, a capacity-recovery attack should be expected to be highly non-trivial at best---and not faster than brute-force at worst.

For Sparkle, we borrowed from Ascon the key XOR after initialization and before tag generation. However, the capacity is smaller so attacks based on finding collisions in it might seem tempting... But since the capacity is at least equal to the tag length, I don't expect this to have a huge impact.

I would expect the behaviour of TinyJambu to be similar (i.e. that nonce-misuse wouldn't be such a big deal for it). Its mode is essentially sponge-based, but with a secret-dependent permutation, which would also hinder forgeries.

I haven't had a close enough look at the other finalists to say what kind of security they offer, so the fact that they are not mentionned here doesn't mean that they are "nonce-misuse brittle".

Overall, I don't remember nonce-misuse being a property NIST demanded in their initial call, which is probably why it was not given any particular attention. Still, many finalists are sponge-based, and as a result wouldn't collapse in the way GCM does in case of nonce-misuse. 

Cheers,

/Léo

De: "Uri Blumenthal, 0553 - MITLL" <[email-masked]>
À: "John Mattsson" <john.mattsson=[email-masked]>
Cc: "cfrg" <[email-masked]>, "Robert Moskowitz" <[email-masked]>
Envoyé: Mardi 29 Mars 2022 14:46:34
Objet: Re: [CFRG] FYI - NIST Fifth Lightweight Cryptography Workshop (virtual)

_______________________________________________
CFRG mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 1 Apr 2022 16:25:14 +0000

My general understanding is that it’s always better to discuss requirements for a standard before that standard has been adopted, rather than afterwards…

From: CFRG <[email-masked]> On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: Tuesday, March 29, 2022 6:28 PM
To: Thomas Peyrin <[email-masked]>
Cc: John Mattsson <john.mattsson=[email-masked]>; cfrg <[email-masked]>; Robert Moskowitz <[email-masked]>
Subject: Re: [CFRG] FYI - NIST Fifth Lightweight Cryptography Workshop (virtual)