Multiple encryption subkeys

[David Shaw]

--m51xatjYGsM+13rf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 29, 2003 at 01:15:10PM -0400, Dennis Lambe Jr. wrote:
> I've read through the archives, but I still have a question or two about
> subkeys.  Most of the discussion has been about signing subkeys, or
> encrypting subkeys that are used in succession, with one only coming=20
> into use after another expires.  I haven't read anything about having=20
> multiple active encrypting subkeys and the issues they present.
>=20
> What I'd like to do is have a public key with multiple ElGamel and RSA
> subkeys of different key lengths, 1024, 2048, and 4096, for example.  My
> goal is to allow the sender more control over the encryption vs. speed
> tradeoff and the encryption algorithm, instead of requiring that she use
> the level of security that I deemed appropriate.  My reasoning is that
> how secure a message needs to be may be more appropriately determined by
> the contents of the message, rather than the identity of the recipient.
>=20
> 1) Is this a worthwhile endeavor, cryptographically speaking?  That is
> to say, am I justified in wanting to do this, or is there something I've
> overlooked that makes this a bad or useless application of subkeys?

It is not a *bad* application of subkeys, but perhaps not as useful as
you'd like.  Given the speed of (most) machines these days, and the
common use of GnuPG for email and file encryption, there is little
difference in the user visible speed differences between 1024, 2048,
and 4096 bit encryption keys.  I'm assuming that a few seconds here or
there don't matter to you.  If someone was encrypting many files to
you every minute, or had a slow machine (like a PDA) then this would
be more useful.

Note, by the way, that this:

    My reasoning is that how secure a message needs to be may be more
    appropriately determined by the contents of the message, rather
    than the identity of the recipient.

leaks some information to traffic analysis.  The snoop may not be able
to read a given message, but she does know that the message was
"important" because it used the 4096-bit subkey.

> 2) Is there a way to specify a default encrypting subkey?  I have read
> that GnuPG will encrypt to the most recently self-signed subkey unless
> the exclamation-point syntax is used.  Can that be overridden by a flag
> in the key?  I haven't read anything to suggest that it could, so this
> is just wishful thinking.

There was discussion at one point about a "primary subkey" flag which
would suggest to a sender which subkey to use, but it didn't progress
much beyond that.  Currently it is completely up to the sender which
subkey to use.  As you noted, GnuPG uses the timestamps to choose.

There is an argument that programs should use the subkey with the
closest expiration date, in order to make perfect forward security
easier.  See
http://www.cs.ucl.ac.uk/staff/I.Brown/draft-brown-pgp-pfs-03.txt

> 3) Apart from the awkward method of deciding a "default" encrypting
> subkey, I think I've figured out everything I need to know to use
> GnuPG with multiple encrypting subkeys.  How is support in other
> OpenPGP programs, though?  Will the commercial PGP be able to work
> with my key?  Does it have an equivilent to the exclamation-point
> syntax, or will it always use the default subkey?

It will work properly, but I don't know offhand what PGP uses to pick
a subkey.

> 4) A lot of messages I read from 2002 and earlier this year suggest that
> many keyservers are still having difficulty with multiple subkeys.  Is
> this still the case, or have there been recent positive developments in
> that area?  What's the official gnupg-users party line on the use of
> keyservers with multiple subkeys?  Is it still "use kjsl.com and pray"?

I submitted a fix for the worst of the key corruption bugs in pks, so
as pks-based servers upgrade, they'll stop eating keys.  This doesn't
mean they handle multiple subkeys properly though, just that they
don't mangle them.

Servers that work properly include:

  ldap://keyserver.pgp.com   (not pks-based)
  hkp://sks.dnsalias.net     (not pks-based)
  hkp://keyserver.bu.edu     (not pks-based)
  hkp://keyserver.kjsl.com   (pks-based, but heavily patched)

Synchronization between the pgp.com LDAP server and the rest of the
world tends to be poor.

David

--m51xatjYGsM+13rf
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2rc2 (GNU/Linux)
Comment: http://www.jabberwocky.com/david/keys.asc

iD8DBQE+rsI14mZch0nhy8kRAnP2AJ9mta+hhjkG1S7sXrn33YKjry08YgCgjSHq
mQG1KNqLB8U0WezvRB/aFiQ=
=VbEF
-----END PGP SIGNATURE-----

--m51xatjYGsM+13rf--