Jon Callas <jon(_at_)callas(_dot_)org> writes:
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?
No, it would make thinks even more worse. In my implementation the
encryption layer does not know about things like packet length or
wehter a packet uses partial length headers. Requiring that the last
chunk must be at least 20 bytes would need some special hacks to allow
it. There is an explicit statement, that the last chunk may even have
a length of zero.
I'd prefer an extra MIC packet which can be handled nearly the same as
a signature packet and has the advantage of easier implementation (no
delay line), usable with 64 bit blocksizes too, extendable to be used
for file attributes (although I think, this has to go to the literal
data packet).
However, to come to a solution we should use the
IV|checkbytes|plaintext|SHA1
proposal and assign a new packet type to it (and add a version number
just in case we want to change it again).
How do we handle secret key material encryption with 128 bit
blocksizes? Increase the IV in the packet to the blocksize or keep
it at 8 bytes?
--
Werner Koch at guug.de www.gnupg.org keyid 621CC013