Werner Koch writes, quoting Hal:
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
Thanks.
In our case we might just compute an HMAC over the entire secret key
packet, and append it.
This still does not solve the problem, how to get the key for the
HMAC.
Yes, it is true we would need another key.
I didn't read the Bellare paper in detail but I can't see
that it goes into the problem of possible interaction between the
encryption and HMAC key. I think it is good practise, not to use
the same key (or a derived onbe). So we would need a second
passphrase - argh.
What is usually done is that both the encryption key and the MAC
key are derived from a common seed. In this case the seed would be
the passphrase. Presently we put the passphrase through a hash-based
transform to generate the encryption key. We could use a different
transform to generate the HMAC key. Perhaps it could have a different
iteration count or the hash function could be pre-loaded with a different
prefix value.
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
Can you please tell us which identifiers you use, so that we don't
run into problems if we encounter such identifiers.
Yes, I'll put together some documentation on these and on the other
places we use packets. For now, we use S2K identifier numbers 4 and 5.
Hal