3

I have a recipient with four hardware keys (HKs) that they use interchangeably. These HKs contain different GPG keys that have all been generated inside and have never left the HKs, thus resulting in four different public keys belonging to the same person.

The keys are tagged so that the name, email and identifier strings are an exact match. Something akin to:

      97E85C8F5ABDC912F2FF8D25EB4D503782686E20
uid           [  full  ] Reci Pient (Comment) <reci.pient@domain.tld>
...
      57CFDEB0ABB5809023F7A37FDF5EB221E3D9D8E5
uid           [  full  ] Reci Pient (Comment) <reci.pient@domain.tld>
...
      B107855A39FA59C7D8FF37617A8F30918D67D1BE
uid           [  full  ] Reci Pient (Comment) <reci.pient@domain.tld>
...
      E97A982270E2090E25393D82DED36993F1DD52A3
uid           [  full  ] Reci Pient (Comment) <reci.pient@domain.tld>

Now comes the time when I need to securely communicate with Reci Pient, perhaps to tell them that food is ready and they should come downstairs.

In order to encrypt the message to Reci, one would write something like:

echo Food! | gpg --encrypt --armor --recipient "reci.pient@domain.tld" > secret.gpg

or even

echo Food! | gpg --encrypt --armor --recipient "Reci Pient" > secret.gpg

Now one would think that this encrypts the message to ALL of Reci's keys, meaning Reci can use ANY of those keys to decrypt the message.

This is not the case. GPG seems to pick an arbitrary key and use that to encrypt the message. We can see this by doing:

%~ cat secret.gpg | gpg -v  
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: encrypted with 2048-bit RSA key, ID 89FEABD93D8E9286, created 2019-12-12
      "Reci Pient (Comment) <reci.pient@domain.tld>"

Imagine the scenario where Reci has just stepped on one of their HKs and it snapped in half. They should be able to use their other HKs to decrypt those messages that were meant for Reci Pient or reci.pient@domain.tld. Now, it is fully possible for Reci to destroy one of their HKs and lose access to "some" of their encrypted messages, whichever happened to be chosen by the senders arbitrarily by this command.

The "correct" way to do this in GPG would seem to explicitly set Reci's keys as the recipient keys:

echo Food! | gpg --encrypt --armor \
                 --recipient "97E85C8F5ABDC912F2FF8D25EB4D503782686E20" \
                 --recipient "57CFDEB0ABB5809023F7A37FDF5EB221E3D9D8E5" \
                 --recipient "B107855A39FA59C7D8FF37617A8F30918D67D1BE" \
                 --recipient "E97A982270E2090E25393D82DED36993F1DD52A3" \
             > secret.gpg

Looking at the cipher, we see all the keys we would expect.

%~ cat secret.gpg | gpg -v
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: encrypted with 2048-bit RSA key, ID 89FEABD93D8E9286, created 2019-12-12
      "Reci Pient (Comment) <reci.pient@domain.tld>"
gpg: encrypted with 2048-bit RSA key, ID B420F45883152A53, created 2019-12-12
      "Reci Pient (Comment) <reci.pient@domain.tld>"
gpg: encrypted with 2048-bit RSA key, ID 251885E708C55D81, created 2019-12-12
      "Reci Pient (Comment) <reci.pient@domain.tld>"
gpg: encrypted with 2048-bit RSA key, ID 6138956F73CF0ACB, created 2019-12-12
      "Reci Pient (Comment) <reci.pient@domain.tld>"

But this seems horribly inconvenient for anyone who wants to send a message to Reci; after all, why would they care about the possibility of Reci stepping on their HK, they just want to send a message.

Even ignoring the inconvenience, when encrypting for reci.pient@domain.tld, why does GPG not complain about multiple keys, but instead pick a seemingly arbitrary key (which isn't always the first one)? This seems confusing and most often not what people would want to do. Why wouldn't GPG just encrypt for ALL the public keys matching reci.pient@domain.tld? Is it a security concern for somehow encrypting the message for the wrong reci.pient@domain.tld?

Maybe I am misunderstanding the way GPG wants to work here (wouldn't be the first time), or maybe Reci Pient is doing something wrong with their multiple public keys of their hardware keys (they spent a small fortune on those). I would greatly appreciate if some light could be shed onto what is being done wrong and how this is supposed to be done.

ilmikko
  • 39
  • 2
  • 1
    After consulting with various people in the university, it seems like Reci Pient is doing something uncommon in using multiple different encryption keys. That is, Reci should only have one (public) encryption key to give others to encrypt with. Reci could add that as a subkey on their hardware key via `gpg --edit-key` and `keytocard`. Because of the different capabilities (Sign, Encrypt, Authenticate), Reci can still use other keys as generated on the card. However, this does not answer the arbitrarity of GPG whilst selecting keys to encrypt with, so I will leave the answer open. – ilmikko Feb 04 '20 at 16:00

1 Answers1

1

why does GPG not complain about multiple keys, but instead pick a seemingly arbitrary key

But it isn't arbitrary - GnuPG encrypts to the most recently created key for that user ID. I imagine any other encryption program would handle this the same way.

This is sensible because the typical case where a user ID would have a newer encryption key is if the previous encryption key were not to be used anymore for some reason. Maybe the previous key had become compromised, or better algorithm was chosen for the newer key.

Why wouldn't GPG just encrypt for ALL the public keys matching reci.pient@domain.tld?

See above. Automatically encrypting to all encryption keys for a user ID is much more likely to be a security weakness than encrypting only to the most recent key.

"reci.pient@domain.tld" is doing something very unusual (and not particularly sensible) by creating multiple encryption keys to use for the same identity. And yes, the only way to encrypt to all of them is specifying each key ID: gpg -r KEY1 -r KEY2 -r KEY3 -r KEY4 -e FILE

fuzzydrawrings
  • 471
  • 2
  • 9