On Wed, 19 May 1999, Werner Koch wrote:
tzeruch(_at_)ceddec(_dot_)com writes:
We are in agreement that there should be no mechanism for turning the MDC
off. Having a mechanism for selecting a hash algorithm is different, and
I don't see it as leaving the same openings.
And when the NIST comes up with a wider hash for the DSA-plus (or whatever
it will then be called) you absolutely, positively never ever want to be
able to use it here? (Or if OpenPGP comes up with a wider DSA, say SHA
Not for the purpose of a MDC, even the 160 bit digest is overkill, but
we already have to use it elsewhere so it does make sense to use it.
We also have a 24 bit CRC which must be implemented for the ASCII armor
and it is even faster. If that is adequate (and faster), why not use it
instead of a cryptographic hash?
wider, i.e. better (PRZ can do a commercial for GM) hash algorithm, since
(What is GM?)
General Motors - they have an ad campaign for one of the cars of the theme
"Wider is Better".
The MDCP appears first PRECEEDING the encrypted plaintext and contains
only the version number and algorithm ID(s), and a checksum word.
I think that is much to complicated and I can't see the benefit from
it. Putting a checksum (or a copy of the algid and version number)
into the encrypted text E(random_prefix,2_checkbytes,version_byte,
algorithm byte) is much easier and all waht we need. We already
encode the cipher algorithm in the pk-encoded sessionkey - so why I
see no argument why not putting additional input into the encrypted
packet.
Where exactly? We have a packet header for the encrypted packet itself,
the key material from the PK or SK material packet, and potential
information in a packet at the head of the encrypted plaintext.
(see my next comment)
Then the real MDCP but is 20 (or whatever the hash length(s) is(are) )
bytes longer than the one at the top, and has a checksum which reflects
the full packet.
Why an extra checksum if we already have an MDC?
Because someone was suggesting that if anyone ever changed the algorithm
ID byte they could turn off the MDC. That could be prevented by a
checksum. If it is not reasonable to have an attack of this form, then
there should be no problem having an algorithm ID byte. But if it is
unencrypted, it can be changed.
And I might want to specify other algorithm IDs, e.g. the Palm Pilot has
MD5 (and DES) in the OS kernel, but not SHA1. I would really prefer to
have my MDCs there as MD5, and use 3DES for a minimal Palm implementation.
In either case, the MDC proper should be encapsulated in a packet, and if
the algorithm can be specified as I want (maybe 0 could be the ASCII CRC)
the algorithm ID with version number should be in a packet and preceed the
encrypted data.