Subject: Re: Message Integrity

From: [email-masked]
Date: Thu, 22 Apr 1999 15:23:42 -0700

I still don't see that the signature packets are a very natural or
comfortable place to put this data.

We would probably use one-pass signature packets for this so that the MDC
(MIC) can go at the end and the encryptor doesn't need to buffer up all
the data.  The format of a one-pass signature is:

 - version number
 - signature type
 - hash algorithm
 - public key algorithm
 - signing keyid (8 bytes)
 - nesting flag

Most of these fields are not relevant for the MDC.  We need to put
a magic value into one of them (Tom is looking for all-zero keyid,
others had suggested using a zero public key algorithm).  The others are
really not meaningful.  The signature type with all its variations is not
relevant; hash algorithm is unnecessary, a fixed hash algorithm is fine;
public key algorithm and signing keyid aren't meaningful; nesting flag
is not relevant either.

Likewise, the signature packet fields are equally meaningless:

 - version number
 - length of hashed portion (must be 5)
 - signature type
 - signature creation time
 - key id of signer
 - public key algorithm
 - hash algorithm
 - left 16 bits of hash
 - Multi Precision Integer holding the signature

Again, we have signature type, key id, public key and hash algorithms,
all unnecessary or irrelevant.  We have a timestamp, also inappropriate
for an MDC (which is inherently a transient concept).  We have the left
16 bits of the hash!  Will we keep that, when we're going to be storing
the hash itself in the MPI signature field?  It's just going to be a copy
of two bytes of the hash.  Utterly pointless.

And last we have the signature itself, which is the only meaningful piece
of data in this entire packet, since that is where we will put the hash.
We have to agree on how to encode the hash, presumably as an MPI, which
implies special treatment of leading zeros.  Or maybe we'll just shove
the 20 bytes in there and have done with it since we're misusing the
rest of the packet so badly anyway.

Looking over these comments, it's clear that these packets are completely
inappropriate for the use to which we are proposing to put them.
This solution is a real kludge.

If we absolutely, positively had to put this data into signature packets,
maybe we should create a new version of the packets and use that.
Or better still, use new packet types.  Make the prefix packet be just
a flag that the following data will be checked with a MIC.  Then make
the trailer packet just have the MIC in it.  Simple and clean, unlike
the above.

Or even better, use a special encryption packet to indicate that there
is a MIC (MDC) following, and a special MIC packet to hold it following
the encryption packet, as Werner proposed.  It is not too different from
the original idea and if it would help with the implementation it seems
like a reasonable method.

Hal

---

From: Werner Koch <[email-masked]>
Date: Fri, 23 Apr 1999 21:30:43 +0200

> is a MIC (MDC) following, and a special MIC packet to hold it following

I think this will be the cleanest solution.

  * Create a new encrypted data packet:
    - 1 byte version number (please, we have this on most others too)
    - 1 byte mdc-algorithm  (hash algorithm used or 0 for no MDC)
    - n byte encrypted-data (in standard CFB mode with prepended
			     random and check bytes)	
    
  * Create a MDC packet:
    - 1 byte  version number  
    - 1 byte  mdc-algorithm (should be > 0 )
    - n bytes hash  

I don't know whether it is better to use 1 or 3 for the version
numbers.  I think PGP 6 has some new packet types, so someone
else should suggest the numbers.

Implementation of this seems to be more easier than the hacked
signature packets.  Maybe a little bit more code but much easier to
understand.  And we don't need to redefine the specs (I still remember
the trouble I had when using the old rfc1991 comment packet and then
the one from the draft).

We can state that the new ciphers (which are not yet defined in the
specs) SHOULD use the new encryption packet. 

  Werner

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013