Jon writes:
The consensus that I've seen since late last year is for a new data
packet that has a standard encryption mode, be it CFB or CBC, and a
hash in it.
I did a little grepping of last years open-pgp traffic. The posts
discussing MDCs are below. None of them mentions this idea. I asked
at the time if anyone at PGP planned to fix MDCs and Hal responded:
Hal wrote in Jul 98:
There is no plan to add MAC or other lightweight signatures to PGP 6.0.
That may go into a future version.
As far as I recall Hal's recent posting of PRZs "hash inside enc
envelope" was the first time I have seen that proposal.
As none of the posts to the list mention the proposal in question I
can't see how you can claim there was a concensus for it on list "last
year".
I have no idea what was discussed at the Orlando meeting, because as I
said, no minutes were ever published that I found.
These were all made around July 1998:
Tom:
Unless they do something nonsensical, it would be easy to extend 1.0 - for
example, a signature algorithm of 0 means the message digest is stored in
the clear (maybe as a MPI), and leave the rest of the format alone. Old
implmentations should fail gracefully with "unknown signature algorithm".
The onepass signature header lets the "MAC" be at the end yet insures that
someone can't just delete the "MAC".
Adam in response to Toms above proposal:
The most important aspect of this, as Tom suggested, is that
openPGP-1.0 should gracefully cope with this (and other similar)
unknown signature packets, by still emitting plaintext.
I suggest that we consider reserving a packet number for MDC/Integrity
check purposes.
Jon in response to Adam:
If you can design something that is wholly backwards-compatible, it'll be
trivial to put it in 1.1 or simple document it as an extension. Not being
in 1.0 won't be an issue
If you can't design something backward compatible, then it's too late to go
in 1.0. Either way, it doesn't make it.
So after arguing against the idea of reserving an MDC packet in Jul
98, and saying it'll be trivial to make something backwards compatible
with 1.0 without doing so, you then argue the reverse now, when Tom,
Werner and I bring up Tom's earlier proposal for this which would have
benefited from reserving a verification packet ID.
Adam
--
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`