Werner Koch writes:
No need for a new format - doing such changes for OpenPGP right now
will delay getting to draft even more.
There is a far easier way to do this and we can do this first in our
implementations and use the old format for transferring secret keys
(which is a Bad Thing doing it at all or over an insecure channel):
Yes, I like the idea of doing extra checks internally, while retaining
at least for now the current format as a data interchange. We could
add language to the draft warning implementors to check the arithmetic
validity of the keys if the files may have been meddled with.
We introcude a new S2K mode and encrypt this:
1. fingerprint of the public key
2. the secret MPIs
3. A SHA-1 hash over 1 and 2.
A thread on sci.crypt recently pointed to an AsiaCrypt 2000 paper by Mihir
Bellare, http://www-cse.ucsd.edu/users/mihir/papers/oem.html. This is
a theoretical analysis showing that based on very minimal assumptions
of the properties of MAC and encryption algorithms, the strongest mode
is to encrypt and then MAC. That is, you compute a keyed MAC on the
ciphertext in order to detect modification.
In our case we might just compute an HMAC over the entire secret key
packet, and append it.
Now, Bellare's analysis is highly theoretical, and some of the attacks
he shows on other modes are quite artificial. In practice something
like what Werner suggests should be fine. But still we might want to
consider using the Bellare approach since it is strong even when we
consider artificial-seeming attacks.
So either each implementation uses it's own scheme or we agree
informally on one in the (not officially reserved) private range of
S2K mode.
The commercial version of PGP also uses some special S2K values, but
we could certainly decide on a new value to identify the new form of
checksum.
Hal