Search Results

We believe that HMAC-SHA512 is a secure MAC (assuming an unguessable key); hence we believe that it is secure in your case. …

Now, if you look at how HMAC works internally, then there will be (with high likelihood) will be values that cannot be produced by a specific key; that is, values which cannot be achieved by any message … Also, a minor terminology note: If I have a HMAC_SHA1 signature… In crypto, we tend to use the term 'signature' to refer to a public key signature operation (which HMAC is not). …

CodeInChaos has it right about the infeasbility of this against a random key; however, lets run the numbers to see how extremely correct he is: Let us assume we are attacking HMAC-MD5 within TLS; this … It gets even worse if we talk about HMAC-SHA1; that uses 160 bit keys; that increases the amount of time we'd expect to take by about 4 billion. …

Modern thought is that it'd be generally better if you first encrypt, and then perform the MAC, as in: E := AES(M) Send IV, Encrypted HMAC(IV | Encrypted) But no radical problem is known with your idea …

Well, there are two potential key recovery attacks against HMAC (assuming a reasonable hash function): Brute force the key; that is, take a valid (Message, MAC) pair, and try every possible key, and …

They then go on to HMAC, and show that HMAC is as secure as NMAC; the prepended keying material (which occupies precisely one hash block) sets the hash internal state to a value which is unpredictable … HMAC also has the advantage that it can be implemented using a standard hash implementation. Hence, the answer is "you don't need to set the HMAC IV values; the HMAC keys do that for you" …

The other way he can win is if he selects an incorrect key, however the HMAC of that key just happens to be the right one (by shear chance). … If we assume that HMAC acts like a random oracle, and that we using an untruncated (256 bit) HMAC (I say this because it is quite common to truncate the HMAC output when transmitting it), then (assuming …

This doesn't apply to HMAC; there, they only thing you can do is test various messages, compute the HMAC of all of them, until you stumble across one with the observed output. …

In what way does using a 256-bit key rather than a 512-bit key with HMAC-SHA-512 decrease its security strength? It doesn't, in any real sense. … If we assume that the attacker had a working reliable Quantum Computer, he could, in theory, attack the system by performing $O(2^{128})$ HMAC-SHA512 evaluations, which is still not very practical, but …

Should they come directly from the store of OTP key material, or should they be entered from memory by the user (via a password then a key derivation function)? Depends on what the security goals ar …

Collision resistance is a stronger assumption than the normal assumptions that HMAC makes, hence this doesn't seem to be a great trade-off. …

I wonder how secure the HMAC is going to be if I use a public key verified data. With HMAC, anyone with access to the key is able to generate the correct tag to any message he wants. … If the key is public, well, that means anyone is able to generate HMAC tags. Also, AEAD has the same issue; anyone with the AEAD keys can encrypt anything they want. What does this mean? …

If $P$ goes and asks $S$ for what the answer should be (as in your HMAC attempt), well, by doing that, $P$ learns $f$, and so the objective has been met. …

additional keying data, what we can do is pick an arbitrary block value $B$ (perhaps the all-zero block), encrypt that using the block cipher in ECB mode, and use that $Encrypt_{key}(B)$ value as the HMAC … be bounded by $2^{-b}$ The above analysis rather assumed that you need only one block of information for your HMAC key; if you happen to need multiple, it is easy to extend this analysis to $Encrypt_ …

It is indeed safe to send it along with the ciphertext; the attacker can't learn anything from it (other than possibly how many packets has been generated so far, if you use a counter to generate the …