tags:

views:

45

answers:

3

http://en.wikipedia.org/wiki/CMAC

http://www.rfc-archive.org/getrfc.php?rfc=4493

There are two keys K1 and K2. Are there any other reasons, beside that messages 1 differs from 10^127 (1 and 127 zeroes)

If message carries length (and length is also CMAC-ed whit message), are there any security weaknesses using only one randomly generated K?

A: 

I suppose symmetric ciphers are susceptible to know-plaintext attacks, at least they have been in the past. And since you do a portion of the plaintext (the padding pattern) you don't want to leak information about your key. If you can extract some bits of the key that way you can brute-force attack the last block but all other blocks remain secure (under this KP attack at least) since they have been encrypted via K1.

To overcome the very same problem, block-based ciphers usually operate in various modes, see: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation. Don't know why this obvious solution hasn't been considered in the design of CMAC.

hroptatyr
You might become really famous if you apply practical chosen plaintext attack on AES. http://en.wikipedia.org/wiki/Chosen-plaintext_attack
ralu
@ralu: working on it, right *now* :P
hroptatyr
+1  A: 

First of all, there's really only one key K in AES-CMAC - it's the only one you have to generate, to address your last question, and that's stated explicitly in the spec:

The subkey generation algorithm, Generate_Subkey(), takes a secret key, K, which is just the key for AES-128.

Your other question - why do we need to generate K1 and K2 from K - is a little bit harder to answer, but there's actually a very simple explanation: to eliminate any ambiguity in the message authentication.

To illustrate, supposed we take the binary keys from the wiki article: K1 = 0101 and K2 = 0111. Now let's play with the message M = 0101 011. Because M is not made up of full blocks (three bits rather than four), we have to pad it. Now we have M' = 0101 0111.

To generate the MAC for this message, we just have to XOR our keys in:

M'  = 0101 0111
K1  = 0101
K2  =      0111
MAC = 0000 0000

If we had used K1 in both cases, then we'd have the following procedure:

M'  = 0101 0111
K1  = 0101
K1  =      0101
MAC = 0000 0010

This is all fine and good, but watch what happens when we try to generate a MAC for M'' = 0101 0111 (that is, an unpadded message M'' identical to the padded message M').

M'' = 0101 0111
K1  = 0101
K1  =      0101
MAC = 0000 0010

We've generated the same MAC from two different messages! The use of the second key (which has some number-theoretical properties that prevent it from being problematically "similar" to K1) prevents such an ambiguity.

ladenedge
+1  A: 

I don't believe it has to do with known-plaintext attacks, and I disagree with symmetric ciphers are susceptible to them. One of the conditions of a cipher being secure is that it is secure under KPA, CPA (chosen-plaintext attacks) and CCA (chosen-ciphertext attacks).

Unless I am not understanding your question, yes, you still need both subkeys. K2 is used when a block is not a complete block. . K1 and K2 are not randomly generated, but are derived from K. Is there a reason you do not want to generate these subkeys?

There are a number of weaknesses in authentication codes based on chaining modes. CBC-MAC was provably secure only for fixed size messages. The security completely fails for variable length messages where the last block is padded.

You can read the XCBC paper to see how the attack works:

"As a simple example, notice that given the CBC MAC of a one-block message X, say T = CBCEK(X), the adversary immediately knows the CBC MAC for the two-block message X || (X ^ T) since this is once again T."

[1] http://www.cs.ucdavis.edu/~rogaway/papers/3k.pdf

mattjf
Nice observation. Would appending the length at the end of stream prevent such extension attack? Do you know any other generic attacks on CBC MAC?
ralu
This is a good paper on attacks and security bounds of chaining authentication modes: http://www.cs.ucdavis.edu/research/tech-reports/1997/CSE-97-15.pdfI wouldn't append the length. I can see a couple possible attacks, but I'd have to think through them completely. It would invalidate all the security proofs, and be a completely new, untested scheme. I really wouldn't deviate from any of the standard primitives. Dual Counter Mode showed how easy it is to make a mistake.
mattjf