Subject: Re: Message Integrity

From: [email-masked]
Date: Wed, 21 Apr 1999 17:12:21 -0700

Jon Callas, <[email-masked]>, writes:
> I've been waiting for someone else to create this packet, and I'm tired of
> waiting, so here's *my* definition of it. This new packet is like Packet 9
> in semantics but consists of:
>
> - Encrypted data, the output of the selected symmetric-key cipher
>        operating in (XXX) mode.
>
> -  A 20-octet SHA-1 of the plaintext contents of the packet. Note that if
> the contents of the encrypted packet is another packet (or packets), the
> hash runs over the whole of them.

I did make a proposal for a format, to wit:

: The first thing in the packet would be the IV, of a size equal to the
: block size of the cipher.  It would be followed by the ciphertext, which
: would be handled in CFB-n mode, where n is the block size of the cipher.
: There would be no special shift or sync operations.
:
: The plaintext would be prepended with a header consisting of check bytes
: so that the proper key can be detected.  The check bytes could be two
: random bytes, followed by the same two bytes, repeated.
:
: The plaintext would be followed by a SHA-1 hash of the plaintext data.
: This would be checked after decryption and detect message modification
: attacks.

I proposed to put check bytes before the plaintext so that we can tell
when we have the right decryption key.  This is important in some cases,
notably following symmetric ESK packets which don't have any internal
check bytes in them.

It is important to make it clear that the SHA-1 hash gets encrypted
along with the plaintext data.  Otherwise it could leak info about
the plaintext.

> I confess that I am concerned about the possible implementation
> difficulties here, but I'm also confused, because I don't see the problem.
> Unless the packet is encoded with indefinite length, you know how long the
> thing is. So you just subtract 20 from the length, and you know how much to
> hash. I am willing to write in there that if the packet is coded with
> indefinite length, the last chunk MUST include at least one byte of data
> and the 20-byte hash. Does this help any implementation problems? Tom? Hal?
> Werner?

As I said, I didn't particularly have difficulties even in the general
case, by using an extra buffer.  I don't really like putting restrictions
on the indefinite length encoding for this case, when we don't have them
anywhere else.  But if it would really make a difference for other
implementations, we could consider it.

If we do it, it should be sufficient to require that the whole hash
be in one chunk (which will automatically be the last one), not to
also require an extra byte of data.  This is enough that the decryptor
will always know when he is looking at data which is part of the hash.
That data is never broken up, and it is always in the final subpacket,
which is recognizable in our encoding.  Furthermore, this should not be a
significant constraint on the encryption end.  I wouldn't expect anyone
to need to output the hash in more than one packet.  You get the hash
in one step, and you have all the info you need to put it into a packet.

Hal Finney
Network Associates, Inc.

---

From: Jon Callas <[email-masked]>
Date: Wed, 21 Apr 1999 17:27:58 -0700

At 5:12 PM -0700 4/21/1999, [email-masked] said:

Mea culpa. Please forgive me. I obviously was on a mental lunch break.

Okay -- I thought the hash would be at the end, rather than the front, just
for one-passedness. OpenPGP tends to do that, to make it easy to pipeline,
and I would have thought that would mean hash at the end. Either way is
fine with me. Does anyone else have a preference?

We do have one, that the first indefinite packet must be at least 512
bytes. But nonetheless, no restrictions are better than some, and if the
hash is at the front, then there's no problem. My suggestion was just to
make it easier for implementors, and if it doesn't, we don't need it.
Merely keeping the hash whole is also just fine with me.

	Jon