Tom Zerucha says:
The new model becomes (please correct ommissions)
Plaintext -> MAC append -> IV/CFB xor -> Ciphertext
^
|
Secret -> Cipher
It's not MAc - it's MDC. Otherwise your diagram looks correct to me.
The IV/CFB box is different. So why not just define a new IV/CFB mode or
method instead of jamming this definition into the cipher?
I don't know - does it really matter how to define "this" new way
of processing?
Also the MAC gives me some indigestion. There are uses of this for stream
processing, and the MAC in this format needs an OOB EOF and processing.
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?
And to ask a question, how do I know where the MAC is?
In the last 20 bytes of the plaintext, where else...
I have to decrypt and hold back 20 bytes just in case I see the EOF?
You have to decrypt - then you have to "clip" the last 20 bytes of
the resulting plaintext and give them to MDC verifier. Of course
you can be computing the MDC block-by-block as you're
decrypting the message...
Is there a particular reason not to use the old ciphers with the new
format (if it is available)? Other than backwards compatibility - which
you won't have anyway?
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
the better.
We have also discussed providing integrity protection via some
modification to the signature packet format rather than by a new form
of encrypted packet. There would be a special kind of "signature" which
would just consist of a hash of the message to protect its integrity.
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].
Doing a MAC within the encryption packet now adds a layer on the inside,
which will be there even for signed messages.
It is NOT a MAC - it's MDC (Modification Detection Code). Different
type, different application, different security considerations.
I really don't like extra layers if an existing layer can provide the
functionality.
(:-)
Since you can have multiple signature packets, adding the symmetric MAC
"non-signature" adds this function without the layer.
In short, I'm against it.
--
Regards,
Uri uri(_at_)watson(_dot_)ibm(_dot_)com
-=-=-=-=-=-=-
<Disclaimer>