warlord(_at_)ALICE-WHACKER(_dot_)MIT(_dot_)EDU writes:
pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz (Peter Gutmann) writes:
Urgh, I hope no-one interprets it that way. The partial-length encoding is
incredibly painful to use with its silly power-of-two restriction (you can't
just say "This is what I've got so far, the next lot starts here" but have to
chop it up into little power-of-two length pieces just to fit the *&#^$&#*
length-encoding mechanism). GPG uses the definite-length format where it can
and 0xA3 where it can't (compressed data), something I agree with
wholeheartedly.
Come on, Peter... If you have to buffer 4K-bytes, is that so horrible?
If only it were that easy. Consider what happens when someone says "You have a
900K transfer buffer, stream data through it". Instead of being able to drop a
simple 32-bit length at the start and read in 899,996 bytes, encrypt, and write
it out again, I have to break off a 512K chunk, then a 256K chunk, then a 64K
chunk, then a 32K chunk, then an 8K chunk, then a 4K chunk, etc etc etc.
Because the amount of expansion is variable-length, depending on the size of
the I/O buffer I have to precalculate the encoding expansion beforehand and
reduce the data amount read by that amount to see what it'll take to optimally
fill the buffer, and because I have to keep dropping in partial-length headers
all over the place I can't do a single I/O but have to do it all in dribs and
drabs, and in general do a lot of unnecessary work (both in terms of writing
code and CPU time) and waste a lot more space in encoding than simply using a
32-bit length would have.
Peter.