58
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 ...
41
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 ...
38
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 ...
33
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 of ...
32
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 ...
30
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 ...
28
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 ...
28
The distinction is that ECDSA solves a problem that HMAC does not. If you need that problem solved, then you need to do ECDSA rather than HMAC; if you do not, then HMAC works just as well (and is a lot cheaper).
With HMAC, here is what we have: we have an authenticator that has a secret key. It takes a message, and gives that (and the secret key) to the ...
27
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 ...
26
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 ...
26
Short answer: 32 bytes of full-entropy key is enough.
Assuming full-entropy key (that is, each bit of key is chosen independently of the others by an equivalent of fair coin toss), the security of HMAC-SHA-256 against brute force key search is defined by the key size up to 64 bytes (512 bits) of key, then abruptly drops to 32 bytes (256 bits) for larger ...
25
In the first section of this answer I'll assume that through better hardware or/and algorithmic improvements, it has become routinely feasible to exhibit a collision for SHA-1 by a method similar to that of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu's attack, or Marc Stevens's attack. This has been achieved publicly in early 2017, and had been clearly ...
24
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 ...
22
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 ...
21
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 ...
21
Length extension attack
The reason why $H(k \mathbin\| 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 \mathbin\| m \mathbin\| m^\prime)$ knowing only $H(k \mathbin\| m)$ but not $k$. This violates the security ...
21
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 ...
20
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, which ...
19
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 ...
17
Put simply, if you're using a simple hash of a file to guarantee file-integrity, then an attacker could modify the file, re-calculate the hash of the modified file, and replace the old hash with the modified one. With a HMAC, a key is used when calculating the hash value, so unless the attacker has the key, they're unable to calculate a valid hash value of ...
16
Alas, there is no simple satisfactory answer to this question. What I can offer is a very strong property that $m \mapsto H\bigl(k \mathbin\| H(k \mathbin\| m)\bigr)$ fails to achieve; a more pedestrian property which even HMAC may or may not achieve but is typically asked to achieve; a reason not to worry about it for any new systems; and some historical ...
16
When people say HMAC-MD5 or HMAC-SHA1 are still secure, they mean that they're still secure as PRF and MAC.
The key assumption here is that the key is unknown to the attacker.
$$\mathrm{HMAC} = \mathrm{hash}(k_2 | \mathrm{hash}(k_1 | m)) $$
Potential attack 1: Find a universal collision, that's valid for many keys:
Using HMAC the message doesn't get ...
16
The only rule for the key is that it should at least contain 256 bits of randomness. If the key is smaller you may not get the full security of HMAC.
Preferably this should be condensed into 32 bytes. What you are talking about is probably the hexadecimal representation of those 32 bytes. If the key is too large it may affect performance and efficiency of ...
16
Authentication and probabilistic encryption are two desirable features which each take up a small amount of extra space. And you are absolutely right that the percentage of space consumed is of no concern in most scenarios.
But as the other answers also point out that means you can no longer fit a logical sector inside a physical sector of the same size. ...
15
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 ...
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 ...
14
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. ...
14
The construction you are proposing is called the "envelope" or "sandwich" MAC, it predates HMAC, and it is in fact secure—provided the key and message are appropriately padded. That is,
$$
\text{SHA256}(k \parallel m \parallel 1 \parallel 0^{b - 1 - (|m| \bmod b)} \parallel k)
$$
is secure, as long as $k$ is the underlying hash function's block length $b$ (...
14
So, are there reasons for not using authentication that I'm missing?
I believe that the real reason is not actually space, but time.
As you said, storing the tags would not require that much space. However, the tags need to be stored somewhere, and whenever you read the sector, you also need to read the sector containing the tags as well. So, unless you ...
13
Given some string s I want to [integrity protect], are following methods are equivalent to produce message with signature, assuming it does not matter whether s is visible in message or not?
Absolutely not; with AES_CBC, if the attacker modifies one particular block of the ciphertext, then the decryption of the modified ciphertext will have two blocks ...
Only top voted, non community-wiki answers of a minimum length are eligible
