On Tue, 2026-02-10 at 15:09 +0100, Filip Skokan wrote: > Hello Michael, > > On AES-256-GCM: The primary motivation here is uniformity and simplicity of > choice. Within the PQ[/T] algorithm set the goal was to offer a choice > between AES-GCM and ChaCha20Poly1305 but not introduce a further AES-128 > vs. AES-256 decision axis. This keeps the number of algorithms manageable, > each KEM gets exactly two AEAD options rather than three.
[..] > Maybe like so (see below), without ChaCha and with P-256 and X25519 paired > with SHAKE128 and AES-128-GCM, but as evident by HPKE-7, requests will come > for pairing 128-bit traditional curves with AES-256-GCM at which point I'd > rather have "no additional security given" than an explosion of the number > algorithm choices. > > +--------------------+----------+-------------------+ > > HPKE KEM | HPKE KDF | HPKE AEAD | > +--------------------+----------+-------------------+ > > MLKEM768-P256 | SHAKE128 | AES-128-GCM | > > (0x0050) | (0x0010) | (0x0001) | > +--------------------+----------+-------------------+ > > MLKEM768-X25519 | SHAKE128 | AES-128-GCM | > > (0x647a) | (0x0010) | (00x0001) | > +--------------------+----------+-------------------+ > > MLKEM1024-P384 | SHAKE256 | AES-256-GCM | > > (0x0051) | (0x0011) | (0x0002) | > +--------------------+----------+-------------------+ > > ML-KEM-768 | SHAKE256 | AES-256-GCM | > > (0x0041) | (0x0011) | (0x0002) | > +--------------------+----------+-------------------+ > > ML-KEM-1024 | SHAKE256 | AES-256-GCM | > > (0x0042) | (0x0011) | (0x0002) | > +--------------------+----------+-------------------+ > > Do you think starting off with these 5 (+ their KE variants) and seeing > what additional discussions arise later is better? ML-KEM is clearly used to address PQC, in that case I think it would make sense to standardize exclusively on AES-256 for all 5 options above, given keys are supposed to be reduced in security by half by Grover's. NIST is discussing the introduction of a 512 bit key AES, if/when that one comes out perhaps add an option with AES-512 (or however it will be called) later. Best, Simo. > > S pozdravem, > *Filip Skokan* > > > On Tue, 10 Feb 2026 at 13:25, Michael P1 <michael.p1= > [email protected]> wrote: > > > Hi all, > > > > > > > > Posting as an individual, with chair hat off. > > > > > > > > Firstly, thank you Filip and Brian for doing this work and I agree with > > this as a path forward following the previous discussions. > > > > > > > > I did have a question on the algorithm combination choices. At the moment, > > the security levels between KEM, KDF and AEAD are not consistent in some of > > the algorithms. In draft-ietf-jose-hpke-encrypt we match P-256/x25519 with > > AES-128-GCM as they provide the desired security level, but that's not the > > case here at the moment. > > > > > > > > I understand the choice of ML-KEM-768 over ML-KEM-512 as per discussions > > around draft-ietf-hpke-pq and this is documented well in the security > > considerations. > > > > > > > > However, could you outline the reasoning for the choice of AES-256-GCM > > over AES-128-GCM? > > For example, in algorithm HPKE-8, we use P256 in our KEM to give 128 bits > > of traditional security for those who want to use a hybrid approach, and so > > AES-256-GCM provides no additional security over AES-128-GCM in this > > algorithm. > > > > > > > > If it's motivated by discussions of Grover's algorithm, then there has > > been separate analysis from both ETSI and the University of Waterloo to > > show that security impact on symmetric algorithms of quantum computing is > > in-fact limited. > > > > > > > > Similarly, worth discussing the motivation for the choice of SHAKE256 > > throughout. > > > > > > > > Thanks again for your work on this, > > Michael > > > > > > _______________________________________________ > > jose mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
