decryption trouble - primary/subkey confusion, maybe version issues?
mhannemann at meperia.com
Tue Jun 19 17:37:25 CEST 2012
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:
> 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
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.
More information about the Gnupg-users