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

Hauke Laging mailinglisten at
Tue Jun 19 07:50:09 CEST 2012

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 

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

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/3fbd14da/attachment-0001.pgp>

More information about the Gnupg-users mailing list