# Tag Info

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

6

I do not know how they are related to each other. EtM, MtE and E&M are generic constructions that take pairs of schemes that satisfy weaker security notions (chosen-plaintext security and unforgeability) and turn them into AEAD-secure schemes. GCM is a construction that takes a 128-bit block cipher and turns it into - an AEAD-secure scheme and ...

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

5

what is the minimum amount of bitflips on the message that can be corrected Zero bits, Poly1305 doesn't provide error correction (at least Bernstein doesn't claim that property in the original paper). (or at least detected) by someone who knows the corrupt message, the mac code, and the key? One bitflip is already detectable, it will change all bits of ...

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

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 $... 3 When Alice and Bob are using a message authentication code (MAC) scheme, both of them have the shared MAC key, and both of them can generate valid MAC tags. Between Alice and Bob, they can be sure who is the sender. For example, if Bob receives a message with a valid MAC, and the message was not sent by himself, then the message must come from Alice. Hence "... 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 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 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 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 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 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 ... 2 No, you can use the same HMAC key for any message, including an already HMAC'ed message (regardless if the HMAC value is encrypted or not). The key in HMAC is protected by the one-way hash function used internally, so getting the key should be hard. The collision resistance and other security properties will also prevent an attacker from generating a HMAC ... 2 Would it be possible to create a signature scheme like this: As I understand it, your proposal is that the signature consists of the MAC key, along with the signed MAC value of the message. In general, this would not be secure, for two reasons: For many MACs, it is not difficult, if you know the key, to find a second message with the same MAC as an ... 2 Can we get the$msg$from this? Yes, as long as we know the nonces, and as long as$msg$is no more than$128n$bits long, and$n$isn't too incredibly huge (the latter might not be a required assumption, I just need it for my approach). Poly1305 can be modeled as computing a tag this way: $$tag = c_a r^a + c_{a-1} r^{a-1} + … + c_1 r^1 + z - 2^{128} k \... 2 Poly1305 itself has the requirement that its keys can only ever be used to generate a tag for a single message. That means that when Poly1305-AES (or another Poly1305-based authenticated encryption algorithm) is used as intended, the Poly1305 authentication key will be different for each message even if a key is reused. However, the various Poly1305-based ... 2 assuming that it is a deterministic MAC using a canonical verification It is not, randomness is involved in the tag generation, therefore it is not deterministic and cannot use canonical verification. This then means that an attacker doesn't have to follow the MAC algorithm but instead has to find m',(r',t') such that verification suceeds, picking t'=0 ... 1 How exactly does the modification made defeat this attack? So first, let's quickly recap how XCBC works: Receive a message m and three keys (k_1,k_2,k_3) with k_1 being the key for a block cipher (or a fixed-domain PRF) and k_2,k_3 being random strings of length n, the block cipher's block length (or the PRF's input length). Split m=m_1\mathbin\|... 1 There are two general approaches to parallelizing MACs: Use a universal hash like GHASH or Poly1305 whose algebraic structure admits essentially arbitrary levels of parallelism. For GHASH and Poly1305, the hash is polynomial evaluation: H_r(m_1 \mathbin\| m_2 \mathbin\| \dotsb \mathbin\| m_n) := m_1 r^n + m_2 r^{n-1} + \... 1 None of these constructions will lead to key recovery unless the underlying hash function is spectacularly broken in the sense of preimage resistance, which pretty much none of them are (archived). But key recovery is not usually what's directly relevant to your application. If you're using one of these constructions as a MAC, for example, what's relevant ... 1 If a PPT adversary can influence the key of a MAC function, is it still secure? In general probably no if you make no restrictions on the ways the key can be influenced. In particular the answer is "no" when you rely on your MAC actually being a PRF for your security proof (like HMAC does). This means that if your MAC relies on this then you need some ... 1 It is not hard to construct a secure MAC where f(k) = \textsf{MAC}(k,0) is not one-way. Take any secure \textsf{MAC} and define a new one as$$\textsf{MAC}^*\Bigl( (k_1,k_2), m \Bigr) = \textsf{MAC}(k_1,m) \oplus k_2.$$It should be relatively clear that$\textsf{MAC}^*$is also a secure MAC. Now given arbitrary$m$and$t$, it is easy to find a key ... 1 I want to know if the following would also be equally secure Yes, both schemes are equally secure. Also for what you are trying to achieve you really shouldn't puzzle things together yourself but rather use pre-made modes like AES-GCM, AES-EAX or ChaCha20-Poly1305. In fact, we can prove the above claimed security equivalence. Because Encrypt-then-MACis ... 1 By using SPAKE2, we can achieve this as Poncho said in comments. Let$s_a$be the salary of Alice Let$s_b$be the salary of Bob Let we have Ed25519 curve with the base point G. Exchange part; Alice pics a random scalar$x$and calculates$X = x\cdot G$and$T = s_1\cdot M+X$, where$M$is another point on ECC and sends the value$T$and$M\$ to Bob (...

1

Yes, the attacker does have the ability to make messages to appear to be from SenderA. In the end, the crypto_box functionality relies on a MAC, not a signature. That means that it depends on a shared secret key, rather than a private key for message authenticity. As explicitly stated by the protocol, this allows any message to be signed if you possess just ...

1

I suspect it is because you can still do a truncation attack under specific circumstances. Say an adversary obtains the tag of another message m' that is shorter than the original message m. Then the adversary can replace the first block from m (the one containing the length) with the first block from m', and also replace the first element in the tag for m ...

1

Why does HMAC do that? The process of expanding or compressing the key material to exactly one block length this way shouldn't be necessary from a security perspective. The reason for this transformation is to enable an optimization when the same key will be used to process multiple messages. (See RFC 2104) If this optimization is used, it means that you ...

1

Another option is to use an AEAD scheme (authenticated encryption with additional data). In each packet you can both send some data to be encrypted and authenticated and some data to be only authenticated. For example, ChaCha20-Poly1305 or AES-GCM.

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