2
$\begingroup$

I'm studying Authenticated encryption with Associated Data (AEAD).

My questions are

  1. About AE - I heard that when it comes to Encrypt-then-MAC, if an attacker forges the ciphertext then he gets the wrong MAC value and can't decrypt the ciphertext to plaintext. Is this correct? If so, what is happening Encrypt-and-MAC and MAC-then-Encrypt? Isn't there a filter like Encrypt-then-MAC that filters out invalid ciphertext?

  2. Questions about the history of AE and AEAD. I wonder what the limitations of AE have led to the emergence of AEAD. In some papers, the limitation of AE is that it cannot effectively authenticate by binding associated data to ciphertext. If so, I would like to ask the following question: "Do I have to bind the associated data to the ciphertext?"

  3. About AEAD. The input of the encryption process is key, nonce, plain text, and associated data, and goes through some algorithm to return a ciphertext and a tag for authentication. The input of decryption process is key, nonce, ciphertext, associated data, tag, and plaintext if authentication is completed successfully, and an error is returned if there is a problem. However, for attackers, the key is not known during the decryption process. Moreover, I thought nonce was not even known by the attacker. In my opinion, the only information the attacker knows during the decryption process is ciphertext, related data, and tags. So, is the attacker attacking without knowing both key and nonce? So is AEAD called a strong cryptographic algorithm?

Improve this question
$\endgroup$
1
  • $\begingroup$ The answer requires a long writing and some of them are asked before: 1. 2. AD it really depends on the protocol. Some AD only needs integrity and authentication. 3. A nonce is public and no problem with that. The secret is the key. $\endgroup$
    – kelalaka
    Oct 21, 2019 at 10:47

1 Answer 1

Reset to default
1
$\begingroup$

I heard that when it comes to Encrypt-then-MAC, if an attacker forges the ciphertext then he gets the wrong MAC value and can't decrypt the ciphertext to plaintext.

Indeed, a forged ciphertext would immediately imply a forge on the MAC used therefore if the MAC is secure, the system is unforgeable.

If so, what is happening Encrypt-and-MAC and MAC-then-Encrypt?

They both also achieve authenticated encyption if done properly (that is if "tidiness" is achieved and you treat the nonce explicitly). However in the other cases there is a simple counter-example to these constructions' AE security: Namely pick a CPA-secure encryption scheme and append an unchecked random bit. Now for the attack, simply flip that bit and you get a "different" ciphertext which the decryption oracle will happily decrypt.

Do I have to bind the associated data to the ciphertext?

No, you don't have to bind associated data to the ciphertext. However, if there's context that needs to be sent publicly (such as routing information) or that is known by both parties and important to the state of the protocol (such as the current packet index), using associated data is a neat mechanism to conveying the correctness of the current state.

So, is the attacker attacking without knowing both key and nonce?

No, it's usually assumed that the adversary can see and change the nonce if they want to (which is why it must be MAC'ed as well). Also in common security definitions the adversary has access to a pre-keyed encryption / decryption function so they have some sort of "access to the key" though not directly.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thank you for your answer. I have some questions. In your 2nd answer, What does "nonce explicitly" mean? Does it just mean that the recipient can get a nonce value? And what do you think led to the emergence of AEAD? In your 4th answer, you said that "the adversary can see and change the nonce if they want to". However, in the paper RFC 5116, they says that the nonce is stored, sent with the plaintext or reconstructed. How can they change the nonce? $\endgroup$
    – pioneer
    Oct 22, 2019 at 1:51
  • $\begingroup$ @PioneerBaek "treating the nonce explicitly" means that the nonce is an explicit input to functions and not merely part of the ciphertext and generated at random. The RFC does say "The nonce MAY be [...] transported with the ciphertext" and as it's part of the ciphertext, an adversary can manipulate it before asking decryption queries. People used "sort of AEAD" in practice so it was formalised and they did use the "sort of AEAD" because they wanted to bind meta-data to the ciphertext and it was intuitive and easy to do with generic compositions. $\endgroup$
    – SEJPM
    Oct 22, 2019 at 7:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.