Authenticated Encryption mode & AEAD

Question

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?

Answer 1

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.