Trying to understand the bond between master and subordinal key pairs

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed Feb 12 20:27:47 CET 2014


On 02/12/2014 06:40 AM, Michael Anders wrote:

> I am still puzzled, however. Can anyone explain the logical reason as to
> why we need this jungle in OpenPGP, which thankworthily is usually more
> or less hidden from the user anyways? 
> A good reason would help the complicated workings to stick with my
> memory :-) 
> Why would we need more than one key and this hierarchy on top of it?
> (Proper padding according to the standard to my knowledge removes even
> the dangers of using the same RSA key for signatures as well as for
> ciphers.)

it's a bad idea to use the same key for multiple mechanisms.  keeping
the uses distinct is the most reliable way to avoid cross-protocol
attacks.  For a given key, it's very difficult to effectively mandate
that everything uses "proper padding" or that different uses will use
distinct padding from every other use.  Being able to associate keys
with your primary identity that might be used in other contexts (c.f.
recent discussions about bitcoin and otr) is a useful feature.

> Is the necessity (given that it is there) for the subkey hierarchy
> endemic to RSA or would such a structure also be needed for ECC or other
> cryptosystems?

here are four reasons at least that are not specific to any particular
public key cryptosystem.  there are probably more:

 * offline primary keys

 * subkeys that are incapable of being abused to make fraudulent OpenPGP
identity certifications

 * subkey-specific export: you can make a key, let an agent use it on
your behalf in one context without allowing that agent access to any of
your other keys.

 * frequent expiry/rollover of encryption or signing subkeys while the
primary key (and thus the user's identity) stays constant.  this can
deal with a heavily-used signing public key, for example, to mitigate
attacks that scale with volume of visible signatures.  for encryption
keys, this can also potentially be used as a (weak) form of forward
secrecy, assuming the user actually destroys the secret key when it expires.

Regards,

	--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/20140212/77d19b14/attachment.sig>


More information about the Gnupg-users mailing list