Subject: MDC, gnupg 1.0.3, and PGP7

From: "Michael Young" <[email-masked]>
Date: Thu, 19 Oct 2000 00:18:06 -0400

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.

---

From: Werner Koch <[email-masked]>
Date: Thu, 19 Oct 2000 17:53:09 +0200

> revision of June 15 is dead.  [That revision used tags 18 and 19, and

18 and 19 is right.

> that 1.0.4 was release in source form yesterday -- does it use tag 15 again?

No.

> Werner Koch's recent reply suggests that PGP7 also uses tag 15.

I was wrong, it uses 18,19 and I did some interoperability tests.

> an MDC and Twofish?  (I'd also love to see a secret key packet encrypted

Passphrase "test"

Here are the packets:

symkey enc packet: version 4, cipher 10, s2k 3, hash 2
	salt 503a47a468e26509, count 96
:encrypted data packet:
	length: 137
	mdc_method: 2
:literal data packet:
	mode b, created 971969290, name="geheim",
	raw data: 83 bytes
:mdc packet: length=20

And here come the same thing with compression:

:symkey enc packet: version 4, cipher 10, s2k 3, hash 2
	salt f8c920d888fc458a, count 96
:encrypted data packet:
	length: 135
	mdc_method: 2
:compressed packet: algo=1
:literal data packet:
	mode b, created 971969488, name="geheim",
	raw data: 83 bytes

The MDC packet is not listed due to a bug/implementation issue.

From packet.h:
	PKT_ENCRYPTED_MDC =18, /* integrity protected encrypted data */
	PKT_MDC 	  =19, /* manipulaion detection code packet */

Hth,

  Werner

-- 
Werner Koch				GnuPG key:  621CC013
OpenIT GmbH                             http://www.OpenIT.de

---

From: Jon Callas <[email-masked]>
Date: Thu, 19 Oct 2000 10:47:01 -0700

In our last episode ("Re: MDC, gnupg 1.0.3,  and PGP7", shown on 10/19/00),

>	PKT_MDC 	  =19, /* manipulaion detection code packet */

I only do what the voices in my head tell me to. This time, the voices told
me to use 15 and 16. :-) I'm changing them to 18 and 19.

Send me some more changes/additions, folks and they'll go in, too.
Otherwise, in a week or so, I'll just fling out another draft with this
correction.

	Jon