3

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 Mar 17 '16 at 21:59
  • 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 Mar 17 '16 at 23:45
  • It 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 Mar 18 '16 at 8:24
3

Implementations of OpenPGP (including GnuPG) will by default choose the newest valid encryption (sub)key and encrypt using this. There is no way to define that a given subkey is somehow bound to a given computer or user ID in OpenPGP, nor can you enforce encryption is performed for all valid encryption keys.

One can very well manually choose the key to be used for encryption with GnuPG by using the key ID of choice as recipient, but followed by !. For example, given there is an older encryption subkey DEADBEEF, and you want to override the default of using another, newer encryption subkey:

gpg --recipient DEADBEEF! --encrypt

If the ! is omitted, GnuPG resolves the key ID to the primary key instead, and chooses the newest matching subkey again. Using the same method, you can enforce use of the primary key (if it has the encryption capability set).

If you want to use encryption different keys on different computers, you will have to use different primary keys. This is one of the major shortcomings of OpenPGP.

  • This is the answer, despite your fairly non-contributive comment on the question. – Jeremy Fortune Mar 17 '16 at 23:47
  • 1
    "There is no way to define that a given subkey is somehow bound to a given computer or user ID" – well, there is, but it makes things a little more complex. See e.g. here: You could chose to create specific key rings for each machine, only holding the subkeys you want to dedicate to them, omitting the "master key" altogether (which then e.g. could be kept secure on an "offline medium" like an USB stick you've placed into a tresor). Haven't played with that yet, though, so I cannot tell how practicable it is for the "casual user" ;) – Izzy Jun 1 '17 at 9:20
  • This is something you can do on your own machines, but not on the one's of your peers (and therefor a very reasonable scenario for signing subkeys, but nothing useful for encryption where the other party selects which of your subkeys to use). – Jens Erat Jun 2 '17 at 19:13
  • @Izzy Is it feasible to have a different encryption subkey for each computing device you have? Does this make it more difficult to decrypt it later? – CMCDragonkai May 3 '18 at 2:31
  • @CMCDragonkai I don't think that's feasible. The idea behind using subkeys (without the master) is rather one can abandon them if they seem compromised and generate new ones – without losing the trust collected (as that sticks to the master). – Izzy May 3 '18 at 6:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.