DEV Community: Haven Messenger

SRP: The Password Protocol That Never Sends Your Password

Haven Messenger — Thu, 04 Jun 2026 08:17:33 +0000

The Secure Remote Password protocol, designed by Thomas Wu at Stanford in 1998 and standardized for TLS in RFC 2945 and RFC 5054, belongs to a family called augmented PAKE — Password-Authenticated Key Exchange. The promise is unusual enough to sound like marketing, but it is a provable property: the server learns nothing it could use to impersonate you, an eavesdropper learns nothing useful, and an attacker who steals the server's entire database still cannot log in by replaying what they found. They would have to crack each password offline, one user at a time.

The Problem With "Just Hash It"

The conventional advice — never store plaintext passwords, always store a salted slow hash — is correct and necessary, but it protects only the database at rest. The password still travels from client to server on every login. That means it exists, in plaintext, at several moments of risk:

In transit, protected only by TLS — which fails the instant a certificate is mis-issued, a CA is compromised, or a corporate middlebox terminates the connection.
In server memory, where a logging bug, a crash dump, or a memory-scraping intrusion can capture it before hashing.
At the application boundary, where reverse proxies and load balancers can inadvertently log request bodies.

SRP's design goal was to remove the password from all of these surfaces by never transmitting it at all.

Registration: Storing a Verifier, Not a Password

When you create an account, your client picks a random salt s and computes a private value x from your salt, username, and password (via a hash). It then computes a verifier v = g^x mod N, where g and N are agreed group parameters (a generator and a large safe prime). The client sends the server only the salt and the verifier v. It never sends x, and never sends the password.

The verifier is a one-way function of your password in the same spirit as a hash, but it is a public key, not a secret to be checked by comparison. The server stores (salt, v). Critically, knowing v does not let the server — or a thief who steals v — authenticate as you. They would still need to recover the password by brute force, exactly as with a stolen password hash.

The key distinction: A stolen password hash and a stolen SRP verifier are equally useless for an immediate login — both force an offline cracking attack. But SRP additionally guarantees the password never reached the server in the first place, closing the in-transit and in-memory exposure that hashing alone leaves open.

Login: A Zero-Knowledge Handshake

Authentication is a short challenge-response built on Diffie-Hellman. Both sides generate random ephemeral values and exchange public components: the client sends A, the server sends B (which is blended with the stored verifier). Each side then independently computes the same shared session key — but only if the client's password matches the password baked into the verifier the server holds.

Finally, each side sends a proof (an HMAC over the handshake values) demonstrating it derived the same key. If the client typed the wrong password, the two computed keys diverge and the proofs do not match — so the server rejects the login without ever having seen, or needed, the password itself. This is why SRP is often described as a zero-knowledge password proof: you prove knowledge of the secret without revealing it.

As a bonus, that shared session key is a strong, mutually authenticated secret both sides now hold — usable to key an encrypted channel, which is what some end-to-end systems do with it.

What SRP Resists — and What It Doesn't

Threat	SRP outcome
Passive eavesdropper on the wire	Learns nothing usable; no offline-crackable value is sent
Stolen server database	No instant login; attacker must crack each verifier offline
Phishing site / wrong server	A fake server can't complete the handshake without the verifier
Weak, guessable passwords	Offline guessing still works once the verifier is stolen
Malware on the client device	Captures the password as you type it — SRP can't help

The honest summary: SRP raises the floor dramatically against network and server-side attacks, but it cannot rescue a weak password from offline cracking, and it cannot protect a compromised endpoint. It moves the attacker's cost, not their possibility.

Where SRP Actually Lives

SRP is not a museum piece. Apple has used SRP-6a in iCloud Key Vault and in the authentication for some of its services; the 1Password and ProtonMail authentication flows have used SRP to keep the master password off the server; and it appears in a long tail of VPNs, enterprise systems, and TLS-SRP deployments. The reason it never became the universal web login is mostly inertia and tooling: the modern web standardized on bearer tokens and OAuth flows, and browser-native PAKE never shipped.

SRP's quiet insight is that "don't store plaintext" was always the wrong place to stop. The password shouldn't reach the server at all.

SRP, OPAQUE, and the Modern PAKE Landscape

SRP has a known wart: its security proof is less clean than newer designs, it bakes in specific group assumptions, and its augmented-but-not-quite handling of the salt leaks the salt to anyone who asks, enabling some pre-computation. The current state of the art is OPAQUE, an aPAKE selected by the IETF's CFRG that fixes the salt-exposure issue and rests on stronger, modern security proofs. If you are designing a new system today, OPAQUE is generally the better default; SRP remains a perfectly defensible choice in systems that already deploy it well.

Both belong to the same broader idea as privacy-preserving authentication: the server should be able to check that you are you without accumulating secrets that turn it into a high-value breach target.

Why This Pattern Matters for Encrypted Apps

For any service that holds your encrypted data, the password problem is doubly important: the password often doubles as the root of your key-derivation chain. If it ever reaches the server in a usable form, the server could, in principle, derive your keys. That is exactly the property a credible end-to-end system must avoid.

At Haven, the design rule is that your passphrase never leaves your device — encryption keys are derived locally and only a derived credential is presented to the server, which is the same instinct that motivates SRP and OPAQUE. The protocol you pick matters less than the invariant it enforces: the server should never be in a position to know your password. SRP was one of the first practical ways to guarantee that, and understanding it makes every authentication design decision that follows clearer.

Originally published at havenmessenger.com

Constant-Time Programming: Why Crypto Code Can't Branch on Secrets

Haven Messenger — Wed, 03 Jun 2026 08:18:45 +0000

Ordinary code is judged on whether it produces the right answer. Cryptographic code is held to a stranger standard: it must produce the right answer in exactly the same amount of time, no matter what the secret data is. Violate that rule and an attacker who can only measure how long your code runs can, given enough samples, recover the key it was protecting. This is why crypto libraries are full of code that looks needlessly convoluted — and why that convolution is the point.

Imagine a function that checks whether a submitted password matches a stored one by comparing them character by character and returning false the instant it finds a mismatch. It's correct. It's also leaking. A comparison that fails on the first character returns faster than one that fails on the tenth. An attacker measuring response times can learn how many leading characters they guessed correctly, turning an exponential brute-force problem into a linear one. The function gives the right answer and still betrays the secret — through time.

This is a timing side channel, and defending against it is the discipline of constant-time programming: writing code whose execution time, memory access pattern, and control flow do not depend on secret values. It's one specific, code-level corner of the broader family of side-channel attacks, and it's the one application developers are most likely to get wrong themselves.

The threat model: an attacker with a stopwatch

The unsettling part of timing attacks is how little the attacker needs. They don't need to read your memory, exploit a buffer overflow, or break the math behind the cipher. They only need to measure something observable — wall-clock response latency over a network, cache behavior on a shared machine, even power draw — and correlate it with secret-dependent work your program does.

Individual measurements are noisy, especially over a network. But statistics defeat noise. In 2003, researchers David Brumley and Dan Boneh demonstrated a practical timing attack that extracted an RSA private key from an OpenSSL-based server over a network connection. The defense — and the reason modern RSA implementations use a technique called blinding — exists precisely because "it's only a few microseconds" is not a safe assumption when an attacker can collect millions of samples.

The core rule: Execution time, branch decisions, and memory access addresses must be independent of secret data. If an attacker measuring any of these can distinguish one secret from another, the secret is leaking — no matter how strong the underlying cipher is.

The three things that leak

Constant-time programming targets three distinct sources of secret-dependent timing variation, and a real implementation has to neutralize all of them.

Secret-dependent branches

Any if statement whose condition depends on a secret can leak, because the two paths take different amounts of time and may prime the CPU's branch predictor differently. The fix is to compute both possibilities and select between them with arithmetic rather than a jump. Instead of "if the bit is set, add X," you compute a mask (all-ones or all-zeros depending on the bit) and AND it with X — the addition always happens, but contributes nothing when the bit is clear.

Secret-dependent memory access

If your code uses a secret value as an index into a table — as naive AES implementations do with S-box lookups — then which memory address you touch depends on the secret. An attacker sharing the same CPU can observe, through the cache, which table entries were accessed, and work backward to the key. Constant-time code either avoids table lookups on secret indices entirely or accesses every entry so the access pattern carries no information. This is why modern CPUs added dedicated AES instructions (AES-NI): they perform the round function in hardware without secret-dependent memory access.

Secret-dependent loop bounds and early exit

The password-comparison example above is this category. A loop that stops early when it finds a difference reveals where the difference is. The constant-time version always examines every byte, accumulating differences into a single value with OR, and only checks that accumulator at the very end. Standard libraries ship vetted versions of this — for example, crypto_memcmp-style functions and language-level helpers like Python's hmac.compare_digest — and you should use them rather than rolling your own equality check on any secret.

A concrete before-and-after

Leaky pattern	Constant-time replacement
Return `false` on first byte mismatch	OR all byte-differences together; compare the total to zero once at the end
`if secret_bit: result = a else: result = b`	Mask-based select: `result = (mask & a) \
Table lookup {% raw %}`sbox[secret]`	Hardware AES instructions, or scan the whole table
Loop runs `secret_length` times	Loop runs a fixed maximum number of times

Why the compiler is your adversary too

Here's the genuinely hard part: even if you write constant-time source code, an optimizing compiler may quietly undo it. Compilers are designed to make code faster, and a "redundant" full-table scan or a branchless construct that looks like a missed optimization is exactly the kind of thing they rewrite. The C language has no portable notion of "constant time," so there is no standard way to tell the compiler "do not optimize this for timing's sake."

Writing constant-time code in a language that doesn't understand the concept means fighting your own toolchain — and the toolchain doesn't promise to lose.

This is why serious cryptographic code is often written in assembly, generated by specialized tools, or formally verified (projects like HACL* and the assembly in libsodium and BoringSSL exist for this reason). It's also a quiet argument for modern systems languages: ecosystems like Rust's have crates such as subtle that provide constant-time primitives with explicit barriers to discourage the optimizer from collapsing them.

What this means for the software you trust

The practical lesson for anyone evaluating a security product is not that you should audit assembly. It's that cryptography is an implementation discipline, not just a choice of algorithm. "We use AES-256" tells you almost nothing about whether the AES is implemented without timing leaks. Two products can use the identical cipher and have wildly different real-world security depending on whether their developers respected constant-time rules and, crucially, whether they used well-audited libraries instead of writing their own primitives.

That's the rule we follow at Haven, and that anyone building secure software should: don't hand-roll cryptographic primitives. Use vetted, constant-time libraries for the dangerous parts — comparison, key handling, the cipher core — and keep secret-dependent logic out of branches and table indices. The flashy part of cryptography is the math. The part that actually gets broken in the field is almost always the implementation. Constant-time programming is where a surprising amount of that battle is won or lost.

Originally published at havenmessenger.com

SS7 Attacks: How Your Phone Number Betrays You

Haven Messenger — Tue, 02 Jun 2026 08:17:30 +0000

Somewhere underneath the apps and the LTE bars sits a signaling network from the 1970s that quietly coordinates every call, text, and roaming handoff on Earth. It was designed for a closed club of national telecoms who trusted each other completely. That club no longer exists — but the trust assumption was never removed.

When you send a text or your phone latches onto a tower in a foreign country, two separate things happen. There's the voice and data path — the actual content moving across the network — and there's the signaling path, the out-of-band control messages that tell the network where you are, how to route a call to you, and which carrier should bill whom. That second path runs on a protocol family called Signaling System No. 7, or SS7.

SS7 was standardized in the mid-1970s and built out globally through the 1980s. Its security model was simple because the world it served was simple: a small number of state-owned or heavily regulated monopoly carriers, physically interconnected, who had every commercial and legal reason to behave. There was no authentication between network elements because there didn't need to be. If a message arrived on the SS7 network claiming to come from a legitimate carrier, it was treated as if it did.

The Trust Model That Quietly Collapsed

Deregulation changed the membership of the club without changing the locks. Over the following decades, the number of entities with some form of SS7 connectivity exploded — hundreds of mobile operators, virtual operators, SMS aggregators, roaming hubs, and interconnect resellers. Access to the network, once the exclusive privilege of national monopolies, became something you could effectively lease. Researchers have repeatedly demonstrated that obtaining a global title (an SS7 network address) and sending traffic is within reach of a determined, modestly funded attacker.

Once you can speak SS7 and the network trusts you by default, a handful of standard, legitimate messages become weapons. These aren't exploits of buggy code — they're the protocol working exactly as designed, asked the wrong question by the wrong party.

The core flaw: SS7 has no meaningful authentication of the messages flowing between carriers. The network answers a request based on what the request claims to be, not on any cryptographic proof of who actually sent it. Everything below follows from that single missing check.

What an Attacker Can Actually Do

The capabilities cluster into three families, all built from ordinary mobility-management messages:

Locating you

Mobility messages such as anyTimeInterrogation and provideSubscriberInfo exist so a network can answer "which switch is this subscriber currently attached to?" — a legitimate need for routing. Abused, they let an outsider query a subscriber's approximate location, sometimes down to the serving cell tower, with nothing more than the target's phone number. No malware on the device, no consent, no trace visible to the victim.

Intercepting SMS and calls

The more dangerous attack abuses UpdateLocation. By telling the home network that the target has "roamed" onto a mobile switching center the attacker controls, the attacker convinces the network to route the victim's incoming calls and texts to attacker-controlled infrastructure. The victim's phone keeps showing full bars. Their text messages — including bank confirmations and one-time login codes — can be silently diverted, read, and even forwarded on so nothing looks missing.

Denial and fraud

The same primitives support cutting a subscriber off the network entirely, or manipulating billing and roaming records. Disruption is often the crudest and least interesting use; interception is where the money and the espionage live.

This Is Not Theoretical

Two well-documented episodes anchor SS7 in reality rather than research labs. In 2016, security researcher Karsten Nohl demonstrated on the CBS program 60 Minutes that, given only the phone number of U.S. Representative Ted Lieu — who consented to the test — he could track the congressman's movements and record his calls from a base in Berlin, purely via SS7.

In 2017, German newspaper Süddeutsche Zeitung reported that criminals had exploited SS7 to intercept the SMS one-time codes banks send for transaction confirmation, draining money from victims' accounts after first stealing their online-banking passwords through conventional phishing. The phone network itself became the second half of a two-stage theft.

The uncomfortable lesson of SS7 is that a code texted to your phone is not delivered over a private channel. It is delivered over a global routing system that was never engineered to keep a determined third party from reading it.

Doesn't 4G and 5G Fix This?

Partly, and not as much as you'd hope. Modern LTE and 5G core networks replaced SS7 with a newer signaling protocol called Diameter, and 5G adds further service-based architecture on top. But Diameter inherited a similar interconnect-trust philosophy and has its own documented weaknesses, and — crucially — networks must remain backward compatible. Calls and texts still fall back to older technology for roaming and interworking, and a chain is only as strong as the legacy link an attacker can force you down to. SS7 will be reachable in the global network for years yet.

Carriers are not standing still. The GSMA publishes signaling-security guidance, and many operators now deploy SS7 and Diameter firewalls that screen incoming signaling for messages that have no business arriving from a given peer. These help. They are also unevenly deployed across hundreds of networks worldwide, and you, the subscriber, have no way to audit whether your carrier — or the foreign carrier you're roaming on — has done the work.

What You Can Actually Control

You can't patch SS7. What you can do is stop relying on the phone number as a security boundary. The throughline of every serious SS7 attack is that something valuable was trusted to the telephone network.

If you currently use…	Move toward…
SMS one-time codes for 2FA	App-based TOTP, or better, a hardware security key — neither touches the cellular network
Phone calls / SMS for sensitive talk	End-to-end encrypted messaging, where content is unreadable even if signaling is hijacked
Your phone number as account identity	Accounts and recovery paths that don't hinge on receiving a text

SMS-based two-factor authentication is still meaningfully better than no second factor at all — it raises the bar against casual attackers. But against an adversary with SS7 access, it is close to no protection. If you're choosing a second factor, the case for hardware keys over authenticator apps comes down to the same principle: keep the secret off the cellular network.

SS7 interception also has a close cousin in SIM swapping, where the attacker takes over your number at the carrier rather than rerouting it in the network — and in IMSI catchers, which attack you over the air rather than through the signaling core. Different mechanisms, same conclusion: a phone number is an address, not an identity, and certainly not a secret.

Where Haven Fits

Haven doesn't use your phone number as your identity, and it doesn't send security codes over SMS. Accounts are built on a passphrase-derived key that never leaves your device, and messages are end-to-end encrypted — so even if an adversary reroutes your texts through SS7, there is nothing of yours sitting in that stream to read.

No app can fix a 1970s signaling network. What an app can do is stop depending on it. If your threat model includes well-resourced adversaries, the move that matters most is structural: stop letting the telephone network sit on the critical path of your security.

Originally published at havenmessenger.com

Merkle Trees Explained: One Hash to Vouch for Everything

Haven Messenger — Mon, 01 Jun 2026 08:20:07 +0000

Suppose someone hands you a single 32-byte string and claims it represents a million records exactly as they should be. Later, you want to confirm one specific record is genuinely in that set — without re-downloading the other 999,999. A Merkle tree makes this possible with a few dozen bytes of proof. It's one of those rare ideas that's simple enough to sketch on a napkin and foundational enough to sit underneath Git, Bitcoin, and the system that keeps the web's certificate authorities honest.

The structure is named for Ralph Merkle, who described it in work dating to the late 1970s. The idea has aged extraordinarily well because it solves a problem that keeps reappearing in distributed systems: how do you commit to a large collection of data with a single small value, and then prove things about individual items efficiently?

Start With the Hash Function

A Merkle tree is built entirely out of cryptographic hash functions, so it's worth recalling what those give us. A hash function (SHA-256, for example) takes any input and produces a fixed-size fingerprint with three properties that matter here:

Deterministic — the same input always yields the same hash.
Collision-resistant — it's computationally infeasible to find two different inputs with the same hash.
Avalanche effect — flip one bit of input and roughly half the output bits change, unpredictably.

Together these mean a hash is a tamper-evident summary: if the data changed, the fingerprint changes, and nobody can engineer a different document that matches the same fingerprint. A Merkle tree is what you get when you apply this recursively.

Building the Tree

Picture your data split into chunks — transactions, files, log entries, whatever. The construction goes bottom-up:

Leaves. Hash each data chunk. These hashes are the leaf nodes at the bottom of the tree.
Pair and hash. Take the leaves two at a time, concatenate each pair, and hash the result. Each pair produces one parent node one level up.
Repeat. Keep pairing and hashing each new level until only a single node remains.

That final, lone node is the Merkle root (or root hash). Because every parent's value depends on its children, and theirs on their children, the root is a single value that depends on every single byte of every chunk. Change one transaction at the bottom and the change cascades all the way up: a different leaf hash, a different parent, a different root. The root is a fingerprint of the entire dataset.

A Merkle root is a hash of hashes of hashes. It collapses an arbitrarily large dataset into one fixed-size value such that any modification, anywhere, produces a different root.

The Magic Trick: Merkle Proofs

A plain hash of all the data would also detect tampering — so why the tree? Because the tree lets you prove membership of a single item without revealing or processing the rest. This is the part worth slowing down for.

Say you want to prove that chunk #5 belongs to a dataset whose root you already trust. You don't need the other chunks. You need only the sibling hashes along the path from leaf #5 up to the root — called the Merkle proof or authentication path. To verify, you:

Hash chunk #5 yourself to get its leaf hash.
Combine it with the provided sibling hash to compute its parent.
Combine that with the next provided sibling to get the grandparent, and so on up the tree.
Compare the root you computed against the trusted root. Match means chunk #5 is authentic and unmodified. Mismatch means something is wrong.

The beautiful part is the cost. For a tree of n items, the path from any leaf to the root has only about log₂(n) levels. A dataset of a million items needs a proof of roughly 20 sibling hashes — well under a kilobyte — to confirm any single member. The verification doesn't grow with the size of the data; it grows with its logarithm.

Dataset size	Approx. proof length (sibling hashes)
1,000 items	~10
1,000,000 items	~20
1,000,000,000 items	~30

That logarithmic scaling is why Merkle trees show up wherever a lightweight client needs to trust a small piece of an enormous structure it can't hold in full.

Where You're Already Relying On Them

Git

Every Git commit is, in effect, a Merkle structure. File contents, directory trees, and commits are all identified by the hash of their contents, and each commit's hash incorporates its parent's. That's why a commit hash uniquely pins the entire history leading to it — and why you can't quietly rewrite an old commit without every later hash changing.

Bitcoin and other blockchains

Each block summarizes all its transactions in a single Merkle root stored in the block header. This lets a lightweight wallet confirm a specific transaction is in a block by checking a short Merkle proof, rather than downloading the full chain.

Certificate Transparency and Key Transparency

Merkle trees are the backbone of accountability for the web's certificate system. Certificate Transparency logs use an append-only Merkle structure so that auditors can verify a certificate was logged and that the log was never secretly rewritten. The same machinery powers key transparency for messaging apps, letting users confirm the public key they're handed is the one everyone else sees too.

Distributed storage and databases

Content-addressed systems and distributed databases use Merkle trees (and a generalization, Merkle DAGs) to compare replicas efficiently. Two nodes can find exactly where their data diverged by comparing roots, then subtree hashes, narrowing down without shipping everything.

What a Merkle Tree Does and Doesn't Promise

It's worth being precise. A Merkle tree proves integrity and membership: that data hasn't changed since the root was published, and that a given item is part of the committed set. It says nothing on its own about who produced the data or when — that requires a signature over the root, or a trusted timestamp, layered on top. And an append-only log additionally needs consistency proofs (showing the new tree is a strict superset of the old one) to guarantee history wasn't rewritten, not just that the current state is internally consistent.

A Merkle tree turns "trust me, all this data is intact" into "here are 20 hashes — check for yourself." That shift, from assertion to verification, is the whole reason it underpins so much of modern cryptographic infrastructure.

The recurring theme across all of this is the one that guides how we think about trust at Haven: the strongest systems don't ask you to take their word for it. They give you a small, cheap, mathematically grounded way to verify the claim yourself. A Merkle root is one of the most elegant expressions of that idea — a single fingerprint that lets anyone, anywhere, hold an entire dataset accountable.

Originally published at havenmessenger.com

Quantum Key Distribution: Encryption Secured by Physics

Haven Messenger — Sun, 31 May 2026 08:17:30 +0000

Almost all the cryptography you use rests on math being hard: factoring big numbers, computing discrete logarithms. Quantum key distribution makes a different bet entirely. It secures a shared key with the laws of physics — and guarantees that any eavesdropper leaves fingerprints. That sounds like a silver bullet. It isn't, and understanding why is more interesting than the marketing.

First, clear up a name collision that causes endless confusion. Quantum key distribution (QKD) and post-quantum cryptography (PQC) are not the same thing, and they are not even the same kind of thing.

Post-quantum cryptography is ordinary software — new mathematical algorithms (like ML-KEM) designed to resist attack by quantum computers. It runs on the hardware you already own.
Quantum key distribution is hardware — it uses the physical behavior of individual photons to establish a key over a special optical link. It defends against eavesdropping using quantum physics, not quantum computers.

Both are responses to a quantum future, but PQC is what's actually being deployed across the internet today. QKD is a narrower, infrastructure-heavy technology. This article is about the second one.

The Physical Idea

QKD rests on two facts from quantum mechanics. First, you cannot measure a quantum system without disturbing it. Second, the no-cloning theorem says you cannot make a perfect copy of an unknown quantum state. Together these mean that an eavesdropper who intercepts photons in transit cannot do so invisibly — measuring them changes them, and that change is statistically detectable by the legitimate parties.

This is the key reframing. Classical cryptography assumes an eavesdropper can copy every bit on the wire silently and attack it later at leisure (the "harvest now, decrypt later" threat). QKD aims to make silent interception physically impossible. If someone listens, the error rate climbs and the parties know to throw the key away before using it.

What QKD provides: QKD does not encrypt your data. It establishes a shared secret key whose secrecy can be verified — and that key is then used with ordinary symmetric encryption. The quantum part is purely about agreeing on a key nobody else could have learned undetected.

BB84, Step by Step

The original and still most-taught protocol is BB84, proposed by Charles Bennett and Gilles Brassard in 1984. Here's the shape of it, using the convention that Alice sends and Bob receives.

Alice encodes random bits on photons, choosing for each one a random "basis" — think of it as two different orientations of polarization, rectilinear (+) or diagonal (×). The bit value and the basis are both random.
Bob measures each photon in a basis he also picks at random. When his basis matches Alice's, he reads the correct bit. When it doesn't, he gets a random result.
They compare bases over a public channel — not the bit values, just which basis each used. They keep only the photons where the bases happened to match (about half) and discard the rest. This surviving string is the "sifted key."
They check for eavesdropping by publicly comparing a random sample of the sifted bits. If an eavesdropper measured photons in transit, she had to guess bases too, and her wrong guesses introduce errors. A quantum bit error rate above a known threshold means someone was listening — abort.
They distill a final key from the remaining bits using error correction and privacy amplification, which shrinks the key while squeezing out any partial information a weak eavesdropper might have gained.

The elegance is that security comes from the public basis-comparison step combined with physics: an eavesdropper cannot avoid disturbing the photons she measures, so she cannot learn the key without being caught. Other protocols (E91, which uses entanglement; and various decoy-state schemes) refine this, but BB84 captures the core intuition.

Why It Hasn't Taken Over the Internet

If QKD offers physics-grade key secrecy, why aren't we all using it? Because the practical constraints are severe, and several national security agencies — including the UK's NCSC and the US NSA — have publicly recommended post-quantum cryptography over QKD for general use. Here's the honest list of limitations.

Limitation	What it means in practice
Distance	Photons get absorbed in fiber. Direct QKD links are limited to roughly a few hundred kilometers; going further needs trusted relay nodes or immature quantum repeaters.
Trusted relays	Long-distance QKD networks chain together relay nodes that see the key in the clear. You're back to trusting infrastructure — the very thing QKD was supposed to avoid.
Special hardware	It needs dedicated fiber or line-of-sight optics, single-photon sources and detectors. It does not run over the ordinary internet.
No authentication	QKD can't tell who is on the other end. It still needs classical authentication to stop a machine-in-the-middle — so it doesn't remove the need for conventional cryptography.
Implementation attacks	Real devices aren't ideal. Attacks like detector blinding have exploited hardware imperfections to defeat deployed QKD systems without violating any physics.

The theory of QKD is unconditionally secure. The hardware that implements it is not. Most real-world QKD breaks have attacked the gap between the two.

The Authentication Catch

This point deserves its own emphasis because it undercuts the "physics replaces math" narrative. QKD guarantees that the photons weren't read undetected — but it cannot, by itself, tell Alice she's talking to Bob and not to an impostor sitting in the middle running QKD with each of them separately. To prevent that, the public discussion channel must be authenticated, and authentication relies on classical cryptography (a shared secret or signatures).

So QKD does not eliminate the need for conventional cryptography — it sits alongside it. This is part of why agencies recommend hardening systems with post-quantum algorithms and good forward secrecy instead: those defend the whole internet in software, today, without new fiber.

Where It's Real

QKD is not vaporware. China's Micius satellite demonstrated entanglement-based key distribution between ground stations over 1,000 km apart in 2017, and a Beijing-to-Shanghai fiber backbone has carried QKD traffic. Several commercial vendors sell QKD systems, and some banks and government links use them. The technology works — within its niche of point-to-point links where one party controls both ends or trusts the relays, and where the cost of dedicated optical infrastructure is justified.

That niche is genuine but small. For protecting communication at internet scale — which is what most people, and most privacy tools, actually need — the answer is strong end-to-end encryption with forward secrecy, migrating to post-quantum algorithms over time.

The Takeaway

Quantum key distribution is a beautiful idea: detect eavesdropping using the fact that observation disturbs quantum states. It delivers on that idea in theory and, with caveats, in practice. But it requires special hardware, is distance-limited, still needs classical authentication, and has been broken through implementation flaws. It complements conventional cryptography rather than replacing it.

If you're worried about a quantum future, the practical move is not a fiber link to your contacts — it's using tools built on modern, well-audited cryptography that are adopting post-quantum algorithms. That's a software upgrade, not a physics project.

Originally published at havenmessenger.com

Zero-Knowledge Proofs: Proving You Know a Secret Without Revealing It

Haven Messenger — Fri, 29 May 2026 08:16:50 +0000

Suppose you need to prove you are over 18 without showing your birthdate, or that you know a password without sending it, or that a financial statement balances without exposing the numbers. Zero-knowledge proofs make all three possible: they let you convince a skeptic that something is true while leaking nothing beyond that single fact.

The concept dates to a 1985 paper by Shafi Goldwasser, Silvio Micali, and Charles Rackoff — work so foundational that two of the authors later won the Turing Award. Their question sounds almost philosophical: how much knowledge must change hands to prove a statement is true? Their answer was startling: for many statements, the answer is none beyond the truth of the statement itself.

The Cave That Explains Everything

The standard intuition comes from a 1990 paper by Jean-Jacques Quisquater and colleagues, "How to Explain Zero-Knowledge Protocols to Your Children." Picture a ring-shaped cave with a magic door at the back that only opens with a secret word. The cave forks into two paths, A and B, that meet at the door.

Peggy (the prover) wants to convince Victor (the verifier) she knows the word, without saying it. Peggy walks into the cave and picks a path at random. Victor, who stayed outside, then shouts which path he wants her to come out of. If Peggy truly knows the word, she can always comply — opening the door if she needs to switch sides. If she does not know it, she only had a 50% chance of guessing the right starting path.

Run it once and a cheater gets lucky half the time. Run it twenty times and the odds of a fraud passing every round drop below one in a million. Crucially, Victor never learns the word — he just watches Peggy emerge from the side he named, over and over.

The Three Properties

Every zero-knowledge proof must satisfy three properties. They are worth stating precisely, because each one is doing real work:

Completeness — if the statement is true and both parties follow the protocol, the verifier is convinced.
Soundness — if the statement is false, no cheating prover can convince the verifier except with negligible probability.
Zero-knowledge — the verifier learns nothing except that the statement is true. Formally, anything the verifier sees could have been simulated without access to the secret.

The simulator trick: zero-knowledge is proven by showing a "simulator" can produce a transcript indistinguishable from a real proof — without ever knowing the secret. If a fake transcript is indistinguishable from a real one, the real one couldn't have leaked the secret. That argument is the conceptual heart of the whole field.

From Interactive to Non-Interactive

The cave protocol is interactive: it needs back-and-forth challenges. That is impractical when you want to publish a single proof anyone can check later, like in a blockchain transaction.

The Fiat–Shamir heuristic (1986) removes the interaction. Instead of waiting for the verifier to send a random challenge, the prover generates the challenge themselves by hashing the protocol transcript so far. Because a good hash function is unpredictable, the prover cannot rig the challenge in their favor. The result is a non-interactive proof — a self-contained string that any verifier can check independently.

A closely related building block is the Schnorr protocol, an elegant three-message proof that you know the discrete logarithm of a public value — i.e., that you hold the private key matching a public key. Apply Fiat–Shamir to a Schnorr proof and you get the Schnorr signature scheme, which underpins modern signatures including Bitcoin's Taproot upgrade.

SNARKs vs STARKs

Modern zero-knowledge systems aim to prove arbitrary computations succinctly — that you ran a program correctly, with a proof far smaller than re-running the program. Two families dominate:

Property	zk-SNARKs	zk-STARKs
Proof size	Very small (constant)	Larger (logarithmic)
Trusted setup	Usually required	None
Post-quantum	Often not	Yes (hash-based)
Verification speed	Very fast	Fast

zk-SNARKs (Succinct Non-interactive ARguments of Knowledge) produce tiny proofs that verify in milliseconds, but many variants need a trusted setup — a one-time ceremony that generates public parameters. If the secret randomness from that ceremony ("toxic waste") is not destroyed, someone could forge proofs. Multi-party "powers of tau" ceremonies mitigate this by requiring all participants to collude.

zk-STARKs (Scalable Transparent ARguments of Knowledge) eliminate the trusted setup entirely and rely only on hash functions, which makes them plausibly quantum-resistant. The trade-off is larger proof sizes.

Where They're Actually Used

Zero-knowledge proofs left the theory journals and entered production over the last decade:

Private cryptocurrency — Zcash uses zk-SNARKs to validate that a shielded transaction is legitimate (inputs equal outputs, no double-spend) without revealing sender, receiver, or amount.
Blockchain scaling — "zk-rollups" bundle thousands of transactions and post a single proof that all of them were executed correctly, cutting costs dramatically.
Authentication — protocols like OPAQUE let a server verify your password without ever seeing it, a close cousin of the zero-knowledge idea.
Selective disclosure — emerging digital-ID systems aim to let you prove "over 18" or "resident of this country" from a credential without exposing the underlying document.

The privacy promise is precise: not "trust me," and not "here is all my data so you can check." Instead — "here is mathematical proof of exactly the one fact you need, and nothing else."

The Limits

Zero-knowledge proofs are not magic. Proof generation can be computationally expensive, sometimes seconds or minutes for complex statements. The soundness guarantee is probabilistic — astronomically strong, but not literally absolute. SNARK trusted setups are a genuine risk that must be handled with care. And a proof only certifies what the statement says: a flawed statement, correctly proven, is still flawed.

Still, few cryptographic ideas have moved from "elegant theory" to "deployed infrastructure" as decisively. As digital identity and privacy-preserving verification grow, the ability to prove a fact while revealing nothing else is becoming one of the most valuable tools in the box. For the complementary problem — computing on data you still cannot read — see our piece on homomorphic encryption.

Originally published at havenmessenger.com

Nonce Reuse: The Catastrophic Crypto Mistake

Haven Messenger — Thu, 28 May 2026 08:20:01 +0000

A nonce is a "number used once." The whole security of several widely deployed encryption and signature schemes rests on that single word — once. Break the rule, even by accident, even one time, and you can hand an attacker your message contents, your forgery key, or in the worst case your private signing key. This is the bug that has sunk WEP, a game console, and more than one TLS library.

Most cryptographic failures are gradual: a cipher weakens, a key gets a little too short for comfort, an attack drops from impractical to merely expensive. Nonce reuse is not like that. It's a cliff. With many modern constructions, a single repeated nonce under the same key doesn't degrade security — it eliminates it, often completely, often instantly.

Understanding why turns an abstract rule ("don't reuse nonces") into something you can reason about — and it explains a string of famous breaches that all share the same root cause.

What a Nonce Is For

Encrypting the same plaintext twice with the same key should not produce the same ciphertext — otherwise an eavesdropper learns when you repeat yourself, which leaks more than you'd think. The fix is to inject a unique value into each encryption so identical inputs produce different outputs. That value is the nonce (sometimes called an IV, initialization vector, depending on the construction).

The nonce doesn't need to be secret. It's typically sent in the clear alongside the ciphertext. Its only job is to be different every time for a given key. That's the entire contract — and it's enough to make the difference between a secure cipher and a broken one.

How Reuse Breaks a Stream Cipher

AES-GCM and ChaCha20-Poly1305, the two AEAD ciphers behind most of the modern internet, both work as stream ciphers under the hood: the key and nonce generate a long pseudorandom keystream, and the plaintext is XORed with that keystream to produce ciphertext.

Now suppose you encrypt two different messages, P1 and P2, with the same key and the same nonce. Both get XORed with the identical keystream K:

C1 = P1 XOR K
C2 = P2 XOR K

An attacker who captures both ciphertexts computes C1 XOR C2. The keystream cancels out perfectly, leaving P1 XOR P2 — the XOR of your two plaintexts, with no key required. From there, known structure in either message (HTTP headers, file formats, language patterns) lets an attacker peel them apart. The encryption has effectively vanished.

It gets worse than confidentiality
For AES-GCM specifically, nonce reuse also leaks the authentication subkey (the value GCM uses inside its GHASH function). Two messages under one nonce give an attacker enough to solve for it — and once they have it, they can forge valid authentication tags for messages you never sent. So a single repeated nonce in GCM costs you both confidentiality and integrity at the same time.

The Signature Variant: Even Nastier

ECDSA, the elliptic-curve signature scheme, uses a per-signature random value usually written as k. It's a nonce by another name, and its reuse is the most dangerous of all. If you sign two different messages with the same k under the same private key, the algebra collapses: an attacker who sees both signatures can solve a pair of linear equations and recover your private key outright.

This is not theoretical. In 2010, the group fail0verflow demonstrated exactly this against the Sony PlayStation 3: Sony's code signing used a fixed k instead of a fresh random value for every signature, and that let researchers extract the private key used to sign software for the console. The same class of mistake has been found in Bitcoin wallets with weak random number generators, where reused or predictable k values drained funds by exposing private keys.

The deterministic-nonce construction in RFC 6979 exists precisely because trusting a device to produce a good random k every single time turned out to be a losing bet.

A Short History of the Same Bug

Incident	What went wrong	Consequence
WEP (Wi-Fi, 2001)	24-bit IV with RC4 — far too small, IVs repeated within hours on a busy network	Keystream recovery; WEP keys cracked in minutes
Sony PS3 (2010)	Fixed ECDSA k across all code signatures	Master private signing key extracted
Various TLS libs	GCM nonces generated with insufficient randomness or counters that wrapped	Confidentiality and forgery risk on affected connections

Decades apart, different algorithms, different industries — one root cause. That's what makes nonce reuse worth a dedicated mental model rather than treating each incident as a one-off.

How Engineers Avoid It

There are two disciplined approaches, and they suit different situations:

Counters. If a single key is used by a single sender, a simple incrementing counter guarantees uniqueness — no randomness needed, no collision risk, as long as the counter never wraps or resets. This is how protocols like TLS 1.3 and the Noise Framework manage per-message nonces.
Large random nonces. When a counter isn't practical (multiple writers, no shared state), you can pick random nonces — but the standard 96-bit GCM nonce is risky here, because random 96-bit values start colliding (the birthday bound) after roughly 2^32 messages. Extended-nonce variants like XChaCha20 use a 192-bit nonce, making random selection safe for all practical message volumes.

Nonce-misuse-resistant modes

Because the failure is so catastrophic, cryptographers built modes designed to fail gracefully. AES-GCM-SIV (RFC 8452) and the broader SIV construction derive their effective nonce from the message content itself. If you accidentally reuse a nonce, the worst that happens is an attacker learns whether two ciphertexts encrypt identical plaintexts — the keys and forgery resistance stay intact. For systems where nonce uniqueness can't be guaranteed by design, these modes are a meaningful safety net.

The Takeaway

"Number used once" sounds like pedantry until you see how completely the math punishes a violation. The lesson for anyone building or evaluating crypto is twofold: never hand-roll nonce management when a vetted library or counter discipline exists, and treat "we generate nonces randomly" as a claim that deserves scrutiny about how random and how large.

It's also a reminder of why we lean on audited, high-level cryptographic constructions rather than assembling primitives by hand. The dangerous part of cryptography is rarely the cipher — it's the bookkeeping around it. For a related class of subtle-but-deadly implementation bugs, see padding oracle attacks and side-channel attacks.

Originally published at havenmessenger.com

Memory Safety and the C/C++ CVE Crisis

Haven Messenger — Wed, 27 May 2026 08:20:19 +0000

Microsoft analyzed a decade of their security bulletins and found roughly 70 percent of critical vulnerabilities were memory safety bugs. Google found roughly the same number in Android and Chromium. The NSA published an advisory recommending memory-safe languages by name. The conclusion is industry-wide and unusually unanimous: the problem isn't bad programmers, it's the languages.

In 2019, Microsoft Security Response Center engineer Matt Miller presented an analysis of roughly a decade's worth of Microsoft's published vulnerabilities. The number that travelled around the industry was 70%: of Microsoft's serious, externally exploitable bugs, about seventy percent were caused by memory safety errors. Google's Project Zero, looking at Chromium, reported a remarkably similar number. Android's security team, looking at native code, found that memory safety vulnerabilities accounted for the majority of high-severity Android security bugs as well.

In late 2022, the NSA published a Cybersecurity Information Sheet titled "Software Memory Safety," recommending that organizations move to memory-safe languages where possible and listing Rust, Go, Swift, Java, C#, and Python as examples. The CISA followed in 2023 with similar guidance. When an intelligence agency publishes a software engineering style guide, the industry has reached an unusual point of consensus.

What "Memory Safety" Actually Means

Memory safety is the property that a program cannot access memory it has no right to access. In a memory-safe language, the runtime, compiler, or both prevent a series of categorical bugs:

Buffer overflows — writing past the end of an allocated region
Use-after-free — accessing memory after it's been returned to the allocator
Double-free — freeing the same allocation twice
Null pointer dereferences — using a pointer that doesn't point at a valid object
Uninitialized memory reads — reading values that were never written
Type confusion — interpreting a chunk of memory as the wrong type

Each of these is a different mechanism, but they share a common feature: they let an attacker influence values the program treats as trusted. A buffer overflow can overwrite a return address, redirecting control flow. A use-after-free can be massaged so that the freed memory is reallocated as something attacker-controlled, then accessed as the original type. Decades of attacker craft have turned these bugs into reliable exploitation primitives.

Why C and C++ Are Where Most of These Live

C and C++ trust the programmer to be correct. The languages let you take a pointer, do arithmetic on it, and dereference the result. They let you free a pointer and use it again — they don't even warn you. They let you cast between pointer types with no runtime check. Each of these features is a power, and a hazard.

Programmers can write correct C. Some do, for a while, on small programs. At scale, with large teams, deadline pressure, and decades of accumulated code, mistakes are statistically inevitable. The industry's experience is consistent across companies and projects: memory safety bugs slip past code review, slip past testing, and ship.

Not a competence question. The teams writing the affected code at Microsoft, Google, Mozilla, Apple, and the kernel projects are world-class. The persistence of memory safety bugs at those organizations is the clearest possible evidence that the problem isn't programmer skill — it's that the language tolerates errors a more restrictive language would refuse to compile.

The Modern Memory-Safe Languages

Memory-safe languages take one of two general approaches: a runtime checker, or compile-time enforcement.

Java, C#, Python, JavaScript, Go, Ruby, and most modern application languages use garbage collection plus runtime bounds checking. Memory is managed by the runtime; the programmer cannot create dangling pointers or overrun an array without an exception. The trade-off is performance overhead and a runtime dependency — fine for application code, problematic for the lowest layers of an operating system or a cryptographic primitive.

Rust takes the second approach. Its compiler enforces a system of ownership and borrowing that statically prevents the categorical memory errors. There's no garbage collector and no runtime overhead — Rust compiles to native code with performance comparable to C. The price is that you have to convince the borrow checker your code is correct, which is harder than just writing it. Once it compiles, the program is provably free of the bug classes above.

Where Rust Is Replacing C

The places where memory safety matters most — operating system kernels, browser engines, networking code, cryptographic libraries — are exactly where C has dominated for fifty years. Rust is the first credible challenger because it doesn't impose a garbage collector or a runtime, which is what makes C indispensable in those contexts.

Linux kernel — Rust support was merged in 2022; drivers and modules can now be written in Rust within the kernel tree.
Android — Google has been writing new native components in Rust since 2021. Their reported result: zero memory safety vulnerabilities in Rust code shipped to production.
Chromium — Google has begun adopting Rust for new components, with the QR code generator and others now in Rust.
Firefox — Mozilla developed Rust originally; large parts of Firefox's CSS engine (Servo, Stylo) are Rust.
Windows — Microsoft has rewritten parts of Windows kernel components in Rust, including portions of the DirectWrite font shaping library that had been a recurring source of exploits.
cURL — The HTTP/HTTPS backend can now optionally be backed by Rust-written libraries.

The Counter-Arguments, Honestly

No language change comes for free. The serious objections to "just rewrite in Rust" deserve direct answers.

Rewriting C is expensive and risky

Absolutely true. A large, mature C codebase represents enormous accumulated effort and bug-fixing. Rewriting it from scratch loses that history. The pragmatic answer most projects have adopted is incremental: keep the existing C, write new components in Rust. Android's data on this is encouraging — most of their memory safety bugs were in new code, not the long-lived components. Writing new code in Rust closes the dominant pipeline of fresh vulnerabilities without touching legacy.

Rust has its own complexity

Also true. The borrow checker is hard to learn. Async Rust is harder still. Programmers who internalized C's mental model often find Rust frustrating for the first few months. The honest assessment: there is a real learning cost, and the value depends on the domain. For application code that's never going to run on the bare metal, garbage-collected languages remain easier and probably enough. For systems code where C was the only choice, Rust's complexity is a worthwhile trade against C's exploitation history.

What about unsafe Rust?

Rust has an unsafe escape hatch — small blocks where the borrow checker stands down so you can do things like raw pointer arithmetic, FFI, or manual memory management. Critics point out that unsafe Rust is just C-with-extra-steps. Defenders point out that unsafe is typically a tiny fraction of a codebase, audited separately, and grep-able. The mainline of a Rust project is safe; the unsafe blocks are the part you focus security review on.

What About Hardware Mitigations?

The industry didn't sit still waiting for language change. Modern hardware has accumulated layers of mitigation — stack canaries, ASLR, DEP, control flow integrity, pointer authentication on ARM64. These make exploitation harder but don't eliminate the underlying bugs. They're a defense-in-depth layer, not a replacement for safety. The result over time is a slow arms race: each new mitigation raises the bar for exploitation, attackers adapt, the bar rises again. Memory-safe languages cut the loop by eliminating the bug class.

The Industry Trajectory

Year	Milestone
2015	Rust 1.0 released
2019	Microsoft publishes "70% of CVEs are memory safety"
2021	Android starts writing new native code in Rust
2022	Linux kernel accepts Rust support
2022	NSA publishes Software Memory Safety advisory
2023	CISA: vendor responsibility includes memory-safe language choice
2024	White House ONCD report endorses memory-safe languages
2025+	Major C/C++ projects adopting incremental Rust components

Why This Matters Beyond Programmers

Memory safety bugs aren't a programmer-only concern. They are the most common mechanism for the privilege-escalation and remote-code-execution bugs that turn into real incidents. The browser tabs you trust, the messaging clients you depend on, the operating systems your devices run — all of them have shipped exploitable memory safety vulnerabilities in the last decade. Moving the foundation toward languages where those bugs are categorically impossible is not a stylistic choice. It is the largest single available improvement in software security, and the industry's biggest names have agreed on it.

The cost is real. The transition is slow. But the trajectory is clear, and twenty years from now, the share of the software stack running in C and C++ will be smaller — by deliberate engineering, not nostalgia.

Originally published at havenmessenger.com

Self-Hosted Password Managers Compared: Vaultwarden, KeePassXC, Pass

Haven Messenger — Tue, 26 May 2026 08:19:56 +0000

Three serious self-hosted password managers have meaningfully different threat models, operational burdens, and ergonomic trade-offs. Picking the right one depends on whether you want a Bitwarden-compatible server, an offline-first encrypted file, or a Unix-philosophy command-line tree of GPG-encrypted files. Each is the right answer for different people.

Hosted password managers have a real, documented track record of being targeted. The 2022 LastPass breach disclosed encrypted vault data of every customer, and the months of analysis that followed showed that vaults with weak master passwords were brute-forceable from the stolen ciphertext. The hosted model is convenient. It also means the encrypted blob containing all your secrets exists on someone else's infrastructure, where it can be stolen even if your password is perfect.

Self-hosting eliminates this category of risk by relocating the blob to infrastructure you control. It introduces a different category — your infrastructure, your problem. Three serious self-hosted password managers are widely deployed: Vaultwarden, KeePassXC, and pass. They take fundamentally different architectural approaches.

Vaultwarden

Vaultwarden (formerly bitwarden_rs) is a Rust implementation of the Bitwarden server API. It's fully compatible with all official Bitwarden client apps (web, desktop, mobile, browser extension) but runs as a single small binary instead of Bitwarden's heavier official server stack. A typical Vaultwarden deployment is a Docker container with a SQLite database, fronted by a reverse proxy with HTTPS.

The architecture is conventional client/server. Vaults are encrypted client-side with a key derived from your master password (PBKDF2 or Argon2id, depending on configuration). The server stores ciphertext only — it cannot read your passwords. Sync between devices works through the server, so any client with network access to your Vaultwarden instance can pull the current vault.

Strengths: Excellent client ecosystem because of API compatibility (browser autofill on all major browsers, native iOS and Android apps with biometric unlock, full Bitwarden CLI compatibility, official passkey/FIDO2 support, organizations and sharing for families and small teams). The Bitwarden clients are mature, audited, and actively maintained. The Vaultwarden server is small enough to read end-to-end and runs comfortably on a Raspberry Pi.

Weaknesses: You're running an internet-exposed service (or at minimum a VPN-exposed service) that holds the encrypted blob of every credential you have. Compromise of the server still gives an attacker ciphertext, but ciphertext you control is no better than ciphertext Bitwarden controls if your master password is weak. You also inherit the operational burden — TLS certificates, backups, OS updates, container updates, intrusion monitoring.

KeePassXC

KeePassXC is the actively-maintained desktop fork of the original Windows-only KeePass. It is fundamentally not a server — it is a desktop application that reads and writes a single encrypted database file (typically a .kdbx file). The database format is open, well-documented, and supported by dozens of third-party clients on every major platform.

The trust model is markedly different from Vaultwarden's. KeePassXC has no concept of a server, and the database file is just a file. Sync is whatever you make it: Syncthing, Nextcloud, Dropbox, manual USB transfer. Mobile clients (KeePassDX on Android, Strongbox or KeePassium on iOS) typically open the same database file from a sync service or local copy.

Strengths: The smallest attack surface of any option here. There is no service to compromise — only a file format. The encrypted database can be stored on any storage medium without trust assumptions about the medium. KeePassXC supports YubiKey challenge-response as a second factor on the database itself, which is dramatically stronger than most second-factor implementations because the YubiKey must be present to decrypt. Browser integration via KeePassXC's official browser extension is functional but less polished than Bitwarden's.

Weaknesses: Sync conflicts are real. If you edit the database on two devices simultaneously without saving in between, KeePassXC will fail to merge cleanly and you'll lose one set of changes. Mobile UX is workable but not as smooth as a native cloud-backed client. Setup of multi-device sync requires picking and configuring a separate sync mechanism.

The YubiKey hardware factor: KeePassXC's YubiKey challenge-response support is one of the strongest defensive features in any password manager. The Yubikey must be physically present and respond to a challenge to decrypt the database. Without the key, even a perfectly correct password produces only gibberish. This makes the encrypted database meaningfully safer to store in untrusted locations.

Pass (passwordstore.org)

Pass takes a Unix-philosophy approach: every credential is a small GPG-encrypted file, and the entire collection lives in a directory tree, optionally versioned with git. There is no database — just files. The reference implementation is a bash script of approximately 800 lines.

To retrieve a password, you run pass show github.com/myaccount and pass decrypts the corresponding file with GPG, prompting for your GPG passphrase (typically cached via gpg-agent for a configurable interval). To sync between devices, you push and pull the git repository. To share credentials with a teammate, you add their GPG key to the relevant subdirectory and re-encrypt.

Strengths: The data model is extraordinarily transparent. If pass disappeared tomorrow, you'd still have a tree of GPG-encrypted files that any GPG implementation can decrypt. The git history gives you free versioning, audit trail, and conflict resolution. Multi-recipient encryption (different GPG keys for different password subtrees) provides clean per-credential access control. Browser extensions exist (browserpass), but most users access pass via terminal or via rofi/dmenu launchers.

Weaknesses: You need to be comfortable with GPG, which is notoriously rough. Mobile support exists (Password Store on Android, Pass on iOS) but is more cumbersome than the alternatives. The browser autofill experience is functional but not as smooth. There's no built-in concept of TOTP storage (though plugins exist). Backup-and-recovery requires understanding both your git remote and your GPG key infrastructure.

Side-by-side comparison

Property	Vaultwarden	KeePassXC	Pass
Architecture	Client/server	File-based	Git tree of GPG files
Sync mechanism	Built-in (HTTP)	External (Syncthing, etc.)	Built-in (git)
Conflict handling	Strong	Manual	Git merge
Browser autofill quality	Excellent	Good	Functional
Mobile UX	Excellent	Good	Rough
Operational burden	Server + TLS + backups	Sync + backups	GPG + git + backups
Audit-friendliness	Codebase auditable	File format auditable	Files = trivially auditable
YubiKey support	Login second factor	Challenge-response (strong)	Via GPG smartcard

How to pick

The decision is mostly about how much operational complexity you'll tolerate vs. how much polish you want:

Vaultwarden is the right answer if you want a Bitwarden-quality experience without trusting Bitwarden the company. You will run a server. The clients are excellent and your family members will not complain. Pair with a strong master password and reverse-proxy authentication (basic auth + your normal HTTPS layer) to reduce the attack surface of the server itself.

KeePassXC is the right answer if you want maximum simplicity in the trust model and are comfortable picking and configuring your own sync mechanism. The YubiKey integration is a significant defensive feature for users handling sensitive accounts. Sync conflicts are the main operational annoyance — Syncthing handles this better than cloud-drive options.

Pass is the right answer if you're already a GPG user, comfortable on the command line, and want your password manager to be readable, scriptable, and trivially auditable. It is the worst option for users who want polished mobile and browser experiences. It is the best option for users who want to be able to inspect every byte of their password storage and understand the cryptography end to end.

All three are meaningful improvements over closed-source hosted password managers if you have the operational capacity to run them well. The largest mistake is choosing one and then operating it poorly — a self-hosted password manager without backups, with a weak master password, or exposed to the public internet without proper hardening is worse than a competently-run hosted alternative. The infrastructure has to be at least as well-administered as the service you're replacing.

Originally published at havenmessenger.com

HPKE Explained: Hybrid Public Key Encryption (RFC 9180)

Haven Messenger — Mon, 25 May 2026 08:18:36 +0000

Most cryptographers used to assemble public-key encryption out of spare parts — pick an ECDH curve, pick an AEAD, write your own glue, hope nobody footguns it. HPKE is the standardized version of that glue. It's now load-bearing under MLS, TLS Encrypted Client Hello, and Oblivious DNS, and it's quietly the most important new crypto primitive of the last five years.

HPKE — Hybrid Public Key Encryption — is published as RFC 9180 by the IRTF Crypto Forum Research Group. The name is plain-spoken: it does public-key encryption, hybrid in the sense that it combines an asymmetric Key Encapsulation Mechanism (KEM) with a symmetric Authenticated Encryption with Associated Data (AEAD) construction. The combination isn't new. The standardization is.

Before HPKE, every protocol that needed to encrypt to a public key (without a full TLS handshake) reinvented the same pattern: generate an ephemeral keypair, do a Diffie-Hellman exchange against the recipient's static key, derive a symmetric key, and encrypt the payload with AES-GCM or ChaCha20-Poly1305. The reinventions varied in subtle and broken ways. HPKE fixes the categories of bugs by drawing the lines once.

What HPKE Actually Does

Conceptually, HPKE provides a sealed-envelope API. The sender has the recipient's public key. The sender calls Seal, gets back an encrypted message plus an encapsulated key. The recipient — who holds the private key — calls Open on the same inputs and recovers the plaintext.

Under the hood, four building blocks compose:

KEM — Key Encapsulation Mechanism. Produces a shared secret and an encapsulation. Concrete choice: DHKEM over X25519, P-256, P-384, P-521, or X448. Post-quantum hybrids are being layered in.
KDF — Key Derivation Function. Turns the shared secret plus context strings into the symmetric keys actually used. HKDF-SHA256, HKDF-SHA384, HKDF-SHA512.
AEAD — symmetric encryption with integrity. AES-128-GCM, AES-256-GCM, or ChaCha20-Poly1305.
Mode — base, PSK, auth, or auth-PSK. Determines whether sender authentication or a pre-shared key is mixed in.

A given HPKE "ciphersuite" is just the choice of KEM, KDF, and AEAD — a tuple registered with IANA. Implementations advertise the suites they support, and protocols pick. This is the same pattern as TLS cipher suites but scoped much smaller.

Why hybrid is the right word. The KEM does an expensive elliptic-curve operation once, to establish a shared secret. The AEAD does cheap symmetric encryption on the payload. You pay public-key cost once, symmetric cost per byte. This is the same shape as TLS, just stripped down to its smallest useful unit.

The Four Modes

HPKE's mode parameter changes who authenticates what. Most uses pick one and stick with it.

Mode	Sender	Properties
Base	Anonymous	Recipient knows nothing about who sent it; only that it was sealed to their public key. Most common mode.
PSK	Holds a shared symmetric key	Mixes a pre-shared key into derivation. Recipient learns the sender belonged to the PSK group.
Auth	Holds a static asymmetric key	Sender authenticates via their own static keypair. Recipient verifies sender identity cryptographically.
Auth-PSK	Both static key and PSK	Belt and suspenders. Both authentication mechanisms layered.

Most real-world HPKE deployments use Base mode. The sender is genuinely anonymous because the protocol provides identity elsewhere — through TLS, through an MLS commit, through an OAuth token. HPKE doesn't have to do everything.

Single-Shot vs Streaming

The minimal API is single-shot: seal one message, open one message, done. Both sides derive the same key from the shared secret and pass a fixed nonce.

The streaming API exposes the AEAD context directly. The sender calls Seal repeatedly; the recipient calls Open repeatedly. A monotonically increasing sequence number generates a unique nonce per message. This is how MLS uses HPKE for welcome messages, and how ECH handles its inner ClientHello — many messages, one encapsulation.

The streaming form is where most subtle implementation bugs live. If the sequence number ever wraps, or if it ever resets without re-keying, AES-GCM nonce reuse breaks confidentiality and integrity simultaneously. RFC 9180 mandates explicit limits and re-keying behavior. Audit any custom HPKE wrapper against those limits.

Where HPKE Shows Up in 2026

MLS — Messaging Layer Security

MLS (RFC 9420) uses HPKE for its Welcome message — the bundle a new group member receives that lets them derive the current group key. MLS could have rolled its own asymmetric encryption, but using HPKE means MLS gets the underlying construction's security analysis for free.

TLS Encrypted ClientHello

ECH hides the server name a client is connecting to from passive observers. The mechanism is HPKE-Sealing the inner ClientHello to a public key the client fetches via DNS HTTPS records. ECH is the load-bearing reason HPKE got fast-tracked through the IRTF.

Oblivious DoH

Oblivious DNS-over-HTTPS — ODoH (RFC 9230) — uses HPKE to encrypt DNS queries inside an envelope only the resolver can open, then relays them through a proxy that knows the client IP but not the query. The proxy and the resolver each see only half the picture. HPKE is what makes the envelope sealing efficient enough to be deployable.

Privacy Pass and Anonymous Tokens

Privacy Pass extensions and related anonymous-token systems use HPKE for the issuance-to-redemption envelope, allowing a token to be issued by one party and redeemed by another without correlation.

Why It Replaces Ad-Hoc KEM+AEAD Glue

Before HPKE, the canonical reference for "encrypt to a public key" was often "look at how libsodium does sealed boxes" or "look at how Signal does X3DH." Both are fine in isolation. Neither is interoperable across protocols. Worse, both bake in specific algorithm choices that can't easily be swapped without redesigning the wire format.

HPKE separates the wire format (an encapsulation followed by ciphertext) from the algorithm choice (ciphersuite ID). Hybrid post-quantum ciphersuites are being added by registering new KEMs — the rest of the construction stays put. This matters as the industry transitions to post-quantum.

The KEM-DEM paradigm dates back to Cramer and Shoup in the late 1990s. HPKE is what you get when you take twenty-five years of attacks on its naive implementations and write down the version that survived.

Common Implementation Pitfalls

The spec is careful, but implementations are where things break:

Re-using the encapsulated key. Each Seal must generate a fresh ephemeral. If you cache and reuse, you destroy forward secrecy and create deterministic ciphertexts.
Wrong info string. The "info" parameter binds the encryption to its context (protocol name, version, purpose). If sender and recipient pass different info, Open fails — but if a system loops a malleable string into info, you can get cross-protocol attacks.
AAD confusion. Associated Authenticated Data covers integrity but not confidentiality. Putting secrets in AAD leaks them. Putting message-binding metadata in AAD is correct.
Nonce sequencing in streaming. Same warning as TLS 1.3: never reset the sequence counter without re-keying. The spec mandates rekeying limits per AEAD; respect them.

Picking a Library

Implementations vetted against the RFC and its test vectors:

hpke-rs (Rust) — used in MLS implementations including OpenMLS.
BoringSSL and OpenSSL 3.2+ — ECH and HTTP-over-QUIC use these.
CIRCL (Go, by Cloudflare) — production-tested through ECH rollout.
hpke-js — the JavaScript implementation reference. Suitable for browser ECH-adjacent work.

Rolling your own HPKE is the kind of choice that looks reasonable on a Monday and turns into a CVE by Friday. The construction is small enough to look tractable. The boundary conditions — nonce limits, info domain separation, ciphersuite negotiation, hybrid PQ wrapping — are where the time goes. Use the library.

The Takeaway

Shared standards beat ten clever local solutions, every time. If you're designing a protocol that needs to encrypt to a public key, the answer in 2026 is HPKE.

Originally published at havenmessenger.com

JWT Security Pitfalls: The Mistakes That Keep Breaking Tokens

Haven Messenger — Sun, 24 May 2026 08:21:47 +0000

JSON Web Tokens look deceptively simple. Three base64-encoded segments, a signature, and you're authenticating users across a distributed system. The problem is that the format hands authors enough rope to hang an entire application — and the same handful of mistakes keep showing up in CVE feeds year after year.

A JWT is three dot-separated chunks: a header describing the signature algorithm, a payload of claims (subject, issuer, expiry, custom data), and a signature over the first two. RFC 7519 defined the structure in 2015 and it became the default token format for OAuth, OpenID Connect, and roughly every "stateless authentication" tutorial since.

Most of the trouble lives not in the spec itself but in the libraries that implement it — and in the validation code developers write around them. The fundamental issue is that JWTs are flexible: they support multiple algorithms, optional claims, and several legitimate use cases. Each axis of flexibility is a place where a mistake can let a forged token through.

The "alg: none" Trap

The JWT spec includes an algorithm called none. It's intended for tokens that don't need cryptographic integrity — a stretch of use case that has never made sense in practice. When the algorithm is none, the signature segment is empty. A token with {"alg":"none"} in its header has no signature to verify, and a naive library will accept it.

The attack writes itself. Take a legitimate token, modify the payload to escalate privileges, change the header's alg to none, and submit it. If the server's verifier doesn't explicitly reject none, the token validates.

Mitigation: Every modern JWT library lets you pin the accepted algorithms. Always pass an explicit list — ["HS256"] or ["RS256"] — never trust the library default. If your code path includes none as accepted, that is the bug.

Several widely-used libraries shipped with none accepted by default until around 2018. The class of bug is fixed in current versions, but old deployments persist, and the lesson generalizes: trusting the token's own description of how to verify it is the original sin of JWT validation.

The Algorithm Confusion Attack

A subtler version of the same problem. JWTs support both symmetric algorithms (HMAC variants — HS256, HS384, HS512) and asymmetric ones (RSA — RS256, etc., and ECDSA — ES256, etc.). A symmetric algorithm uses a single shared secret; an asymmetric one uses a private key to sign and a public key to verify.

If a server expects RS256 — verifying tokens with an RSA public key — but a library trusts the alg field, an attacker can craft a token with "alg":"HS256" and sign it with the server's public key as the HMAC secret. The public key is, by definition, public. The library, asked to "verify HS256 with the configured key," dutifully validates the HMAC. The token is accepted.

This is the algorithm confusion attack, and it's the canonical reason you must pin algorithms at validation time. The library cannot decide what algorithm is acceptable; the application must.

Skipping Signature Verification Entirely

Most JWT libraries have a decode() function that parses the token without verifying the signature, and a separate verify() function that does both. The decode() function exists for legitimate reasons — inspecting a token for debugging, reading the kid header to look up the correct key — but it has a habit of finding its way into production code paths where verification was the actual intent.

The symptom is code that "works" — claims parse correctly, the user ID is present, requests succeed — while never actually validating the signature. A forged token with arbitrary claims gets accepted indistinguishably from a legitimate one. The bug is silent and code review catches it only if reviewers know the API surface.

One memorable production failure mode: a refactor moved authentication to a middleware layer; the new layer called decode() instead of verify(); tests passed because the test fixtures had valid signatures; deployment passed because the integration tests didn't include any forged tokens. The bug was found by a security audit eight months later.

Missing Claim Validation

A valid signature proves the token wasn't forged. It doesn't prove the token is currently valid, was issued by the right party, or is being used by the right service. Those are claim-level checks, and they're the developer's responsibility.

Claim	Check	Failure mode if skipped
`exp` (expiry)	Reject if past current time, with clock-skew tolerance	Stolen tokens never expire
`nbf` (not-before)	Reject if before current time	Pre-dated tokens accepted
`iss` (issuer)	Reject if not your trusted issuer	Tokens from another tenant or service accepted
`aud` (audience)	Reject if not your service's identifier	Tokens intended for a different API accepted
`iat` (issued-at)	Sanity-check it's not far in the future	Replay window confusion

Audience validation in particular is widely skipped. If your authorization server issues tokens for three services and only one of them checks the aud claim, a token issued for one service can be replayed against the others. This was the root cause of several high-profile breaches in OAuth-based architectures.

JWKS Key Confusion

Asymmetric JWTs are usually verified by fetching the issuer's public keys from a JWKS (JSON Web Key Set) endpoint, often discovered through OpenID Connect metadata. The token carries a kid (key ID) in its header indicating which key to use.

Two recurring bugs here. First, libraries that fetch the JWKS over plain HTTP — a network attacker can swap in their own keys. Always use HTTPS, and ideally cache the keys with a short TTL. Second, applications that trust an arbitrary jku (JWK Set URL) header from the token itself — an attacker provides a URL pointing to a key set they control, and the library cheerfully fetches and uses it. The jku header was never safe to trust without an allowlist, but the spec doesn't make this obvious.

The "Stateless" Lie

Half the appeal of JWTs in marketing material is statelessness: the server doesn't need a session database, just a signing key. This works fine until you need to log a user out.

A signed JWT is valid until its exp claim says otherwise. If a user's account is compromised, or they hit "log out," the token still cryptographically validates. The options are:

Accept the window — tokens live for at most a few minutes, refresh tokens are revocable
Maintain a server-side denylist of revoked token IDs (and at that point you have a session database)
Issue very short access tokens and rely on the refresh token endpoint to enforce policy

The first and third approaches are the modern norm. Long-lived JWTs — say, 24-hour access tokens — without a revocation mechanism are a security liability disguised as a feature.

What to Use Instead, When You Can

For server-to-server authentication, mTLS often removes the entire bearer-token attack surface. For user-facing authentication, opaque session tokens stored in a database — old-school session cookies — have the property that revocation is trivial and the token itself reveals nothing.

JWTs make sense when you genuinely need self-contained claims that downstream services must verify without consulting the issuer. OpenID Connect's ID tokens fit this; cross-service authorization in a microservice mesh fits this. For "logged in user has a session," they're often overkill — and the operational complexity costs more than it saves.

The Validation Checklist Worth Printing

If you must use JWTs, the non-negotiable checks before trusting any claim:

Pin the algorithm. Pass an explicit allowed list to your verifier. Never accept none.
Verify the signature. Use verify(), not decode().
Check exp and nbf with a reasonable clock-skew tolerance (a minute is generous).
Check iss and aud against an allowlist your application defines.
Fetch keys over HTTPS from a hard-coded JWKS URL. Never honor jku or x5u headers from the token.
Use a current library version. Many older versions have CVEs for the bugs above.
Have a revocation story. Short-lived access tokens or a denylist. Pick one.

Most JWT vulnerabilities are not algorithm breaks — they're implementation oversights at the validation layer. The cryptography is fine; the contract around it is the dangerous part. As with most security primitives, the failure mode is rarely the math.

Originally published at havenmessenger.com

BGP Hijacking Explained: How Internet Traffic Gets Stolen

Haven Messenger — Fri, 22 May 2026 08:19:54 +0000

When you load a website, your packets do not travel along a fixed wire. They are handed from network to network, each one consulting a routing table that says "to reach this block of addresses, forward toward that neighbor." Those tables are built from announcements. Networks tell their neighbors which address ranges they can deliver to, the neighbors propagate the claim, and within minutes the whole internet agrees on a path.

The protocol that carries those announcements is BGP, and it was designed in an era when every network operator personally knew the others. It assumes good faith. A network can announce a route for address space it does not own, and by default its neighbors will believe it. When that false announcement is more attractive than the legitimate one, traffic for a victim's addresses starts flowing to the attacker instead. That is a BGP hijack.

How a Hijack Actually Works

Every network on the internet has an Autonomous System Number — an AS number — and the address blocks it is authorized to originate. A hijack is an AS announcing a block it has no authority over. There are two flavors, and the difference matters.

The more-specific route hijack

Internet routing always prefers the most specific match. If the legitimate owner announces a large block and an attacker announces a smaller, more specific sub-block of it, every network on earth will prefer the attacker's route for that sub-block — not because it is shorter, but because it is more precise. This is why even a network "far" from the victim can pull traffic globally with a single sufficiently specific announcement.

The equal-specificity hijack

If the attacker announces the same block size as the victim, there is no precision tiebreaker. The hijack only succeeds for the slice of the internet that happens to be topologically closer to the attacker. It is partial — but partial is often enough.

Hijack vs. blackhole — An attacker who simply wants to take a service offline can announce the route and drop the traffic — a blackhole. An attacker who wants to spy does something harder: announce the route, inspect or modify the traffic, then forward it on to the real destination so the victim never notices the detour. That second pattern is an interception hijack.

What Hijacks Have Actually Been Used For

BGP incidents fall into a few recurring categories, and not all of them are malicious:

Fat-finger leaks. A misconfigured router accidentally announces routes it should not. A well-known 2008 incident took a large video platform globally unreachable for hours after a telecom's attempt to block it domestically leaked worldwide.
Traffic interception for surveillance. Researchers have documented hijacks that route traffic through a distant country and back, holding it just long enough to inspect.
Cryptocurrency theft. One of the most cited criminal cases involved hijacking the address space of a public DNS service in 2018, redirecting users of a cryptocurrency wallet site to a malicious clone and draining funds.
Spam and abuse. Hijacking unused address space to send spam from "clean" IPs, then disappearing.

The common thread: the attacker briefly becomes a network you never chose to trust, sitting directly in the path of your traffic. Everything that crosses an untrusted network in plaintext is readable. Everything not cryptographically authenticated can be modified.

The Defenses: RPKI and BGPsec

The internet's structural answer to hijacking is to attach cryptographic proof to routing claims. Two mechanisms matter.

RPKI — Resource Public Key Infrastructure — lets an address-block owner publish a signed statement called a Route Origin Authorization: "AS number X is authorized to originate this block." Networks that perform Route Origin Validation reject announcements that contradict a valid ROA. RPKI adoption has grown substantially, and it is genuinely effective against the most common case: a wrong-origin announcement, whether accidental or malicious.

But RPKI only validates the origin of a route, not the path it claims to have taken. A sophisticated attacker can craft an announcement that lists the legitimate origin AS at the end while still inserting itself into the path — a defense-aware hijack that RPKI alone does not catch.

BGPsec closes that gap by cryptographically signing the entire AS path, so each hop can be verified. It is the more complete answer — and the less deployed one, because it demands far more router resources and near-universal adoption to be useful. The realistic state of the internet in 2026 is broad RPKI origin validation and very limited path validation.

Mechanism	Protects against	Does not stop
RPKI / ROV	Wrong-origin announcements — the most common hijack and nearly all accidental leaks	Path manipulation that keeps the real origin AS at the end
BGPsec	Forged AS paths, by signing every hop	Limited by sparse deployment; high router cost
Transport encryption (TLS)	Reading or altering your content on a hijacked path	The hijack itself, and metadata exposure

Why This Is Ultimately an Encryption Problem for You

Here is the uncomfortable part: as an individual, you cannot fix routing. You do not run an AS. You cannot make your ISP deploy RPKI or audit the path your packets take. Routing security is an operator-level discipline, and you are downstream of every decision those operators make.

What you can control is whether a hijack matters when it happens. An attacker who diverts your traffic through their network gains a front-row seat — but only to whatever you sent in the clear. If your connection is protected by TLS 1.3, the attacker sees ciphertext. They cannot read it, and they cannot modify it without breaking the connection, because TLS authenticates both endpoints and every byte.

The internet's routing layer was built on trust and never fully retrofitted with proof. Treat every network between you and your destination as potentially hostile — because for the duration of a hijack, one of them is.

This is the same logic behind certificate pinning and forward secrecy: assume the path is compromised and design so it does not matter. A hijack can still hurt you in two ways encryption does not erase — it can take a service offline entirely, and it still exposes metadata, the fact that you connected to a given destination at a given time. But it cannot turn your communications into the attacker's reading material.

Where Haven Fits

Haven cannot patch BGP, and we would be lying if we claimed to. What we can do is assume the network is untrustworthy and build accordingly. Message content is end-to-end encrypted with keys derived on your device, so a hijacked path carries ciphertext and nothing else. Connections are authenticated, so a man-in-the-middle on a diverted route cannot silently substitute itself.

Routing-layer security is a job for network operators, and the slow grind of RPKI and BGPsec adoption genuinely helps everyone. But your defense as a user does not depend on that grind finishing. It depends on never trusting the path in the first place — which is a property your tools either have or do not. Haven is one option built on that assumption; the principle holds whichever service you choose.

Originally published at havenmessenger.com