Re: Specification for Kyber in GnuPG

Kai Engert via Gnupg-devel <[email protected]>
Newsgroups gmane.comp.encryption.gpg.devel
Message-ID <[email protected]>
On 02.05.24 08:42, Werner Koch via Gnupg-devel wrote:
> Many thanks to Stavros Kousidis, Falko Strenzke, and Aron Wussler for
> their draft on adding PQC to OpenPGP.  The algorithms used by LibgrePGP
> are the same except for the fixed info.  I took the freedom to remove
> the rationale parts which are not helpful for an implementer and was
> thus able to make the description more concise.

Hi Werner,

is my understanding correct, LibrePGP reuses most of the PQC 
specification from draft-ietf-openpgp-pqc, and your only concerns are 
about the algorithm IDs and the fixed info?

If that's correct, I think it's exciting that your views are so close to 
each other!

I wonder if the authors of draft-ietf-openpgp-pqc might be willing to 
accept these changes, for the sake of a common specification.

Would you be open to a shared specification for the PQC subkey format?

Furthermore, as I understand it, the v5 key format and the v6 key format 
are very close to each other (thanks a lot to Andrew Gallagher for 
enlightening me about this detail).

I wonder if we could find a way to introduce the specification of a v5 
format subkey (only) into an IETF specification, to allow the 
draft-ietf-openpgp-pqc specification to use it.

Actually, I think it would be better if there was a common 
specification, agreed to by both the LibrePGP and IETF groups. How could 
such a common specification be defined? Do you have ideas or suggestions?

I'm dreaming here, but I think it would be great to see a base 
specification, that extracts the common denominator of draft-librepgp 
and crypto-refresh, and which could be extended to contain the v5 subkey 
format. Then, draft-librepgp (and ideally crypto-refresh) could 
potentially be rewritten to be incremental specifications on top of the 
common denominator spec.

Thanks
Kai
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.