Hot answers tagged

38

Everything was changed between SHA-2 and SHA-3. In the specific case of the "length extension attack": the issue is that SHA-2 process data by splitting it into elementary blocks (64 or 128 bytes, depending on the SHA-2 variant), and produces for each block an output which has exactly the same size as the function output. Moreover, the output for a complete ...


16

Alas, there is no simple satisfactory answer to this question. What I can offer is a very strong property that $m \mapsto H\bigl(k \mathbin\| H(k \mathbin\| m)\bigr)$ fails to achieve; a more pedestrian property which even HMAC may or may not achieve but is typically asked to achieve; a reason not to worry about it for any new systems; and some historical ...


8

Yes, a MAC can of course have an all zero result. But that doesn't matter, because the chance of that happening should be the same as taking a random choice out of a set where each element has the same probability, i.e. has a uniform distribution. So the chance of an all zero popping up should - in this case - be about $1$ in $2^{128}$, assuming of course ...


5

If a (nonce, key) is reused with two distinct messages A and B, an attacker can learn A⊕B = E(A)⊕E(B). So, if either plaintext is known, the other one can be immediately decrypted. This is why nonce-misuse resistant schemes require two passes: a first pass to compute a hash of the message, the second one to perform the actual encryption with an IV, and ...


4

In the first case, $\Pi_3$ is not secure. We can use $(m_1, m_2)$ and $(m_3, m_4)$ to query the adversary $A$. $t_1||t_2 = A(m_1, m_2)$ $t_3||t_4 = A(m_3, m_4)$ The forged MAC would be $t_1||t_4: Verify(t_1||t_4, (m_1, m_4)) \rightarrow Accept$. In the second case, $\Pi_3$ is not secure. We can use $(m_1, m_2)$ and $(m_1, m_3)$ to query the adversary $...


4

I need to calculate a MAC using ISO 9797-1 Algorithm 3 (padding mode 2) and the context makes references to 3DES (as confirmed by the 8-byte width of the result without mention of truncation, and the fact that all bytes of the test key 7962D9ECE03D1ACD4C76089DCE131543 have odd parity). ISO/IEC 9797-1:2011 (revising the 1999 edition) specifies MAC ...


4

But, for the purpose of optimization, I was thinking to delete only its IV and Tag, thus hoping to make decryption of that segment's data computationally infeasible. Neither work. The IV might seem to work (as doing a brute force search over a space of size $2^{96}$ might appear to be daunting), however the attacker has another potential approach. If an ...


4

To supplement the other answer, I will show that the proposed scheme cannot be shown secure assuming only collision resistance of the hash function. (I.e., the standard assumption on hash functions.) Let $H' : \{0,1\}^* \to \{0,1\}^{\ell-1}$ be a collision resistant hash function. We construct another hash function $H : \{0,1\}^* \to \{0,1\}^{\ell}$ as ...


3

The construct in the tutorial is a horrifying case of non-secure MAC - it can hardly provide assurance of anything. Why would server consider the file path --omitted-- a valid path, Why not? It's perfectly valid bytestring, although it ends at the first %00 because it's nul-terminated. A path does not become invalid just because it doesn't name an ...


3

You are in the right direction. First, some intuition. The idea is that $y = ax+b$ constitutes a line, and if you need two points in order to fully determine it. However, if you only know one point, and if you don't have any additional information, then it is not possible to determine which line is it since there are "infinitely many" lines passing through ...


3

I assume that by a "strong MAC" you mean that it is infeasible for an adversary to also find a different MAC tag on a message which has been tagged. Any deterministic MAC (with canonical verification) is a strong MAC, but it is certainly not the case that every MAC is a strong MAC. Thus, indeed, there exist secure MAC schemes (that are existentially ...


3

1. Is it a reasonable solution? That's hard to say; for a transport protocol - which is what you are designing - you have hardly described anything at all. Yes, a counter can be used to make messages unique as to avoid replay attacks and introduce randomness when combined with the AES key. 2. Are there any possible security risks? Plenty, but with the ...


3

The question as posed (in the book) is a bit weird, mainly because it does not state that $F$ is required to be length preserving, however for the CBC-MAC construction to make sense it clearly has to be. But ignoring this fact for a moment, one of your observations was indeed crucial. A MAC does in general not hide it's input message. As you point out, if $F'...


3

Adding to Yehuda Lindell's answer, there are two special cases that one should take care to avoid: If the HMAC key $k$ is longer than the block size of $H$, then it is compressed into $k' = H(k)$ and $k'$ is used instead with HMAC as usual. This means that there are easily constructed collisions in HMAC keys, namely $k' = H(k)$ and $k$ for any key $k$ that ...


3

HMAC (and any other MAC) are totally different from Digital Signatures (RSA, DSA, ECDSA, EdDSA). MACs require a shared secret key that both the communicating parties have. The same secret is used to create the MAC as is used to verify it. Anyone with the shared secret key can create a MAC, and anyone with the shared secret key can verify a MAC. Digital ...


2

Yes, the attacker can recover the key with high probability in the event of such a collision. For example, in two-block messages $m_1 \mathbin\| m_2$ and $m'_1 \mathbin\| m'_2$, this means that $$m_1 r^2 + m_2 r = m'_1 r^2 + m'_2 r,$$ so the key $r$ is a root of the quadratic polynomial $$(m_1 - m'_1) r^2 + (m_2 - m'_2) r,$$ of which there are at most two ...


2

In the general case, the security goal is to reduce the probability that the internal 128-bit counter block ever takes the same value when instantiating the GCM cipher with a given key. That is catastrophic in combination with the CTR mode. The best strategy to minimize such probability depends on how the IV is generated. Case 1: IV is deterministic, 96 ...


2

By my read of the question, I don't see why this is even correct. It does depend on how one interprets that "H is not computation resistant for every key K". I assume that this just means that $H$ is not computation resistant for a randomly chosen key $K$. Otherwise, I'm not sure what it would mean. According to this understanding, I don't see why the ...


2

Your first approach was almost correct. Your question says nothing about the shape of the secure MAC except the length. The secure MAC only says that you cannot forge a new tag from the previous ones. Let $MAC_1$ be a secure map with output length $n-1$ than $$MAC_2(m) = MAC_1(m)\|0$$ will be a secure MAC with output length $n$. Now, put $MAC_2$ into ...


2

Anyone who holds the key can create a MAC. For any secure MAC it should be computationally infeasible to create a MAC without knowledge of the key. By the correctness of a MAC, anyone who holds the key can verify it. In pretty much any practical MAC, the key is also needed to verify, but this is not something that's actually implied by the functionality or ...


2

There are two ideas going on here: Radix 256 arithmetic with delayed carries. Here we represent an integer $x$ by $x_0 + 2^8 x_1 + 2^{16} x_2 + \dots + 2^{128} x_{16}$. In canonical form, the digits $x_i$ lie in $\{0,1,2,\dots,255\}$, but in the Poly1305 computation, we delay the propagation of carries as long as we reliably can in order to save ...


2

As cheaper alternatives to HMAC with modest security goals, consider: SipHash—cheaper than MD5 because you don't have to pay for collision resistance; security is limited by the 64-bit output size Maybe a Gimli-based PRF—Gimli is a new compact design Derive a fresh key for each message, and use a one-time authenticator like a polynomial evaluation universal ...


2

Yes, the IV is the same in both encryption and decryption for all modes that use an IV. And yes, the decrypter must have access to the IV to decrypt the ciphertext. The IV is not a secret. The only caveat is that for CBC mode the IV must be unpredictable to an attacker whose data is being encrypted by another party. Once the attacker has presented the ...


2

Would there be any benefit to symmetrically encrypting the IV and MAC in an AEAD mode of operation? Not really. The MAC is already encrypted as part of GCM mode. Encrypting the IV just hides it, decryption of the message still requires the key. More specifically would this prevent someone from exploiting the accidental use of a duplicate IV with the same ...


2

The first scheme is similar to what's called Encrypt-and-MAC. It is not ideal, but it is not fatally broken, and it is still used by the SSH protocol securely. You need to include a counter or other unique value in the data being MACed to maintain IND-CPA security (i.e. identical plaintexts don't have identical MACs). The second scheme you present doesn't ...


1

Yes, the length extension is identical for key sizes that are a multiple of 64 as SHA-1 has an input block size of 512 bits. So you would have to generate the exact same padding for the same message in that case. However, commonly this includes the encoding of the length of the input message of the hash in bits. The output of a number of blocks of SHA-1 ...


1

Not necessarily. Let $M$ be a secure deterministic MAC like HMAC-SHA256. Define the randomized MAC $M'_{k, \rho}(m) := M_k(m) \mathbin\| \rho$; that is, $M'$ just appends the randomization to the MAC. Then encrypt-and-authenticate with $M'$ still leaks message equality, even though the MAC is technically randomized.


1

Cryptographic strength of an authentication tag strongly depends on the tag size and you shouldn't use a tag less than 64-bits for any application. 64-bits is really the minimum you should use. Such a short tag is acceptable for online protocols, where the intent is just to authenticate a packet that has been received. Since 64-bits will not be collusion ...


1

Given that a secret key was exchanged among some parties any of them can authenticate/verify a message using some MAC implementation in conjunction with the shared key. Typically you would share a key between 2 parties because otherwise you cannot tell who was the sender. However, this is not to be confused with the property of non-repudiation that you get ...


1

Currently, it is not clear what should happen when $m$ and $k$ have different length. You should clarify what happens, even if it's just to say that $m$ and $k$ will always have the same length. Regarding security, the function $m \mapsto H(k \oplus m)$ is actually a secure MAC when $H$ is a random oracle (and $m$ and $k$ always have the same length). But I ...


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