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


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


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

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


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


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

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

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


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.


5

One option would be to get them to select a one-time MAC of the form: $mac(m,k_0, k_1) = (k_0 \times m + k_1) \mod p$ You would select $p$ to be something like 29. $k_0$ and $k_1$ would be chosen at random from the values 0-29. $k_0$ has the additional restriction that it can't be 0. You can aid the computation by giving them a 29x29 matrix of all ...


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

As correctly pointed out in a comment, the authenticated encryption model assumes that the attacker knows the algorithm; the attacker can query the encryption oracle with any plaintext $P$ (and a unique nonce $N$) and get MAC-then-Encrypt ciphertext $C$; the attacker can query the decryption oracle with any string $C$ pretending to be a ciphertext. No ...


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

Quite a difficult question. What you seem to need is a one-way permutation $P$. Indeed, suppose you have it of width $d$, then consider the function $$ F(K,S,R_S) = E_{K_2}(P(E_{K_1}(S,R_S))), $$ where $E$ is any good 64-bit block cipher (say, Simon) and $K_1,K_2$ are derived from $K$. This function $F$ should fulfill (2) because of the encryptions of both ...


3

Not sure if hash trees miss some of your requirements, but many of requirements you have could be satisfied with hash trees. Note: The scheme described below is essentially "Merkle Hash Tree-based Storage Enforcing Scheme (MHT-SE)[Golle et al. 2002]". So my question is, if we relax the requirement of being able to perform an unbounded number of ...


3

I do not know of any approaches in context of proofs or retrievability (PoRs)/provable data possession (PDP) that use homomorphic encryption. However, many of those schemes employ homomorphic (linear) authenticators/tags for the metadata such that the proofs delivered by the server can be of constant size, i.e., by aggregating single tags. Now to some ...


3

If there exists an encryption scheme, then there exists an encryption schemes such that one can easily modify a single ciphertext so that whether or not that modifies the decryption result depends in a predictable-and-useful way on what the plaintext message was, such as: The modified encryption operation outputs a zero concatenated with the original ...


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