Subject: Re: Problems with v4 key packet format

From: [email-masked] ("Hal Finney")
Date: Wed, 21 Sep 2005 09:52:33 -0700 (PDT)

Let me give my responses to Daniel's points about V4 key packets.

First I want to mention that Ian seemed to take a much larger view and
wanted to redesign the whole of the OpenPGP format.  V4 to V5 key packets
is only one small part of the spec.  No one is proposing to redo OpenPGP
from scratch here.

> 1. No cryptographic binding between the encrypted private key material and
> the public key material.
>
> This results in a serious security issue, by allowing an attacker to replace
> the public material thus compromising the private material with the first
> use in the signature. There are various stop-gap measures to deal with this
> attack, but the only sure protetction would be some MDC binding together the
> private and the public key material.

This is a very good point, and it is a little different from the previous
attacks.  If we had thought of it, we would have tried to fix it when
we added the checksum over the private key material.

The previous attack involved modifying some private key material and
causing the signature algorithm to fail.  In RSA keys, if you hack
just one of p or q and get it to do the signature using the Chinese
Remainder Theorem (CRT), the resulting value can leak the other of p or
q and therefore leak your private key.  To defend against this we added
a SHA-1 hash over the private material as a checksum.

Daniel proposes an extension to the attack where the private key
material is left alone and the public material (in the private key
packet) is modified.  I don't think this would do anything on RSA
keys, as the CRT based signature algorithm does not use the public
modulus or exponent.  However it would be effective against DSA keys.
The attacker could change p and q to be much smaller values, such that
discrete logs were feasible, then request a DSA signature using these
values, solve the discrete log and reveal x (the private value) mod q.
Do this a few times with different q's would reveal x.

Had we thought about this, we could easily have had the SHA-1 hash
cover the public as well as the private key material, but we didn't,
unfortunately.  Putting some size-based sanity checks in the DSA signature
code might be a good idea though.

I don't know if there are other variations on the attack that could also
be addressed for now with sanity checks.

> 2. No explicit count of MPIs constituting the key material (both public and
> private).
>
> This information can only be inferred from the algorithm specifier, meaning
> that any implementation that wants to perform key management must have some
> rudimentary knowledge about all public key algorithms. This, in turn,
> hampers forward-compatibility.

I am inclined to agree with David that there is not much point to being
able to parse a packet's details when we can't do anything useful with it.

> 3. Key fingerprint depends on data unrelated to the actual key (namely:
> creation date).
>
> This prevents solutions when signature keys are generated on the fly (e.g.
> directly from a passphrase), as the key creation (or, in this case, key
> registration) date is not available at the time of signing, thus making it
> impossible to put am unambiguous reference to the public key into the
> signature.

Yes, this has hurt our PGP implementation when dealing with foreign keys
such as X.509 certificates.  If we want to import a raw modulus+exponent
pair as a PGP key, and we want to know if we already have one on the
keyring, we can't easily compute a fingerprint and look for a match,
because creation date affects fingerprints.  I agree that fingerprints
should just be over the formatted key material.

> 4. More generally, creation time does not belong to the key packet.
>
> Because it is just an attribute of the key as any other, thus belonging to
> certificatiton signature sub-packets, rather than the key packet.

I like David's idea better to have some sub-packets in the V5 key.
I would like to see immutable material put there.  One thing that bothers
me in the current V4 is that the key's expiration date can be changed by
updating the self-signature.  Suppose your key has expired and you don't
use it any more.  As a result perhaps you don't protect it that well.
If someone gets hold of the private part, they can issue a new self-sig
with a new expiration date and bring this dead key back to life.  It would
be better if a dead key would stay dead.  Expiration date and creation
date would be better placed in the key packet, IMO (as they were with
V3 keys).

Hal Finney

---

From: Werner Koch <[email-masked]>
Date: Wed, 21 Sep 2005 19:18:58 +0200

> date would be better placed in the key packet, IMO (as they were with

We discussed this issue a long time ago and came to the conclusion
that both kinds of exiration dates make a lot of sense.  Prolonging
the expiration time is something what quite some users are doing now
on a regular basis.  If nothing else it helps against a lost
passphrase.

The suggestion was that we put a hard-expiration into a v5 key packet
but keep the existing soft-expiration in the self-signature.

Salam-Shalom,

   Werner

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 21 Sep 2005 21:49:13 +0200

> but keep the existing soft-expiration in the self-signature.

I think, David's subpacket solution accomodates for this without being
overly restrictive. If you want to make sure your key stays dead after
expiration, you put a hashed expiration date subpacket into your key.

-- 
Daniel

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 21 Sep 2005 21:56:38 +0200

> I like David's idea better to have some sub-packets in the V5 key.

Me too.

> date would be better placed in the key packet, IMO (as they were with

Careful! If this information is not part of the fingerprint/keyID it can
still be changed by updating the self-signature, no matter whether it's in
thte signature packet or in the key packet.

David's idea with sub-packets should be implemented in such a way that
hashed sub-packets are part of the fingerprint. Maybe, we don't even need
unhashed sub-packets.

If you're importing a foreign key or generating one on the fly, you don't
put subpackets into the key that cannot be determined next time you use the
same source to get the key. A flag in a subpacket indicating where the key
comes from might be useful, though.

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Wed, 21 Sep 2005 16:19:21 -0400

> hashed sub-packets are part of the fingerprint. Maybe, we don't even need

There have been a number of mentions of the key-with-subpackets idea
recently, so I'll repost the mail where I first proposed the idea.  It
has many more details than I mentioned in this thread.

In short though, the subpackets are hashed into the fingerprint and
any certification signatures (including self signatures).  In my
proposal there are no unhashed subpackets.  In the case of expiration,
we would have two different ways to specify expiration.  The
expiration time hashed into the key is a hard expiration time that
cannot be extended.  The expiration time in the self-signature is a
soft expiration time that can be extended or changed whenever desired
- but only up to the hard limit given in the key itself.

David