Who can read a message as it travels online?

Make a prediction before sending

Maya has a fictional message for Leo. With protected connections alone, can the chat service read it? The answer depends on where those connections end, not just whether a lock is pictured.

Follow the first connection

The initial connection key belongs to Maya and the service in our route. Nearby observers lack that key. At the service, the connection layer opens and reveals whatever was inside it.

Give the message its own inner layer

For end-to-end content protection, only the two phones hold the inner content key in this model. The service can pass that protected content along without being able to open it.

Start the next connection

The service uses a separate outgoing connection key toward Leo. Two protected connections through a service are not automatically the same thing as an inner end-to-end content layer.

Wrap part of the journey in a VPN

The tunnel ends at its gateway. The gateway can remove its own layer. If the remaining application traffic is unprotected, it can read it; if a separate connection layer remains, it does not automatically have that key.

Look beyond the message text

Size, timing, routing and account context can remain visible. A service may recognize a signed-in account even if the apparent network address changes. Hidden content is not the same as automatic anonymity.

Change one byte

Authenticated encryption checks the protected content and associated envelope information. With an altered ciphertext and unchanged key, nonce and tag, the receiver refuses to release plaintext. A refusal does not identify the person or event that caused it.

Choose the right kind of evidence

Encoding changes a representation. A hash computes a digest without a secret key. A signature can be checked with a public key. These operations answer different questions, and none alone establishes that an endpoint is honest.

The primitive is real; the route is a teaching model

This page uses the browser Web Cryptography API for AES-GCM, SHA-256 and ECDSA P-256. It does not perform a TLS handshake, operate a VPN or implement MLS. All role keys live in one page runtime; the role boundaries explain ownership but do not isolate real participants.

A precisely defined envelope

The original container has a six-byte header: version 1, layer code, then a four-byte big-endian message ID. It then stores a twelve-byte nonce, ciphertext and a sixteen-byte authentication tag. The header is authenticated associated data. One layer adds 34 bytes; this is not TLS or VPN overhead.

Count encoded bytes

UTF-8 encodes é as two bytes. Hi! is three bytes: one teaching envelope is 37 bytes, two nested envelopes are 71, and three are 105. Nesting encrypts the complete inner frame, including its existing header, nonce, ciphertext and tag.

Per-key nonces must not repeat

A fresh 128-bit AES key is generated with the browser cryptographic API. Each key owns a 96-bit monotonic nonce counter. A nonce is consumed before encryption begins, including concurrent requests. Resetting a counter requires replacing its key; none is derived from a short name or ordinary random-number generator.

Authentication can cover readable information

GCM associated data is checked but not encrypted. In the published examples, the same plaintext with the same public reference key and nonce can have the same ciphertext but a different tag when AAD changes. Those fixed examples are isolated tests, not instructions to reuse a nonce for fresh messages.

A shared-key tag is not a public signature

Any holder of the shared key can create a valid GCM envelope. A digital signature instead uses a private signing key and a corresponding public verification key. Calling that public key a particular person’s key requires a trustworthy association.

Verification does not conceal a message

ECDSA P-256 with SHA-256 checks the signature/message/public-key relationship. The message can remain readable. WebCrypto represents this signature as 64 bytes of fixed-width r followed by s, rather than ASN.1 DER.

A hash does not identify its author

SHA-256 gives a 32-byte digest. If someone changes both a message and its displayed unkeyed hash, the new pair can match. A trusted reference digest or an appropriately verified signature has a different role. This lesson does not teach raw SHA-256 as password storage.

An authenticated replay can still be a replay

A previously valid envelope can authenticate again. Our optional seen-message-ID rule declines repeated acceptance at the application layer. The rule is separate from AES-GCM, and turning it off does not make an unchanged tag invalid.

Key setup is an explicit assumption

The journey creates shared keys locally and assigns them to roles. Actual systems must establish and authenticate keys between endpoints. This lesson does not demonstrate secure key exchange, forward secrecy, group membership, recovery or compromised-device protection.

Metadata depends on the configuration

IP endpoints, approximate sizes and timing remain observable in our route. Hostname exposure depends on DNS protection, Encrypted Client Hello and deployment details. The VPN comparison assumes relevant traffic and DNS use the tunnel without bypasses; no live traffic capture is performed.

Confidentiality is not availability or endpoint control

A delivery service can withhold bytes it cannot decrypt. A recipient can copy or photograph content it legitimately opens. Cryptographic operations do not prevent every action at an endpoint or every inference about communication.

Understand an encrypted chat claim

Ask who holds content keys, where connections terminate, what metadata is retained and which endpoint assumptions apply. A single lock picture cannot answer all of these.

Understand a VPN’s role

Find the tunnel endpoint, then inspect the protection still present afterward. A gateway address, a connection layer and an authenticated service account are different aspects of a journey.

Check a file or message

Choose evidence suited to the question: representation, digest, shared-key authentication or a public-key signature. Keep the expected value and trusted key source attached.

Does someone need a secret key to read a Base64 message?

• Yes, because it looks scrambled
• No, it is a public encoding
• Only on a phone

A chat service receives a message on one protected connection and forwards it on another. Who can read it here?

• The chat service
• Automatically nobody between the phones
• Only a nearby network observer

Only the two phones hold the inner content key. What can the service do?

• Relay ciphertext without opening the content layer
• Receive no bytes at all
• Read the secret key from the public nonce

A VPN tunnel carries otherwise unprotected application traffic. Can its gateway read that traffic after opening the tunnel?

• No, a VPN automatically protects every later step
• Yes, in this setup
• Only if end-to-end encryption is also added

The service cannot decrypt end-to-end content. Does that prove it learns nothing?

• Yes, all communication facts disappear
• No; account context, timing or other metadata may remain
• Only the message’s font remains

A ciphertext byte changes but its tag, key and nonce stay the same. What should this receiver release?

• A partly garbled message
• The secret key so it can be repaired
• No plaintext; authentication failed

Someone changes both a file and the plain SHA-256 hash beside it. Does their new matching pair prove the original author approved it?

• Yes, every matching hash identifies its author
• No, anyone can compute this unkeyed hash
• Yes, if the digest has 64 hex characters

A public key verifies a signature on a readable message. What follows?

• The message is now secret
• The message can never be replayed
• It verifies under that key; whose key it is needs a trustworthy association

Transport confidentiality, integrity and endpoint boundaries

Current TLS 1.3 protocol specification. Our selected service is the connection endpoint; no TLS handshake is implemented here.

End-to-end architecture, delivery services and metadata limits

MLS architecture, especially security considerations. Mechanism reference, not a claim to implement MLS.

Tunnel boundaries and separate outer/inner packet protection

IPsec architecture, §§4–5. Generic encrypted-tunnel illustration does not imply every VPN uses IPsec.

Hostname visibility is configuration dependent

Encrypted Client Hello specification. Do not assume every HTTPS hostname is universally exposed or universally hidden.

Browser AES-GCM, SHA-256 and ECDSA operations

Stable W3C Recommendation. Unsupported operations show an explicit unavailable state.

GCM construction, associated data, failure and nonce requirements

Original NIST recommendation; this lesson uses 128-bit authentication tags.

Exact AES-128 GCM reference outputs

Worked examples 1, 2 and 4; independent expected bytes for both empty and nonempty plaintext. Derived mutation tests are identified separately.

Public Base64 encoding and reference cases

Sections 4 and 10. Encoding does not require a secret decoding key.

SHA-256 and public P-256 signature fixture

Section 8.1; verification uses the published public point and signature. Published private material is not used for visitor sessions.

Digital signature purposes and algorithms

FIPS 186-5 with its published errata notice. A signature does not encrypt readable content.

Reuse terms for NIST material

Distinguishes employee works, third-party material and Standard Reference Data. The lesson presents original tables of numerical facts with citation.