[CFRG] Re: ML-KEM for HPKE: just use seeds

["Markku-Juhani O. Saarinen" <[e-mail]>]

On Sun, Oct 13, 2024 at 8:11 AM John Mattsson <john.mattsson=
[e-mail]> wrote:

> I think it would be good if the draft registered KMAC based KDFs. While
> HMAC-SHA-2 could make sense in a transition period, it does not make sense
> to force future implementations to support both SHA-2 and SHA-3. ML-KEM
> uses SHA-3 internally so any implementation of ML-KEM has an implementation
> of SHA-3.
>

+1

Especially in pure hardware SHA-2 is slow & relatively cumbersome to
protect against side-channel attacks. It would be unfortunate that after
putting a lot of effort to have a protected ML-KEM, the secrets would be
just leaked out by the KDF. And of course, since SHA-2 is not not used that
much in PQC era, having it around is just an extra hardware cost.

The standard NIST SP 800-108r1-upd1 "Recommendation for Key Derivation
Using Pseudorandom Functions" defines a KMAC-based KDF.
https://doi.org/10.6028/NIST.SP.800-108r1-upd1

This is already covered by ACVP (i.e. I can get a FIPS cert for it.) Some
NIST test vectors are at:
https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files/KDF-KMAC-Sp800-108r1

I recall SP 800-108r1-upd1 has a version there that can be ran in counter
mode (i.e. parallelizable to make it arbitrarily fast if that is a priority
for someone.)

Cheers,
-markku

Dr. Markku-Juhani O. Saarinen <[e-mail]>


>
>
> Cheers,
>
> John
>
>
>
> *From: *Deirdre Connolly <[e-mail]>
> *Date: *Friday, 11 October 2024 at 19:20
> *To: *CFRG <[e-mail]>
> *Subject: *[CFRG] ML-KEM for HPKE: just use seeds
>
> Hello CFRG, I have published a new-new version of 'ML-KEM for HPKE':
>
> https://datatracker.ietf.org/doc/draft-connolly-cfrg-hpke-mlkem/02/
>
>
> Previous versions used ML-KEM to craft an updated KDF out of HPKE's
> subroutines to achieve similar binding properties to the default KEM for
> HPKE, DHKEM. With the final publication of FIPS 203
> <https://doi.org/10.6028/nist.fips.203>, we now have a better compromise:
> the officially FIPS-compliant 64-byte seed format of ML-KEM keys. This
> format gives us MAL-BIND-K-CT and LEAK-BIND-K-PK security
> <https://eprint.iacr.org/2024/523.pdf> out of the box. This seems good
> enough for most use cases (especially inside IETF so far) and so I have
> updated my document to just say, 'use ML-KEM as it is, but you MUST use the
> 64-byte seed format for the keys', and that's it. Hopefully you can take a
> look.
>
> Thanks!
> Deirdre
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Fri, Oct 11, 2024 at 1:06 PM
> Subject: New Version Notification for draft-connolly-cfrg-hpke-mlkem-02.txt
> To: Deirdre Connolly <[e-mail]>
>
>
> A new version of Internet-Draft draft-connolly-cfrg-hpke-mlkem-02.txt has
> been
> successfully submitted by Deirdre Connolly and posted to the
> IETF repository.
>
> Name:     draft-connolly-cfrg-hpke-mlkem
> Revision: 02
> Title:    ML-KEM for HPKE
> Date:     2024-10-11
> Group:    Individual Submission
> Pages:    7
> URL:
> https://www.ietf.org/archive/id/draft-connolly-cfrg-hpke-mlkem-02.txt
> Status:   https://datatracker.ietf.org/doc/draft-connolly-cfrg-hpke-mlkem/
> HTML:
> https://www.ietf.org/archive/id/draft-connolly-cfrg-hpke-mlkem-02.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-hpke-mlkem
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-connolly-cfrg-hpke-mlkem-02
>
> Abstract:
>
>    This memo defines ML-KEM-based ciphersuites for HPKE ([RFC9180]).
>    ML-KEM is believed to be secure even against adversaries who possess
>    a cryptographically-relevant quantum computer.
>
>
>
> The IETF Secretariat
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>