# Tag Info

9

It is not secure, because an attacker can "mix and match" the output blocks from different authentication tags on different input messages, or repeat output blocks for repeated input blocks. For example, if the attacker knows the tag $F_k(m)$ for a one-block message $m$, then it can forge the correct tag $F_k(m) \mid F_k(m)$ for the two-block message $m ... 8 This scheme is not worth the name MAC; it is horribly weak. First and foremost, the tag/MAC is unchanged when two blocks of plaintext are exchanged (because of the commutativity and associativity of the$\oplus$operation). If follows that from any message with at least two different blocks, we can make a different message for which we know the tag/MAC. ... 8 First the theoretical explanations: Integrity and authenticity are different goals to achieve, but both are achieved (for symmetric encryption) with a MAC. You should probably be using encrypt-than-MAC or an authenticated cipher unless you have very good reasons not to. No blanket statements can be made though. HMAC: HMAC is a often used construct. It ... 7 The other answer is correct in general. However, if your messages are all exactly one block long (or all one block after padding), ECB is a secure MAC. A PRP looks like a PRF up to half its bit length, i.e. up to$2^{64}$blocks for AES. A secure PRF is a secure MAC of the same size. Thus, AES ECB used on 128-bit messages is a secure MAC as long as you use ... 6 Using a MAC on the plaintext may potentially leak information about the plaintext (MAC algorithms do not necessarily ensure confidentiality of the data they are applied to, although some MAC algorithms like HMAC seem pretty safe). If you want to avoid this (theoretical) problem, then you should encrypt the MAC on the plaintext (i.e. MAC-then-encrypt, not ... 6 Although there are already many answers here, I wanted to strongly advocate AGAINST MAC-then-encrypt. I fully agree with Thomas' first half of the answer, but completely disagree with the second half. The ciphertext is the ENTIRE ciphertext (including IV etc.), and this is what must be MACed. This is granted. However, if you MAC-then-encrypt in the ... 5 We can attack the MAC defined by: MAC(k,m)=MD5(m||k), in a chosen-messages setup, basically because MD5's collision-resistance is broken. The adversary chooses m and m' of the same length$b\ge64$bytes, differing only in their first$\lfloor b/64\rfloor$64-byte blocks, such that there is a collision after hashing these blocks of m and m'. If follows that ... 5 First of all there does exist information theoretically secure message authentication codes suitable for use with a one time pad. An HMAC is not one of those information theoretically secure. As far as I recall the first article presenting such a construction is the 1981 article by Wegman and Carter: New hash functions and their use in authentication and ... 5 The pseudocode has a serious issue: changing the value of nonce2 in an otherwise valid cryptogram is not detected, and results in invalid deciphered plaintext. That would be fixed by encrypt(password, string): nonce1 := generate_random_nonce() nonce2 := generate_random_nonce() key := derive_key(nonce1, password) encrypted := nonce2 || cipher(nonce2, ... 4 As correctly pointed out in a comment, the authenticated encryption model assumes that the attacker knows the algorithm; the attacker can query the encryption oracle with any plaintext$P$(and a unique nonce$N$) and get MAC-then-Encrypt ciphertext$C$; the attacker can query the decryption oracle with any string$C$pretending to be a ciphertext. No ... 4 If key 2 and key 3 has a nonnegligible chance to be the same, then the attacker has a nonnegligible chance of being able to generate a valid (Message, MAC) pair. Here's how it works, if the message is not a multiple of 16, then XCBC pads the message out to the next multiple of 16; if it already is, the message remains the same. Then, XCBC logically does a ... 4 It has the disadvantages of any MAC-then-encrypt scheme, which I'm quoting from the linked answer below. In addition: It has the property that you need both a nonce and a hash, so for equivalent security it requires more message space. The nonce has to be random, so it requires strong random numbers for each message, unlike e.g. AES CTR + HMAC. Doesn't ... 4 My understanding of the term 'pepper' is that it more matches your definition 2, in that a pepper is an unknown salt, which makes it a cryptographic secret, but not a key. However, in use it is not as limited by either of your definitions: The pepper can be different (or random) for all users (like a salt). The pepper can be the same for all users (like a ... 4 Yes, this should be secure, as it is largely compatible with KDF1 and KDF2 which basically use a 4 byte big endian encoding of the counter instead of a direct ASCII conversion to a byte. Note that this construct works fine for master keys (short length, high entropy) but may be vulnerable to length extension attacks if larger input is allowed. However, if ... 4 What you think of is called an extension attack and it turns out that this is the way to go if you would like to break the general CBC-MAC when the message length is not fixed. All that an adversary needs to do is to mount a chosen message attack. Suppose he asks for the tag on the message$m=m_1||m_2||...||m_l$. The resulting CBC MAC would be ... 4 In summary: Yes, HMAC is the way to go for construction of a MAC from an arbitrary concrete iterated hash. We have no constructive argument of security of the MAC constructs in the question; we even have a concrete attack when using some otherwise apparently fine hashes. I consider a hash constructed by iterating a compression function$F$as ... 3 In general (without talking about MD5): Suppose our hashfunction$H$is a Merkle-Damgard construction using a Davies-Meyer compression function$h=(H_i,m)=E_{m_i}(H_{i-1})\oplus H_{i-1}$. Since the compression function is public, everybody is able to compute the input to the final round of the MD-Hash. In addition, if you know the input to the final round ... 3 An answer surfaced from careful reading of appropriate documentation. The MAC in the question is also defined in ANSI X9.19, and is supported by some PKCS#11 tokens as the mechanism CKM_DES3_X919_MAC_GENERAL. Other than that, this MAC can be simulated using CKM_DES_MAC_GENERAL (or CKM_DES_CBC or CKM_DES3_CBC) for all but the last block, then CKM_DES3_CBC; ... 3 If there exists an encryption scheme, then there exists an encryption schemes such that one can easily modify a single ciphertext so that whether or not that modifies the decryption result depends in a predictable-and-useful way on what the plaintext message was, such as: The modified encryption operation outputs a zero concatenated with the original ... 3 Well, 32 bits is somewhat short, so one could just try ciphertexts. However, there is a much better attack. Choose M0 arbitrarily, let P be the CBC padding for Headers || CRC || M0, and choose M1 so that CRC( M0 || P || M1 ) = CRC(M0). Submit M0 || P || M1 to be encrypted, truncate the ciphertext to the length of encryptions of M0, and then output the ... 3 GMAC is quite simply GCM mode where all data is supplied as AAD (or additional authenticated data), or as NIST SP 800-38D puts it: If the GCM input is restricted to data that is not to be encrypted, the resulting specialization of GCM, called GMAC, is simply an authentication mode on the input data. If you don't have access to a cryptographic provider ... 3 Here are some advantages and disadvantages for each of the three classes of MACs, which I know about: Based on block cipher There are constructions where the security of the MAC is proven in terms of the security definition of a block cipher. This means as long as the block cipher is secure, the MAC will be secure. There are constructions where encryption ... 3 It is certainly wrong to state that "MAC can only be produced with AES in CBC and CFB mode", but there seems to be a simple reason that people were inspired by these modes when thinking up possible MAC constructions: They carry along some state that incorporates information from the message while traversing the input blocks. In both modes, encrypting a block ... 3$Tag = MAC_k(\Sigma_i m_i)$. Too many attacks to enumerate. As long as the sum over the blocks remains the same, the tag remains valid. If the sum is reduced modulo$2^{\mathrm{blocksize}}$at the end, the attacker can choose the whole message, apart from a single block used to balance the sum.$t_i = MAC_k(m_i)$and$Tag = (t_1, ..., t_l)$. ... 3 The MAC is NOT redundant. As alluded to by Paŭlo Ebermann's comment, the word authentication has a different meaning in the two scenarios you mentioned. In the key exchange phase of SSH, the purpose of authentication is to ensure to both parties that they are indeed talking to the right peer (if using mutual authentication). Typically, the server ... 3 A normal security notion for MAC's is that of unforgeability. So given some set of message,tag pairs$(m_0,t_0),\ldots,(m_k,t_k)$is should be hard to create a tag for a new message not among the$\{m_0,\ldots,m_k\}$, stated informally. In your case, you could just use$E_k(m_0)$with the secret MAC key$k$($H_0\$ in your notation); no need for the extra ...

3

First, terms: A MAC is a generic term for a class of cryptographic primitives. It's in the same category as "hash" or "PRNG." HMAC is a particular construction that, combined with a suitable cryptographic hash, gives a secure MAC function (it can also be used to generically refer to any HMAC algorithm, since HMAC is secure with pretty much any standard hash, ...

3

I'm going to agree with @fgrieu's marvelous post above in a back-handed way. My answer is: No, you don't have to use an HMAC. Do it anyway. As you noted, some hashes, sush as SHA-3 (especially in its Keccak form), Skein (which I was a team member on), and others will work just fine. In the case of Skein, there is a one-pass Skein-MAC that has a proof of ...

3

I would propose a rather different scheme. encrypt(password, string): nonce := generate_random_nonce() secret := pbkdf(nonce, password) mackey := kbkdf(secret, 'mackey') enckey := kbkdf(secret, 'enckey') iv := kbkdf(secret, 'iv') encrypted := cipher(iv, enckey, string) return (nonce || encrypted || mac(mackey, encrypted)) Note that I've ...

2

Actually the HMAC value is not decrypted at all. The recipient takes all the needed input and she computes the HMAC on her own side and check if the result she got it is equal to the value on the message she got. You can roughly see the HMAC algorithm as an symmetric key signature. You cannot decrypt an HMAC, you only check that the value is correct.

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