# Tag Info

16

Length extension attack The reason why $H(k || 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 || m || m^\prime)$ knowing only $H(k || m)$ but not $k$. This violates the security requirements of a MAC. Like all ...

11

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

10

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

8

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

8

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

8

It looks like, given your adversary model, things should be secure. HMAC as a randomness extractor has been shown to be good, especially when we can assume the hash function is collision resistant. That paper also has some results which tell how you could guard against the collision resistance being broken (basically use a hash function with larger output ...

7

Comparing a brute force attack on DES (with $2^{56}$ operations) to a birthday attack on CMAC (with $2^{64}$ operations) would appear to be an apples-to-Volkswagen comparison; they are assuming two things are similar, when they really aren't. The brute force attack on DES involves obtaining a single plaintext/ciphertext block pair, and then going through ...

5

As shown in the paper Ricky Demer linked in the comments, HMAC can be secure even when the underlying hash function is not collision resistant. Only PRF-ness of the hash function is required, and SHA-1 is not known to lack it. Or a couple of other conditions can suffice even if it isn't a PRF. Intuitively, it makes sense that HMAC is secure as a MAC even ...

5

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

5

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

5

Under the assumption that $(K,\text{Msg})\to H_K(\text{Msg})$ is a secure MAC (be it HMAC or any other MAC), and $\text{Nonce}$ does not repeat and is of fixed size, both $H_K(\text{Msg}||\text{Nonce})$ and $H_K(\text{Nonce}||\text{Msg})$ are demonstrably secure, in the sense that an adversary not knowing $K$ can't distinguish either from random, even for ...

5

First of all there does exist information theoretically secure message authentication codes suitable for use with a one time pad. An HMAC is not one of those information theoretically secure. As far as I recall the first article presenting such a construction is the 1981 article by Wegman and Carter: New hash functions and their use in authentication and ...

4

As pointed in the question, with common Merkle–Damgård hashes like SHA-256, $H(key\ \Vert\ message)$ is vulnerable to a length extension attack, where $H(key\ \Vert\ message\ \Vert\ pad\ \Vert\ extension)$ can be computed knowing $H(key\ \Vert\ message)$ and the length of $key\ \Vert\ message$ (with $pad$ trivially determined from that), for any known ...

4

A key derivation function lets you derive keys from others. In this case I would use HKDF, which means using HMAC in a predefined way. Your key material is the keys $X$ and $Y$, so you can concatenate those to get the PRK for HKDF-Expand. An output key would then be $\operatorname{HMAC}(X||Y, \text{info} || \text{0x01})$, if the size of the HMAC is long ...

4

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-than-encrypt or MAC-and-encrypt, using single key). Cipher-text length is the same for same ...

4

HMAC and NMAC make assumptions of the underlying hash function $H$ for their security proofs. Additionally they are designed to eliminate known flaws in other MAC constructions using MD type hashes. NMAC is not $H(k1$ $||$ $H(k2$ $||$ $m))$, it actually uses the keys as the initial hash values, which require a higher level of access to the internals of the ...

3

To attack a MAC in general, the attacker needs to find a valid MAC of a message that they do not have the MAC for (or find a message collision that allows a different message to have the same MAC digest). In this case, the attacker would be appending data to the original message, not the MAC itself, and trying to obtain a valid MAC for the new message. In ...

3

The generator in the question internally transforms the $512$-bit string designated tag into an output determined either: as $1/10^4$ of a non-negative integer less than $10^6$, whenever the "If the result is smaller.." clause applies; as $1/10^2$ of a non-negative integer less than $2^{12}$, otherwise. Determination process 2 occurs for ...

3

HMAC-SHA-256 is sufficient for up to 256 bit security. Confer e.g. NIST SP 800-107. This recommendation is based on the premise that collision attacks are infeasible against common uses of HMAC, and that you consequently only have to worry about primary pre-image attacks that attempt to recover the secret key (and use this for forging subsequent messages). ...

3

My question is: does it add any security to add a random salt to the message you are validating with HMAC? This depends on what the HMAC is used for. If you use a key to sign more than one secret message, a salt will prevent an attacker from knowing whether two of them are equal. (Or brute forcing a message if the key is revealed...) It is more common ...

3

This is vulnerable to a length extension attack. Given a valid nonce/MAC, the nonce can be extended to forge a new valid nonce/MAC value. This is because $m_4$ is appended to the end inside the outer hash. How this affects you will depend on how you validate your nonce. But in general, this is not a secure construction. There's probably more things wrong ...

3

AES CBC usually requires padding, such as PKCS#7 padding. This padding is 1 to 16 bytes, 16 being the block size of AES. The HMAC will add 256 / 8 = 32 bytes to the total. Usually you will need to store the randomized IV as well with ciphertext, to allow for reuse of the key, adding another 16 bytes (the block size again). So the total overhead will be about ...

3

Rejecting replays is the duty of a higher level protocol. Simple authenticated encryption will accept any message with a valid MAC, even if you receive it several times. Decryption is a stateless process, but you need state to keep track of messages you already received. For example you could associate an increasing counter for each message you send. The ...

2

Unsurprisingly, any secure MACs are a secure choice. Assessing their relative security beyond how many bits of security they offer isn't possible in general. However, there are some differences that don't depend on the protocol: Unmodified CBC-MAC is only secure for fixed length messages, otherwise it allows some forgeries. Block cipher based MACs allow ...

2

Here are some advantages and disadvantages for each of the three classes of MACs, which I know about: Based on block cipher There are constructions where the security of the MAC is proven in terms of the security definition of a block cipher. This means as long as the block cipher is secure, the MAC will be secure. There are constructions where encryption ...

2

Exhaustive computation over the range of possible 20-bit values less than 1000000 shows that exactly half of them are >= 50 when divided by 10,000. So the output of this PRNG, assuming HMAC512 produces independent, uniform bits, is evenly distributed on [0,100), all assuming the last case (using the upper 3 hex digits) is not used. That being the case, ...

2

So I was finally able to work this out. The pin code isn't important and is simply used to decrypt the activation code locally (not sure why our server asks for it in that case). The activation code is a base32 encoding of a seed where every fifth character acts as a checksum for the previous four. The seed is then passed through KDF1 to generate the ...

2

As long as the key is secret, your list of MACs is safe and the numbers are not guessable. You probably can truncate your MACs to 80 bits in order to save space, as collisions are highly unlikely for $2^{23}$ entries or so. If your numbers do not repeat and fit into 128 bits, the simple Electronic Codebook (ECB) mode with AES should also do a good job, ...

2

We think that the player will not be able to get this key by extracting it from the memory or somehow else. Forgive me, but I'm skeptical. If you really have figured out a way to do this --- and plenty of well-funded, intelligent people have tried and failed --- I'd recommend slapping a patent on it and making millions off of licensing fees. How ...

2

Does allowing users to test VALUEs increase the likelihood that SECRET will be broken or illegal hashed values generated, relative to the CONTROL scenario? By definition a cryptographic Message Authentication Code such as HMAC is secure only if resists existential forgery under chosen-plaintext attacks. i.e. if allowing users to test VALUEs increases ...

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