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

[Michael Hannemann]

On Jun 18, 2012, at 6:38 PM, Hauke Laging wrote:

> 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.

I'd begun to suspect that, after digging through files I'd encrypted for any hint of my key.  Thanks for the confirmation.


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

No, they have not.  I can ask them to do so.



> 
>> 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?

Almost -- I substituted the "xxxx-TsTsTs" gibberish in place of the real keys to protect the innocent here, just making sure I did it carefully & consistently, and re-verifying the fingerprint vs what they sent me again.

>> 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).

Right, that's what I keep seeing and trying to reconcile with their statement that this has been working without issue for other users and I'm the only one who has problems.

Here's the output of your requested command above:

pub:f:1024:17:xxxxxx--TpTpTpTp:1999-04-08:::-:[my collaborator]::scaESCA:
sub:f:2048:16:xxxxxx--TsTsTsTs:1999-04-08::::::e:


>> 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.

Useful, thanks!  I would've never thought to specify --fingerprint twice.


>> 5. I accepted the default (RSA + RSA) version for key generation. 
> 
> Your key has most probably nothing to do with this problem.

Understood.

>> 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.

Good suggestions, thank you.  I can ask them to encrypt a file for themselves and send that to me, and then look to see what keys they're using there.  The others are good suggestions as well; I just want to make sure to them that I'm not asking for someone else's private data.

This seems better than my request that they send me the results of "gpg --vv --list-secret-keys ...", which I suggested because I read somewhere that if the passphrase is somehow disconnected, the "sec" header on that will show up with a # or some other indicator indicating a broken key.


thanks,

Michael