Ed25519 keys: what's stored in a secret key packet?

Marco Ricci m at the13thletter.info
Mon Feb 15 00:08:57 CET 2021


Greetings!

Thus spoke James Bottomley:
>> I'm aware, as well. I believe though that the normative EdDSA version
>> is to use the `r = H(KM)` calculation. I see no indication in the
>> EdDSA for OpenPGP spec that a non-standard version of determining `r`
>> is used.
>
> libgcrypt uses K = LH
>
> The relevant code is ecc-eddsa.c:_gcry_ecc_eddsa_sign
>
> The only slight deviation gnupg does for elliptic curves is that it
> uses RFC6979 deterministic signatures for ECDSA.

The latter is good to know, thanks.

I believe you on the former -- it looks plausible, given the libgcrypt
code -- but I gave up trying to actually verify it. I find libgcrypt's
code rather too opaque and confusing for me to follow. (But then I've
touched libgcrypt for all of 10mins, I'm not too familiar with its
coding style (names, data structures, etc.), and this kind of low-level
C code isn't really my forte anyway.)

>> But then the spec and GnuPG's behavior differ, no? And one of them
>> should be fixed -- presumably the spec, because it's still a draft,
>> and because IMO the current practice is saner than the spec. Should I
>> file a proper report against the spec then?
>
> Well, it's not really relevant any more:  The spec is documenting the
> secring keypacket format, which isn't used by current gnupg (it started
> switching to the encrypted s-expression format in 2017).

Inasfar as GnuPG alone is concerned, maybe, but what about file exchange
of secret keys between different OpenPGP implementations, say GnuPG and
Thunderbird/RNP? My reason for worrying about secret key contents in the
first place is because I ultimately want to share Ed25519 key material
between OpenPGP and (Open)SSH, and perhaps other systems. And the most
future-proof way of doing that is to attempt converting the "standard"
key formats of the respective systems into one another. That use case
would definitely benefit from a corrected spec.

> The current format is documented in agent/keyformat.txt

I'm starting to feel like I'm not doing my homework properly. Thanks
again for the pointer, I'll give the v2.3+ text-based private key format
a try.

Regards,
Marco


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210215/0de9b7c0/attachment.sig>


More information about the Gnupg-devel mailing list