Tag Info

Hot answers tagged

96

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


55

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


24

These types of cryptographic primitive can be distinguished by the security goals they fulfill (in the simple protocol of "appending to a message"): Integrity: Can the recipient be confident that the message has not been accidentally modified? Authentication: Can the recipient be confident that the message originates from the sender? Non-repudiation: If ...


18

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


18

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


17

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


15

Length extension attack The reason why $H(k || m)$ is insecure with most older hashes is that they use the Merkle–Damgård construction which suffers from length extensions. When length extensions are available it's possible to compute $H(k || m || m^\prime)$ knowing only $H(k || m)$ but not $k$. This violates the security requirements of a MAC. Like all ...


14

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


13

$Encrypt(m|H(m))$ is not an operating mode providing authentication; forgeries are possible in some very real scenarios. Depending on the encryption used, that can be assuming only known plaintext. Here is a simple example with $Encrypt$ a stream cipher, including any block cipher in CTR or OFB mode. Mallory wants to sign some message $m$ of his choice. ...


12

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


12

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


11

HMAC was there first (the RFC 2104 is from 1997, while CMAC is from 2006), which is reason enough to explain its primacy. If you use HMAC, you will more easily find test vectors and implementations against which to test, and with which to interoperate, which again explains continued primacy. Being the de facto standard is a very strong position. On many ...


10

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


9

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


9

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


9

It is not secure, because an attacker can "mix and match" the output blocks from different authentication tags on different input messages, or repeat output blocks for repeated input blocks. For example, if the attacker knows the tag $F_k(m)$ for a one-block message $m$, then it can forge the correct tag $F_k(m) \mid F_k(m)$ for the two-block message $m ...


8

This scheme is not worth the name MAC; it is horribly weak. First and foremost, the tag/MAC is unchanged when two blocks of plaintext are exchanged (because of the commutativity and associativity of the $\oplus$ operation). If follows that from any message with at least two different blocks, we can make a different message for which we know the tag/MAC. ...


8

In general, a MAC with a known fixed "key" is not a secure hash. That is, you can have a secure MAC (that is, someone without the key, but with a large number of message/MAC pairs, cannot come up with another valid message/MAC pair) that is not collision resistant, or even preimage resistant, if the attacker does know the key. In addition, you don't have ...


8

The generic model for a MAC is the following: the attacker is given access to a block box which implements the $S$ function with a key $k$ that the attacker does not know of. The attacker is allowed to make $q$ requests to the box on messages that he can choose arbitrarily. The goal of the attacker is to make a forgery, i.e. produce values $m$ and $t$ such ...


8

Yes, this would be secure. CTR (Counter) mode based on keyed function $F_K$ is secure as long as its output $$ W_i = F_K(i) $$ is unpredictable given previous outputs $$ F_K(1),F_K(2),\ldots,F_K(i-1). $$ This requirement is essentially the definition of a pseudo-random function (PRF). Most HMAC instantiations with widely used hash functions are believed to ...


7

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


7

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


7

The other answer is correct in general. However, if your messages are all exactly one block long (or all one block after padding), ECB is a secure MAC. A PRP looks like a PRF up to half its bit length, i.e. up to $2^{64}$ blocks for AES. A secure PRF is a secure MAC of the same size. Thus, AES ECB used on 128-bit messages is a secure MAC as long as you use ...


6

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


6

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


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

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


6

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


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



Only top voted, non community-wiki answers of a minimum length are eligible