[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Agree with PRZs MDC suggestion
> 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
> 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
> 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