On Thu, 22 Mar 2001, hal(_at_)finney(_dot_)org wrote:
and how the key for the HMAC is calculated from the passphrase (generally
it is a good idea for MAC keys to be different from decryption keys).
Do we need to define a new packet format, V5 for keys? Or could we keep
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):
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.
This closly resembles the MDC encryption we are now using. The
fingerprint also comes handy to store these secret parts on hardware
tokens and migh be a good idea anyway for an internal secret key
storage format. If there are concerns about known plaintext we
could leave the fingerprint out of the encryption so that we hash
1+2 and encrypt 2+3.
GnuPG can already use an extension to the secret key protection,
which is used to allow for a primary key without secret key but
workable secret subkeys (nice on a automated system):
| S2K mode 101 is used to identify these extensions.
| After the hash algorithm the 3 bytes "GNU" are used to make
| clear that these are extensions for GNU, the next bytes gives the
| GNU protection mode - 1000. Defined modes are:
| 1001 - do not store the secret part at all
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.
I agree with Hal that there is no urgent need to do something. This
might backfire on repudation of the OpenPGP specs.
Ciao,
Werner
--
Werner Koch Omnis enim res, quae dando non deficit, dum habetur
g10 Code et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions -- Augustinus