Tag Info

23

HMAC was there first (the RFC 2104 is from 1997, while CMAC is from 2006), which is reason enough to explain its primacy. If you use HMAC, you will more easily find test vectors and implementations against which to test, and with which to interoperate, which again explains continued primacy. Being the de facto standard is a very strong position. On many ...

14

The problem with CBC-MAC for variable-length messages is that CBC-MAC applied to a one-block message essentially amounts to an oracle for evaluating the block cipher at values of the adversary's choice. And that oracle allows an adversary to break the scheme. Consider first CMAC restricted to messages that consist of a whole number of blocks. Then the ...

8

A similar question as been asked before: Use cases for CMAC vs. HMAC? To resume it, AES-CMAC is a MAC function. It can be seen as a special case of One-Key CBC MAC1 (OMAC1) which also a MAC function that relies on a block cipher (so AES in the present case). HMAC is also a MAC function but which relies on a hash function (SHA256 for HMAC-SHA256 for example)...

8

Comparing a brute force attack on DES (with $2^{56}$ operations) to a birthday attack on CMAC (with $2^{64}$ operations) would appear to be an apples-to-Volkswagen comparison; they are assuming two things are similar, when they really aren't. The brute force attack on DES involves obtaining a single plaintext/ciphertext block pair, and then going through ...

6

The answer is simple. The recommandations of all experts in this case is to dissociate Keys used for Encryption from Keys used for MAC-ing. Then you have to use two different Keys.

6

Or is that true only under some special circumstances? This statement is based off of Remark 9.60 of the Handbook of Applied Cryptography (PDF of chapter 9) which reads as when talking about the strongly related CBC-MAC: Remark (truncated MAC outputs) Exhaustive attack may, depending on the unicity distance of the MAC, be precluded (information-...

5

With AES_CMAC, tag truncation acts like you would expect; if an attacker generates a message and a random tag, then they have a $2^{-32}$ (or one in 4 billion chance) of happening to pick the correct random tag (and getting the message accepted), and with AES_CMAC, there's nothing they can do to improve on that. Is a $2^{-32}$ success probability per ...

4

CMAC(masterKey, i) should generally suffice, yes. Note that you would need to specify an encoding for i (e.g. octet string consisting of the big endian encoding of i, left-padded with zero valued octets up to 4 octets). It's probably better to implement one of the schemes defined in NIST SP 800-108: "Recommendation for Key Derivation Using Pseudorandom ...

4

No, CMAC is not susceptible to block reordering. Unlike CBC, the attacker does not see the values of the intermediate encryptions (and because of the tweak applied to the last block, he can't find that out by asking for the MAC of prefixes). Hence, the attack cannot modify the plaintext (including reordering blocks) in a way to make a predictable change to ...

4

No, you cannot assume that if the first four bytes are correct, the other bytes are correct, too. Truncating the CMAC tag to four bytes means that an adversary will be able to forge a valid tag value (without knowing the secret key) with a success probability of about $2^{-32} \approx 4\cdot 10^{-9}$. This value is usually considered in most threat models ...

4

AES is a block cipher. It permutes (maps) input blocks to output blocks of 16 bytes. The permutation that is used depends on the key. AES must be used in a mode of operation such as CBC to be able to be offer confidentiality of dynamically sized messages. CBC is commonly used in Smart Card environments. CBC offers confidentiality against (passive) ...

4

AES - CCM, why not use CMAC inside instead of CBC-MAC? So in their original suggestion of the mode for 802.11i (for WPA2) the only reason given by Whiting, Housley and Fergueson is: A combination of counter mode encryption and CBC-MAC authentication is proposed here. These modes have been used and studied for a long time, with well-understood ...

3

The lack of a generic security reduction for MAC-then-encrypt is basically only for pathological cases where an encryption scheme admits modifications to the ciphertext that don't affect the plaintext, like AES-CTR with an extra bit of key stream appended to the message on encryption and ignored on decryption. So is your AES-CMAC-then-AES scheme or an AES-...

3

This is like stating that $H(C_1|m_1|x|C_2) = H(C_1|m_2|x|C_2)$ if $H(C_1|m_1|C_2) = H(C_1|m_2|C_2)$ for HMAC. That is probably correct if $H$ is a hash function based on Merkle–Damgård construction (such as SHA-1 and SHA-2) and if $m_1$ and $m_2$ end on block boundaries. $H(C_1|m_1|C_2) = H(C_1|m_2|C_2)$ implies that the state after hashing $C_1$ and $m_1$...

3

Everything that Maarten has said is true; however I would emphasize one point that may not be obvious. I'm pretty sure you've doing things correctly; however it would be prudent to say it anyways. CMAC is a good KDF is the key is unknown, and the message being MACed is known. It is not a good KDF if the key is known, and the message is unknown. That is, ...

3

Do I have to do all the "zero" stuff and doubling and XORing? If you are implementing the S2V primitive, using an AES-CMAC function, then yes, you will need to do all that "zero" stuff and doubling and XORing. Yes, if you peek inside the AES-CMAC function, you will find some logic that looks sort of like this; processing an all zero block, doubling the ...

3

I am answering on the basis of this paper (pdf) linked in the comments, as well as some of the related papers it cites or is cited by. I am not aware of more realistic attacks on HMAC. It assumes a DPA side channel that leaks the number of bits flipped when a new value is read into a CPU register (or in another instruction in some of the papers). I.e. it ...

3

Brute forcing ciphertext an offline attack, while attacking the authentication tag (the result of the CMAC-calculation) is an online attack: it requires an active oracle. That is: you can try and break the confidentiality of a message on your own PC network of computers. However, you need to send many ciphertext (including authentication tag) to a receiver ...

2

AES-CMAC is defined for messages of any length. The algorithm can be reduced to the following, if you have non-empty messages smaller than the block size: (K1,K2) := Generate_Subkey(K); n := ceil(len/const_Bsize); M_last := padding(M_n) XOR K2; X := const_Zero; Y := M_last XOR X; T := AES-128(K,Y); return T; You don't need to derive some non-standard way ...

2

Look at how the keys $K_1$ and $K_2$ are used in CMAC (pdf, Section 6.2): If $M_n^*$ is a complete block, let $M_n = K_1 \oplus M_n^*$; else, let $M_n = K_2 \oplus (M_n^*||10^j)$, where $j = nb-Mlen-1$. They are combined with message blocks using XOR. So they must be equal in length to the block size, not the key size (if different), of the cipher....

2

Does this mean that it is possible to attach any string x on m1 and the tag of it will be the same as the tag for x attached to m2? Yes. If using HMAC, then with high probability, the tag on (m1, x) will be the same as the tag on (m2, x). With CMAC, the attack works with probability 1. If my assumption is true could this be considered as a length ...

2

What the specification is saying is that prior to processing, the message is padded to a full block length, with the empty message padded to a single block. The spec on page 4 describes the input into the algorithm as: Define $||a||_n = max\{1, \lceil|a|/n\rceil \}$, where the empty string counts as one block Let $m = ||M||_n$ Partition $M$ into $M[1] ... ... 2 Wrapping my (now deleted) comments into an answer… OMAC, as described in the OMAC spec and its addendum, is what Rogaway et al provide security proofs for in their EAX paper. If you take a quick look at RFC 4493, you’ll notice that it states: The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message ... 2 If a MAC is encrypted using CTR specifically then specific bits can still be flipped by an attacker. So although the MAC isn't known, specific bits can still be altered in transit. This may allow certain attacks, depending on the error handling of the receiver of the protected messages. [The question I cannot readily answer is if such a small authentication ... 2 Yes, truncated MACs influence the cryptoperiod. First of all, I cannot really think of any case where it makes sense to assume that the attacker only sees a truncation of the MAC if that isn't what is actually used in the system! And if you actually truncate your MACs to 30 bits you will probably have collisions after$2^{15}$message blocks. So you ... 2 CMAC is also called OMAC1, which is a message authentication code and was recommended by the NIST in 2005. The security definition of a MAC (wiki link) states, that a MAC must resist existential forgery under chosen plantext attack. That means, that an attacker must not be able to generate any valid MAC (under a certain key), regardless of how many valid ... 2 That is, why is the scheme insecure if we compute the output tag$t'$using$F_{k_1}$? Computing$F_{k_1}( \text{CBCMAC}_{k_1}(M))$is precisely equivalent to taking the padded message$M$, appending an all-zero block to it, and then preforming the CBC-MAC on it (sans the padding operation). Here's how an attacker can exploit that to break the MAC scheme, ... 1 From rfc4493 (The AES-CMAC Algorithm); The security provided by AES-CMAC is built on the strong cryptographic algorithm AES. However, as is true with any cryptographic algorithm, part of its strength lies in the secret key, K, and the correctness of the implementation in all of the participating systems. As the standard states; the longer key the ... 1 I hope you mean drawback caused by AES CBC-MAC which is resolved in AES-CMAC. AES_CBC MAC if used properly with ISO padding technique should not result into a tag collision. So AES-CBC MAC should look something like this. [Please look at the image in the above link] In AES-CBC MAC if the last block is not 16 byte alligned(considering AES as PRF) then ... 1 The XOR of the tags is trivially vulnerable to multiple easy attacks by an active attacker, which will yield the same tag, for example: They can reorder chunks, because XOR is associative ($a \oplus (b \oplus c) = (a \oplus b) \oplus c$) and commutative ($a \oplus b = b \oplus a$). They can triplicate any chunk, because$a \oplus a = 0$and$a \oplus 0 = a\$,...

Only top voted, non community-wiki answers of a minimum length are eligible