66
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 ...
44
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 ...
38
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 ...
33
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 ...
32
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 ...
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 ...
30
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 ...
29
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 ...
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
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 ...
25
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 ...
24
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 ...
22
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 ...
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
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
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-SHA-256. The full security of HMAC is basically identical to the output size. Unless you are trying to protect yourself against quantum computers you should be able to get away with a key that contains 128 bits ...
19
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 ...
18
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 ...
17
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 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 ...
16
To add to poncho's answer (since they beat me to it!), there are several advantages to choosing HMAC over ECDSA (or RSA) if you can get away with it:
Insanely better performance: signing and verifying is much faster
Much simpler implementation: this is important for security (even if you're not the one doing the implementation), since more complexity leads ...
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
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
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 ...
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 ...
13
A PRF or pseudorandom function family is a family of functions $F_k\colon \{0,1\}^n \to \{0,1\}^m$ such that if $k$ is uniformly distributed, then $F_k$ appears to be uniformly distributed among all functions $G\colon \{0,1\}^n \to \{0,1\}^m$. A PRF $F_k$ is secure if an adversary who does not know the key $k$ can't distinguish $F_k$ from a uniform random ...
answered Aug 15 '17 at 15:36
Squeamish Ossifrage
42.5k3 gold badges83 silver badges175 bronze badges
12
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 ...
12
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 ipad) |...
Only top voted, non community-wiki answers of a minimum length are eligible
