Multiple Subkey Pairs

[Daniel Kahn Gillmor]

On 03/13/2014 12:30 PM, Martin Behrendt wrote:
> Am 13.03.2014 16:42, schrieb vedaal at nym.hush.com:
>> ===== You can let all your correspondents know that they can
>> encrypt simultaneously to all 3 of your keys that have the same
>> e-mail address (assuming that you give them the fingerprints and
>> long key id' s for the 3 keys, and they aren't going to be fooled
>> by some attacker making a new key with your name and  e-mail
>> address).
> 
> 
> Thank you, that sounds like a solution worth going for. I'm just not
> sure, how to e.g. tell thunderbird/enigmail to use multiple keys for
> one email address when sending (or will it do that by default?). If
> you have a hint for that would be nice, otherwise I will try to find
> out myself.
> My closest thoughts to a solution like this were, go set my reply-to
> to two email addresses and maybe play around with the subkey
> identities to achieve the same. Or also two different key pairs. One
> big key with subkeys would be nicer tho, to hide the "complexity" a
> little.

what is the advantage of this approach?  what threat are you trying to
defend against?

I'll work from the assumption that you are worried that an attacker
might compromise one of your machines, copy that machine's decryption
key, and then use its key do decrypt messages that had been sent prior
to the compromise.

In this case, having your recipients encrypt every message to all three
keys is *exactly* as risky as having a single key shared across all
machines -- a compromise of any one of the machines results in a
decryption of all messages.

so what are the differences between the two approaches (separate
"per-machine" vs a single "shared" encryption keys)?

 0) per-machine keying is more work for your peers -- they have to
encrypt to K keys instead of 1.

 1) on compromise, per-machine keying means you need to revoke a single
key, and do no extra secret key distribution.  shared keying means
revoking a single key and doing a bit of extra secret key distribution.

even if it was easy to convince clients like enigmail or other
mechanisms to encrypt to multiple keys for a single user (i don't think
it is), i don't think the per-machine approach to encryption-capable
keys makes any sense.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140313/45bd453a/attachment.sig>