Modern security rests on a paradox rarely stated explicitly: each layer of protection you add shifts trust toward an actor you do not control, without eliminating it. Understanding this shift is a prerequisite for any honest reasoning about privacy.
The Myth of the Chain Without a Weak Link
An engineer designing a secure system naturally thinks in layers: end-to-end encryption, strong authentication, secure key storage, boot integrity. Each layer is audited, documented, justified. The final result gives an impression of a fortress. It is precisely this impression that is dangerous.
Absolute privacy would require a property that computing has never achieved: being master of the entire processing chain, from silicon to application. In practice, this chain includes at minimum a processor whose microcode you do not control, a compiler whose integrity you cannot verify at every build, and one or more hardware components whose firmware is proprietary. Real security is not the absence of trusted third parties; it is a reasoned choice about the nature and position of those third parties in your threat model.
Three points illustrate this shift in a concrete and verifiable way.
The TPM Seals Your Secrets in a Black Box You Cannot Open
The Trusted Platform Module has become the cornerstone of secure key storage on modern architectures. Its principle is solid: a dedicated chip, isolated from the main processor, capable of generating non-extractable keys and conditioning their use on the measured state of the system via PCRs (Platform Configuration Registers). Ubuntu Core explicitly uses it to seal LUKS2 keys directly to the TPM at boot — if the firmware, bootloader, and kernel hashes match the recorded state, the key is automatically released. Otherwise, the disk remains encrypted with no recourse.
It is elegant. It is also a total delegation of trust to the chip manufacturer.
In 2017, a critical vulnerability called ROCA (Return of Coppersmith's Attack, CVE-2017-15361) was discovered in Infineon TPMs. The RSA key generation library embedded in the firmware produced keys whose prime factors followed a reducible pattern, bringing the factorization complexity of RSA-2048 down to a practically attackable level. Millions of chips deployed in laptops, smart cards, and authentication tokens were affected. The flaw resided in closed, non-auditable code, on a chip certified Common Criteria EAL4+. The certification had not detected the problem.
The fix required a firmware update, distributed by laptop manufacturers, not directly by Infineon, with variable delays depending on the OEMs. During this window, any system relying on the non-extractability of RSA keys generated by those TPMs had a security guarantee worth nothing.
This is not an argument against the TPM. It is an argument against the illusion that the TPM eliminates dependence on a third party. It concentrates it. You have replaced the diffuse weakness of a human password with a precise dependency on Infineon, STMicroelectronics, Nuvoton, or AMD depending on your hardware — companies subject to jurisdictions, legal constraints, and commercial imperatives you do not control. AMD fTPM and Intel PTT are firmware implementations integrated directly into the main processor: the boundary between "dedicated isolated chip" and "code running on the main CPU" becomes blurred.
Google's OpenTitan project is the structurally coherent response to this problem: a root-of-trust whose hardware design and firmware are public and auditable. It is available on some recent Chromebooks. For the rest of the market, the situation has not fundamentally changed.
End-to-End Encryption Only Encrypts What the Application Chooses Not to See
Signal is the reference implementation of end-to-end encryption for messaging. The Signal Protocol (Double Ratchet + X3DH) is public, audited, and formally verified by independent cryptographers. The cryptographic properties are real: forward secrecy, authentication, protection against long-term key compromise.
A common confusion is to conflate the properties of the protocol with the properties of the application.
End-to-end encryption protects message content in transit between two clients. It says nothing about what the client does with the content once decrypted. On Android, the Signal app runs in a process that can be subjected to memory extraction by the operating system if it is compromised. Signal's encrypted backups on Google Drive use a key derived from the user's PIN, stored in an HSM managed by Signal — you trust Signal not to have exploitable access to that HSM. Metadata (who contacts whom, at what frequency) is not encrypted in the same way as content, and Signal collects a minimum but still collects some.
A more direct example: WhatsApp implements the Signal Protocol for message encryption. Contact metadata and usage frequency flow to Meta. The encryption is real. The privacy from Meta is not. This is not a technical flaw — it is a deliberate design choice, but it illustrates precisely the point: the cryptographic protocol and the application are two distinct objects, with distinct trust models.
TerminalPhone, the Bash encrypted communication project over Tor that we mentioned in the introduction, pushes this reasoning to its logical conclusion: no third-party server, no account, no centralized metadata, a .onion address as the sole identity. The trust model is reduced to the minimum — Tor Project, OpenSSL, and the underlying OS. It is coherent. It is also a sign that reducing the trust surface demands ergonomic compromises that few users are willing to accept.
The Compiler You Didn't Audit Compiles the Code You Did Audit
In 1984, Ken Thompson published "Reflections on Trusting Trust," a text that remains one of the most disturbing contributions in the history of computing. The demonstration: it is possible to inject a Trojan horse into a compiler so that the produced binary is compromised, even if the source code is perfectly clean. The modified compiler re-injects itself during its own recompilation. Reading the source code reveals nothing. Only analysis of the produced binary can detect the anomaly.
This is not a dated academic exercise. The build chain of a modern system involves: a compiler (GCC, Clang/LLVM) for which you have not personally compiled every version from original sources, system libraries (glibc, OpenSSL) whose distribution binaries are produced by third parties, a kernel whose build process is controlled by distribution teams, and UEFI firmware whose source code is only partially available (EDK2 is open source; manufacturer blobs are not).
The 2020 SolarWinds attack materialized exactly this threat at scale: the build chain of SolarWinds Orion was compromised, producing binaries signed with the company's legitimate certificate but containing a backdoor. Thousands of organizations installed this software after verifying the signature — which was correct. Source code audit would have revealed nothing, since the modification occurred during the build.
The technical response to this problem is called reproducible builds: a deterministic compilation process such that, from the same sources and the same environment, anyone obtains a bit-for-bit identical binary. Debian has been leading this project since 2013. Bitcoin Core adopted it. Coverage remains partial across the entire ecosystem. And even with reproducible builds, trust in the bootstrap compiler remains necessary — Thompson's Trusting Trust does not disappear; it is pushed back one level.
What This Analysis Implies for Design
Privacy is not a binary property. It is a function of your threat model, the position of your trusted third parties in the chain, and the probability that those third parties are compromised or coerced in your operational context.
An engineer designing a truly sensitive system must explicitly map their trusted third parties: TPM manufacturer, certificate authority, bootstrap compiler, distribution provider, cloud provider if applicable. For each third party, the question is not "are they trustworthy?" but "what is the cost of a compromise of this third party, and does my threat model include an adversary capable of compromising or coercing them?"
For a standard threat model (protection against opportunistic attackers, regulatory compliance, user data protection), TPM + LUKS2 + audited protocol is a reasonable and defensible choice. For a state-level or high-value threat model, every third party in the above list is a potential vector, and the appropriate responses (OpenTitan, reproducible builds, air gap, manual passphrase in place of TPM sealing) represent significant operational constraints that few systems fully assume.
Absolute privacy does not exist outside of a system whose entire chain — from silicon to application — is under your control. That control is a horizon, not an achievable state under real production conditions. Rigor consists in knowing precisely where you have placed your trusted third parties, why, and what you lose if one of them is compromised.
Technical references: CVE-2017-15361 (ROCA, Infineon TPM) — K. Thompson, "Reflections on Trusting Trust," CACM 1984 — Reproducible Builds project, reproducible-builds.org — Google OpenTitan, opentitan.org — NIST SP 800-155 (BIOS integrity measurement) — SolarWinds supply chain attack, CISA Advisory AA20-352A.
