A
Authentication
Who is at the other end? Authentication binds a cryptographic identity or key to a person, device, organisation or account.
Abstract
Most explanations of secure messaging begin with algorithms. That is backwards. A communication system can use excellent encryption and still fail if the parties never establish who is actually at the other end.
A secure channel needs three properties: authenticity, integrity and confidentiality. Two of them are largely solved. Modern authenticated encryption delivers integrity and confidentiality reliably, and has done for years. Authentication is where channels genuinely differ — and they differ in a specific way: in how and when the parties establish who is at the other end. This guide proposes a three-level classification on exactly that axis, and shows how it determines whether a man-in-the-middle can succeed.
The central idea: encryption can protect a message from eavesdroppers, but only authentication tells you whose key you encrypted it to. The strength of a secure channel is therefore bounded by its weakest trust-establishment step.
The three pillars
I
Integrity
Was anything changed? Integrity lets the receiver detect modification, substitution, insertion or corruption of a message.
C
Confidentiality
Who can read it? Confidentiality prevents anyone outside the intended set of recipients from learning the message contents.
A modern secure channel generally needs all three. Encryption without integrity is often unsafe. Integrity without authentication may prove that a message was not altered without proving who originated it. Authentication without confidentiality can be perfectly valid for public statements but not for private conversations.
The three are not independent, and one of them has to come first. A message authentication code proves a message came from whoever holds the key — but which key you hold is the authentication question. So integrity and confidentiality are solved once you know whose key you have: pick a mature authenticated-encryption construction and both follow. Authentication is the one an algorithm cannot give you. It has to come from outside the mathematics — a meeting, a comparison, or somebody else's word.
Why this guide is shaped the way it is: if two of the three pillars are handled by picking good primitives, then the interesting design space is the third. Everything that follows classifies channels by how they answer it.
Before cryptography: name the adversary
“Secure” is not an absolute property. A system must say what it is secure against. A passive observer merely listens. An active attacker can intercept, replace or inject traffic. A compromised service can lie about keys. A compromised endpoint can simply read plaintext before encryption or after decryption.
Alice
endpoint
endpoint
→
Network
hostile by default
hostile by default
→
Bob
endpoint
endpoint
Cryptography is extraordinarily good at protecting data between trustworthy endpoints. It cannot make a malware-infected phone trustworthy, and it cannot infer a human identity from a public key unless some authentication process establishes that binding.
The three-level trust ladder
Before you can trust a channel, it has to answer one question: who checked that this key really belongs to that person — and when did they check?
Level 1The two parties check each other's keys in person, before the channel exists.
Level 2They connect over the network first, then check each other through a separate channel.
Level 3Somebody else does the checking — a certificate authority, account provider, company directory, or a peer who vouches.
There are three levels rather than some other number because only three parties can do the checking: the two of you standing together, the two of you apart, or somebody else on your behalf. When the check happens follows from who does it — and the timing is what decides how hard an attacker's job is.
| Level | How authentication happens | When, relative to the channel | A man-in-the-middle must |
|---|---|---|---|
| 1 In person | Physical presence — QR scan, fingerprint comparison, key transfer, device provisioning | Before the channel exists. There is no unauthenticated window. | Defeat the physical exchange. Network position does not help. |
| 2 Remote + OOB | Keys are agreed over the network; humans then compare a safety number, security code or QR through an independent channel | After the channel exists. A window opens at pairing and closes only if the check is actually performed. | Survive the out-of-band channel as well as the network — or rely on the check never happening. |
| 3 Third party | Someone outside the conversation vouches for the key: a certificate authority, account provider, company directory, or a peer who signs it | At every connection, performed by someone other than the users. | Become, compel or compromise the authority — or subvert the endpoint's trust in it. |
One rule cuts across all three: any party that generates or holds key material is in your trust graph, whatever level the system is otherwise classified as. That covers a key distribution centre issuing session keys, a cloud backup of your private keys, and a vendor that injected keys during manufacture. Delegation is usually visible in a system's design; custody often is not.
Important: “Higher level” here means greater reliance on parties outside the conversation, not “worse.” Level 3 carries the modern internet and is frequently the correct choice. The ladder describes where trust comes from, not how good a system is.
1In person
Checking happens before the channel exists
The two parties are in the same room when they check each other's keys — scanning a QR code, comparing a fingerprint, handing over a public key, or loading devices from a station they control — and only then open a channel.
This level removes the need to trust a remote directory to tell Alice which public key belongs to Bob. The meeting establishes that binding directly. After that, the system can use public-key cryptography for key agreement and signatures, then fast symmetric authenticated encryption for normal traffic.
What sets Level 1 apart is timing, not cryptography. The checking is finished before any traffic flows, so there is never a moment when a working channel is sitting there unverified. Nobody can slip into the middle of a conversation that happens face to face — they would have to break into the meeting itself, and no amount of control over the network gets you that.
The same pattern works at very different scales. Two people scanning each other's phones is Level 1. So is a company loading a fleet of devices from an offline station before sending them out: someone is physically present with every device, the keys never cross a network, and afterwards the devices can talk to each other or back to base with the question of who is who already settled.
There are relatively few mass-market systems that require an in-person ceremony, because it adds friction. But the pattern is common in high-assurance systems, hardware provisioning, closed organisations and manual key-signing workflows.
Examples: Briar's nearby-contact workflow has both people scan each other's QR code while physically together; Briar explicitly describes this as ensuring that the contact is the right person. OpenPGP/GnuPG can likewise reach this level when a fingerprint is checked directly with the key owner in person. Signal, WhatsApp or Element can also be operated at Level 1 when their contact verification is performed face-to-face before the channel is trusted.
The cost is distribution, not security: Level 1 scales badly for exactly the reason it is strong — somebody has to physically be somewhere. It fits closed groups, sensitive peer relationships and device fleets with planned logistics, not open social messaging, where the people who need to talk have generally never met.
2Remote + OOB
Authentication after the channel exists
Cryptographic keys are established over a network first. The users then have a second, independent mechanism for checking that those keys correspond to the intended person.
The defining feature is a window. Between the moment the channel is established and the moment the out-of-band check is performed, the endpoints are talking securely to somebody — and nothing in the cryptography says who. The window closes when a human compares the two sides through a channel the network attacker does not control. If nobody ever performs that comparison, the window never closes, and the identity assurance quietly falls back to whatever the service asserted during onboarding.
Signal is a useful example of this architecture. Its protocols establish shared secrets using public-key cryptography, while one-to-one chats expose a safety number that users can compare or verify via QR. Signal explicitly recommends comparison in person or through another trusted channel when automatic verification is unavailable. WhatsApp similarly exposes a per-chat security code that can be used to verify an end-to-end encrypted connection.
Examples: Signal safety numbers, WhatsApp security codes and Matrix/Element interactive verification all fit this pattern. They can establish encrypted device-to-device channels automatically, then give users a separate mechanism for validating the cryptographic relationship.
The critical distinction is that the cryptographic channel may exist before the human has strongly authenticated the remote identity. The out-of-band check upgrades confidence in the key-to-person binding. If users never perform it, part of the identity assurance remains delegated to the service's onboarding and key-distribution mechanisms. For especially sensitive relationships, verification should not merely happen once: unexpected key or safety-number changes should be treated as security events and independently re-checked.
Design principle: make key verification understandable, rare and visible. A security mechanism that every ordinary user ignores is weaker in practice than its mathematical description suggests.
3Third party
Authentication performed by someone else
The system trusts an external authority or platform to establish identity: an email account, phone number, OAuth provider, enterprise identity system, public certificate authority, app account or similar directory.
Here the users never check anything themselves. It happens automatically on every connection, done by someone who is not part of the conversation. That is what lets this level work for billions of strangers — and what puts another organisation permanently inside the circle of people you have to trust.
This is the normal model for public web applications. Examples include online banking websites, SaaS applications, ecommerce sites, ordinary email web interfaces, government portals and almost any app whose authoritative identity is an account on the provider's server. TLS can create a strongly encrypted and integrity-protected connection to that server, while a password, passkey, social login or enterprise identity provider authenticates the user. This can be extremely secure, but the trust graph now includes additional organisations, account-recovery procedures, server infrastructure and policy.
Level 3 should not be read as “weak encryption.” A Level 3 application may use excellent modern cryptography. The classification says that human or organisational identity is principally asserted by third-party infrastructure rather than by direct verification between the communicating parties.
Where Level 3 bottoms out: a delegated root is only as good as the step that installed it. A browser accepts a certificate authority because that authority's key was already in the operating system's trust store — put there by the vendor, carried through manufacturing and software distribution, and accepted along with physical possession of the device. So the checks Level 3 makes on every connection rest on the same kind of physical act as Level 1: somebody put a key on your device before any conversation existed. That is what stops the ladder going round in circles — every source of trust, however distant it looks, ends at a physical act that a person carried out and a person decided to trust.
End-to-end encryption is not the same thing as end-to-end trust
The phrase “end-to-end encrypted” answers an important question: where does plaintext exist? It does not, by itself, answer the equally important question: how do I know whose endpoint holds the other key?
In the strongest sense, an end-to-end channel should terminate cryptographically only on the intended endpoints, while those endpoints also have an independently authenticated binding to the people or devices they are supposed to represent.
| Level | Can content be endpoint-to-endpoint encrypted? | When can the endpoint identity be fully trusted? |
|---|---|---|
| 1 | Yes. The in-person exchange directly defines the communicating endpoints. | Immediately. The checking was done before the channel opened, so there is never a moment of doubt. |
| 2 | Yes; this is what Signal, WhatsApp and Matrix-family systems can provide. | Only once the out-of-band verification is actually performed, and only for as long as subsequent key changes are noticed and re-validated. |
| 3 | Usually the protected path is device ↔ service, even if every network hop is encrypted. | The service is the authenticated remote endpoint. It can ordinarily access plaintext or act on the user's behalf unless a separate application-level E2EE scheme exists. |
A useful language distinction: Level 3 can have excellent transport encryption, including TLS from the user's device all the way to the application's server. But that is not person-to-person end-to-end encryption: the server is one of the ends. “Encrypted all the way to the server” and “encrypted so the server cannot read it” are fundamentally different properties.
Level 2 needs one further qualification. Signal's own documentation notes that its safety number verifies the security of a particular one-to-one cryptographic relationship; it does not magically prove a person's civil identity. The human still needs a trusted comparison channel. Once a contact has been deliberately verified, unexpected key changes become meaningful and should be investigated rather than silently accepted.
Man-in-the-middle attacks in the real network
A MITM attack is not primarily about “breaking encryption.” It is about convincing each endpoint to establish a secure connection with the attacker instead of with the intended peer.
Alice
thinks she reached Bob
thinks she reached Bob
→
Mallory
terminates one secure channel
and creates another
terminates one secure channel
and creates another
→
Bob
thinks he reached Alice
thinks he reached Alice
1. Traffic steering is not yet decryption
An on-path network — an ISP, Wi-Fi operator, enterprise gateway, mobile carrier or other routing intermediary — can potentially influence where packets travel. DNS manipulation can also cause a hostname to resolve to an attacker's IP address. But with correctly validated HTTPS, merely redirecting the packets is not enough: the attacker's server must still present credentials that the client accepts for the requested name.
2. DNS tells you where to go; TLS asks who answered
Traditional DNS was not designed to provide strong cryptographic authentication of every answer. This is why DNS poisoning or resolver manipulation is an important threat. HTTPS adds a separate authentication layer: the browser or app validates the server certificate and its name before trusting the connection. Thus DNS control can steer a victim toward the wrong machine, but a normal TLS client should reject that machine unless the certificate trust problem is also solved.
3. The operating system's root store is a trust boundary
Modern operating systems and browsers ship with trusted certificate-authority roots. Android, for example, documents a system-wide set of installed certificate authorities; applications may also deliberately restrict or customise their trust anchors. A public website certificate is accepted only if a valid chain ultimately reaches a trust anchor the client accepts.
This produces an important theoretical MITM condition: an interceptor that can both control the path and cause the endpoint to trust an interceptor-controlled certificate authority can transparently create one TLS session toward the user and another toward the real site. Enterprises sometimes do this intentionally on managed devices for traffic inspection. The security boundary is therefore not just “AES is strong”; it includes the integrity of the endpoint's trust store and certificate policy.
Defensive boundary: this guide deliberately describes the prerequisites and trust relationships rather than instructions for spoofing particular sites, obtaining fraudulent certificates or deploying interception infrastructure. The useful lesson is architectural: routing control alone does not defeat authenticated TLS; the attacker also needs to defeat or become part of authentication.
4. Mobile-network interception and lawful access
Telecommunications standards define lawful-interception architectures in which network operators or service providers can deliver authorised intercept information to law-enforcement interfaces. At the network layer this can provide visibility into traffic and metadata available to the operator. It does not imply that an operator can mathematically decrypt arbitrary correctly implemented application-level E2EE.
A carrier-controlled “checkpoint” can be thought of as an on-path enforcement point: traffic can be observed, blocked, delayed or routed through infrastructure under operator control. For ordinary unencrypted traffic that may reveal content. For HTTPS it still encounters certificate authentication. For independently authenticated Level-1 or properly verified Level-2 E2EE, rerouting the packets does not give the intermediary the endpoint keys.
5. Why each level reacts differently
This is where the when of authentication pays off. Each level hands the attacker a different problem.
Level 1: the checking finished before the channel opened, so there is no moment to attack. Anyone sitting on the network arrives after the question is already settled. To get anywhere they would have had to be at the meeting — which is not a network attack at all.
Level 2: the service can assist with discovery and key delivery, but a correctly performed out-of-band comparison gives the users a way to detect a substituted identity key. A planned MITM must therefore survive the independent verification channel as well. This is exactly why key-change warnings and repeated verification matter — and why an attack here is really a race against whether the humans ever look.
Level 3: the user intentionally trusts a service endpoint. If the service itself is compelled, compromised or instrumented, it may already possess the plaintext because it is an endpoint. Network MITM is therefore only one of several paths to the data, and often not the easiest one.
The mathematical point: the encryption primitive can be flawless while the protocol fails around it. MITM resistance comes from authenticating the key exchange, not from simply increasing key length.
Two very different meanings of “hard to break”
Information-theoretic security
Security follows from the information available to the attacker, not from limited computing power. A correctly used one-time pad is the canonical example for confidentiality. More computation does not resolve the ambiguity in the ciphertext.
Computational security
Security depends on a problem being infeasible with realistic resources. AES, modern hash functions, elliptic-curve cryptography and post-quantum schemes live here. We do not claim an attack is mathematically impossible; we claim the required work is beyond an adversary's feasible capability under stated assumptions.
Most real systems deliberately choose computational security because it scales. A 256-bit symmetric key can protect enormous amounts of traffic, while a true OTP requires secret random material roughly equal to the protected plaintext volume.
The one-time pad is worth understanding as the limiting case. A true OTP combines plaintext with a key that is uniformly random, at least as long as the plaintext, kept secret and never reused. Under those conditions the ciphertext alone reveals no information about the plaintext, even to an adversary with unlimited computation.
That is a claim about confidentiality and nothing else. A raw OTP does not provide integrity or source authentication, so a design that wants those must reserve separate secret material for a message authentication construction. The pad must also genuinely be a pad: material produced by expanding a short seed through a deterministic generator is a stream cipher with computational security, whatever it is called.
This is a separate question from the ladder. Choosing a one-time pad changes the kind of secrecy you get. It tells you nothing about who is at the other end. A pad handed over in person is Level 1 because of the meeting, not because of the pad — and the same pad delivered by a courier you have never met authenticates nobody.
Symmetric and asymmetric cryptography have different jobs
Symmetric cryptography uses the same secret (or closely related secret material) on both sides. It is fast and is normally what protects message payloads. Modern designs use authenticated encryption so confidentiality and integrity are provided together.
Asymmetric cryptography separates public and private keys. Its great advantage is not that it encrypts data “better”; it solves distribution and authentication problems that become painful at scale. It is commonly used to agree on shared secrets, authenticate keys and produce digital signatures.
| Level | Key establishment | Payload protection | Typical role of asymmetric crypto |
|---|---|---|---|
| 1 | In-person authenticated public key or shared secret | Symmetric AEAD; a pre-shared pad where the threat model justifies it | Optional — useful for scalable key agreement and signatures after the physical authentication, but not required |
| 2 | Network key agreement + out-of-band verification | Symmetric ratcheting / AEAD | Essential to remote initial key agreement and identity-key authentication |
| 3 | Platform / PKI / account provider / server-assisted exchange | Symmetric session encryption | Essential for TLS, certificates, passkeys, signatures, public-key identity systems |
Randomness: TRNG, CSPRNG and why the distinction matters
A cryptographic system needs unpredictability for keys, nonces, salts and challenges. Two sources are often confused.
TRNG / entropy source
A physical process produces nondeterministic entropy: thermal noise, oscillator jitter or another measured phenomenon. In standards language, the important concept is a validated entropy source, not merely a marketing label saying “true random.”
CSPRNG / DRBG
A deterministic cryptographic generator expands a secret seed into a long stream of unpredictable-looking bits. If properly seeded and designed, it is appropriate for cryptographic key generation in mainstream computational systems.
For ordinary computational systems — which is to say almost everything, at every level — a well-designed operating-system CSPRNG/DRBG seeded from adequate entropy is the normal choice. It is efficient and exactly what modern cryptographic libraries are built around.
If you are building a one-time pad, the requirement changes. A design claiming information-theoretic confidentiality needs pad material with genuine statistical randomness and secrecy; a deterministic generator expanding a short seed into a long “pad” converts the construction into a stream cipher with computational security instead. A hardware entropy source may therefore be used to generate the pad, with careful health testing, storage and distribution.
Rule of thumb: never implement “randomness” with a general-purpose PRNG such as a simulation or game RNG. Use the platform's cryptographic random API unless you are deliberately building and validating an entropy subsystem.
Comparison matrix
| Property | Level 1 — in person | Level 2 — remote + OOB | Level 3 — third party |
|---|---|---|---|
| Who authenticates | The endpoints, physically together | The endpoints, at a distance | An external authority, on their behalf |
| When | Before the channel exists | After the channel exists, if the check is performed | At every connection |
| Window of doubt | None | From connecting until checking — forever, if nobody ever checks | None for the user, but the authority is trusted permanently |
| Network MITM resistance | Strong; a network position gives no purchase | Strong after correct OOB verification, weak before it | Depends on the third-party trust chain and the endpoint's trust store |
| Scalability | Low | High | Very high |
| User friction | High | Medium | Low |
| Best fit | Closed groups, sensitive peer relationships, device fleets | Private human messaging between people who have not met | Public apps, web services, enterprise systems |
A design recipe
Start with trust, not algorithms.
1. Identify endpoints. Decide whether the identity you need is a device, account, person, organisation or role. These are not interchangeable.
2. Choose how and when authentication happens. A physical ceremony, an out-of-band check after remote pairing, or an external identity provider each create a different failure model — and, just as importantly, a different window during which an attacker can act.
3. Authenticate before trusting payloads. Ensure the cryptographic key is bound to the entity you intend to communicate with.
4. Use authenticated encryption for data. In computational systems, prefer established AEAD constructions through mature cryptographic libraries rather than assembling encryption and MAC primitives manually.
5. Design key lifecycle explicitly. Generation, storage, rotation, revocation, device replacement, recovery and deletion are part of the protocol.
6. Treat metadata separately. End-to-end encryption may hide message content while exposing who talked to whom, when, how often and from which network.
7. Make compromise recoverable. Modern messaging protocols increasingly aim for forward secrecy and post-compromise security so one stolen key does not expose an entire communication history or permanently poison future sessions.
What this model deliberately leaves out
This three-level ladder is a teaching model, not a replacement for a full protocol threat analysis. It classifies two-party channels, and it classifies a relationship at a moment in time rather than a piece of software: systems move between levels depending on how users operate them. Signal with no manual verification and Signal after an in-person safety-number check do not have identical identity assurance, even though the software is the same.
It also assumes correct implementation. The ladder classifies where trust is rooted, not whether the code around that root is sound. Nonce management, pad synchronisation, replay and ordering, state handling, memory safety, side channels and library misuse can each defeat a design that is faultless at this level of description. Those failures are real and historically common, but they belong to implementation review rather than to architectural classification.
The model also does not rank endpoint security, anonymity, metadata protection, coercion resistance, traffic analysis resistance, availability, deniability, forward secrecy, post-compromise security, legal compulsion or supply-chain integrity. These deserve separate axes.