[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Agree with PRZs MDC suggestion
On Tue, 18 May 1999 hal@xxxxxxxx wrote:
> As I described earlier, I propose not to have any mechanism for turning
> the MDC on and off, or for selecting a hash algorithm, because these would
> leave openings for an attacker to possibly modify this selector. He might
> be able to turn off the MDC, which would completely defeat the purpose.
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.
You could put a simple checksum (like used for keys) so that the attacker
would have to change both the algorithm ID and checksum within the
Also you assume that you could somehow calculate an RMD160 (or other) hash
of modified encrypted data and reencrypt that.
And you could still simply strip off the last N bytes as you have things
now, which is another thing a prefix, the equivalent of "Hash:" helps.
> 5.Y Modification Detection Code Packet (Tag 16)
> The Modification Detection Code packet contains a SHA-1 hash of
> plaintext data which is used to detect message modification. It is
> only used in the context of a Symmetrically Encrypted Integrity
> Protected Data packet. The Modification Detection Code packet MUST
> be the last packet in the plaintext data which is encrypted in the
> Symmetrically Encrypted Integrity Protected Data packet, and MUST
> appear in no other place.
> A Modification Detection Code packet MUST have a length of 20 octets.
> The body of this packet consists of:
> - A 20-octet SHA-1 hash of the preceding plaintext data of the
> Symmetrically Encrypted Integrity Protected Data packet, not
> including prefix data but including the tag and length byte of
> the Modification Detection Code packet.
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
followed by RMD160 over the same input we don't want to use that here
There were strong arguments for removing ElGamal signatures. But they
turned on providing a mechanism for allowing a DSA like signature to use a
wider, i.e. better (PRZ can do a commercial for GM) hash algorithm, since
a 4096 bit DSA key doesn't add anything when you only have 160 bits of
hash to protect. I am assuming that this might actually be resolved with
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
that happens I would really want the option to use that wider hash here.
> Note that the Modification Detection Code packet MUST always use a
> new-format encoding of the packet tag, and a one-octet encoding of
> the packet length. (These requirements are already imposed by the
> rules for tag and length encoding.)
My proposal (not in spec language):
The MDCP appears first PRECEEDING the encrypted plaintext and contains
only the version number and algorithm ID(s), and a checksum word.
Alternative 1: 1 MDC packet with version byte, number of hashes byte -
must be nonzero, N algorithm ID bytes.
Alternative 2: N MDC packets, one per algorithm used in reverse order
(therefore no #-of-hashes byte), and nested, i.e. an outer hash will be
made only over all the inner hash packets. e.g. RMD+ ( SHA+ ( plaintext )
SHA= ) RMD =
Alternative 3: only 1 MDC allowed, with version, algid, and checksum.
Then any plaintext packets (should this be required to be 1?).
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.
So would a header MDCP, and having both MDCPs checksummed be adequately
secure? If the entirety was encrypted how would you attack it? You would
have to change two algorithm ID bytes, come up with two correct checksums,
and a valid hash for the algorithm you are altering the hash algorithm to.