At 5:12 PM -0700 4/21/1999, hal(_at_)rain(_dot_)org said:
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.
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?
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.
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