Adam Back <[EMAIL PROTECTED]> writes:
>I can see that, but the security of CBC MAC relies on the secrecy of the
>ciphertexts leading up to the last block. In the case of the mode you
>describe in RFC3211, the ciphertexts are not revealed directly but they are
>protected under a mode which has the same splicing attack. The splicing attack
>on "CBC MAC with leading ciphertext" works through CBC encryption, here's how
>that works:
Right. One minor point, the IV is never zero, for disk encryption it's a
cryptographic transform of the sector number, for PWRI it's supplied by the CMS
algorithm parameter (this doesn't affect the attack).
>I would have thought this would be considered a 'break' of a non-malleable
>cipher mode as discussed for disk encryption where each bit of plaintext
>depends on each bit of ciphertext as would be the case with a secure cipher
>matching Mercy's design goals (a block cipher used in ECB mode with a
>different key per block).
Yup. Actually the no-stored-IV encryption was never designed to be a non-
malleable cipher mode, the design goal was to allow encryption-with-IV without
having to explicitly store an IV. For PWRI it has the additional nice feature
of avoiding collisions when you use a 64-bit block cipher, which is probably
going to be the case for some time to come even with AES around. It was only
after all that that I noticed that the first pass was effectively a CBC-MAC,
but it didn't seem important enough to mention it in the RFC since it wasn't an
essential property (good thing I didn't :-).
>With a disk mode, unlike with RFC3211 pasword based encryption for CMS there
>is no place to store the structure inside the plaintext which may to some
>extent defend against this attack.
Even with PWRI you get at most ~32 bits of protection, and can bypass even that
if you encrypt 5 or more 64-bit blocks and mess up the second block, since the
garble will propagate to at most 4 of the 5 blocks. The 32-bit limit was
deliberate, I was worried about dictionary attacks above all else (in fact the
first version of the wrap was a bit too paranoid in that it had no redundancy
at all, which unfortunately meant that it wasn't possible to catch incorrect
passwords. User complaints lead to the addition of the 24-bit check value
which is enough to catch virtually all mistyped passwords but not enough to
provide more than a small reduction in the number of guesses necessary for an
attacker. The length byte is there so an attacker can't perform an iterative
attack where they change the algorithm ID for the wrapped key to 40-bit RC4 and
brute-force it, then 56-bit DES and brute-force the 16-bit difference, then 80-
bit Skipjack, 112-bit two-key 3DES, and finally 128-bit AES. There was another
key wrap design where this was possible).
Digressing from the original disk-sector-encryption, I'd be interested in some
debate on the requirements for password-based key wrapping. The design goals
I used were:
1. Resistance to dictionary/password-guessing attacks above all else.
2. No need to use additional algorithms like hash algorithms (see the RFC for
the rationale, to save me typing it all in again).
The reason for 1. is that provided you use a secure cipher the best approach
for an attacker is going to be a dictionary attack or similar attack on the
password used to wrap the key. Since the wrapping key is going to be used to
protect things like long-term private keys, this is an extremely high-value
item.
Note that the immunity to key-guessing requirement is mutually exclusive with
modification-detection, since (for example) storing a SHA-1 hash would allow
you to immediately verify whether you'd found the password/key. This is the
exact problem which PKCS #12 has, you don't need to attack the key wrap since
the MAC on the wrapped data is a much easier target. There's another key wrap
which stores a full SHA-1 hash alongside the wrapped key (to protect against
some problems present in an earlier version of the same key wrap mechanism,
which fell to fairly trivial attacks). This is great for integrity protection,
but terrible for security, since it allows you to verify with pretty much 100%
accuracy whether you've guessed the password.I also looked at some sort of
OAEP-like wrapping (or, more generally, a Feistel-like construct of the kind
used in OAEP), but it seemed a bit ad-hoc when used with symmetric key wrap
rather than RSA.
Does anyone have any thoughts on symmetric key wrap, and specifically the
differences between high-value and low-value (ephemeral) key wrap requirements?
General rant: It's amazing that there doesn't seem to be any published research
on such a fundamental crypto mechanism, with the result that everyone has to
invent their own way of doing it, usually badly. We don't even have a decent
threat model for this, my attempt at one for password-based key wrap may or
may not be appropriate (well, I hope it's more or less right), but it'
