# Tag Info

## Hot answers tagged hmac

28

As Chris Smith notes in the comments, HMAC is a specific MAC algorithm (or, rather, a method for constructing a MAC algorithm out of a cryptographic hash function). Thus, HMAC can be used for any application that requires a MAC algorithm. One possible reason for requiring HMAC specifically, as opposed to just a generic MAC algorithm, is that the HMAC ...

25

Would you use HMAC-SHA1 or HMAC-SHA256 for message authentication? Yes. That is a semi-serious answer; both are very good choices, assuming, of course, that a Message Authentication Code is the appropriate solution (that is, both sides share a secret key), and you don't need extreme speed. How much HMAC-SHA256 is slower than HMAC-SHA1? Those sorts ...

23

A Message Authentication Code (MAC) is a string of bits that is sent alongside a message. The MAC depends on the message itself and a secret key. No one should be able to compute a MAC without knowing the key. This allows two people who share a secret key to send messages to each without fear that someone else will tamper with the messages. (At least, if ...

22

This is something I tend to disagree somewhat with Colin Percival on. You should use Encrypt-then-HMAC if and only if you can get it right. The biggest pitfall is using a short-circuiting string comparison versus a constant-time string comparison. Given the former, people can use timing attacks to forge valid HMACs for arbitrary ciphertexts. With an ...

20

Those "magic numbers" are related to the security proof behind the HMAC construction. In their Crypto'96 paper, Bellare, Canetti and Krawczyk first prove that $\mathrm{NMAC}_{(k_1, k_2)}(x) = F_{k_2}(F_{k_1}(x))$ forms a secure MAC ("message authentication code") provided $F_k(\cdot)$ is an iterated and keyed compression function enjoying some good ...

20

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

19

Brute forcing the key would hardly be an issue: 128-bit keys (assuming they have been properly generated) are in a space which is way too large to be successfully explored by brute force; and 256-bit keys (the kind you put in AES-256) are even more larger. Whether AES is "faster" than HMAC or not does not make such brute force more feasible: even if each key ...

18

Yes, there are currently no known attacks on HMAC-MD5. In particular, after the first collision attacks on MD5, Mihir Bellare (one of the inventors of HMAC) came up with a new security proof for HMAC that doesn't require collision resistance: "Abstract: HMAC was proved by Bellare, Canetti and Krawczyk (1996) to be a PRF assuming that (1) the underlying ...

18

In short: You must authenticate the IV. Which particular attacks apply if you don't depends on the block cipher mode; I will give two common examples. In CTR mode, an attacker who fiddles with the IV can forge authenticated messages, but the content of the corresponding plaintext is beyond his control (since he doesn't know the key). Depending on the ...

17

You're missing the most important strength of HMAC: it comes with a proof of security (under some plausible assumptions). The outer key plays an important role in the proofs. The best place to learn more is to read the HMAC papers: Message authentication using hash functions: The HMAC construction, Mihir Bellare, Ran Canetti, Hugo Kawczyk, CryptoBytes ...

17

Actually, HMAC might still be secure for a hash function that is broken (with respect to the requirements of a cryptographic hash function, such as primary preimage resistance, secondary preimage resistance and collision resistance), but it must not be too badly broken. If you read the original paper, you see that the authors assume things such as the hash ...

16

The short answer is: $2^{128}$ operations, no known birthday-like attack. The long answer: when HMAC was first published, it came with a security proof, tailored for iterated constructions like Merkle-Damgård. In a MD hash function (MD4, MD5 and the whole SHA family are MD hash functions), the data to hash is processed by blocks with a compression function: ...

15

HMAC remains unbroken with MD5 and SHA1 because it has a secret key that the attacker doesn't know. Therefore, the attacker cannot carry out huge computations on itself (as is required for finding collisions). [A parenthetic comment: please do not misunderstand me; MD5 is completely broken and should not be used anywhere including in HMAC.] In contrast, when ...

13

The original security proof of HMAC, as well as a new one not requiring collision-resistance of hash, are for the construction hash(o_key_pad ∥ hash(i_key_pad ∥ message)) with o_key_pad different from i_key_pad (and both filling a block). That's the rationale for at least one of the constant. The other plays no role, it just must be different from the first. ...

13

It is well defined. The hash function has no impact on whether HMAC is defined for a null string text argument. As long as HMAC is defined for a particular hash function, the resulting HMAC of a null string text argument should also be well defined. The definition of HMAC according to FIPS 190-1 is: $HMAC(K, text) = H((K_0 \oplus opad)|| H((K_0 \oplus ... 12 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 ... 10 TL;DR, an HMAC is a keyed hash of data. A good cryptographic hash function provides one important property: collision resistance. It should be impractical to find two messages that result in the same digest. An HMAC also provides collision resistance. But it also provides unforgeability. In order to generate an HMAC, one requires a key. If you only share ... 10 Is the calculated MAC encrypted using AES? What is the purpose? How about signing and verifying? How does AEs Play a role here? Is the case here that the encrypted AES is HMACed for signing and the HMAC is verified No, the MAC is not encrypted per se, however, it is calculated in conjunction with a key (independent of the encryption key). Simply ... 10 Yes, this would be secure. CTR (Counter) mode based on keyed function$F_K$is secure as long as its output $$W_i = F_K(i)$$ is unpredictable given previous outputs $$F_K(1),F_K(2),\ldots,F_K(i-1).$$ This requirement is essentially the definition of a pseudo-random function (PRF). Most HMAC instantiations with widely used hash functions are believed to ... 10 I would use HMAC-SHA256. While poncho's answer that both are secure is reasonable, there are several reasons I would prefer to use SHA-256 as the hash: Attacks only get better. SHA-1 collision resistance is already broken, so it's not impossible that other attacks will also be possible in the future. It allows you to depend on just one hash function, ... 10 The Keccak submission says: From the security claim in [12], a PRF constructed using HMAC shall resist a distinguishing attack that requires much fewer than$2^{c/2}$queries and significantly less computation than a pre-image attack. Here,$c$denotes the capacity of the sponge, i.e. the effective size of the internal state in bits. Since HMAC is a ... 10 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 prepend ... 9 I really don't have an answer (other than saying that storing a hash of the password is good as any other way of solving your immediate problem; there are other ways, but they all allow an attacker to run a dictionary attack on the database). On the other hand, I do have these comments on what you're doing: If getting decrypted gibberish will really crash ... 9 No, you are not leaking any information except how to MAC those specific values with the specific key you are using. Using a short message is exactly as secure as using a long message. For the following, remember the definition HMAC (K,m) = H((K ⊕ opad) || H((K ⊕ ipad) || m)). There are two hashes here, an outer hash and an inner hash nested inside the ... 9 What if text would replaced with H(text)? Will it weaken the HMAC algorithm? Yes. It makes collision attacks on the hash function apply to the MAC, which isn't normally the case with HMAC. You can find a pair$(m, m')$that hash to the same value, get the MAC for one of them and move it to the other. That means that your modified HMAC construction would ... 8 HMAC is much faster to compute. Also, HMAC might still be secure, even if the underlying hash function is broken. This is not true for RSA + a broken hash function. 8 GCM mode is best, as it can not be attacked using padding oracle attacks, which are much more common than commonly thought. It is also the only one providing integrity protection, something that is certainly much overlooked. Make really sure your NONCE is random though, or use one that is uniquely defined (even in time) within the database. ... 8 Clearly, if you had been using AES-256-CBC for confidentiality and AES-256-CBC-MAC for authentication, it would not be secure to use the same key for both confidentiality and authentication. Hence, using the same key for confidentiality and authentication cannot generally be secure; you need additional premises to arrive at that conclusion. In your case it ... 8 From a security standpoint, HMAC-SHA256 is exceptionally secure, so the move is unlikely to relate much to cryptographic security unless they were using the construction incorrectly, which is improbable. I freely admit that I know almost nothing about Salesforce, but I can guess at the rationale behind the decision: since HMAC is a symmetric primitive, both ... 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 ...

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