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.
wider, i.e. better (PRZ can do a commercial for GM) hash algorithm, since
(What is GM?)
some mechanism for a 256 or 320 bit hash, maybe without the NISTs help, we
can use a modified DSA, and depricate and drop ElGamal signatures. And if
But a MDC is very different to a signature and there is no need for
wider hash.
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.
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?
--
Werner Koch at guug.de www.gnupg.org keyid 621CC013