I gather from Jon Callas's recent MDC spec message that his proposed
revision of June 15 is dead. [That revision used tags 18 and 19, and
purported to have the hash include the block+2 salt bytes (but wasn't
changed consistently).] Is that right?
I note that gnupg 1.0.3 uses tag 18. As I started to write this, I noticed
that 1.0.4 was release in source form yesterday -- does it use tag 15 again?
Werner Koch's recent reply suggests that PGP7 also uses tag 15.
Would someone be willing to post a sample encryption from PGP7 that uses
an MDC and Twofish? (I'd also love to see a secret key packet encrypted
with Twofish.)
My understanding of a reasonable packet sequence and proper containment
is as follows:
zero or more PKE- or SKE- session-key packets
Protected-SE-data packet (tag 15) {
version "1";
encrypted<
block-size+2 random data (last two bytes repeated);
% some packet(s?) { ... } -- typically a Compressed-data packet
MDC packet (tag 16) % { 20-byte SHA hash result }
>
}
where the hash occurs over the data between the two %-signs.
The gnupg 1.0.3 release generates roughly this format, but it uses an
indeterminate
size for the Compressed-data packet. An implementation that treats an
indeterminate
size as that of the containing file or packet, as I think the spec implies,
would consider
the MDC packet to be extraneous junk at the end of the Compressed-data packet.
Moreover, this approach won't work for the "uncompressed" algorithm, or for
a Literal-data or other packets in the payload. Given that an MDC packet will
follow, the
receiver must understand new-style packets, so a partial-body representation
should
always be valid. Does this sound reasonable? [I apologize to Werner Koch for
asking about his implementation in public, but I thought others might have yet
other
ideas on how this ought to work.]
Would it be reasonable to specify the encrypted payload more precisely,
something like
"a sequence of OpenPGP packets, ending with an MDC packet"? The MDC packet
section loosely implies this, but I think it would help to say so in the
Protected-SE data
packet section explicitly.