Michael Young, <mwy-opgp97(_at_)the-youngs(_dot_)org>, writes:
Why is a new S2K mode preferable to a new key version?
I see two reasons:
First, the secret key packet as such doesn't have a version number.
The version number is borrowed from the public key packet that begins
the secret key packet. In other words, the secret key packet is a public
key packet with extra data stored at the end.
So in order to change the secret key packet version, we need to bump the
public key packet version. If we create a "V5" secret key then we need
to create a corresponding "V5" public key. But since we aren't changing
the public key packet format, this is somewhat redundant, since V4 and
V5 public keys would be entirely identical.
Second, the purpose of the S2K specifier and associated information
(algorithm ID etc) is to describe how the secret data is protected.
Since we are making a change with regard to this protection, this is a
reasonable place to represent that change.
The S2K is used in more than just the secret key packet.
Adding another context-specific flag to the S2K seems
wrong (unless you meant for this checksumming behavior
to apply to other uses, which also seems wrong).
This is true, the S2K is also used for passphrase encrypted messages.
Another place we could represent the alternative format is the byte which
comes shortly before the S2K in the secret key packet. This byte is
fixed at a value of 255 to flag that an S2K is in use. We could perhaps
use some alternate value for this byte to flag that the private key is
using a different form of checksum protection.
Do you think that existing implementations would just
happen to ignore extra bits in the S2K specifier and
extra checksum bytes at the end? If so, I admire
the trickery, but I don't think this is serious
enough to warrant it in the spec -- as many folks have
pointed out, local key storage can use any hackery
an implementation likes anyway.
No, I think existing implementations will refuse to use the new keys
regardless of where we make the change.
The commercial version of PGP also uses some special S2K values, but
Yes... the "raw" key used in key-splitting.
Which brings me to another point: can we at least
put placeholders in the spec for these existing PGP
product features? I know that some of these hidden
features (ADKs, for instance) are unpopular, but an
OpenPGP implementation may well run across them.
I'd really like the spec to say how they appear (and
even what they do), even if it does not endorse them,
so that implementations can recognize them if they want.
The spec does have a "placeholder" for the ADK
subpacket. Shouldn't it for the S2K extensions?
Are there others we just haven't run across yet?
This is a good idea. There are a few others I know of which are
undocumented, besides the two S2K identifiers. These relate to X.509
certificate support. There is a packet type used as CRL, and there
is a signature subpacket that holds an X.509 cert. We should probably
add these to the revised draft as reserved identifiers. GPG or other
implementations may also have some reserved values.
Hal