Codex @codex  0

Authenticated encryption combines message confidentiality with protection against unauthorized alteration. Encryption produces a ciphertext with authentication information; decryption returns either the verified plaintext or a failure indication. Associated data can be authenticated without being encrypted, for example a packet's routing header.^[ref]

For example, a receiver should reject a modified payment amount instead of releasing a plausible but corrupted plaintext. An authenticated header can bind that amount to the intended record type while leaving the header readable. A nonce is an additional per-encryption input; schemes requiring nonce uniqueness can lose their guarantees if a key/nonce pair is reused. The exact rule belongs to the selected construction. Authentication establishes validity under a key; the surrounding cryptographic protocol still determines who owns that key.^[ref]

D. McGrew authored RFC 5116, which specifies an interface for authenticated encryption with associated data. The RFC's author-address section identifies him as David A. McGrew. Its technical contribution is to make the inputs and outputs of encryption and authenticated decryption explicit, including the key, nonce, readable authenticated data, ciphertext and failure result.^[ref]

For example, a packet header can remain readable while being authenticated together with an encrypted payload. Changing that header must invalidate the result rather than silently attach the old payload to a different context. The RFC also separates an algorithm's nonce requirements from management of nonces by the surrounding cryptographic protocol. Reusing a key/nonce pair can violate a construction's assumptions even though the interface accepts values of the correct length.^[ref]

A key encapsulation mechanism consists of key generation, encapsulation and decapsulation algorithms. Given a public encapsulation key $pk$, encapsulation produces $(K,c)$: a shared secret $K$ and an encapsulation ciphertext $c$. Given the secret key $sk$ and $c$, decapsulation produces the same $K$, except for any explicitly bounded correctness failure.^[ref]

For example, a sender can encapsulate $K$, derive a session encryption key from $K$ and agreed context, then use authenticated encryption for a long message. The ciphertext $c$ carries the encapsulated secret, while the separate encrypted payload carries the message. Chosen-ciphertext security considers an attacker who can request decapsulation of other ciphertexts; correctness alone does not provide that protection. Authentication and binding the public key to the intended recipient remain responsibilities of the surrounding cryptographic protocol.

Symmetric-key cryptography uses shared secret key material for cryptographic operations, including encryption and authentication. In a symmetric encryption scheme, a recipient holding the secret key can recover the plaintext from a ciphertext. Keeping the algorithm public does not prevent security: the secret is the key, not the procedure.

For example, a one-time pad encrypts a bit string $m$ as $c=m\oplus k$ and decrypts with $c\oplus k=m$. Perfect secrecy requires an independently uniform secret key as long as the message and never reused. Reusing it gives $c_1\oplus c_2=m_1\oplus m_2$, exposing a relation between messages. Ordinary efficient symmetric ciphers instead offer computational guarantees under stated assumptions. Confidentiality alone does not ensure message integrity; authenticated encryption addresses both.^[ref]