3

Some time ago I generated an ed25519 GnuPG (GPG) keypair using the gpg command line utility. Now, when I import this key into gpg, I get a warning:

gpg: key 0123456789ABCDEF: public key "User Name <[email protected]>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: key 0123456789ABCDEF: "User Name <[email protected]>" not changed
gpg: warning: lower 3 bits of the secret key are not cleared
gpg: key 0123456789ABCDEF: secret key imported
gpg: Total number processed: 1
gpg:              unchanged: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1

As far as I understand from casual searching, this message: warning: lower 3 bits of the secret key are not cleared is caused by a potential vulnerability in the key, which is probably due to the fact that I created this key with an earlier version of gpg.

Is there a way to 'fix' this situation, while retaining the keypair?

2
  • Did the key work prior to being exported and what program was used to export? Dec 5, 2021 at 4:41
  • Yes: the key worked prior to exporting and still works after importing. I used gpg CLI tool (GnuPG, gnupg.org, version 2+) on macOS (from Homebrew) for generating, exporting, and importing.
    – CBlew
    Dec 6, 2021 at 8:23

2 Answers 2

3

For elliptic curve keys using edwards-25519/curve25519 the lowest 3 bits of the key should be set to zero to ensure the key is a multiple of 8, avoiding a small subgroup attack.

You could edit the key in binary, however this attack is hard to mount and probabilistically unlikely.

EDIT: from GPG code:

  • new keys will be generated with correctly tweaked bits using secret key with non-tweaked bits would issue a warning

  • CLI command --edit-key [--check-cv25519-bits | --fix-cv25519-bits] added, allowing to fix older key

2
  • Is the CLI command available for GNUPG? I think this is only available for [RNPGP](rnpgp.org/) . I also found some references here: dev.gnupg.org/T5464, but I am not clear how to fix this. I definitely could not find the options in gnupg.
    – ksinkar
    Mar 26, 2023 at 9:54
  • Just hex edit the key and zero the bits yourself (being careful to check the endianness)
    – Woodstock
    Mar 27, 2023 at 14:25
3

After an abnormally large amount of deep digging on my part ...

This appears to be an interoperabilty issue. I wouldn't be concerned about it unless you are "crossing the streams" (moving between OpenPGP, GnuPG, RNP = the one that caused the messsage to be added in 2.3.3). It is just a warning, and implies that GnuPG knows something is amiss (and hopefully will handle it properly??).

I can't find any explicit confirmation of that, but it seems like a reasonable take-away from all that I read. I invite others to confirm or correct me if they discover further information.

The attack isn't easy either.


Gory details (not for the feint of heart):

"gpg: Print a warning when importing a bad cv25519 secret key. [T5464]"

https://dev.gnupg.org/T5565

https://dev.gnupg.org/T5464

https://mailarchive.ietf.org/arch/msg/openpgp/-A0CgvBPqWGMw18UBhHE-Gy6LRM/

Basically, there are differences between how libgrypt works with 'ed25519' compared to other algorithms (can classify that as "errata"), as well as differences between internal key format and the exported key format (endian of the bit string, leading zero handling, etc.).

It only seems to apply to 'ed25519' used for encryption, as 'cv25519' used for signing came later, and by that time there was some agreement on how to do things (which was different!)

I once stumbled across instructions for hex editing the exported key, but I didn't bookmark it, and haven't been able to find it again.

1
  • it's the other way around, the twisted Edwards curve is used for signature and cv25519 for ECDH "encryption".
    – Woodstock
    Mar 27, 2023 at 14:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .