Subject: Problems with v4 key packet format

From: [email-masked] (Daniel A. Nagy)
Date: Tue, 20 Sep 2005 07:32:31 +0200

In order to design a successor to v4 key packet format, it is important to
first identify its shortcomings. Here's a list of my problems with it:

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.

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.

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.

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.

-- 
Daniel

---

From: Ian G <[email-masked]>
Date: Wed, 21 Sep 2005 11:58:32 +0100

> first identify its shortcomings. Here's a list of my problems with it:

Perhaps a pass at listing the problems in v4 ** would
be a fair first phase.  Here's a couple of issues
(although I admit to not bit-peeping as much as I
should, most of these are user/mgr level grumbles):

5.  Too many integers and formats and what have you.
There should be a base level of formats which should
cover all requirements, and these should be flexible
enough to do that job, while simple and short enough
to be easily implementable and understandable.

6.  PGP's feedback mode.  There's no point to this.
It's a thing that PRZ added in because he thought it
was cool;  he was wrong on that point && and it would
make matters easier if the standard CBC modes that
are described in all the textbooks were used.

7.  Cipher suites, not algorithms.  Although I like
OpenPGP's tradition of opening up to experiments in
algorithms and so forth, I think it is a pain for
interoperability and implementation.  It might be
fine to demand the "right" to implement odd-length RSA
with Ripem-666 hashes and the latest chinese cipher
feedback modes over GOST encryption, but this is
just plain stupidity at the software engineering
level.

As much as possible, I'd suggest that a cipher suites
approach be used:  Cipher suite #1 should fix the
PK, the encryption algorithm, the hash, the feedback
modes, and all that.  When something breaks, deprecate
the whole sodding lot, and move on to #2.

Life was really good in the days up to pgp2.6.  Then
it all went to pot.  We may never go back to those
simple times, but we can attempt to simulate it by
using cipher suites $$.

(some of these points are contradictory at some
level :-)

iang

PS **: if we are going to start discussing futures like
v5, it might be easier to stick something in the subject
so people know quickly that it does not effect the
current doc.

PS &&: This is not a criticism of him;  nobody ever
builds a perfect cryptosystem, and it falls to later
disciples to carefully clean out the mistakes.

PS $$: Allowing experimental cipher suites would be
fine.  Another trap to avoid is the SSL cipher suite
rabbit explosion ... but that should be easy to do
if we allow people to experiment with their own and
only promote the really useful, strong ones.  I.e.,
rejection of marginal improvements as a routine.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 21 Sep 2005 13:28:27 +0100

> private and the public key material.

I don't understand this attack.

> hampers forward-compatibility.

This appears to me to be incorrect - an implementation that didn't know 
the algorithm could still deduce the number of MPIs by parsing the 
packet until it is exhausted. This would mean introducing a requirement 
that all public key parameters were MPIs, of course.

> impossible to put am unambiguous reference to the public key into the

Not impossible, but I'll agree, crufty. One could use a fixed creation date.

> certificatiton signature sub-packets, rather than the key packet.

So?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

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

> that all public key parameters were MPIs, of course.

You could also do what GnuPG does - if it doesn't know the algorithm
it just reads the entire list of MPIs (or anything else in the packet)
into an opaque buffer.  I suppose it could figure out the MPIs, but
there seems to be little point since either way, the key is not usable
without support for the algorithm.  I suppose if the implementation
stored keys in a backend that needed to know the individual key
parameters that would be different.

> Not impossible, but I'll agree, crufty. One could use a fixed creation date.

Some people want to include things in the key fingerprint and some
don't.  There are good reasons for both, so I favor v5 keys with
optional subpackets like v4 signatures.  Within reason, it's a "make
everyone happy" solution.

David

---

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

> I don't understand this attack.

It's the well-known Klima-Rosa attack. It has been discussed earlier on
this list.

> packet until it is exhausted.

Except for private key packets.

> This would mean introducing a requirement 

That, too.

> Not impossible, but I'll agree, crufty. One could use a fixed creation date.

That's a horrible cruft breaking all sorts of things (validity period, etc.).

I like Dave's suggestion about adding optional subpackets, similar to those
in signatures.

-- 
Daniel

---

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

Oh, one item that I forgot to include in my list:

Encrypted private key packets are superfluous, IMO. Internally, it can be up
to the implementation how it secures private keys (as it varies from
situation to situation what the requirements and environmental assumptions
are), while for interoperability, it's perfectly secure to export
unencrypted private key packets (and the auxiliary stuff) within an
MDC-protected encrypted data packet, with some ESK in front of it.

This way, designers and implementers would only need to worry only about the
security of one MDC-protected encrypted data packet format, instead of two,
slightly different ones.

The only capability that would be lost is exporting and importing private
keys without knowing the corresponding passphrases, but I can't imagine
legitimate uses for that anyway, while such an action may well be part of
some more sophisticated active attack.

-- 
Daniel

---

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

> parameters that would be different.

That's what I actually do. But I don't like it. From an OO perspective, it
makes certain abstractions less efficient.
 
> everyone happy" solution.

Excellent idea! Maybe, we can use a common set of subpackets, where some
make sense only in signatures while others only in keys. There are too many
overlaps for warranting a separate design.

-- 
Daniels