# Tag Info

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 ... 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 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 ... 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 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 ... 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 How are these keys agreed upon/distributed? Practically speaking is asymmetric crypto a requirement to "bootstrap" and distribute keys? The answers to those questions are beyond the scope of the RFC. So, it depends on the context in which HMAC is being used. The keys can be agreed upon/distributed in any secure manner. The RFC doesn't care. It could be ... 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 thatH$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), ... 5 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 ... 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 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 ... 5 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 general, use a cryptographic MAC to protect your ciphertext, and verify it first. Emit those errors. Then padding errors should not occur at all. The "in general" seems to have been used to show that commonly is performed or should be performed. I don't think it had anything to do with the security of the scheme itself. PKCS#7 compatible padding can ... 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 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 ... 4 The data input to HMAC (which is passed directly to the underlying hash function, after prepending the padded and masked key to it) is an arbitrary string of bytes. In particular, the zero-length string is a perfectly valid input. Of course, if you're using a wrapper around HMAC that encodes some kind of structured data into a byte string before passing it ... 4 I'll answer in order: 1) No, you may not be doing something wrong. This is just the compiler warming up and performing optimizations. The second run you see that AES-128 is already about as fast, which is what you would expect (it should be ever so slightly faster in the end, but that might not even be noticeable). 2) Don't know, you'd have to debug, ... 4 Is is feasible to alter b and produce a valid MAC under the unknown key? We most certainly hope not. The fundamental security property of a MAC is that, even if that attacker can get a huge number of valid (Message, MAC) pairs (where he gets to choose the messages), he still is unable to generate a MAC for a message he has not seen. This fundamental ... 4 See NIST SP 800-107, section 5.3.4: The effective security strength of the HMAC key is the minimum of the security strength of$K$and the value of$2C$. That is, security strength = min(security strength of$K$,$2C$). For example, if the security strength of$K$is 128 bits, and SHA-1 is used, then the effective security strength of the HMAC key is 128 ... 4 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 ... 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 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'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 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 ...