Exploring Privacy

In the previous exploration, we solved the problem of Identity. We figured out how to verify who is speaking using cryptographic keys and graphs of authority.

But knowing “who” is speaking doesn’t stop others from listening.

If we send our verified data to a random, untrusted warehouse in a basement somewhere, we might have trusted signatures to ensure they don’t change the data, but can we trust them not to read it? Can we trust them not to sell it, leak it, or use it against us?

Once we decouple storage from trust, we must assume the server is malicious. To build a truly sovereign system, the server (the Relay) must be more than just “Dumb”; it must be Blind.

This brings us to the science of keeping secrets on an untrusted disk: Encryption at Rest.

The Illusion of Scrambling

When we first think of encryption, we imagine a secret code. We turn a readable sentence into a garbled mess of characters, and we assume that as long as the mess is unreadable, we are safe. This is the “Scrambling” mental model.

I hadn’t appreciated until now just how dangerous this simplification is. While technically true, it hides a vulnerability that a senior engineer cannot ignore: The Bit-Flip Attack.

Imagine I encrypt a message that says: “Transfer $100 to Alice.” I send this encrypted blob to the server. The server can’t read it, but it can manipulate it. A malicious admin might flip a few random bits in the ciphertext. When I later download that blob and decrypt it, the math might interpret those flipped bits as a new number. My message now says “Transfer $900.”

The server didn’t need to know the key to break the system; it just needed to know that the system lacked integrity checks. In a distributed world, hiding the meaning of data is not enough. We must also protect its structure.

The Trap of Composition: Sign then Encrypt?

This leads to a second, more subtle problem. We know we need Identity (Signatures) and Privacy (Encryption). But how do we combine them?

It seems trivial, but manual composition is a famous trap in cryptography.

Sign-then-Encrypt

• I sign a letter (“I love you”), then put it in an envelope (Encrypt).
• The Trap: If I send this to Bob, Bob can decrypt it, take my signed letter (“I love you”), re-encrypt it with Charlie’s key, and send it to Charlie. Charlie opens it and sees my signature on “I love you.” I have been tricked into professing love to a stranger. This is the Surreptitious Forwarding attack.

Encrypt-then-Sign

• I put the letter in the envelope, then sign the outside.
• The Trap: I am signing ciphertext (random noise). I might be tricked into signing a malicious blob that I cannot read.

This forced me to unlearn the idea that cryptographic primitives are like lego bricks. I realized that “Privacy” and “Identity” cannot be slapped together; they must be fused into a single, context-aware structure.

The Solution: Authenticated Encryption (AEAD)

To solve both the Bit-Flip Attack and the Composition Trap, modern cryptography has moved to a standard called Authenticated Encryption with Associated Data (AEAD). Algorithms like AES-GCM or ChaCha20-Poly1305 don’t just act as locks; they act as tamper-evident seals.

When you encrypt data with AEAD, the algorithm produces two things: the Ciphertext (the scrambled data) and an Authentication Tag (a cryptographic checksum).

The magic lies in the “Associated Data” field. This allows us to bind the encrypted secret to its public context.

For example, if I store an encrypted block in a database, I can feed the “Block ID” into the encryption function as Associated Data. This binds the ciphertext to that specific ID. If an attacker tries to cut-and-paste a valid encrypted message from “Block A” into the slot for “Block B,” the decryption will fail because the Associated Data won’t match the Tag. The data is not just secret; it is mathematically anchored to its specific place in the universe.

The Politics of Algorithms: AES vs. ChaCha20

When investigating which algorithm to use, I stumbled into a fascinating technological divide. The choice of cipher isn’t just about math; it’s about architecture.

The Enterprise Choice: AES. The Advanced Encryption Standard (AES) is the gold standard for banks and governments. It is incredibly fast because modern Intel and AMD chips have special circuits (AES-NI) dedicated to it. However, implementing AES in software (without those chips) is notoriously dangerous; it is prone to “timing attacks” where a hacker can guess your key by measuring exactly how many nanoseconds your CPU takes to process a zero vs. a one.

The Sovereign Choice: ChaCha20. Decentralized systems often run on the edge, on cheap Android phones, Raspberry Pis, or browser tabs. These devices might not have AES hardware acceleration. This is why protocols like Signal, WireGuard, and IPFS prefer ChaCha20.

ChaCha20 is a “software-first” cipher. It was designed by Daniel J. Bernstein to be secure and fast on any general-purpose CPU. It relies on simple addition and rotation operations that take the same amount of time regardless of the data, making it naturally immune to timing attacks. By choosing ChaCha20, we are optimizing for the User’s Device, not the Server’s Cloud. It is a subtle but powerful statement about who the system is built for.

The Seed of Truth: Entropy

This was the point where I realized that all this complex math rests on a surprisingly fragile foundation: Randomness.

Cryptography is deterministic. If I feed the same Key into the same Algorithm, I get the same Result. The only thing that makes it “secret” is that the attacker cannot guess the Key. But where does the Key come from?

If your computer generates a key using a predictable source (like the current time in milliseconds), an attacker can just guess the time you created the key and derive the secret. This happened famously in 2013, when a flaw in the Android Random Number Generator allowed hackers to steal coins from thousands of Bitcoin wallets. The math was perfect; the randomness was flawed.

A sovereign system must rely on the OS CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). This subsystem acts as an “Entropy Sponge,” soaking up noise from the physical world: mouse movements, network packet arrival times, thermal sensor fluctuations.

It turns the chaos of reality into the mathematical certainty of a key. Without this bridge to the physical world, our digital vault is just a predictable illusion.

The Burden of the Key

If we use these tools correctly, AEAD for integrity, careful ordering for safety, ChaCha20 for speed, and CSPRNGs for entropy, we achieve the “Blind Warehouse” ideal. The server holds blobs of noise and can verify their integrity, but it has no idea what is inside.

But this privacy comes at a steep price.

We have successfully locked the world out. The problem is, we have also locked ourselves in. To make this data useful, we have to figure out how to smuggle the key through the very same untrusted channels we just built the walls to protect. That is what I’ll explore next.