3
2
I have multiple subkeys for signing and encryption. Here is my public and private key list.
jeremy@localhost ~
$ gpg -k
/home/jeremy/.gnupg/pubring.gpg
-------------------------------
pub 4096R/35E40FA7 2015-04-14
uid keybase.io/jeremytwfortune <jeremytwfortune@keybase.io>
uid Jeremy Fortune <jeremytwfortune@gmail.com>
uid Jeremy Fortune <jeremy.fortune@uvmhealth.org>
sub 2048R/73671EAD 2015-04-14 [expires: 2023-04-12]
sub 2048R/0690427C 2015-04-14 [expires: 2023-04-12]
sub 4096R/AEE9FB5F 2015-12-06 [expires: 2025-12-03]
sub 4096R/757D1A1D 2015-12-06 [expires: 2025-12-03]
sub 2112R/9B5BAC36 2015-12-06 [expires: 2025-12-03]
sub 4096R/5A8F548A 2015-12-06 [expires: 2025-12-03]
jeremy@localhost ~
$ gpg -K
/home/jeremy/.gnupg/secring.gpg
-------------------------------
sec 4096R/35E40FA7 2015-04-14
uid keybase.io/jeremytwfortune <jeremytwfortune@keybase.io>
ssb 2048R/73671EAD 2015-04-14
ssb 2048R/0690427C 2015-04-14
When I encrypt a message to myself, the newest encryption key (9b5bac36) is used. This would seem fine since it's a subkey, but when decrypting, gpg is still only looking for exactly that private key. It doesn't even attempt to use 0690427c.
jeremy@localhost ~
$ echo -e "\nAn encrypted message." | gpg -vver 35e40fa7 | gpg -vvd
gpg: using subkey 9B5BAC36 instead of primary key 35E40FA7
gpg: using PGP trust model
gpg: key 35E40FA7: accepted as trusted key
gpg: checking the trustdb
gpg: 1 keys cached (11 signatures)
gpg: 1 keys processed (0 validity counts cleared)
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: This key belongs to us
gpg: reading from `[stdin]'
gpg: writing to stdout
gpg: RSA/AES256 encrypted for: "9B5BAC36 keybase.io/jeremytwfortune <jeremytwfortune@keybase.io>"
:pubkey enc packet: version 3, algo 1, keyid 743409AA9B5BAC36
data: [2111 bits]
gpg: public key is 9B5BAC36
:encrypted data packet:
length: 76
mdc_method: 2
gpg: using subkey 9B5BAC36 instead of primary key 35E40FA7
gpg: encrypted with 2112-bit RSA key, ID 9B5BAC36, created 2015-12-06
"keybase.io/jeremytwfortune <jeremytwfortune@keybase.io>"
gpg: decryption failed: secret key not available
When I revoke the newer encryption keys, everything works as expected.
jeremy@localhost ~
$ gpg -k
/home/jeremy/.gnupg/pubring.gpg
-------------------------------
pub 4096R/35E40FA7 2015-04-14
uid keybase.io/jeremytwfortune <jeremytwfortune@keybase.io>
uid Jeremy Fortune <jeremytwfortune@gmail.com>
uid Jeremy Fortune <jeremy.fortune@uvmhealth.org>
sub 2048R/73671EAD 2015-04-14 [expires: 2023-04-12]
sub 2048R/0690427C 2015-04-14 [expires: 2023-04-12]
sub 4096R/AEE9FB5F 2015-12-06 [expires: 2025-12-03]
sub 4096R/5A8F548A 2015-12-06 [expires: 2025-12-03]
jeremy@localhost ~
$ echo -e "\nAn encrypted message." | gpg -vver 35e40fa7 | gpg -vvd
gpg: using subkey 0690427C instead of primary key 35E40FA7
gpg: using PGP trust model
gpg: key 35E40FA7: accepted as trusted key
gpg: This key belongs to us
gpg: reading from `[stdin]'
gpg: writing to stdout
gpg: RSA/AES256 encrypted for: "0690427C keybase.io/jeremytwfortune <jeremytwfortune@keybase.io>"
:pubkey enc packet: version 3, algo 1, keyid 60A3F13E0690427C
data: [2045 bits]
gpg: public key is 0690427C
gpg: no secret subkey for public subkey AEE9FB5F - ignoring
gpg: no secret subkey for public subkey 5A8F548A - ignoring
gpg: using subkey 0690427C instead of primary key 35E40FA7
You need a passphrase to unlock the secret key for
user: "keybase.io/jeremytwfortune <jeremytwfortune@keybase.io>"
gpg: using subkey 0690427C instead of primary key 35E40FA7
2048-bit RSA key, ID 0690427C, created 2015-04-14 (main key ID 35E40FA7)
gpg: gpg-agent is not available in this session
gpg: public key encrypted data: good DEK
:encrypted data packet:
length: 76
mdc_method: 2
gpg: encrypted with 2048-bit RSA key, ID 0690427C, created 2015-04-14
"keybase.io/jeremytwfortune <jeremytwfortune@keybase.io>"
gpg: AES256 encrypted data
:compressed packet: algo=1
:literal data packet:
mode b (62), created 1458172973, name="",
raw data: 23 bytes
gpg: original file name=''
An encrypted message.
gpg: decryption okay
But, of course, this is because it's now encrypting with 0690427c. Can I really only have one encryption subkey? If not, do I have to keep all of the secret subkeys on every machine?
I hardly understand your question. You talk about expected and unexpected behavior, but never actually explain what the expected behavior is. Furthermore, I'm not sure whether the very verbose option is really required for the quoted commands, and it hides the relevant information. I think I guessed correctly what you're after for my answer, if your actual question is something else, consider editing it with a clarification. – Jens Erat – 2016-03-17T21:59:15.293
The very verbose option removes information? I take it you mean that it's harder to see, but there was no way to show which subkey was being used without the verbosity. Furthermore the intent of
echo "text" | gpg -er myself | gpg -d
is pretty obvious. It should display "text", but doesn't. The output I put above describes why it does not. – Jeremy Fortune – 2016-03-17T23:45:42.643It does not remove information, but might hide it in the massive amount of (possibly?) unrelated output. My point is that the question is missing a clear and distinct statement "I'm trying this and expect that, but it fails as another thing happens. Why is that?" Your question mostly consists of a confusing and confused (the subkey handling with and without
!
is confusing, don't worry) dump of command line output only describing what you tried, but not why; I guess some explanation of your intent would definitely made your question clearer. – Jens Erat – 2016-03-18T08:24:14.313