Tag Info

Hot answers tagged

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


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


10

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


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

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

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

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


6

Using a MAC on the plaintext may potentially leak information about the plaintext (MAC algorithms do not necessarily ensure confidentiality of the data they are applied to, although some MAC algorithms like HMAC seem pretty safe). If you want to avoid this (theoretical) problem, then you should encrypt the MAC on the plaintext (i.e. MAC-then-encrypt, not ...


6

You can, but you don't because you need secure storage for $k$ as well as a secure computing platform. Those things are expensive.


6

As K.G. and nightcracker note, the reason we don't recommend this method of password storage is that it becomes insecure if the secret $k$ is compromised. Given that the whole point of password hashing is to protect the passwords in the event that your server is compromised, it's generally not safe to assume that the compromise won't include the secret key ...


5

Yes, your MAC is secure. It's probably not quite as secure as you're expecting it to be, and it's not a construction I would recommend to anyone, but it should be secure. Let's start with a simpler variant: $F_K(M) = E_K(H(M))$ where $H(\cdot)$ is a 128-bit collision-resistant hash (say, the first 128 bits of SHA1) and where $E_K(\cdot)$ is a 128-bit ...


5

Well, yes, it does matter; however the terminology 'CBC-MAC' does not specify which. CBC-MAC is a generic construction that takes an arbitrary block cipher, and turns it into an object that acts like a MAC for fixed length messages (much like CBC mode is a generic construction that takes an arbitrary block cipher, and turns it into a object that encrypts ...


5

This depends on the MAC algorithm. Two examples: With HMAC based on a secure hash function, no, there is no known way to construct a message fitting the MAC other than brute-forcing it. (If you want to find a specific message, like when you have a MAC of a message containing a password and some fixed text, brute-forcing the password might be quite ...


5

$\langle \langle 1\rangle || m_1, 0^n \rangle$ is a valid tag on $m = m_1$


5

The attack outlined by Drlecter is valid for any deterministic MACs (that is: with the MAC a function of message and key) with an iterated structure and an $n$-bit state. It relies on internal state collisions, expected to occur after about $2^{n/2}$ messages (the birthday bound), that can allow forgery once discovered. I'll illustrate this in the case of ...


5

One simple cryptographically secure rolling hash function is the following: $$F_{k1,k2}(x) = E_{k1}(R_{k2}(x))$$ where $R_{k2}(\cdot)$ is a non-cryptographic rolling hash function (e.g., Rabin-Karp), and $E_{k1}$ represents encryption with a block cipher (e.g., AES). By $R_{k2}(\cdot)$, I mean that the parameters of the rolling hash should be derived from ...


5

There are various factors that go into choosing a MAC algorithm, for example: Use cases for CMAC vs. HMAC? documents CMAC vs. HMAC; I think HMAC is a reasonable default choice though (supported by Colin Percival: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html). Yes, the MAC can be transmitted alongside the ciphertext, one thing ...


4

It has the disadvantages of any MAC-then-encrypt scheme, which I'm quoting from the linked answer below. In addition: It has the property that you need both a nonce and a hash, so for equivalent security it requires more message space. The nonce has to be random, so it requires strong random numbers for each message, unlike e.g. AES CTR + HMAC. Doesn't ...


4

Non-authenticated symmetric encryption schemes are generally malleable, meaning that an attacker who intercepts a message may be able to modify it even without knowing the key, e.g. by flipping arbitrary bits in it. A MAC prevents such attacks by detecting any modifications made to the ciphertext. Also, there are various chosen-ciphertext attacks that work ...


4

The following was originally written as an edit to the question, but I'm going to put it here instead because I think formalizing the schemes might well provide you with enough of a hint for you to solve this question yourself: Let $f(k,m)$ be a pseudo-random function, taking as inputs a key and a message, and outputing a value of the same length as the ...


4

AES-GCM uses single block cipher operation and can be processed in parallel, therefore it should be faster. CTR+HMAC requires block cipher and hash function, which usually can't be processed in parallel. Also it requires 2 keys. It is often miss-implemented (MAC-than-encrypt or MAC-and-encrypt, using single key). Cipher-text length is the same for same ...


4

HMAC and NMAC make assumptions of the underlying hash function $H$ for their security proofs. Additionally they are designed to eliminate known flaws in other MAC constructions using MD type hashes. NMAC is not $H(k1$ $||$ $H(k2$ $||$ $m))$, it actually uses the keys as the initial hash values, which require a higher level of access to the internals of the ...


4

What Stephen says in the comment is correct. It is safe to not use authenticated encryption whenever your adversary model assumes that the attacker does not have the ability to manipulate ciphertexts. I assumed hard drive volume encryption or per file encryption that is not transmitted over an insecure network should be considered safe to do without a ...


4

Two things going on that together may make plain-hash-then-encrypt insecure. First, the distinction between secure MACs and hashes, which is that a hash function may allow you to derive $H(m')$ from $H(m)$ even if you only know how $m'$ and $m$ differ. Length extension attacks on SHA-1 and SHA-2 are a practical way that can happen, but there could be others ...


4

There are no specific requirements for the choice of cipher and MAC in the Encrypt-then-MAC construction, except that both should individually achieve their respective security goals (typically semantic security and existential unforgeability). Indeed, this is the major advantage of Encrypt-then-MAC over other constructions like MAC-then-Encrypt or ...


4

Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC? No, you don't need to do that, but you can. Needless to say we'd still use a key, which we prepend or append to the message, but is that sufficient for a MAC? Yes, you can ...


3

You can construct a one-time MAC that has a similar properties to the OTP. Better still, it uses a fixed number of bits for each message. Here's how it works. Choose the closet prime to your message block size. Let's say you plan to process 128-bit chunks of your message. Let's say there are $L$ such blocks. The first job is to pick the first prime larger ...


3

I am wondering if using Skein or the Keccak hash algorithm in this construction (as a stream cipher) is secure: In the case of Skein and Keccak it should be secure. However, both of those have defined their own cipher modes which you should IMO prefer. (For compatibility, if not security.) The Skein one is defined in section 4.10 of the paper. It uses ...


3

Well, 32 bits is somewhat short, so one could just try ciphertexts. However, there is a much better attack. Choose M0 arbitrarily, let P be the CBC padding for Headers || CRC || M0, and choose M1 so that CRC( M0 || P || M1 ) = CRC(M0). Submit M0 || P || M1 to be encrypted, truncate the ciphertext to the length of encryptions of M0, and then output the ...


3

GMAC is quite simply GCM mode where all data is supplied as AAD (or additional authenticated data), or as NIST SP 800-38D puts it: If the GCM input is restricted to data that is not to be encrypted, the resulting specialization of GCM, called GMAC, is simply an authentication mode on the input data. If you don't have access to a cryptographic provider ...



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