40
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 ...
36
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 ...
34
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 ...
30
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
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 ...
27
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 ...
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
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 ...
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 ...
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 ...
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 ...
18
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 ...
18
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 ...
17
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. ...
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 ...
15
Password hashes need first pre-image resistance and should not cause many collisions among typical passwords (preserve the entropy). This collision "attack" violates neither requirement and causes no practical security issues.
While this issue can find trivial collisions, they're not between commonly chosen passwords. A SHA-1 hash (and thus the shorter of ...
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 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
With 4096-byte sectors, space is a complete non-issue, less than 1 %
Problem 1: 10GB per TB is not a "complete non-issue" for many people.
Problem 2:
If the checksums are inside of their data blocks, there is a huge compatibility problem. The data per block is less than 512/4096, but many (really many) programs and kernel parts of pretty much all ...
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
44.3k3 gold badges94 silver badges192 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
AES-GCM uses single block cipher operation and can be processed in parallel, therefore it should be faster.
CTR+HMAC requires block cipher and hash function, which usually can't be processed in parallel. Also it requires 2 keys. It is often miss-implemented (MAC-then-encrypt or MAC-and-encrypt, using single key).
Cipher-text length is the same for same ...
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) |...
12
Both algorithms provide plenty of security, near the output size of the hash. So even though HMAC-512 will be stronger, the difference is inconsequential. If this ever breaks it is because the algorithm itself is broken and as both hash algorithms are related, it is likely that both would be in trouble. However, no such attack is known and the HMAC construct ...
12
You can find a collision in MD5 at much lower cost than $2^{64}$ evaluations of MD5. You could do the same for HMAC-MD5, if you knew the key, which renders it unfit for unusual applications such as commitments.
But the standard security conjecture of HMAC-MD5 is that it is a pseudorandom function family, which assumes the adversary doesn't know the key. ...
answered May 21 '18 at 14:03
Squeamish Ossifrage
44.3k3 gold badges94 silver badges192 bronze badges
12
I don't think there is any official limitations when it comes from standardization bodies such as NIST. However, there do seem to be some papers such as New Generic Attacks Against Hash-based MACs.
They show that HMAC may have less security than previously thought after the birthday bound. Generally, if you have a hash output size of, say 256 bits for SHA-...
11
Decoding AES256-CTS-HMAC-SHA1-96
AES256 = AES using 256-bit key
CTS = ciphertext stealing
HMAC-SHA1-96 = HMAC using SHA-1 hash function with mac truncated to 96 bits.
The benefits of HMAC truncation are discussed in FIPS PUB 198-1, chapter 5.
For HMAC-SHA1 96 bits is very common truncation, used for instance by IPsec/ESP.
For figuring out what key ...
Only top voted, non community-wiki answers of a minimum length are eligible