Hot answers tagged

22

Poly1305 is a universal hash function. The output of that function cannot be used safely without being encrypted. In order to encrypt it, any cipher can be used. AES was used as an example in the paper, but the very same paper mentioned: Users can switch from Poly1305-AES to Poly1305-AnotherFunction, with an identical security guarantee. All the efforts ...


13

What are those existing constructions? Usually people consider three to four scenarios for authenticated encryption for embedded environments: Constrained for ROM + RAM In this case you probably would want to use as few primitives as possible and using something like the EAX or CCM mode to use your block cipher for both authentication and encryption. (...


12

I don't think there is any official limitations when it comes from standardization bodies such as NIST. However, there do seem to be some papers such as New Generic Attacks Against Hash-based MACs. They show that HMAC may have less security than previously thought after the birthday bound. Generally, if you have a hash output size of, say 256 bits for SHA-...


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


7

Poly1305 today is generally used as part of some AEAD construction alongside Salsa20/ChaCha20, because the key advantage of all of these algorithms is excellent performance in platforms that don't have hardware AES support. Most notably these days, that would be low-end phones and tablets. And one of the big pushers for the standardization and adoption of ...


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

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


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

HMAC is a type of MAC. The output of a MAC is called a "tag". Not all MAC (algorithms) are HMAC. MACs are not required to be one-way or collision resistant for someone who knows the key. HMAC, however, inherits the one-way-ness and collision resistance of the underlying hash function. A CBC-based MAC is mentioned as a hint because it is almost trivial to ...


5

You misunderstood something. HMAC-SHA-1 does not use SHA-1 as the signing algorithm. The signing algorithm is the HMAC-SHA-1 calculation, not an intermediate SHA-1 calculation. The signing algorithm takes the key and the message as inputs and produces the MAC value as output. The usual terminology for the hash algorithm that an HMAC construction uses is “...


3

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


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


3

In modern cryptography it is generally assumed that algorithms are public and only the key is kept private. Thus, the adversary can compute $\operatorname{Mac}(k', m)$ for any key $k'$ and message $m$. The oracle $\operatorname{Mac}_k(\cdot)$ in the experiment allows $A$ to additionally receive valid macs under the challenge-key $k$ for which it is supposed ...


3

VMAC was a joint work by Wei Dai and Ted Krovetz. It so happens that Wei Dai at that time was also actively working on his own cryptographic library (Crypto++), which of course also includes VMAC. You can find the test vectors here and the optimized implementation here. Two examples for VMAC-AES-128 are: Key: "abcdefghijklmnop" IV: "bcdefghi" Message: "" ...


3

While this could be misleading, it is ultimately serving the same purpose here, just with a symmetric key instead of an asymmetric one. Just as an asymmetric signature provides proof of ownership of the private key, a MAC provides proof of ownership of the symmetric key. Depending on how this key comes into existence this may provide varying levels of real-...


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

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

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

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

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

Does a reuse of the Mac key reveal information about the key itself ? One would certainly hope not - Message Authenticate Codes are supposed to be able to be safely used with the same key multiple times. There is one caveat - the Poly1305 algorithm does need a nonce, which must be different whenever you MAC a message (specifically, you cannot reuse the ...


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


2

Why is the comment needed that encrypted MAC part is constant? With the scheme in the question, in a cryptogram with the correct MAC, the last block of the encrypted message is a constant. Importantly, that goes both ways: if the last block of the encrypted message is that constant, then the MAC is correct and whatever plaintext is deciphered will pass the ...


2

A cryptographic MAC is always symmetric By Definition. For those interested in its security properties, one may want to know Does data authenticity always, implicitly, provide data integrity? The tool that provides authenticity asymmetrically is known as Digital Signature. Digital Signatures are asymmetric By Definition; they guarantees the integrity, ...


2

Recall the definition: a cipher is AE-secure iff it is secure against chosen ciphertext attacks and has ciphertext ingegrity. Try going through the attack games with $(E_1,D_1)$ and $(E_2,D_2)$: if the adversary succeeds, can he succeed for $(E,D)$? It's fairly easy to see that $(E_1,D_1)$ and $(E_2,D_2)$ are CPA-secure. If the adversary can distinguish ...


2

Think about 2 special cases when using AEAD: Some confidential data but blank associated data Some associated data, but blank confidential data In first case what you get when using AEAD cipher (e.g. AES-GCM) is just Authenticated Encryption, as there is no associated data. In second case what you get when using AEAD cipher (again, e.g. AES-GCM) is ...


1

With the capacity of SHA-3[1] against length extension, It doesn't need HMAC where the key is used twice to build a secure MAC. Instead one can design with prepending the message with the key. Actually, NIST already standardized this into The KECCAK Message Authentication Code KMAC. With the fixed key and message size, your scheme can be considered as keyed ...


1

A plain MAC algorithm acts as a deterministic function of the key, message, and (maybe) a nonce. Every time you evaluate the function you get the same results. Mathematical functions do not know whether or not they're being evaluated for the first time. Replay attack protection has to be employed at the level of the protocol. Software, not math, is ...


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