1

Using: gpg (GnuPG) 2.0.22 libgcrypt 1.5.3

I am trying to decrypt a file from a remote site. I exported our key to a file. gpg <filename> returns: (Key IDs changed)

pub 2048R/656CC421 2018-04-19
sub 2048R/99F89J32 2018-04-19

I sent it to the sender and asked them to import, sign and trust it.

They sent me two different key files. Using gpg <filename> returns:

1. pub 2048R/62568LK1 2015-09-03

2. pub 2048R/J561VE25 2015-09-23

If I do an edit-key, I get the following:

My key:

Secret key is available.

pub 2048R/656CC421 created: 2018-04-19 expires: never usage: SC
trust: ultimate validity: ultimate
sub 2048R/99F89J32 created: 2018-04-19 expires: never usage: E
[ultimate] (1).

Their keys:

1. pub 2048R/62568LK1 created: 2015-09-23 expires: never usage: SCE
trust: full validity: full
[ full ] (1).

2. pub 2048R/99F89J32 created: 2015-09-03 expires: never usage: SC
trust: full validity: full
[ full ] (1).

I am running the decrypt command in a bash script with the following parameters.

echo $passphrase | /usr/bin/gpg --verbose --passphrase-fd 0 --no-tty --output $output_file --recipient myuser --decrypt $input_file

Following is the output of the command:

Version: GnuPG v1.2.4 (MingW32)
gpg: armor header:
gpg: public key is 99F89J32
gpg: using subkey 99F89J32 instead of primary key 656CC421
gpg: using subkey 99F89J32 instead of primary key 656CC421
gpg: cancelled by user
gpg: encrypted with 2048-bit RSA key, ID 99F89J32, created 2018-04-19
"usrname (Description) <usrname@domain.com>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key

My conclusion from all of this is that the sender needs to send me their public key in the same format that I sent to them. Such as:

pub 2048R/J561VE25 2015-09-23

sub 2048R/SOM3NUMB 2015-09-23

My thought it that the key files they sent me don't have the corresponding pub/sub info and therefore gpg can't validate because I only have one part of their keypair's information.

Can anyone tell me if I'm wrong in this or if my thoughts are correct?

Thanks!

Noobux
  • 13

2 Answers2

0
Version: GnuPG v1.2.4 (MingW32)

Holy balls that's old – version 1.2.4 was released in 2003. The sender doesn't care much about updating their security software, it seems.

(Your own 2.0.22 isn't much better, with 2013 as the release date.)

gpg: public key is 99F89J32
gpg: using subkey 99F89J32 instead of primary key 656CC421
gpg: using subkey 99F89J32 instead of primary key 656CC421

That's normal. The "main" keypair is only used for signing (aka certifying) other keys; often also for signing messages. It is not usable for encryption – you always have a subkey for that purpose.

(The separation also allows for such things as offline signing or frequent encryption key rotation.)

gpg: cancelled by user
gpg: encrypted with 2048-bit RSA key, ID 99F89J32, created 2018-04-19 "usrname (Description) <usrname@domain.com>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key

Sounds like GnuPG tried to display a passphrase prompt to unlock your keypair, but either the passphrase window failed to open, or you accidentally cancelled it yourself.

The password prompt is shown by GnuPG's pinentry component, which itself is started via gpg-agent. I don't really know where to start troubleshooting that on Windows – perhaps a newer version would work better. (Your GnuPG 2.0.22 was released in 2013.)

Newer versions, starting with GnuPG 2.1, support a "loopback pinentry" mode which can work without the pinentry component. If upgrading doesn't help on its own, try activating this option.

that the sender needs to send me their public key

The sender's public key is useless for decryption and is only necessary for signature verification.

Such as:

pub 2048R/J561VE25 2015-09-23

My thought it that the key files they sent me don't have the corresponding pub/sub info and therefore gpg can't validate because I only have one part of their keypair's information.

No. This bit of information is meant for you, the user – it summarizes the key's type, short (useless) ID, and expiry date. GnuPG can perfectly well extract it from the key itself, not that it needs to.

Community
  • 1
grawity
  • 501,077
0

Well after much back & forth, I found the solution in two changes.

  1. The gpg-agent.conf needed to have pinentry-program /usr/bin/pinentry-curses added to it.

  2. The script writer needed to add --batch to his command line.

Once that was done, gpg was able to get to the secret key and decrypt.

Thanks to grawity for replying. Your time is appreciated.

Noobux
  • 13