New answers tagged hmac
1
You asked the same question over on the IT Security site.
Please don't cross-post. It is frowned upon, under the rules these sites operate.
Here is what you should be doing:
Truncate the MAC tag to an acceptable length. You will need to choose a length that provides a suitable tradeoff between packet size vs. security against forgery. I suggest you use ...
2
There aren't any known attacks on the PRFness of HMAC-SHA256 better than brute force.
(So you can truncate that MAC to length L where $\:\:\frac1{2^L}+\epsilon\:\:$ is an acceptable risk of forgery.)
To reduce the impact of a forgery without making the ciphertext any longer, one should use a
format-preserving encryption (FPE) scheme that is secure against ...
2
Yes, using K might be safer than using Khex or Kbase64, for a down-to-earth reason distinct from the valid theoretical reason pointed in Henrick Hellström's answer.
RFC 2104 says:
The authentication key K can be of any length up to B, the block length of the hash function.
Applications that use keys longer than B bytes will first hash the key using H ...
3
The theoretical problem with using text encoded keys, is that it doesn't necessarily conform with how the keys are assumed to be formatted in security proofs such as this one. If you are using HMAC with an underlying hash function that is still believed to meet the requirements of a cryptographically secure hash function, such as the SHA-2 family of hashes, ...
3
Before we jump into this question, you first need to know a bit about the internals of hash functions with the Merkle-Dåmgard construction. Here's a pretty picture from Wikipedia:
In this diagram, you see the compression function $f$ being fed the message blocks along with the output of the state of the previous compression block (or the IV). The final ...
2
Inspired by Henrick Hellström's comment, I think you need to dig a bit deeper into what “difficult” means.
Pre-image resistance means that given $h$, it's difficult to find $m$ such that $h = H(m)$. Intuitively speaking, your only chance is to have started with an $h$ that is in the relatively small set of already-computed hashes.
Now suppose you have $h'$ ...
1
No. Assuming HMAC is secure against known-plaintext attacks (which is a plausible assumption), the key cannot be recovered. This follows directly from the definition of a known-plaintext attack; if you could recover the key, you would have a successful known-plaintext attack on HMAC.
1
Under plausible assumptions, the probability of this happening (for a given pre-specified pair $m_1,m_2$) is $1/2^n$, where $n$ is the number of bits of output of the HMAC. For instance, if it produces 160-bit output, then the probability of this happening is $1/2^{160}$ (again, assuming certain unproven assumptions that are probably reasonable to work with ...
1
$\Downarrow \;\;$ (that's me pointing)
$\mathcal{A}^{\mathcal{O}}$ works as follows:
generate m1 and m2 in whatever way
set $\:$tag = $\mathcal{O}$(m1)
output $\:$[m2,tag]
Observe that $\mathcal{A}^{\mathcal{O}}$ has trivial runtime and makes only one query to the oracle. $\:$ Furthermore,
Prob$\hspace{.01 in}$(m1 ≠ m2 $\;$and$\;$ HMAC(k,m1) = ...
Top 50 recent answers are included
