Jon Callas, <jon(_at_)callas(_dot_)org>, 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.