uri <uri(_at_)watson(_dot_)ibm(_dot_)com> writes:
What is "OOB EOF"? What's the big deal anyway? You're firing up encryptor
and at the same time block-by-block computing MDC (SHA-1 hash). When you
reach the last block, you have your MDC complete and can encrypt it as
block-after-last... When decrypting you always take the last 20 bytes
as MDC... What problem am I missing?
Tom already described it. You have always to store the last 20 bytes
of what you are decrypting instead of writing it simply to the output.
We introduce the onepass signature packets to implementing a stream
mode of operation so why add the extra burden for deferring the last
bytes?
But I think this is still the most simple solution and we should do
it. A more sophisticated solution could be to put MDCs every n byte
into the data to help early detection of modification. However this
has not much to do with offline encryption but with online protocols
like SSH. So I suggest we keep the simple solution but use use a new
packet type for it.
Yes. It is preferable not to introduce the whole zoo of algorithms.
So with the move to 128-bit block ciphers I'd expect AND PREFER
the old 64-bit block ciphers to quietly go away, the sooner
I think it is bad style to change a standard which already defines how
to handle different blocksizes (albeit with some conflicts).
Such as a signature with a "zero" encryption algorithm that would just
store the 20 bytes of the SHA-1 hash? This could be easily added to the
existing code (with provisos that it doesn't display as a signature).
I'm strongly against it. Such a signature does not make sense [to me].
It really does not make sense without a MAC (message authentication
code).
--
Werner Koch at guug.de www.gnupg.org keyid 621CC013