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

FWIW I think it would be pretty fine to have just the following
options and the parties can chose what suit them best:

Encryption:
ML-KEM-768+ECDH-NIST-P-384
ML-KEM-768+ECDH-brainpoolP384r1
ML-KEM-1024+ECDH-NIST-P-521
ML-KEM-1024+ECDH-brainpoolP512r1

Signing:
ML-DSA-65+ECDSA-NIST-P-384
ML-DSA-87+ECDSA-NIST-P-521
ML-DSA-65+ECDSA-brainpoolP384r1
ML-DSA-87+ECDSA-brainpoolP512r1

I really believe strengths should be matched properly and that level 1
security strengths are not really interesting for OpenPGP given the
mostly "offline" nature of its use (which means latency is not a big
factor) and the fact that OpenPGP generally does not have size issues
with these algorithms.

For online protocols latency and size are very important factors so for
those protocols the evaluation would be different.

Simo.

On Thu, 2025-10-16 at 07:32 -0400, Quynh Dang wrote:
> 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 <[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]

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

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