Thanks to Bill Stewart for some very helpful comments. There are too
many valid issues raised for me to try to address them in one message.
Maybe we should collect comments, sort them by section, and then work
through them to achieve a decision on each one.
I will only respond to a few areas that I can address right now:
On Wed, 03 Dec 1997, Bill Stewart, <stewarts(_at_)ix(_dot_)netcom(_dot_)com>,
writes:
3.3 Counted Strings -
"A counted string consists of a length and
then N octets of string data"
How long is the length field? What's its format?
I'm guessing it's one of the various variable-length-packed-number
formats used in PGP, but you need to specify which one.
No, the length is meant to be one byte. However counted strings are no
longer used in the document proper, and so they could probably go away.
3.4 Time Fields - Y2038 problem - Also 5.2.2.2, 5.5.2. 5.9
It is only a problem in 2038 if your software assumes dates are signed
or otherwise limits them to 31 bits. With 32 bits it is good until
2106. By then we'll either have destroyed our civilization or transcended
into immortal beings of pure energy, right?
3.5.1.3 / 3.5.3.3 Iterated-Salted
What a blazingly ugly design! Is it really necessary to use
a byte-count in a special one-octet-floating-point format,
rather than using an iteration count? Probably saves one
multiplication when preparing the argument for a hash,
at the cost of a couple masks and shifts and adds a hunk of code.
Especially with the "Conventionally Encrypted Session Key"
available, the extra complexity seems unnecessary.
The actual format of these stringtokey specifiers was established before
I got involved, so I don't know the history. But let me say a few words
in defense of this one, which several other people have objected to.
First, this option is by far the most important of the stringtokey
specifiers. In fact, it is the only one which should ever be used.
The "simple" works like old PGP, but that version never used stringtokey
specifiers so it is not even needed for backwards compatibility.
"Salted" is a subset of "iterated/salted".
Only "iterated/salted" provides the maximum security against dictionary
based passphrase attacks. The salt prevents precalculation, and the
iteration increases the cost to the attacker manyfold. Lutz suggested
that the iteration didn't help because it applies the same cost to
the legitimate user as to the attacker, but in most contexts the user
can tolerate a small delay while for the attacker it makes his attack
hugely harder. He can generate a hash very quickly to test a passphrase.
Making him iterate his hash function thousands or millions of times
means he can test only one passphrase in the time he could have tried
thousands or millions.
As for the one-byte hash length count, granted that may be a bit
over-optimized. But it only takes one line of code to turn it into a
length count, so it is hardly a major implementation cost. Sure, it
could have used a 24 or 32 bit field, but that is not really necessary
for the purpose. You want to set the passphrase testing cost in almost
order-of-magnitude terms. You don't need to differentiate between one
million bytes of hashing versus one million and one versus one million
and two. You just need to specify it roughly as say 1,000 bytes or
1,000,000. The format provides four bits of precision, which is more
than enough for this purpose.
If anybody's really using this option, it probably should be kept,
but as a MAY read, DEPRECATED generate. Otherwise reserve the
S2K-type indicator 0x03 and drop it.
We could make another one which used a 32 bit length but was otherwise
the same, and deprecate this one. I'm not sure it's worthwhile, though.
The thing which I object to about the stringtokey specifiers is that
they have no internal length field. If you don't recognize the type of
stringtokey object, you don't know where it ends. Apparently that is OK
as they are used now, because if you can't interpret them there is no
data following them which is of any use to you. But it will constrain
any future uses of them.
4.2 Packet Headers - Packet Length.
Meanwhile, it appears that the Partial Body Length can
support indefinite-length material, which is critical,
since it allows PGP to be used with streaming input such as
speech that goes on for a long time, (though the particular
encoding is inefficient if the data comes in natural chunk sizes
that aren't powers of 2 (or at least 3*2**n), or compresses
to irregular sizes.) It's worth noting this kind of application
in the draft, to encourage OpenPGP implementations to be designed
in ways that aren't limited by temp files with maximum lengths.
This is a good application for this packet. Many people seem to have
trouble understanding the significance of the one-pass model. It could
be that some motivation would help here.
5.1 Encrypted Session Key Packet - Traffic Analysis Risk -
The KeyID field, as defined, leads to a major traffic analysis risk,
but the format doesn't depend critically on the value in the field.
At a previous Bay Area Cypherpunks meeting, somebody from PGP
mentioned a request from some freedom fighter users that KeyIDs
be shorter, because the current tyrannical government was
using them to identify who to torture into decrypting messages -
having PGP was incriminating enough, but with short KeyIDs,
e.g. 0-3 or 0-16, it's possible to reduce decryption workload
without indentifying the user of the message.
I raised this possibility on the list a few weeks ago, but the only
response was negative (I think because it would break the way the
keyids were being used as indexes).
Some obvious alternative implementations are to keep the field
for compatibility, while specifying that the
- - the receiver of a message MAY attempt decryption regardless
of the value in the field, regardless of whether
it's intended for him or not.
- - the sender must output a value in the field that
- -- SHOULD be the KeyID, but
- -- MAY be all-0, for which the receiver SHOULD/MAY decrypt
- -- MAY be Z=1-63 bits of leading 0 followed by the low-order
64-Z bits of the intended recipient's KeyID, which the
receiver SHOULD/MAY decrypt if it matches his KeyID's low bits.
- -- MAY be some other prearranged value, e.g. a multicast code,
which the receiver MAY decide to attempt to decrypt.
Interesting possibilities. Jon Callas also suggested (internally) the
idea of putting all zeros into the keyid field to mean that the receiver
should try all his keys.
I would prefer to see a new version of the ESK packet (or PKESK if we
want to call it that). One problem we have is that messages encrypted to
DH subkeys have only the keyid of the subkey in them, not the keyid of the
DSS key. The current PGP client software tries to simplify things for
users by not exposing the complexity of the dual-key model, so users only
see the keyid of the top level DSS key. Then if they don't have the key
for a message recipient, displaying the keyid of the missing key won't
match the keyid they see.
One solution we've been discussing would be to add some subpacket
information to the ESK packet similar to what we have in the signatures.
There could be "hint" subpackets to help find the decryption key, like
one which tells the keyid of the DSS key. Maybe other hints could be
useful too, as we have proposed for the signatures (key server URLs,
etc.). This would be for V2.
Since this just requires permission in the spec, rather than
needing specific implementation, and since the main negative impact
on non-implementing users is attempting to decrypt
an occasional message that wasn't intended for them that they
happened to receive, I'd like to ask that it be included.
Definately worth considering, at least the all zeros one. The subset
one has the obvious problem that there is no specification of the matching
length. You may want to send the low order 4 bits of the keyid to use
for decryption, but if they happen to be all zeros then you can't do it.
5.2.2 Version 4 Signature Packet Format
The format does not contain a KeyID field, and does not
document how to find the KeyID from the various Public Key types --
there needs to be at least a reference to the section
currently numbered 8.2.
There is a keyID field, subpacket type 16, but it got left out of this
section by mistake. That should be corrected.
The subpacket stuff is confusing (no surprise, it's new.)
The descriptions of the Hashed and Unhashed subpacket data should be
- - one or more hashed subpackets
Actually zero or more
- - zero or more unhashed subpackets
or else these two lines and their preceding lines should be replaced by
- - hashed_subpacket block
- - unhashed_subpacket block
and the definitions of the subpacket blocks (here or in 5.2.2.1) should be
- - Two-octet octet count for following subpacket data.
- - zero or more (un)hashed subpackets
Maybe some rewording will help here. We just refer to "subpacket data"
where you mention a "subpacket block".
5.2.2.1 - Signature Subpacket Specification
I'm assuming the "Two-octet octet count" in this section is the
same field as in 5.2.2? (Should be anyway.) Only should appear once.
No, it's not. This is the count of the size of one subpacket, while the
5.2.2 count is the size of all the subpackets.
The description up front needs to say something like
- -------------
Some subpacket types are mandatory, others are optional.
Some subpacket types only apply to self-signatures.
Some subpacket types can appear multiple times, others just once.
Some subpacket types are always hashed, some are always unhashed.
(Are any of them optionally hashed?)
A hashed subpacket MUST be in the hashed_subpacket block, and
an unhashed subpacket MUST/MAY appear in the unhashed_subpacket block.
- -------------
I like the idea of showing this kind of information in tabular form.
One quibble is that I'm not sure the optional/mandatory makes sense.
I think there could be contexts in which all of them are optional.
A signature does not necessarily need a creation date. We don't force
them to have expiration dates so symmetry might suggest there are some
contexts where a creation date is not appropriate. Also, maybe there
is no time source handy for the signer. Signer KeyID could be optional
if there was some other subpacket created to help identify the signer
(say signer key fingerprint). Or maybe the signer identity is implicit.
It would be nice to reserve some of this space for
user-defined functions, though it's a tossup whether the best mechanism
is to define additional numbers (e.g. reserve 64-127 or 96-127)
or to use the notation data with user-specified values (better?).
This was the intention of the notation data subpacket.
I've run out of time and steam to do more now. There are many more very
good points raised by Bill which we should consider.
Hal Finney
hal(_at_)pgp(_dot_)com