AEAD Adds Integrity, Not a Login or a Working Route

An authenticated cipher returns two things at once: ciphertext that hides the content, and a tag that lets the receiver detect tampering. Those functions used to be assembled from separate pieces, and combining them badly produced subtle failures. Modern constructions specify the combination and the conditions under which it holds. The word authenticated in that sentence refers to the tag, not to a person.

Both guarantees apply to the protected packet, and neither extends to anything outside it.

Two Guarantees in One Construction

Encryption alone answers one question: can an observer read this? Message integrity answers another: has this been altered? A tunnel needs both, because content that arrives modified is worse than content that arrives unreadable. AEAD defines how to combine them under one key, together with associated data that is authenticated but not encrypted. The receiver rejects input that fails the check rather than treating altered plaintext as acceptable.

Associated data is how a protocol binds visible fields into the check. Which fields receive that treatment depends on the protocol, and the choice is not a promise that every outer address has become secret. A field can be covered by the tag while remaining readable on the wire.

The Nonce Is Not a Detail

These constructions require correct key and nonce handling, and the failure mode for nonce reuse is not graceful. Repeating a nonce under one key can expose relationships between messages and undermine the integrity guarantee entirely. That is why the protocol, not the application, usually owns nonce generation and sequencing. Hand-assembling a construction around a tunnel is how that responsibility gets lost.

The requirement is a condition of the guarantee rather than an implementation suggestion. A system that generates nonces carelessly does not provide the property it advertises.

Replay Protection Is Separate State

A valid old packet can be replayed even though its tag is intact, because the tag proves authenticity and not freshness. Replay handling needs its own state: sequence numbers, a window, and a rule about what to accept. That state lives in the protocol implementation and is unrelated to the cipher choice. A tunnel with strong encryption and no replay protection still accepts yesterday's traffic.

The two mechanisms cooperate without being the same mechanism, and one can be correct while the other is absent.

What the Tag Does Not Tell You

Peer identity is established by certificates or pre-shared keys, not by the fact that a cipher is authenticated. Routing, name resolution and the operator's logging policy sit outside the tunnel's cryptographic boundary altogether. A successful algorithm negotiation says the two ends agreed on a suite and nothing more. It is a statement about compatibility, not about the quality of the implementation on either side. Each of those is a separate question with its own evidence.

For users, the practical instruction is to select a maintained, supported protocol configuration. AEAD is a property of that configuration, not an invitation to construct encryption by hand around a tunnel.

Record which suite negotiated, whether replay protection is active and how peers are identified. Three facts, three different guarantees.