decryption trouble - primary/subkey confusion, maybe version issues?

[Hauke Laging]

Am Mo 18.06.2012, 15:37:27 schrieb Michael Hannemann:

> I'm having trouble sending an encrypted file to a collaborator -- even
> though they've sent me files that I've been able to decrypt.

That means nothing. I can send you an encrypted file without even having a key 
myself.

Have they signed the encrypted files they have sent to you?


> Here's what they see, with their keys replaced -- TsTs = their subkey, TpTp
> = their primary key.
> 
> My keys:
> 
> pub   2048R/F7A48B98 2012-05-22       usage: SC
> sub   2048R/BE7A105E 2012-05-22       usage: E
> 
> And my collaborator:
> 
> pub   1024D/TpTpTpTp 1999-04-08        usage: SCA
> sub   2048g/TsTstsTs 1999-04-08        usage: E
> 
> ===========================================
> gpg: public key is TsTsTsTs
> [GNUPG:] ENC_TO xxxxxx--TsTsTsTs 16 0
> gpg: using subkey TsTsTsTs instead of primary key TpTpTpTp
> gpg: encrypted with 2048-bit ELG-E key, ID TsTsTsTs, created 1999-04-08
>     [my collaborator]
> [GNUPG:] NO_SECKEY xxxxxx--TsTsTsTs
> [GNUPG:] BEGIN_DECRYPTION
> [GNUPG:] DECRYPTION_FAILED
> gpg: decryption failed: secret key not available [GNUPG:] END_DECRYPTION
> ===========================================

This is the error message they sent to you?


> My question is ... what is going on here?  Why can't they decrypt this file,
> when they were able to send me a file that I could decrypt?

That's not the question. The question is whether you encrypt to the correct 
key (and how you KNOW it's the correct one).


> Their technical guy wrote me to say that when sending files, I should be
> using primary key ID TpTpTpTp.   But, so far as I can tell, everything here
> is working as designed, and there's no way I *can* specifically say "use
> TpTpTpTp".

What is the output of
gpg --with-colons --list-keys 0xTpTpTpTp
? This is about the second but last field for pub and sub only. Output for my 
key for example:

pub:...:scaESCA:
sub:...:e:
sub:...:e:
sub:...:s:
sub:...:a:

These are the keys' capabilities. The main key can certify (always), sign and 
authenticate. The subkeys can be used for encryption, signing and 
authentication, each one only. If you encrypt to the ID of the main key then 
gpg recognizes the encryption subkey and uses it instead.

If your (main) key is really correct then I guess there is a problem with the 
subkeys. Maybe you have an old version of the key containing a subkey they 
don't (and can't) use any more. So you should check that you have the newest 
version of the key.

You can enforce the usage of the main key though:
gpg --encrypt --recipient 0xeccb5814\!
(the \ is due to history expansion in the shell; I am not familiar with that, 
maybe the quoting is not necessary)

This works only if the main key has the encryption capability.

When reading my mail just before sending I noticed that your above output 
reveals that the main key has no encryption capability (as usual).


> 1. Using --edit-key, I did compare fingerprints and have validated the
> fingerprint they sent me.

This can be easier done by
gpg --fingerprint 0xeccb5814

gpg --fingerprint --fingerprint 0xeccb5814
shows the subkeys' fingerptints, too.


> 5. I accepted the default (RSA + RSA) version for key generation. 

Your key has most probably nothing to do with this problem.


> What questions can I ask them which will help shed light on this situation?

Ask them for the output of
gpg --with-colons --fingerprint --fingerprint --list-keys 0xTpTpTpTp
on the system which does (tries) the encryption. And ask them to export the 
public key on that system and send that new version of the key to you:

gpg --armor --export 0xTpTpTpTp > 0xTpTpTpTp.asc

And you may ask for an encrypted file which they can decrypt.


Hauke
-- 
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20120619/e476895f/attachment-0001.pgp>