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 ... 10 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, ... 10 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 ... 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 would ... 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 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 the ... 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 via ... 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 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 HMAC does not provide an obvious security improvement over the KMAC construction, which is optimal for Keccak based functions. HMAC is designed to create a secret initialization vector or IV for Merkle-Damgård type hash functions, KMAC does the same for sponge based hash functions but much more efficiently. HMAC also needs to deal with the length extension ... 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 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 "... 4 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 ... 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 ... 4 Should be comparable in strength to$H(m||k)$. The weakness is that a collision in the inner hash breaks the MAC. Using strong hashes the strength in bits is$\min(2^{n_O},2^{{n_I}/2})$where$n_O$is the output size of the outer hash and$n_I$the output size of the inner hash. But since cryptoanalysis usually breaks collision resistance long before it ... 4 As I have a new hash every 3 second, it's easy for everyone to collect a big numbers of hash. And as the difference between every UUID is always 3000 ms, maybe this could make it easier for the hacker to crack the key. You might be reassured to read up on the security requirements that MACs are designed for. Chapter 9 of the Handbook of Applied ... 4 I think the attack by Preneel and van Oorschot (MDx-MAC and Building Fast MACs from Hash Functions, CRYPTO'95) in Proposition 4 applies. It was cited by PulpSpy in reply to my question about H(pass||length(data)||data). With fixed-length data, that amounts to a known suffix for the key. Proposition 4 states in a nutshell that for a generic construction ... 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 Correctly implemented, it should be secure deterministic authenticated encryption. In fact, it is SIV, in the wider sense of using the "SIV construction" as defined in Deterministic Authenticated-Encryption by Rogaway and Shrimpton (except for lacking a header input). The proof of the security of the SIV construction is that: We will now show that if$F$... 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 There is work underway to specify KMAC. It's basically just SHA-3, but with a length specification for the key and a special value to indicate that this is KMAC instead of hashing. These constructions are required to make sure that there are no unfortunate collisions with previously hashed data or - more importantly - key / message pairs where$H(K_1,M_1) = ...