-----BEGIN PGP SIGNED MESSAGE-----
Ingo Luetkebohle replied:
Well, associating all sorts of special meanings to the pre-S2K byte is
somewhat of a mess, too, isn't it?
IMHO, it would have been a lot cleaner to *always* use an S2K
specifier and then have a 0 symmetric algorithm value for "no
Of course. But we already have a pre-S2K byte, for compatibility
with PGP2, which won't go away.
encryption". Then, I would have liked a length byte to precede the
public key data so that you can just skip it entirely without having
If you plan to do any consistency checking on the parameters,
you'll need parse it anyway. If you include them in the hash,
then you might be willing to skip the checks sometimes, but
then you'd at least need to digest the material (but admittedly
not interpret it).
Rather than put in a length, I'd just put in the whole public
key packet. That would also allow the secret key packet to have
its own (independent) version number.
to parse all of the MPI's. Additionally, the differences between the
different session key packets could have been reduced and aligned to
be similiar to the encrypted data packet so that the same header
fields are aligned at the same offsets for all packet types and only
thes differing fields are at different offsets.
Sure, a clean-slate design might do all of these things. But our
slate is well-used. On the whole, that's a good thing ;-).
Most implementations will want to support older formats anyway.
Adding a substantially new format, even if it alone is easier to
parse, means more code than an isolated tweak on the old one.
I wouldn't open the door to any old hack, but this one feels good.
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
-----END PGP SIGNATURE-----