pgut001 <pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz> wrote on 12/08/2006
11:18:53 AM:
Daniel Brown <DBrown(_at_)certicom(_dot_)com> writes:
Presumably encrypt does not protect integrity, so, the attacker may be
able
to change ciphertext to ciphertext', and further know that the
corresponding
decryption plaintext' has some meaningful relationship to plaintext.
Now the
attacker can compute hash(ciphertext') and if the encrypt function has
sufficiently poor integrity, the attacker can use this knowledge of MDC
to
compute MDC' = encrypt(hash(ciphertext')).
The assumption is that they're using a 64- or 128-bit block cipher, so
something like RC4 would be a MUST NOT.
Okay, so you would add a MUST NOT to your ID, just in case somebody later
on adds a stream cipher to CMS.
...
Even if S/MIME does not allow stream ciphers, they demonstrate that the
construction above presumes that the encrypt function must have some
kind of
integrity properties. I'm not sure if AES-CBC, for example, has the
requisite integrity-protection property for the construction above.
Note that this isn't meant to be a high-integrity, provably-secure
solution.
It's meant to be a low-effort fix for the problem that users expect CMS
encryption to exhibit a property that it doesn't currently have. I'd be
interested to see any real attacks on this, since it would mean
OpenPGP's MDC
(which AFAIK has passed crypto scrutiny) would also be vulnerable.
I don't know exactly what OpenPGP does, so maybe it's fine. However, let
me describe an example demonstrating why one may want to be careful, even
with AES-CBC. Suppose hash = MD5, or any other 128-bit hash, such SHA-256
truncated to 128 bits. We're not signing, so arguably, we don't need to
worry about the collision attacks, and this may be reasonable. Suppose
the encrypt function used to compute the MDC is AES-CBC with a random IV.
Then,
MDC = IV || AES_CEK ( IV xor MD5(ciphertext)) = IV || B
The Adversary first swaps ciphertext with ciphertext', and then sets
MDC' = IV' || B
where IV' = IV xor MD5(ciphertext) xor MD5(ciphertext'). Now MDC' is
valid for ciphertext', which is presumably undesirable. Such problems
could perhaps be fixed by setting IV to the last block of the ciphertext,
or fixing it to zero, which may be how OpenPGP works, or by insisting that
hash has more than 128 bits.
To make this a more meaningful attack, it helps to show that plaintext'
and plaintext can somehow be related. This is a well-known result. By
modifying ciphertext block C_b to C'_b = C_b xor delta, the adversary
modifies the subsequent plaintext block P_(b+1) to P'_(b+1) = P_(b+1) xor
delta, while the corresponding plaintext block P_b becomes P'_b = random.
This gives a somewhat meaningful relationship between plaintext' and
plaintext.
...
Dan Brown
(905) 501-3857
http://www.certicom.com