search

rnpgp / rnp

RNP: high performance C++ OpenPGP library used by Mozilla Thunderbird
https://www.rnpgp.org
Other
199 stars 55 forks source link

RNP generated EDDSA+X25519 private key fails with "bad passphrase"/"bad secret key" in GnuPG 2.2.19/libgcrypt 1.8.5 #1383

Closed ronaldtse closed 2 years ago

ronaldtse commented 3 years ago

I do not know, if I should open up a new bug for this, because my problem is related to this.

I created a EDDSA + X25519 keypair in RNP and tried to use the private key with gpg (GnuPG) 2.2.19/libgcrypt 1.8.5 which either fails with a bad passphrase or bad secret key.

I tried:

  1. Created a key with rnpkeys Then:
  2. Exporting the private key with rnpkeys
  3. Importing it to gpg. -> Bad secret key, but it got somehow imported or
  4. Use the keystore (pubring.gpg + secring.gpg) directly with gpg -> bad passphrase on export of private key, But displaying worked fine.

Should I open a dedicated but report?

Originally posted by @func0der in https://github.com/rnpgp/rnp/issues/1018#issuecomment-761699333

ronaldtse commented 3 years ago

Originally from @func0der in https://github.com/rnpgp/rnp/issues/1018#issuecomment-761703750

I tried to create a docker.sh file that could simulate the problem, but CentOS 7 has such an outdated libgcrypt version, that gpg does not support elliptic curves yet. So you have to try it the manual way, sorry.

Commands ran:

export keydir=/tmp
rnpkeys --version -> rnp 0.12.0
rnpkeys --generate-key --expert --userid=foo@bar.de --homedir=${keydir} 
  -> Choose (22) EDDSA + X25519
  -> Passphrase: test123
rnpkeys --export-key --userid foo@bar.de --secret --homedir=${keydir}
(output in attached file `foo@bar.de.asc`)

privkey+secring.gpg.zip

ronaldtse commented 3 years ago

Ping @dewyatt @ni4 for triage.

ni4 commented 3 years ago

This is a problem on the GnuPG side, I reported it here : https://dev.gnupg.org/T5114

func0der commented 3 years ago

@ni4 Neat.

I could create a key with GnuPG and import it in and out of Thunderbird (see: https://github.com/flathub/org.mozilla.Thunderbird/issues/163) and back into GnuPG without any problem. But I guess that the key's first bit was just < 1, wasn't it? If I understand that correctly it was just (bad) luck, that I encountered the bug at all and furthermore in a non-persistent way?

ni4 commented 3 years ago

Actually it's not a bad luck but flip of a coin. This should happen with 50% probability - EdDSA secret keys are generated as random 256 bits.

ni4 commented 3 years ago

JFYI: This was fixed since GnuPG 2.2.24.

ni4 commented 3 years ago

Okay, it was partially fixed for EdDSA secret key, however there is another part for Curve25519 subkey, see https://dev.gnupg.org/T5464