Hot answers tagged

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


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


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


8

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


8

They don't, and in fact the sponge construction used in Keccak (SHA-3) allows for variable length output. In other hashes the Merkle-Damgård construction was used which has a fixed output length due to the nature of its design. But there is no reason to not allow for variable output length other than ease of development or use.


8

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


7

Summary: a single HMAC-MD5 with a key later revealed is a completely insecure way to do commitments of messages that can be chosen malignantly, because of the ease with which MD5 collisions can now be found. There is no compelling evidence that's so insecure for messages constrained to belong in a small arbitrary set that no adversary can choose or ...


7

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


6

A SHA-256 implementation usable on several blocks can be turned it into an HMAC-SHA-256 implementation usable on several blocks, as follows: If the key is larger than 64 bytes, replace it by its 32-byte SHA-256 hash; now the key is at most 64-byte long. Start a SHA-256 hash. Set a 64-bytes buffer to all 0x36; XOR the key into that buffer (leaving unchanged ...


6

NMAC is really just an "education tool" on the way to HMAC and I don't think anyone intended it to be used. The two keys are needed since the first and second hashes have different purposes. The first hash on the message is just needed to get collision resistance, whereas the second hash is supposed to provide a pseudorandom function type property. As such, ...


6

Will it weaken the HMAC algorithm? No, assuming that $H$ is a collision resistant hash function (which is a stronger constraint than what HMAC puts on the hash function). The security property that a MAC (such as HMAC) has is that "given a large set of $message, tag=HMAC(K, message)$ pairs (where $K$ is an unknown key), where the attacker can choose ...


6

The scheme you describe is essentially same as the "SIV construction"* introduced by Rogaway and Shrimpton in their 2007 paper "Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem". This construction takes a PRF (such as HMAC) and a conventional IV-based encryption scheme (such as, say, a block cipher in CTR mode), ...


6

Yes, but doing so wouldn't be any more collision-resistant than just settling on some new IV. (HMAC is only supposed to be a PRF. ​ Collision-resistance is significantly harder to achieve.)


5

In summary: Yes, HMAC is the way to go for construction of a MAC from an arbitrary concrete iterated hash. We have no constructive argument of security of the MAC constructs in the question; we even have a concrete attack when using some otherwise apparently fine hashes. I consider a hash constructed by iterating a compression function $F$ as ...


5

In the first section of this answer I'll assume that through better hardware or 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. Neither has ever been achieved publicly, but it is clearly feasible (the ...


5

What you're describing is pretty similar to the SIV block cipher mode. It also uses a deterministic function of the message to derive the nonce for CTR encryption. Under some pretty widely accepted assumptions about HMAC-SHA256 this is a perfectly fine way of achieving deterministic authenticated encryption. It doesn't meet IND-CPA (as you pointed out) but ...


4

The Encrypt then MAC is done in general in order to be sure to decrypt into the correct plaintext, without risking of parsing a non-authentic plaintext message. If you don't MAC the IV, then Mallory (attacker that can tamper with messages as a man-in-the-middle) can modify the IV and your MAC will be still validated as good. So you will decrypt into an ...


4

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


4

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


4

No, you should not use a password directly as an HMAC key. However, it is fine to use HMAC as part of a key derivation function, which generates keys from a password. However, do not mistake the output as naturally having higher entropy than whatever you put in. "password" has essentially 0-bits of entropy, and running it through a KDF will not magically ...


3

First, terms: A MAC is a generic term for a class of cryptographic primitives. It's in the same category as "hash" or "PRNG." HMAC is a particular construction that, combined with a suitable cryptographic hash, gives a secure MAC function (it can also be used to generically refer to any HMAC algorithm, since HMAC is secure with pretty much any standard hash, ...


3

Will this successfully prevent a timing attack? Strictly speaking you should be checking if openssl_random_pseudo_bytes happens to be returning cryptographically strong numbers or not. If not, an attacker could guess be able to launch a timing attack practically as easily as without the extra HMAC. (Got to love PHP... Even the function name: random ...


3

I know SHAKE128 and 256 are part of the SHA-3 standard but is the SHA3 standard officially released yet? i can only find a draft of the publication, does this mean it's not official and therefor not proven to be secure? No, SHA-3 has not been formally approved. On the other hand, what do you mean "not proved to be secure"? Do you really thing that ...


3

If we assume that AES is a pseudorandom permutation (which is a standard model for block ciphers), then AES can replace the HMAC in your construction. Be aware, this only works because you have a fixed message length, i.e. the protocol must not accept nonces $> 128$bit. Besides, I guess you are aware of this but you have a shared secret key among all ...


3

I would just concatenate. Two 256-bit keys lead to a 512-bit key which is short enough for HMAC with common hash functions to use as is. XOR would allow the second party to easily choose a related key (and has worse behavior when neither key is perfectly random). Hashing and double HMAC use more resources without a clear benefit, unless you care about the ...


3

I'm going to agree with @fgrieu's marvelous post above in a back-handed way. My answer is: No, you don't have to use an HMAC. Do it anyway. As you noted, some hashes, sush as SHA-3 (especially in its Keccak form), Skein (which I was a team member on), and others will work just fine. In the case of Skein, there is a one-pass Skein-MAC that has a proof of ...


3

If you are asking if $M(M(M(k, C_1) C_2), s)$ has the same or better security as $M(k, C_1 | C_2 | s)$ then the answer is yes. You can see this as a double key derivation to calculate a new key from $k$ using the constants $C_1$ and $C_2$ as derivation data. Then the resulting key is used to MAC the final serialNumber. $M$ is of course HMAC, $C_1$ and $C_2$ ...


3

Q: Why do cryptographic hashes need to have a fixed length output? I know that the shallow answer is that an output that varies by key size or file size can leak information somehow, leading to cryptanalysis, but I would like some more intuition as to why this is the case. It depends on what you mean with that. If you mean that they need to have a ...


3

To me it seems like HMAC(salt, IKM) would be weaker against a brute force search of IKMs, as the digest of the salt can in this case be precalculated by an attacker (assuming the salt is a non-secret value or zero). Yes, it is slightly faster to brute force, but if the IKM does not have enough entropy to give brute force resistance, then a small factor ...


3

One solution is to use the choice of which equivalent message you send as a way to encode a MAC value. Take a "base message", where e.g. each word choice is the alphabetically first one. (Or some other known rule.) Calculate the MAC for that: MAC(key, message). The MAC should be $m$ bits or less. HMAC, possibly truncated would work fine. Encode that MAC ...



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