From: Raph Levien <raph@cs.berkeley.edu>
Date: Wed, 13 Nov 1996 09:58:20 -0800 (PST)
To: Gary Howland <gary@systemics.com>
Subject: Re: pgp3
In-Reply-To: <199611131217.NAA19213@internal-mail.systemics.com>
Message-ID: <328A0B7F.68B00890@cs.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Gary Howland wrote:
> Raph Levien wrote:
> > Nope. This RFC is merely a rehash of the pgformat.doc file in the PGP
> > 2.6.? distribution. I'm doing an independent implementation of the PGP
> > 2.6 message formats, and found this document unclear in a few spots. For
> > example, can anyone else figure out the weird CFB variant mode from this
> > document? I used a debugger on the PGP code to help me figure it out.
> 
> Exactly - I spent ages on the same thing.  Then there's the problem that
> packet length headers must be specific lengths for various types (eg.
> key certificates must have a 2 byte length, even if only one is required).
> It is also not clear what the exported key certificates should contain,
> the spec simply mentioning that there should be no trust packets etc. etc.

Right.

> > The PGP 3.0 "spec" that you're referring to is actually a draft for a
> > PGP library API. A couple of those got circulated on some PGP mailing
> > lists, but none have been publicly released, another example of the
> > secrecy surrounding the whole PGP effort.
> >
> > Now that PGP Inc. is happening, it's not exactly clear whether the PGP
> > 3.0 release is going to include an API closely resembling these drafts.
> 
> I agree with your comments.  For example, we are developing PGP compatible
> libraries in both Perl and Java, and are going to add SHA, Blowfish, T-DES,
> etc., along with a better key ring format, encrypted key rings, and features
> such as key generation from a passphrase, and we would very much like to
> remain compatible with the new PGP, but how can we when there is so little
> information available?  I think we need a forum to discuss PGP development
> issues - I would be happy to set one up if there was interest.

I'd be interested.

There's a few extensions I'm interested in, as well. One of the things
I'd _really_ like to see is a standardized, cryptographically strong
naming system for PGP keys. Derek Atkins and I threw around a proposal
(the SHA-1 hash, in hex, of the public key packet, including the packet
headers, with the length field in the packet header constrained to 2
bytes), but I'm not sure where that's headed.

The 8-byte key id is perhaps the biggest mistake in the PGP message
formats. I'm finding that it adds considerable complexity into the
message format code. For example, to check a signature, it's necessary
to iterate RSA exponentiation over all keys that match the key id. In
almost all cases, there will be only one such key, but to protect
against dead beef attacks, you have to do it.

In PGP 2.6.?, it's possible to exploit dead beef as a denial of service
attack. As soon as you add one public key with a given key id, it
prevents other keys with the same key id from being added. Thus, if I
were to create a key with key id 657984b8c7a966dd, and convinced other
people to add it to their keyrings, they wouldn't be able to add Phil
Zimmermann's key.

Knowledgeable users can get around this (for example, by deleting the
bogus key), but most people, especially those using automated tools,
would have trouble.

Of course, the main "extension" to PGP I'm interested in is a new trust
model and distributed database for certifying keys. However, at least
for the prototype, this can be implemented entirely on top of PGP (or
S/MIME, I think), so we don't need to talk about modifying the PGP
engine for this.

Raph