Daniel Brown <DBrown(_at_)certicom(_dot_)com> writes:
Okay, so you would add a MUST NOT to your ID, just in case somebody later on
adds a stream cipher to CMS.
Sure.
I don't know exactly what OpenPGP does, so maybe it's fine.
It encrypts the SHA-1 hash in CFB mode. Unfortunately the only analysis I'm
aware of (I've just asked on the OpenPGP list) is by Hungarian cryptographer
Daniel Nagy:
I have just discussed this issue with my students at our cryptography
seminar. The general consensus is that MDCs do not need collision
resistance. Thus, SHA1 is secure with a huge security margin. The recent
weakening of SHA1 means that finding a pre-image takes approx 2^138
attempts, which is still comfortably beyond reach for today's and tomorrow's
technology. Introducing longer hashes would make it slower, while not
improving security. If you insist, I can provide the complete reasoning why
collision-resistance is not required for MDC.
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.
I think the last step was implied, the MDC should be covered by at least two
cipher blocks (that is, with an SHA-1 hash and any current CMS cipher it's
automatic, and with the even larger SHA-2 family hashes there's no way to
avoid it). In addition OpenPGP (implicitly) sets the IV to the last block of
ciphertext because it simply jams the MDC onto the end of the encrypted data.
In this case I think either fixing the IV for the MDC at zeroes or using the
last ciphertext block would be the best option - it's mostly an implementation
thing, some implementations don't allow an explicit IV reload, but then you
can get around this by treating the IV as an additional data block. Thanks
for bringing this up, I'll mention these issues in the security considerations
section to warn people if they try and "optimise" things in the future.
(I always put a rationale in my docs, it's amazing how much of this stuff
seems obvious when you write it but probably isn't when someone else has to
implement it :-).
Peter.