Who gets the key?: sources & model

Send a fictional note, become a network observer, and open the layers for which you have a key. Compare protected connections, end-to-end encryption and a VPN using real browser cryptography.

What supports the explanation?

What this model assumes

1. Original fictional phones, router, gateway, server cabinet and envelopes are illustrative geometry, not manufacturer CAD or a physical picture of cryptographic computation.
2. All keys are in this page’s runtime. Real operations do not turn the lesson into a secure messaging product or enforce isolation between people.
3. The connection, content and tunnel layers are original AES-GCM containers, not implementations of TLS, MLS or IPsec wire formats or handshakes.
4. Scenarios assume functioning algorithms, authenticated key setup, uncompromised endpoints and the shown key holders. Their role matrix is not a universal guarantee for all products.
5. Only fixed fictional messages are used. No message is sent to another person, no browser traffic is intercepted and no live VPN connection is created.
6. Fresh keys make normal sessions’ bytes differ. Shared links retain lesson settings, not private keys or a promise of independently decrypting an earlier session.
7. Reference-vector success checks specific numerical operations, not certification of an entire browser or product.
8. The paper shift cipher has only 26 possible shifts including no shift. It illustrates a boundary and is intentionally unsuitable for protecting secrets.
9. 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.
10. 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.
11. 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.
12. 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.
13. 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.
14. 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.
15. 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.
16. 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.
17. 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.
18. 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.
19. 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.
20. 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.

What has been checked

Analytical reference cases, conservation or transition invariants, finite drawing commands, bounded setup parsing, discovery and route integrity are checked automatically. These checks do not establish anatomical fidelity, learner outcomes or browser/device compatibility. Independent subject review, learner trials, comprehensive accessibility review and browser video encoding checks remain pending.

Each source supports the associated claim. Sources do not certify this implementation or its visuals.

About the cover illustration

Original fictional message route with phones, router, gateway and chat-service cabinet. Actual teaching scene, not manufacturer CAD, live network capture or a physical picture of encryption.