Re: [lamps] [EXTERNAL] Re: Adoption call for draft-housley-lamps-cms-sha3-hash

[Mike Ounsworth <[e-mail]>]

Hi Ilari,

Good points.

I would love your review of sections 5, 5.1 and 5.2 of draft-ietf-lamps-pq-composite-kem since that is the bit we are debating.

The point is that for id-MLKEM512-RSA2048-KMAC128, we need a message digest for the internal RSA-KEM; currently we have listed sha3-256 since it aligns with the KMAC128/256 used in the outer KEM combiner. Ditto id-MLKEM768-RSA3072-KMAC256 choosing sha3-384 to align with the KMAC256/384. (currently on a plane and can’t check Panos’ CMS SHAKE draft, but I suspect that we would have to choose the next size up which would have some small amount of waste).

---
Mike Ounsworth

From: Spasm <[e-mail]> On Behalf Of Ilari Liusvaara
Sent: Monday, October 30, 2023 2:28 PM
To: [e-mail]
Subject: [EXTERNAL] Re: [lamps] Adoption call for draft-housley-lamps-cms-sha3-hash

On Mon, Oct 30, 2023 at 12: 56: 42PM -0400, Michael StJohns wrote: > On 10/29/2023 10: 02 PM, Kampanakis, Panos wrote: > > > > > try and practice algorithmic pluralism in the way we define things > > > > Personally,


On Mon, Oct 30, 2023 at 12:56:42PM -0400, Michael StJohns wrote:

> On 10/29/2023 10:02 PM, Kampanakis, Panos wrote:

> >

> > > try and practice algorithmic pluralism in the way we define things

> >

> > Personally, I am not sure algorithmic pluralism for the sake of variety

> > is a good idea. Integrating and using only new algorithms that make

> > sense is a better one imo.

> >

> > I can’t think of a case where SHA-3 would be preferred over SHAKEs, but

> > I am open to suggestions.

> >

> AFAICT from FIPS202 both are just parameterized instantiations of the same

> KECCAK function and have exactly the same performance (and strength).  E.g.

> from FIPS202

>

> SHA3-256 (M) ::= KECCACK[512](M||01, 256)

>

> SHAKE256 (M,d) ::= KECCACK[512](M||1111, d)

>

> Now RFC8702 says that SHAKE256 should use d = 512 if you're using it as a

> hash/message digest, but I can't find anywhere in the NIST document that

> also use that value as a default.  That worries me with respect to future

> interoperability.



d=512 is the minimum to reach the nominal strength of SHAKE256: 256

collision, 256 preimage.



This is above the nominal strength of SHA3-256, which is 128 collision,

256 preimage.



Of course, the difference is practically meaningless, but hey, it is

free.



Or if one thinks 128-level is enough, there is SHAKE128, which is even

faster than SHA3-224. It has d=256 (again, minimum to reach nominal

strength).





Now, I do have a major interoperability concern about the ECDSA

variants, but for different reason. And ECDSA with SHA-3 has the exact

same conern (maybe even worse).









-Ilari



_______________________________________________

Spasm mailing list

[e-mail]<mailto:[e-mail]>

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!YZ42MSxjDOe55p83lIgrm1lX93y7hAqitR04NmDpT42i0MvuuNPSPlhST61nOT9xMdd2_IEwXAXbXcKcNTJ0L3ueL_50vTtA-tk$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!YZ42MSxjDOe55p83lIgrm1lX93y7hAqitR04NmDpT42i0MvuuNPSPlhST61nOT9xMdd2_IEwXAXbXcKcNTJ0L3ueL_50vTtA-tk$>

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.