Hal Finney wrote:
Hal Finney wrote:
Krawczyk's paper is about combining MAC and symmetric encryption.
That's not what OpenPGP does. We don't do MACs.
Actually, the only point of the MAC is to tell whether decryption
succeeded. Signatures do the same job.
I have to apologize to Ben, he's right about this. I went back and
re-read Krawczyk's paper and it does apply to signatures as well as
MACs.
Thankyou.
However, the actual result is somewhat different from what is often
stated, which is that MAC-then-encrypt is potentially insecure. What he
actually shows is that encryption that is secure against passive attacks
(like chosen plaintext) is not necessarily secure against active attacks
(like altering the ciphertext en route), and that this is not prevented
by MAC-ing the data before encrypting. As Ben points out, it is also
not prevented by signing the data before encrypting.
In fact, nothing you do to the data before encrypting can prevent
the attack Krawczyk shows, because he assumes certain properties of
the decryption engine which cause it to abort before it even tries to
process the decrypted data. Although Krawczyk suggests that "in a sense"
the MAC can make things worse, in fact his attack never calls the MAC
(nor would it verify a signature). He corrupts the data en route such
that the decryption engine barfs on it, so the plaintext never gets
processed at the receiving end. The attacker is assumed to be able to
notice this response, which leaks information about the plaintext.
So, a MAC/signature _can_ help, if the failure is visible to the attacker.
Krawczyk basically shows that you can't use an encryption function which
is really weak against active attacks, and then assume that an inner
signature or MAC will save you. If the encryption function is bad enough,
there is nothing you can do if you are going to wait until you decrypt.
The only solution is to check integrity before beginning decryption.
The bottom line is that at some level we do need to assume that our
encryption functions do not have the horrible properties that Krawczyk
had to assume in order to make his construction go through.
This was my point about not being clear what the actual limits for those
properties are. I guess he requires, at least, a function where its
possible to change the ciphertext without changing the plaintext. This
is not a property of any cipher I'd be likely to use.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff