[openpgp] Re: I-D Action: draft-ietf-openpgp-nist-bp-comp- 00.txt

Hi Andrew,

There may be cases where ML-KEM-512 has important performance
characteristics.  For example, the IKEv2 initial message works much better
with ML-KEM-512 than with ML-KEM-768 due to the fact that ML-KEM-512's
ciphertext is smaller so most of the initial messages should fit in 1 UPD
package.

That is not applicable to OpenPGP. But I don't have any confident
prediction about the future of OpenPGP's use cases.

I support moving to PQ security and in many cases performance may be an
obstacle in fast migration to PQ security.  So, better performance PQ
security options would be helpful generally.

Regards,
Quynh.

On Thu, Oct 16, 2025 at 7:05 AM Andrew Gallagher <andrewg=
[email protected]> wrote:

> Hi, Quynh.
>
> On 16/10/2025 11:13, Quynh Dang wrote:
> > If it is not, the user should use ML-KEM-768 if ML-KEM-768's performance
> > is acceptable.  If ML-KEM-768's performance is not acceptable, the user
> > should go with ML-KEM-512. I am confident in ML-KEM-512's security.
>
> I'm relatively unconcerned about the security properties of mlkem512.
> Even if the strength is weaker than claimed, it's still Pretty Good (ho
> ho). I'm more curious about the cost/benefit ratio of the combinatorics
> - are there particular applications (such as embedded controllers) where
> a lightweight PQ algorithm is crucial? Or is this more of a nice to have?
>
> A
>
> _______________________________________________
> openpgp mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]