Page MenuHome GnuPG

OpenPGP: Curve 448, modernize?
Closed, WontfixPublic


GnuPG 2.3 has an experimental implementation for Ed448/X448.

In September 2021, I looked around code of ECDH using X448.

I wonder:

  • For KDF, is use of SHA2-512 and its left-most bits good? If we can use modern things, it sounds that SHAKE-256 would be relevant here, because it is designed to output arbitrary size.
  • Futher, for encryption of session key by KEK (by KDF), is AESWRAP is relevant now? Possibly, use of AEAD cipher instead would be better here, because it gives an information if decrypted session key is valid or not.

Event Timeline

The major problem I see is that an implementation needs to add more crypto primitives to support ths curve. And we can expect that 448 will eventually get in widespread use. We already have all primitives but would inhibit the creation of minimal implementations.

I'm reading RFC5297, which says:

SIV can be used as a drop-in replacement for any specification that uses [RFC3394] or [RFC3217], including the aforementioned use. It is a more general purpose solution as it allows for associated data to be specified.

(RFC3394 is the one for AES Wrap)

Is that really required? Should we wait what the conlusion of the WG will be?

I should have explained the context.
No, there is no discussion about this in the WG.

I write this as my memorandum, as the WG charter says something like "Crypto Update". I wonder if use of SIV (instead of AESWRAP) would be more natural, if we were writing the spec today.

In the current specification (of RFC6637), session key encryption with ECDH uses:

  • checksum+padding
  • AESWRAP using a key generated by KDF

... which seems (for me) complicated and not modern. Well, there is one possibly good point in current spec, where the size of session encryption key can be obfuscated (by longer padding), though.

If we keep RSA/Elgamal in the update of spec, checksum+padding for session key is compatible method, so, AESWRAP might be justified (I mean, makes sense).

I try to see if current libgcrypt has enough features.

gniibe triaged this task as Normal priority.Mar 7 2022, 11:15 AM

Given that the OpenPGP WG practically decided to fork OpenPGP I don't see a reason why we should keep this bug open.

werner claimed this task.
werner edited projects, added gnupg; removed gnupg24.

Way to late for a change and also adding another algorithm (SIV) complicates things for no good purposes.