Hot answers tagged mac
13
As Chris Smith notes in the comments, HMAC is a specific MAC algorithm (or, rather, a method for constructing a MAC algorithm out of a cryptographic hash function). Thus, HMAC can be used for any application that requires a MAC algorithm.
One possible reason for requiring HMAC specifically, as opposed to just a generic MAC algorithm, is that the HMAC ...
9
A Message Authentication Code (MAC) is a string of bits that is sent alongside a message. The MAC depends on the message itself and a secret key. No one should be able to compute a MAC without knowing the key. This allows two people who share a secret key to send messages to each without fear that someone else will tamper with the messages. (At least, if ...
9
I'll assumme All ciphered blocks means the same as ciphertext for CBC-Encryption with implicit zero IV, while CBC-MAC is the last block of that.
All ciphered blocks is unsafe as a message authenticator for messages longer than one block, for it succumbs to a trivial attack (here with two blocks):
Eve intercepts message $M=M_0||M_1$ and its authenticator ...
6
You're missing the most important strength of HMAC: it comes with a proof of security (under some plausible assumptions). The outer key plays an important role in the proofs. The best place to learn more is to read the HMAC papers:
Message authentication using hash functions: The HMAC construction, Mihir Bellare, Ran Canetti, Hugo Kawczyk, CryptoBytes ...
5
It is easy to see that this secure, in the sense that the attacker cannot cause Alice to accept any download except for the file that Bob originally sent.
This remains true even if the attacker knows the encryption (CBC) key (alternatively, Alice and Bob doesn't bother to encrypt the message at all), and if the attacker also knows the correct $SHA1(M)$ ...
5
In addition to what mikeazo and Ilmari mentioned, there are also several chosen-ciphertext attacks on various modes of operation, which do not only endanger the message integrity, but also the message privacy, when no message authentication is used.
For example, such attacks on CBC mode were used to break the XML Encryption Standard, by analyzing the error ...
5
To see why CBC mode still needs a MAC to guarantee message integrity, first recall how CBC mode decryption works:
$$P_i = D_K(C_i) \oplus C_{i-1}$$
Here, $D_K$ denotes block cipher decryption using the key $K$, and $C_i$ and $P_i$ denote the $i$-th ciphertext and plaintext blocks respectively.
Now, consider what happens if you modify the encrypted message ...
4
One rationale for avoiding randomized schemes in general, and in MACs in particular, is that the random in such schemes tends to increases the size of cryptograms or reduce the size of the payload. An example is scheme 2 in ISO/IEC 9796-2 RSA signature with message recovery, where the size of the random/salt field is directly antagonist with the amount of ...
4
No, in general, this is not secure, unless you make additional assumptions on the encryption method beyond the standard assumption of privacy.
To simplify things a bit, the assumption of privacy means that given a ciphertext $C$, the attacker has no information about what the plaintext might be. However, in your case, we don't really care if the attacker ...
4
As a Skein co-author, one of the properties of the UBI chaining mode is to give you HMAC-like properties in one pass. Skein itself consists of the Threefish tweakable block cipher, the UBI chaining mode, and some proofs that extend tweakable block cipher theory into a tweakable hash function theory that reduces the security of the hash function to the ...
4
Hmmm, I think I might see the problem. In Generate_Subkey(), you have:
L <<= 1;
k.first = L;
if (k.first[128])
k.first ^= 0x87;
L <<= 1;
k.second = L;
if (k.first[127])
k.second ^= 0x87;
This sets K2 to either L << 2 or (L << 2) XOR const_Rb.
On the other hand, the pseudocode has
+ Step 2. if MSB(L) is equal to 0 ...
4
The birthday attack can be used with every hash function. It's a simple matter of probability (see: birthday problem). However, that only means that a hash function has to generate $2n$ of output to achieve $n$ bits of security.
It's fairly obvious that $H(m||k)$ is collision-resistant provided that $H$ itself is collision-resistant, since ...
4
The short answer is: They prepend bits in that way because the scheme is not secure without them. While they might not explain it in English, their proof makes it clear where they use it.
Let us construct an attack against the scheme that does not prepend a bit to the blocks. The same idea will work against a version of the scheme that prepends the same ...
4
1) The adversary queries the oracle (with some randomly chosen message $m$) and gets as a result a message $m=m_1|m_2|...$ and its tag $t=(t_0,F_{k_2}(t_r))$. She then draws $\rho$ uniformly at random in $\{0,1\}^n$ and outputs the message $m=\rho\oplus m_1|m_2|...$ and its (valid) tag $t=(\rho\oplus t_0,F_{k_2}(t_r))$.
2) The adversary queries the oracle ...
4
This scheme is totally insecure. If an attacker modifies any part of the ciphertext except the last block before the ciphertext corresponding to H, your scheme won't catch it.
CBC decryption of a block only depends on the ciphertext of the previous and current block.
(Based on Cbc decryption.png from Wikipedia)
The red parts are left totally unprotected ...
4
If I understand you correctly, you want to use $C = \mathrm{Enc}_{K,N}(m || \mathrm{hash}(m))$ as authenticated encryption. This is a bad idea, even for cryptographically secure hashes.
Consider an attacker who knows your plaintext $m$ and wants to replace it by $m^\prime$. He calculates $C^\prime = C \oplus (m || \mathrm{hash}(m)) \oplus (m^\prime || ...
3
The MAC algorithm you describe is called "the secret suffix method" in that paper. See the following paper, which shows how to attack the secret suffix method:
On the security of two MAC algorithms. Bart Preneel, Paul C. van Oorschot. Eurocrypt'96, Springer LNCS vol.1070, pp.19-32, 1996.
The paper describes how to use internal collisions to attack the ...
3
Accoding to UMAC RFC Section 6.1, you can use any other "cryptographic objects" instead of AES:
The strength of UMAC depends on the strength of its underlying cryptographic functions: the key-derivation function (KDF) and the pad-derivation function (PDF). In this specification, both operations are implemented using a block cipher, by default the ...
3
One of the goals of MAC is to detect/avoid message tampering.
Bellare, Canetti and Krawczyk defined 1996 formally: "The adversary sees a sequence $(m_1,a_1),(m_2,a_2),\dots,(m_q,a_q)$ of pairs of messages and tags ... and breaks MAC if she can find $m$ not included among $m_1,m_2,\dots,m_q$" and the corresponding valid tag $a = MAC_k(m)$.
However, you can ...
3
In principle this is safe. It's preferable to use a hash function that's collision resistant, even if it doesn't seem to be strictly necessary in your application.
Your usage gives me a bad feeling concerning padding oracles. I see no direct attack in your example, but it looks a bit risky to me. This is related to the encrypt-then-MAC debate.
Finally with ...
3
I see no reason why that would not be secure. If you want to play it safe, though, you could always go with a standardized key derivation function, such as HKDF (RFC 5869) or one of the other KDFs listed in this draft standard. (The draft itself seems to be expired, but it's the most convenient list of standardized key derivation functions I could find.)
3
To answer your original question: no, you can't presume that you can replace the addition mod $2^{128}$ within $Poly1305$ with XOR, and not change the security properties (at least, not without some serious analysis).
The security of the MAC depends on the fact that, given any two distinct messages $M_1$ and $M_2$, and any integer $\Delta$, then the ...
3
One of the factors that determines how hard it is to forge a MAC for a given message is how long the MAC is. If it's 1 bit long, you can definitely produce the correct MAC in two tries.
$2^n$ is the number of possible bit-strings of length $n$; $1/2^n$ is the probability that any random bit-string happens to be the MAC (of length $n$) for a given message ...
2
There are a few reasons for this.
One is for protocol flexibility. Many modern protocols support various modes (including streaming modes, which you already get why they need a MAC) and various configurations. One such configuration many support is integrity protection only. If you did something like what you propose, integrity protection only would have to ...
2
Was, as you stated, a MAC "are both generated and verified using a shared secret key", while with a digital signature, the signatures are generated with one key, and are verified with another (and it is infeasible to sign anything with the verifier key alone).
So, with digital signatures, we can give someone the ability to verify signatures, but not ...
2
One issue with this construction is described in section 6 of the original HMAC paper, "Keying hash functions for message authentication" by Bellare, Canetti and Krawczyk, where they note that finding a collision on $\mathcal H$, i.e. two inputs $x \ne x'$ such that $\mathcal H(x) = \mathcal H(x')$, directly yields a collision on $\mathcal C$ such that ...
2
The short answer: No. It is not secure.
Details. To answer the question properly, we first have to decide what we mean by "secure". In this case, I assume security means confidentiality plus integrity. So let's talk about each separately.
Integrity: yes, this provides integrity, under your assumptions. @poncho explained why.
Confidentiality: no, this ...
2
Your question is ill-posed; to determine whether they provide "security", we need a specification of what you mean by security.
So I'll answer about just one potential use of hash functions:
Are you thinking about using hashing together with encryption to try to protect the integrity of the message against tampering? If so, generally speaking, unkeyed ...
2
I'm putting another answer in because as good as D.W.'s answer is (I up-voted it), it doesn't really answer your question.
You said:
But the simple construction Hash(Hash(key|message)) would offer those properties too.
But the construction you gave -- Hash(Hash(key|message)) -- has a weakness that HMAC does not.
One of those properties was ...
2
If you are doing authenticated encryption with an AES and HMAC combination, the security of your scheme depends on the key for encryption and the key for message authentication being independent. The general idea is that you might generate two independent keys from a single master key, by proper usage of a $PRF$. The most performance effective solution is ...
Only top voted, non community-wiki answers of a minimum length are eligible
