# Tag Info

## Hot answers tagged hmac

17

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

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

6

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

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

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

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

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

4

Actually you are quite near on implementing PBKDF2. It is kind of iterated HMAC execution. So have a look here and just implement the missing parts: PBKDF2

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

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

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

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

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

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

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

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

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

3

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

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

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

Actually the HMAC value is not decrypted at all. The recipient takes all the needed input and she computes the HMAC on her own side and check if the result she got it is equal to the value on the message she got. You can roughly see the HMAC algorithm as an symmetric key signature. You cannot decrypt an HMAC, you only check that the value is correct.

2

PBKDF2 is defined for an arbitrary PRF, but in practice HMAC is usually used. Either with SHA-1 (original definition), SHA-256 (e.g. in scrypt) or even SHA-512-256 (NaCL). So first you can look at how swapping key and message affects HMAC. HMAC has two cases depending on the length of the key: if it's no longer than the block size of the hash, it is used as ...

2

Yes, you are reading this right. The requests for random value from NIST 800-90 drbgs perturbed the state. If this is a problem you can add a layer that optionally buffers values and always makes constant size requests.

2

BCrypt is considered more secure The theoretical security of bcrypt has received less scrutiny than that of PBKDF2, SHA2 and HMAC. PBKDF2 is thus widely standardised (e.g. in NIST SP800-132 and PKCS #5) while bcrypt is not. In practice the security (resistance to brute force attack or dictionary attack) of bcrypt and PBKDF2-HMAC-SHA512 can be ...

2

I understand the system as follows: data blocks are enciphered per AES-CTR, using key encryption_key, with an IV made by concatenating device_id and a counter held in Flash or EEPROM, incremented at each use; that enciphered data is integrity-protected by a 256-bit mac_tag computed using HMAC-SHA256 and mac_key. That's theoretically sound if device_id ...

2

It seems that you are trying to implement your own KBKDF (Key Based Key Derivation Function) using HMAC. Maybe it is better to use a pre-defined one. It would be more sensible maybe to use an HSM that is FIPS certified for NIST SP 800-108. These use one of the KBKDFs defined in NIST SP 800-108. You can still use the idea of the random by putting it in the ...

2

There is no known inherent weakness in HMAC-SHA256 that requires key rotation for a suitably secret key. However, other aspects of the system in which you are using HMAC-SHA256 may make key rotation necessary. For instance if you don't want the same message to have the same hmac over time for some reason a key rotation would achieve that (but so would a ...

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