Key points
- Confidentiality hides plaintext; authentication detects modification.
- Associated data is authenticated but not encrypted.
- A nonce must not repeat with the same key.
- AEAD does not authenticate a user identity unless the wider protocol binds one.
Why encryption needs integrity
Encryption alone can hide content while still allowing an attacker to alter ciphertext in meaningful ways. AEAD returns a ciphertext and authentication tag; decryption fails if the protected bytes or associated data do not match. Applications should treat that failure as a hard error and never release partial plaintext.
What associated data is for
Associated data can bind visible protocol context—such as a version or record type—to the ciphertext. The recipient supplies the same associated data during decryption. A mismatch invalidates the tag. Because associated data is not encrypted, it must not contain secrets.
Nonce uniqueness is a security requirement
RFC 8439 requires a nonce that is unique for each invocation with the same key. Reusing a nonce with ChaCha20-Poly1305 can reveal relationships between plaintexts and undermine authentication. Systems use counters, random generation with bounded risk, or fresh per-message keys to maintain uniqueness. [1]
A nonce is not a secret. Its job is to ensure that encrypting under one key does not reuse the same keystream and authenticator conditions.
Common questions.
Is ChaCha20-Poly1305 encryption or hashing?
It is an authenticated-encryption construction: ChaCha20 encrypts and Poly1305 authenticates.
Can the nonce be public?
Yes. It must be unique for a given key, but it does not need to be secret. [1]
Does AEAD prevent replay attacks?
Not by itself. A previously valid ciphertext can still be replayed unless the application tracks sequence numbers, versions, timestamps, or other freshness state.
Primary sources
Definitions prefer standards bodies, government guidance, and the first-party SealTask architecture. Links open the complete source.
- 01 RFC 8439: ChaCha20 and Poly1305 for IETF Protocols The ChaCha20-Poly1305 AEAD construction and nonce requirements.
- 02 SealTask security architecture Product-specific encryption boundary, server visibility, protocols, and current limitations.