Re: [openpgp] Remarks on Brainpool missing in -06

["Kousidis, Stavros" <[e-mail]>]

Dear all,

I do not see why RFC 6637 defines Brainpool curves simply through the introduction of an OID adressing scheme. Curves have to be defined and described explicitely so that implementations know the necessary metadata that accompanies a curve.

However, I think what Daniel is mainly asking for is just a simple quality assurance for the brainpool-curves merge request and this is an absolutely legitimate question.

The reason why I think that the data given in the merge request stands up to reality is that I've done some certificate generations/dumps to cross-check before submission.

I've used GnuPG 2.3.6 and Libgcrypt 1.10.1 to generate a certificate for each Brainpool curve (i.e. brainpoolP256r1, brainpoolP384r1, brainpoolP512r1) and verify that the Brainpool curve data described in the merge request corresponds to the values in the generated certificates. I've used Sequioa-PGP to (hex) dump the certificates and do the comparison (my compliments to the creators of this great tool!).

That is,

1) The OIDs given in "§9.2 ECC Curves for OpenPGP" for the Brainpool curves match the ones in the generated certificates, i.e. 2B 24 03 03 02 08 01 01 07 (brainpoolP256r1), 2B 24 03 03 02 08 01 01 0B (brainpoolP384r1), and 2B 24 03 03 02 08 01 01 0D (brainpoolP512r1).

2) The formats given in "§9.2.1 Curve-specific Wire Formats" of the merge request match the ones in the generated certificates, i.e. "SEC1" (ECDH Point Format) and "integer" (ECDH Secret Key MPI).

3) The MPI payload counts given in "§12.2.3 Notes on EC Point Wire Formats" of the merge request match the "ecdsa_pub_len" and "ecdh_pub_len" values in the generated certificates, i.e. 0x0203 (515 bits) for brainpoolP256r1, 0x0303 (717 bits) for brainpoolP384r1, and 0x0403 (1027 bits) for brainpoolP512r1.

4) The octet counts in "§12.5 EC DH Algorithm (ECDH)" are pretty straightforward. Those I did by hand and with my pocket calculator.

5) The combinations of curve+hash+encaps in "§12.5.1 ECDH Parameters" correspond to the ones I found in the generated certificates, i.e. brainpoolP256r1+SHA2-256+AES-128, brainpoolP384r1+SHA2-384+AES-192, and brainpoolP512r1+SHA2-512+AES-256.

For reproducability these are the commands I've used

gpg --expert --full-gen-key
gpg --output dummy.pgp --armor --export-secret-key dummy@id
sq packet dump -x --mpis dummy.pgp -o dummy.pgp.dump

Best
Stavros

Von: Werner Koch <[e-mail]>
Gesendet: Mittwoch, 15. Juni 2022 10:29
An: Daniel Kahn Gillmor <[e-mail]>
Cc: [e-mail]
Betreff: Re: [openpgp] Remarks on Brainpool missing in -06


On Tue, 14 Jun 2022 08:30, Daniel Kahn Gillmor said:

> I'm puzzled by this assertion.  RFC 6637 says nothing about Brainpool,
> and the structure of the crypto-refresh draft in -06 is itself no

Read the discussions about RFC-6637 were we decided that the
introduction of an OID is sufficient to implement Brainpool curves
without delaying the publication of that RFC.

> that support Brainpool, in a way that has not been formally
> standardized.

  "We believe in rough consensus and running code." Implementation
  experience provides critical feedback to the standardization process.

Now moving to Geneve?

> I believe that Stavros's proposed change offers the formalization that
> you're asking for.  It would be great to have more comments on it.

We don't need to discuss that because there is running code on millions
of devices.  It the specification is up to the reality, good.  If not,
it is just another bug in an RFC.


Salam-Shalom,

   Werner

--
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein