On Wed, 21 Apr 1999, Jon Callas wrote:
Tom, again -- unless the data is of indefinite-length, you *know* how long
the thing is, and you just subtract 20 from the length you hash. Won't that
work?
Yes, but the specification says that either packet format is valid and
most current implementations use the indefinite length format for any
potentially unknown length stream (e.g. encrypt stdin).
Ask Hal or someone else how easy it would be to make PGP 6.x do definite
length formats by default.
I simply asked if the 20 bytes of hash could be put at the front instead
of the end (a similar problem since if you have to rewind to put the
length in the fields, you could just move a few bytes forward and put the
hash data at the beginning).
In short, if you have definite length packets, there is probably no
penalty for putting the hash at the beginning.
And if indefinite length is a problem, we can always say you can't use
indefinite length with a MICed packet. I have no especial love for
indefinite length, and to my mind, it's there to provide TLS-like function,
which is probably better done with TLS. :-)
I don't like them either, but they are there, and are perfectly valid to
use for any packet and add this given functionality.
If we start to get rid of these, we may as well depricate their use in
future releases.
And why wouldn't a MIC packet work, i.e. why do the 20 bytes have to be
tacked onto the end of the encryption stream without the virtual EOF and
one more packet?