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

[Michael Hannemann]

On Jun 19, 2012, at 1:50 AM, Hauke Laging wrote:

> Am Di 19.06.2012, 01:03:26 schrieb Michael Hannemann:
> 
>> pub:f:1024:17:xxxxxx--TpTpTpTp:1999-04-08:::-:[my collaborator]::scaESCA:
>> sub:f:2048:16:xxxxxx--TsTsTsTs:1999-04-08::::::e:
> 
> This seems not to leave any room for ambiguity: One key only which can be 
> encrypted to. Does the long ID (field 5) match the value you get on your 
> system?

I will check that when I get the response back from them.  I've been cautious,
since I'm getting back into GPG use after 10 years away, while they say this is
a system they've been using with other people.  But the closer I've looked, the
more it's seemed like this can't be any other way.  If, as you suggested, the
key I have matches the key they're using.

>> I just want to make
>> sure to them that I'm not asking for someone else's private data.
> 
> Even if so. Isn't the sense of all this that you can give the encrypted data 
> to just anyone without havong to be worried? 8-)
> 
> But they may, of course, encrypt some dummy data to themselves for giving to 
> you. They shall just check that they can decrypt it.
> 
> 
>> 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.
> 
> That has nothing to do with the passphrase. "#" indicates a stub (key has been 
> there but kind of removed; --export-secret-subkeys), ">" indicates that the 
> key is on a smartcard.

Sorry, thanks for the correction.  I knew there was a way that the secret key could
be removed, and I wondered if somehow this has been done to their system, perhaps 
without the knowledge of the particular person I'm working with.  I just wanted to 
rule that out as a possibility.


thanks,

Michael