Tag Info

17

Length extension attack The reason why $H(k || m)$ is insecure with most older hashes is that they use the Merkle–Damgård construction which suffers from length extensions. When length extensions are available it's possible to compute $H(k || m || m^\prime)$ knowing only $H(k || m)$ but not $k$. This violates the security requirements of a MAC. Like all ...

15

$Encrypt(m|H(m))$ is not an operating mode providing authentication; forgeries are possible in some very real scenarios. Depending on the encryption used, that can be assuming only known plaintext. Here is a simple example with $Encrypt$ a stream cipher, including any block cipher in CTR or OFB mode. Mallory wants to sign some message $m$ of his choice. ...

11

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 ...

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. ... 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 The attack outlined by Drlecter is valid for any deterministic MACs (that is: with the MAC a function of message and key) with an iterated structure and an$n$-bit state. It relies on internal state collisions, expected to occur after about$2^{n/2}$messages (the birthday bound), that can allow forgery once discovered. I'll illustrate this in the case of ... 5 One simple cryptographically secure rolling hash function is the following: $$F_{k1,k2}(x) = E_{k1}(R_{k2}(x))$$ where$R_{k2}(\cdot)$is a non-cryptographic rolling hash function (e.g., Rabin-Karp), and$E_{k1}$represents encryption with a block cipher (e.g., AES). By$R_{k2}(\cdot)$, I mean that the parameters of the rolling hash should be derived from ... 5 There are various factors that go into choosing a MAC algorithm, for example: Use cases for CMAC vs. HMAC? documents CMAC vs. HMAC; I think HMAC is a reasonable default choice though (supported by Colin Percival: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html). Yes, the MAC can be transmitted alongside the ciphertext, one thing ... 5 Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC? No, you don't need to do that, but you can. Needless to say we'd still use a key, which we prepend or append to the message, but is that sufficient for a MAC? Yes, you can ... 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 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 ... 4 HMAC and NMAC make assumptions of the underlying hash function$H$for their security proofs. Additionally they are designed to eliminate known flaws in other MAC constructions using MD type hashes. NMAC is not$H(k1||H(k2||m))$, it actually uses the keys as the initial hash values, which require a higher level of access to the internals of the ... 4 Moxie Marlinspike calls it in his article http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ the doom principle: if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom. He also demonstrates two attacks which are possible because of trying to ... 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 There are no specific requirements for the choice of cipher and MAC in the Encrypt-then-MAC construction, except that both should individually achieve their respective security goals (typically semantic security and existential unforgeability). Indeed, this is the major advantage of Encrypt-then-MAC over other constructions like MAC-then-Encrypt or ... 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 Two things going on that together may make plain-hash-then-encrypt insecure. First, the distinction between secure MACs and hashes, which is that a hash function may allow you to derive$H(m')$from$H(m)$even if you only know how$m'$and$m$differ. Length extension attacks on SHA-1 and SHA-2 are a practical way that can happen, but there could be others ... 4 What Stephen says in the comment is correct. It is safe to not use authenticated encryption whenever your adversary model assumes that the attacker does not have the ability to manipulate ciphertexts. I assumed hard drive volume encryption or per file encryption that is not transmitted over an insecure network should be considered safe to do without a ... 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 ...

3

The biggest issue with padding oracle attacks are when the padding is not very carefully implemented (for example if using EtM you must calculate the MAC over everything - including the padding). To pre-empt references to the classic Belare-Namprempre paper, be wary - their results do not apply to modern primitives, since nowadays we prove security ...

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

Okay. So first up, let's eliminate encrypt-then-sign. Why is this a problem? The idea behind a signature is to prove that a message came from me even in the presence of malicious actors. If a malicious actor changes the ciphertext under the signature, clearly this invalidates the signature as per expectations, however, that is only one possible attack ...

3

Memory of the first round can't help the attacker win the second round. If it could: the attacker could simulate the first round on his own (picking his own key, pretending to play the game against himself), and then play the second round against the challenger. So, adversaries like this are not stronger -- not even if they have memory.

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

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 ...

3

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 ...

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