Hot answers tagged mac
40
I'm assuming you actually know all of this better than I do... anyway, this paper neatly summarises all these approaches and what level of security they do or don't provide. I shall paraphrase it in English, rather than Mathematical notation, as I understand it, here:
Encrypt-then-MAC:
Provides integrity of Ciphertext. Assuming the MAC shared secret has ...
26
@Ninefingers answers the question quite well; I just want to add a few details.
Encrypt-then-MAC is the mode which is recommended by most researchers. Mostly, it makes it easier to prove the security of the encryption part (because thanks to the MAC, a decryption engine cannot be fed with invalid ciphertexts; this yields automatic protection against chosen ...
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 ...
12
The nCipher Advisory #13 cited in your securityfocus.com link contains the explanation of the vulnerability (in the section "Cryptographic details").
The CBC-MAC algorithm works similar to the CBC encryption algorithm, but only outputting the final block (or a part of this).
Each block of the plain text is XOR-ed with the previous ciphertext and then ...
11
The word "secure hash function" usually means (for a function $H$)
Preimage resistance: Given a value $h$, it is hard to find a message $x$ so that $h = H(x)$.
Second preimage resistance: Given a message $x$, it is hard to find a message $x' \neq x$ such that $H(x) = H(x')$.
Collision resistance: It is hard to find two messages $x$, $x'$ such that $H(x) = ...
10
Hugo Krawczyk has a paper titled The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?).
It identifies 3 types of combining authentication (MAC) with encryption:
Encrypt then Authenticate (EtA) used in IPsec;
Authenticate then Encrypt (AtE) used in SSL;
Encrypt and Authenticate (E&A) used in SSH.
It proves ...
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 ...
8
The reason $H(k|m)$ (where $|$ is concatenation) is not the standard comes from the message extension attack. If I, as an attacker, have $H(k|m)$ and $m$, I can compute $H(k|m|p|m')$ (where $p$ is the padding that $H$ would have applied to $k|m$ in computing the digest, and $m'$ is an arbitrary message) without knowing $k$. I would then send ...
7
UMAC is described in full details in RFC 4418.
When the RFC talks about "secret selection", it really means "there is a secret key involved here". UMAC works with universal hashing, which can be viewed as a family of hash functions, and a key which selects which hash function we are talking of. The term "hash function" might be a bit confusing here, because ...
7
This construction is not secure. It was proposed in this paper in a quick sentence for possibly fixing the insecure secret prefix construction from the other question: $\mathcal{H}(k||m)$. The author then proposes and analyzes an enveloping method: $\mathcal{H}(k_1||x||k_2)$.
An attack involving finding an internal collision applies to ...
6
As mikeazo notes, PBKDF2 supports the generation of arbitrary amounts of key data. It accomplishes this simply by appending a running counter to the salt and rerunning the key derivation process to generate new output blocks, so there's no obvious reason why you couldn't apply the same construction to bcrypt.
The scrypt KDF also supports arbitrary-length ...
6
Answering the question as worded in its body: NO, $\mathrm{SHA1}$ is not designed so that the proposed construction is secure under the stated conditions. The design objective of the $\mathrm{SHA1}$ and $\mathrm{SHA2}$ hashes, as explained by NIST, is that
it is computationally infeasible to find a message that corresponds to a given message digest, or ...
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
A PRG and a hash function are both PRFs, but they have different security considerations. (At least, historically they do. Moving forward some of them may be more closely aligned.) Due to this, building a hash from an existing PRG designed under older security constraints probably isn't a good idea for the intuitive construction of using the plaintext as the ...
5
Whether we get any information from a MAC collision rather depends on the details of the MAC.
HMAC is one extreme. If you happen to find a collision (that is, two distinct messages that happen to MAC to the same value), well, that doesn't tell you very much. We don't know how to use that to generate any more collisions, or to gain any information on the ...
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 ...
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
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)$ ...
4
This doesn't exactly address the question, but I thought I would toss my hat into the ring: HMAC uses crypto hash functions like MD5, SHA1, etc. Those are (relatively) slow.
There is another class of MACs that use Universal Hash Function families. These families are not cryptographic; they have a simple combinatorial property, and so they tend to be much ...
4
By the way, if you're interested in UMAC, you may also be interested in VMAC, Poly1305, or Badger. If I had to choose one MAC to use today, without doing any further research on it, I would use Poly1305.
4
In TLS (that's the standard name for SSL; TLS 1.2 is like "SSL version 3.3"), client and server ends up with a shared secret (the "master secret", a 48-byte sequence; when using RSA key exchange, the master secret is derived from the "premaster secret" which is the 48-byte string that the client encrypts with the server public key). That shared secret is ...
4
Commitment functions should be at least hiding and binding, and in your case, you want non-malleable.
Using a hash function as a commitment does require addition assumptions on the hash that are not covered by (second) pre-image and collision resistance for both non-malleability (as you point out) and hiding: the hash can be assumed to not reveal the ...
4
The archetypal situation where the length-extension property becomes problematic is when ones builds a Message Authentication Code from a hash function as $$BadMAC(K,M)=Hash(K||M)$$ where $K||M$ is the concatenation of the Key and the Message.
The length extension property then translates directly into the capability to forge a different message, starting ...
4
If you have a PRF (with larger input than output), you can use it as compression function in a Merkle-Damgård structure, yielding a hash function which you can subsequently turn into a MAC with HMAC. Indeed, the security proof of HMAC relies on indistinguishability of the compression function from a PRF.
There are still an awful lot of details, though. And ...
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
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
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
