# Tag Info

2

Any PRNG with a finite state size is eventually periodic. The maximum period possible is $2^n$ for an $n$-bit state, but the average with a well mixed state is $2^{n/2}$. Here the hash function used is SHA-512, but the state is 1024 bits. A first guess would be a period of $2^{512}$, rather than the $2^{256}$ mephisto gives. Let's look at the cycles. Both ...

1

Yes, this PRG is theoretically periodic. Approximately after generating $2^{512}$ outputs a state will be generated that collides with a previous state. (A previous version of this answer said $2^{256}$ as I missed that two outputs are used for the state. Otus answer pointed out this mistake.) This follows from the birthday problem. However, $2^{512}$ is ...

0

Assuming you mean a normal HMAC with a strong unknown key, no amount of MAC values for known, or even chosen messages would help you find the key. That would mean a failure of HMAC's forgery resistance, which is expected of MAC algorithms. (It would be a very bad case of forgery attack, since it would allow forging MACs for any messages. Even much lesser ...

1

This won't seriously impact the security of the key. HMAC is pretty resilient and changing the last part of the hash won't allow attacks on the a hash such as SHA-256. Note that you only select 4 characters, of which the last one only encodes 4 bits (as it is at the end). That means you've got a check value the size of 2^22 encoded bits, i.e. a chance of 1 ...

0

In a protocol like SSL, if it gets broken tomorrow, we can “simply” turn off all the cipher-suites that use HMAC-SHA1. But what if it is used as MAC protection for encrypted data storage? This isn't as big a problem as it may seem at first. Even with old data it can still be possible to upgrade the MAC later if you find out about a possible attack, as ...

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

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

2

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

0

I managed to find it out by reproducing the test vectors. TL;DR: The standard assumes that you use the low 4 bits of the last byte of the hash, regardless of its length. So replace 19 in the original DT definition with 31 for SHA-256 or 63 for SHA-512 and you are good to go. Finding this out wasn't completely straightforward, as the standard only has a ...

0

Yes, it's fine. However, you might as well use HKDF-Expand (with your counter as the context information 'info'), so that if you later need some session keys to be larger than 256 bits, the extension is already defined for you. So, $$sk_1 = HMAC(mk, 1 || 0x01)\\ sk_2 = HMAC(mk, 2 || 0x01)\\ ...$$ And if you need a 512-bit $sk_3$ that's: sk_3 = HMAC(mk, ...

Top 50 recent answers are included