Earlier this year Apple denied me access to App Store Connect after deciding that I matched someone on a U.S. government restricted-party list.

Their explanation was fairly definitive:

“The information you provided fully matches one or more restricted parties on the U.S. government consolidated screening list or another government’s sanctions list.”

They already had my passport.

I replied with my full legal name, Sean Joseph Byrne, uploaded my driver’s license, and pointed out the address on the government record they appeared to be matching me against. I’ve never lived at that address, never lived in County Sligo, and have no connection to the company involved. I asked them to escalate it to their sanctions compliance folks and make a proper non-match determination.

Apple still hasn’t replied.

Apple’s response after reviewing my identity information.

I knew what had happened because this wasn’t the first time.

Cloonmull House

Search the U.S. government’s Consolidated Screening List for Sean Byrne and you get exactly one result:

Sean Byrne
Cloonmull House
Drumcliffe, County Sligo
Ireland

Source: Entity List, Bureau of Industry and Security
Added: July 21, 2009
License requirement: All items subject to the EAR
License policy: Presumption of denial

The Consolidated Screening List isn’t itself a sanctions list. It’s a U.S. government screening tool that combines a number of export-control, sanctions and other restricted-party lists maintained by the Departments of Commerce, State and Treasury.

The result comes from the Commerce Department’s Bureau of Industry and Security Entity List. “All items subject to the EAR” means the Export Administration Regulations, the rules governing what U.S. companies can ship abroad. “Presumption of denial” is a licensing posture: if someone applies for a licence to export something to this person, the default answer is no. That’s the entire purpose. It’s an export-control instrument but it says nothing about who can be employed, or who can sell shares.

The person in the search result isn’t me. More interestingly, it doesn’t appear to be anyone.

The entry came out of the prosecution of an Irish aircraft-parts business called Mac Aviation. In 2009, the Department of Justice described Sean Byrne as Mac Aviation’s commercial manager and charged him alongside Thomas and Sean McGuinn over the illegal export of U.S. aircraft equipment to Iran.

Except Mac Aviation had apparently invented employees to make the company look bigger than it was.

Mac Aviation was a father and son working out of a cottage on the edge of Drumcliffe village, Ben Bulben behind it. A Rolls-Royce official who came to visit was reportedly speechless. The company he had been selling helicopter engines to, and had taken for a global operation employing hundreds of professionals, was a house in Sligo.

Drumcliffe, County Sligo, with Ben Bulben in the background.

To keep up the impression of a much larger firm, the McGuinns signed documents with false names. Sean Byrne was one of them. John Mooney reported in the Sunday Times that the name appeared on so much company paperwork that the American authorities “became convinced Byrne existed and tried to indict him.”

When DOJ filed a superseding indictment in 2010, replacing the original, Sean Byrne was no longer a defendant. The defendants were Mac Aviation and Thomas and Sean McGuinn.

More importantly, the superseding indictment repeatedly describes Sean Byrne as an alias used by one or more co-conspirators. The phrase appears more than fifteen times, attached to specific invoices, emails and an ownership statement. Mac Aviation staff used the name with suppliers in the U.S. and customers in Iran.

At some stage the U.S. government appears to have worked out that Sean Byrne wasn’t actually a separate person. And yet the entry in the Entity List survived. Sixteen years later it still has no date of birth, passport number, middle name or other useful personal identifier. It’s basically a common Irish name, an address in Sligo and Ireland.

Cloonmull House in Sligo was Thomas McGuinn’s home, and the indictment gives it as Mac Aviation’s registered mailing address. So the entry isn’t a record of a man in Sligo. It’s a name attached to somebody else’s house. And I’ve never lived in Sligo.

This has happened before

Years before I moved back to Ireland, I was selling stock through a tender offer when Nasdaq stopped my order after a background check returned a match on my name.

Their Head of Account Management emailed me saying that the check had found a match associated with a previous incident and that he was confident it was a false positive, but compliance wanted additional proof of my California address. On the phone he gave me more detail and specifically asked me about Mac Aviation. I explained that I’d never had anything to do with the company, provided the extra documentation they wanted and the sale went through with an entertaining story to tell people.

Nasdaq’s response after a background check matched my name.

More recently I ordered a Starlink mounting pole from California. DHL, shipping on behalf of SpaceX, told me the problem was a restricted-party match and asked for my passport. I sent it, they cleared it and the pole arrived. DHL also wouldn’t send a hat I’d ordered in the U.S. on to me in Ireland without a copy of my passport.

The fake Sean Byrne was associated with attempts to procure helicopter engines, fighter-aircraft parts and other U.S. equipment for Iran. The real Sean Byrne occasionally needs to produce a passport before someone will send him a hat.

Apple is the odd one out. Nasdaq and the shippers both generated false positives, asked for enough information to resolve them, and then resolved them. Apple already had my passport, received my driver’s license and a fairly detailed explanation of exactly why the match was wrong, and still told me that I “fully” matched a restricted party.

Twelve men named Robert Johnson

None of this is novel. In October 2006, 60 Minutes found twelve American men named Robert Johnson who all had trouble boarding flights, and brought them to New York together. A politician, a soccer coach, businessmen and a serving member of the military.

The Robert Johnson they kept being confused with wasn’t a man named Robert Johnson. It was a known alias of someone convicted of plotting to bomb a Hindu temple and a cinema in Toronto, who by then had served his sentence and been deported to Trinidad. The airline agents checking the twelve real ones against it had a name and nothing else. Not even a date of birth.

Asked about it, the head of the FBI’s Terrorist Screening Center said Robert Johnson would never get off the list, and that anyone with the name would be inconvenienced every time they tried to check in.

I’m not on the Entity List. I’m being misidentified as an entry on it. Apple didn’t make that distinction.

The consumer version of this has been litigated. In 2005 Sandra Cortez was held up buying a car in Colorado because TransUnion matched her against a woman on the Treasury Department’s sanctions list who was born 27 years after her. The credit bureau had compared first and last names only, not dates of birth. A jury awarded her damages and the Third Circuit upheld it, describing the failure to compare birth dates as reprehensible. Sergio Ramirez had the same experience at a car dealership six years later, and his case reached the Supreme Court in 2021.

In both cases the courts called for better matching. Compare the date of birth. Compare the middle name.

There is no version of that available to me. The listing has no date of birth to compare. No middle name and no passport number, because the person doesn’t exist. A screening system that does its job perfectly will still flag me, forever, on the only two facts the record contains: a common Irish name and a country.

Which is why arguing with companies one at a time is the wrong approach.

The real fake Sean Byrne

Remote hiring has developed a serious identity-fraud problem. It has also developed, somewhat unbelievably, a North Korea problem.

North Korean IT workers have been getting remote jobs at U.S. companies using stolen or fabricated identities, proxy interviewers and U.S.-based “laptop farms” that make workers overseas appear to be connecting from inside the United States. The FBI has been warning companies about it, and the DOJ has prosecuted schemes that successfully placed workers at more than 100 U.S. companies.

So if you’re hiring remote engineers, “is this person actually who they claim to be?” is now a legitimate security problem.

A new class of recruiting products is being built around that problem. They sit inside the software companies use to manage job applications, the applicant tracking system or ATS.

Tofu is one of them. Their pitch is that they screen every applicant across more than forty signals before a recruiter opens a résumé, and that when a screened applicant triggers a sanctions match the signal routes straight to compliance review. They are explicit that this has to happen early: screening at the background-check stage is, on their account, already too late, so it should run at application submission before any recruiter makes contact. They also say a candidate flagged by one of their customers is flagged across their whole customer network through their API. Brainner makes a similar case, checking applicants against 3.5 billion data points and flagging high-risk profiles before a recruiter reviews them.

Tofu says its database is built from analysed applicant profiles. Their homepage says more than 18 million. Most of their other pages say more than 5 million.

The sanctions screening these vendors describe is OFAC and the Specially Designated Nationals list, which is the right list for the risk they’re selling against: paying wages to a sanctioned person. I’ve no evidence that either company queries the BIS Entity List, and no idea whether any company I’ve applied to uses either product.

But screening my name against U.S. restricted-party data produces a false positive. It did at Nasdaq, at SpaceX, at DHL and at Apple. Four times in six years. And the industry’s answer to remote-hiring fraud is to run that class of check earlier, before a human is involved, and propagate the result across a network of employers.

Mac Aviation fabricated an employee to make itself look like a bigger company. That fabricated employee ended up in an authoritative U.S. government database. Sixteen years later, companies are building systems using that database to detect fake applicants, fraudsters, criminals and state-backed actors before they get through the hiring process.

Has this cost me a job? I don’t know. I’ve spent my career in information security, much of it in the U.S., and I’m now applying for roles from Ireland. There have been jobs where I’ve a background that should at least get a conversation and I’ve heard nothing. That’s hardly remarkable on its own. Hiring is messy, roles get frozen, recruiters disappear and companies reject perfectly good candidates for reasons the candidate will never know. There is an entire website called Did They Ghost You?, so we’re not dealing with an unexplained phenomenon.

But Nasdaq told me it was Mac Aviation. DHL shipping on behalf of SpaceX asked for a passport and told me it was due to a hit against the restricted parties on the U.S. government consolidated screening list. Apple at least told me I’d matched something, even if it then stopped talking. An applicant tracking system will tell me nothing at all.

Upstream

I asked the Bureau of Industry and Security’s End-User Review Committee to review the original Entity List entry. I’m not sure anything will come of it. The normal process is designed for a listed person asking to be removed, which creates an interesting problem here. I’m not the listed Sean Byrne, and the available evidence suggests that person may never have existed.

For now the U.S. government’s screening data still says Sean Byrne, Cloonmull House, Drumcliffe, County Sligo.

I’ve still never lived in Sligo.

Download the slides (PDF)

Here’s a summary of the argument.

The hard part of cryptography is the keys

End-to-end encrypted systems like WhatsApp and Signal have always had to grapple with an awkward question: where do the encryption keys actually live? And more importantly, when you lose your phone, where does access come back from?

Key storage is key recovery. The cryptography is the easy part. The hard part is what happens when a user drops their phone in a river.

This is where E2EE has historically lost to convenience. Telegram doesn’t beat Signal on security. It beats it on “enter your phone number, you’re chatting.” Users consistently choose less friction, even at the cost of a server that can read their messages.

Three generations of E2EE key management

The history of E2EE key storage is a steady migration away from user memory.

Generation 1: password-derived keys. Derive the root key directly from the user’s password through a KDF. The server only ever sees encrypted data. The problem is that a human picked the secret. “123456” has been used over 4.5 million times, and no KDF saves you from that. When you lose your devices, access comes back from a password you remembered. Everything rests on user memory.

Generation 2: PIN + hardware. Signal’s Secure Value Recovery is the canonical design. Users pick a low-entropy PIN, but the PIN-protected backup key lives inside a secure enclave that enforces a hard guess limit; after too many wrong attempts, the secret is destroyed. WhatsApp shipped the same shape with an HSM-backed Backup Key Vault. Juicebox pushed the pattern further with Shamir secret sharing and OPRFs across multiple operators. User memory still matters, but much less of it, and hardware does the heavy lifting.

Generation 3: trusted devices. Apple’s Advanced Data Protection removes the memorized secret from the critical path entirely. Keys sync across a set of explicitly trusted devices, and recovery comes from another device, a recovery contact, or a printed recovery key. Nothing the user has to remember in steady state.

Worth noticing: Moxie Marlinspike walked this entire arc personally. He built Signal’s SVR (Gen 2), co-designed Juicebox (Gen 2.5), and is now shipping what I’d argue is Gen 4.

Generation 4: passkey PRFs

Passkeys changed the FIDO2 story in one crucial way: credentials sync. Old FIDO2 credentials were device-bound, so losing the device meant losing the credential, which is largely why adoption stalled. Passkeys sync through provider infrastructure (iCloud Keychain, Google Password Manager, 1Password), so a new device already has them.

The WebAuthn PRF extension builds on that. A passkey can now produce cryptographic keys, not just authentication signatures. The application supplies a salt, and the authenticator returns a deterministic, high-entropy value derived from the credential. It’s HMAC under the hood, originally the CTAP hmac-secret extension designed for disk encryption.

That means one passkey can do both jobs:

One thing to lose instead of three. Recovery inherits from passkey sync. Hardware-backed by default. The same UX as login.

“Cryptography turns data security problems into key management problems.”

• Moxie Marlinspike

This is deployable now

The primitive is old; cross-platform availability is recent. Chrome shipped PRF support in 2023, Android followed in 2024, and Apple’s iOS 18 / macOS 15 / Safari 18 release in September 2024 put PRF on a billion-plus devices. That was the inflection point. Windows Hello support landed in February 2026. 1Password, Dashlane, and Bitwarden already derive vault keys from PRF outputs.

The cleanest production example is Moxie’s Confer, an E2EE AI chat product. Sign up, and a PRF-capable passkey is created on your device. No password. The PRF output is fed through HKDF to derive a root key, which envelope-encrypts everything else. The server never sees it, and key recovery inherits from passkey sync.

And then there’s the proof at scale: WhatsApp, the largest E2EE deployment on earth. Backups went from plaintext (pre-2021), to a password-protected HSM vault (Gen 2, 2021), to passkey-backed encrypted backups in 2025. One product, three billion users, two generational jumps, and it skipped Gen 3 entirely.

What actually changes

Passkey PRFs are not a cryptographic breakthrough. They’re an engineering simplification that collapses two long-separated key management problems, authentication credentials and encryption root material, into a single primitive.

What gets fixed:

• No per-service PINs
• No backup key escrow ceremony
• No recovery phrase to write down
• No “you will lose everything unless you guard this with your life” warnings
• One credential lifecycle instead of two

The bigger win is that, for the first time, E2EE has a recovery story competitive with non-E2EE systems. Telegram’s advantage was never security. It was friction. Passkey PRFs close that gap.

And because every modern phone and laptop ships with a secure enclave or TPM, every employee already carries hardware-backed key material in their pocket. The trust relocates from servers to client devices that already exist. I wrote more about the enterprise angle in Passkeys and the Quiet Revolution in Corporate Crypto.

Credits

The work that brought passkey PRFs from spec to production E2EE: Adam Langley and the WebAuthn WG wrote the PRF extension spec; Matthew Miller introduced PRF-for-encryption to web developers in 2023; Kevin Lewi documented WhatsApp’s OPAQUE + HSM backup design at RWC 2023; 1Password shipped the first major production use in 2024 and open-sourced their library; Filippo Valsorda brought cryptographer-grade design to PRF file encryption with typage; and Moxie Marlinspike’s Confer gave the clearest public framing of why this matters.

Full slides here (PDF)

Everything feels uncertain right now. Security is no different.

Here’s what’s been nagging at me. For all the talk about AI transforming cybersecurity, we’re not seeing the attacks we should be seeing. Not given what the technology can do. The phishing is better, the reconnaissance is faster, but the truly AI-native attacks, bespoke exploit chains, automated zero-day discovery across entire ecosystems, haven’t materialised at scale. Not yet.

There’s a scene in Jurassic Park where the electric fences go down. The dinosaurs don’t charge through. They don’t know the fence is off. They’ve been conditioned to stay put, so they do. For a while.

That’s where we are. The fence is down. Most threat actors just haven’t copped on yet.

This week, Anthropic published the results of a security collaboration with Mozilla. They pointed Claude Opus 4.6 at the Firefox codebase and in two weeks it found 22 previously unknown vulnerabilities, 14 classified as high-severity. That’s nearly a fifth of all high-severity Firefox vulnerabilities remediated in 2025. Found in a fortnight by a model. When they tested whether Claude could also write working exploits, it managed only two crude successes across several hundred attempts. Discovery is dramatically cheaper and more effective than exploitation right now. That’s good news for defenders. Anthropic themselves noted that gap is unlikely to last, but right now the window favours defence.

That’s the good news.

The bad news is what’s coming. Alex Stamos laid this out at Reddit’s SnooSec conference in his talk AI is Eating Security. Open-source models are less than a year behind frontier models in bug discovery. Once widely available, thousands of adversary groups will have tooling that was recently the preserve of nation-states. As Stamos put it: we have no historical precedent for this many adversary groups having this kind of capability while we have a massive dearth of skilled defenders. Attacker benefits are going exponential. Defender benefits are geometric.

The answer isn’t more headcount. Using AI leads to a different model. Smaller, narrower teams. Fewer but more senior people on top of AI agents. AI coding tools already make security engineering dramatically faster. The organisations that make this transition keep pace, AI gets you there faster. The ones that don’t get left operating at human speed against machine-speed attackers.

If you’re a security leader, the harder part is getting the rest of leadership there. Especially when you’re asking for more money or restructured teams. The Anthropic blog post helps. It’s 22 zero-days in a production browser, found by a model in two weeks. That cuts through boardroom scepticism.

We might be in for a tough time ahead, but in the immortal words of Toto: hold the line, love isn’t always on time.

A sophisticated iPhone exploit framework known as “Coruna” appears to have originated from tools developed for US government use, before making its way through the murky exploit market. From there it seems to have ended up first in the hands of Russian espionage groups targeting Ukrainians, and later with cybercriminal operations stealing cryptocurrency from victims. The toolkit bundles multiple full iOS exploit chains and more than twenty individual exploits, capable of compromising vulnerable devices simply by visiting a malicious website.

What caught my eye, though, was a small but notable detail: the exploit kit apparently checks for Lockdown Mode and does not attempt infection if it’s enabled.

This isn’t the first time Lockdown Mode has stopped an attack dead in its tracks. When the FBI raided the home of Washington Post reporter Hannah Natanson earlier this year, court records show their forensics team couldn’t extract a thing from her iPhone. Lockdown Mode made the device a non-starter from the outset.

I tried Lockdown Mode when Apple first released it a few years back. At the time I left it on for a few days, but eventually turned it off. Some sites I rely on simply weren’t behaving properly, and it felt a bit too restrictive for everyday use.

Since then, though, Apple has gradually improved the feature’s usability, for example by allowing exceptions for trusted websites, while keeping the stronger security posture in place. Reading about real-world exploit chains like this finding their way from state actors to ordinary criminals was a good reminder that these defences aren’t purely theoretical.

For people like myself who tried Lockdown Mode early on and gave up, it may well be worth another look now that the rough edges have been smoothed out a bit.

For the full story, the Wired article is well worth a read.

B2B Developers, Corporate IT and security teams should open their minds about what Passkeys can do for them. Not because they finally kill passwords. Passkeys can change who controls cryptographic key material inside organizations. After all the blood, sweat, and tears of deploying a better MFA solution, it would be nice to get more in return. And if you haven’t deployed them yet, maybe this will give you more reasons to do so.

For decades, serious cryptography in enterprises lived in narrow domains: PKI teams, HSMs, code signing infrastructure, smart cards for a subset of employees. Everyone else got passwords plus MFA bolted on top. Keys were expensive, specialized, and centrally managed.

Passkeys invert that model. Every modern phone and laptop ships with a secure enclave or TPM capable of generating and protecting asymmetric keys. WebAuthn exposes a standard interface for creating and using those keys. The user experience is solved: biometric prompt, done.

The result is simple but profound: every employee now carries hardware-backed key material by default.

Authentication Is the Obvious Win

Passkeys eliminate entire categories of enterprise pain. There are no shared secrets to reset, no TOTP codes to phish, no push notifications to fatigue-attack, and no hardware token inventory to manage. The private key never leaves the device. Authentication is origin-bound and gated by biometrics or a device PIN.

For many organizations, password reset support is one of the most expensive recurring IT costs. Passkeys materially reduce that surface area.

But authentication is just the surface.

Hardware-Backed Cryptography

Underneath the UX, passkeys are hardware-protected asymmetric keys accessed through WebAuthn. That matters less because of how they log users in, and more because of what they normalize.

For the first time, enterprises have ubiquitous access to hardware-protected signing and key derivation capabilities on employee devices, without issuing smart cards or deploying client certificates. Every enrolled device can hold non-exportable private keys, gate their use behind biometrics, and produce signatures over structured data.

Historically, if an organization wanted hardware-backed keys on endpoints, it meant provisioning smart cards, managing certificates, or distributing tokens. Now the capability ships by default on iPhones, Android devices, Windows laptops, and Macs.

That changes what is economically feasible. And in enterprise security, money decides most things.

Moxie’s Direction: Using Passkeys for Encryption, Not Just Login

The most interesting extension of this idea comes from the creator of Signal, Moxie Marlinspike’s recent work with Confer. In Passkey Encryption, he describes using the WebAuthn PRF extension to derive durable encryption key material from a passkey. The private key remains protected by the secure enclave. The server never receives the derived root secret.

Instead of using passkeys only to authenticate to a server that holds the real keys, Confer uses them to generate client-side encryption keys. The service stores ciphertext. Decryption requires local biometric authorization on the user’s device.

Image: Confer.to AI

Moxie trying to do for AI what he did for messaging: make it private by design. The important move is subtle. The passkey is not just proving identity. It is controlling access to encryption keys. The server cannot read user data, even if it wants to.

In practical terms, this replaces a lot of the awkward machinery behind encrypted systems. End-to-end messaging usually requires long-lived identity keys, recovery phrases, or some form of server-assisted key escrow. Encrypted SaaS products often rely on password-derived keys or server-stored wrapped keys for recovery. Using passkeys and the WebAuthn PRF shifts that root of trust into hardware-backed credentials that already exist on user devices, reducing both system complexity and the number of high-value secrets stored on servers.

That relocation of trust is what should matter to enterprises.

If employee devices already contain hardware-backed keys capable of deriving stable secrets, signing structured data, participating in key agreement, and attesting to hardware properties, those keys can gate access to encrypted documents, internal AI systems, sensitive knowledge bases, and collaboration tools without standing up traditional enterprise PKI for every use case.

Passkeys are not just a cleaner login flow. They are a client-side cryptographic foundation that now ships, by default, on every endpoint your organization owns.

I’ve led coordinated disclosure processes within organizations and participated as a reporter, so I’m sympathetic to the people trying to make the process work. It is a difficult task.

However, we are well over two decades into responsible disclosure, and one of the world’s largest processor manufacturers is committing failures like this. If the reporting is accurate, AMD’s auto-updater downloaded software updates insecurely and did not verify signatures. That is inexcusable for a company of this scale. Authenticated updates and signature verification are the basics. These are not exotic research problems. They are baseline engineering responsibilities.

What concerns me most is how we, as a community, treat the completion of the responsible disclosure process as the end of the matter. A bug is reported. A patch is issued. There is a brief news cycle. The reporter may receive credit. And then we collectively move on, as if fixing the bug and absorbing a modest amount of bad press is sufficient.

But the fact that issues like this exist at this scale should prompt harder questions. How did this pass design review? Where were the guardrails? What incentives allowed this to ship? What organizational decisions made this acceptable? Instead, the process itself becomes the story. The completion of disclosure is treated as evidence that the system works, when in reality it often just contains the damage.

These are billion-dollar firms. Issues like this should not exist at this level of maturity. In other industries, when bridges collapse or ships crash due to professional negligence, there are investigations, accountability, and reform. In software, the cost is frequently externalized and quietly absorbed, poisoning the system while no one feels the pain directly.

Responsible disclosure remains essential. But as it exists today, it too often serves to contain reputational damage rather than raise engineering standards. It should not function as closure. It should be the starting point for accountability and structural improvement. Otherwise, what are we doing?

That isn’t what’s going to kill it. In the US you now can’t send an authentication text without clearing a registration process that small teams & independent developers mostly can’t clear.

A week to send a six digit code

I spent over a week trying to register an OTP-only application with two providers. The app does one thing. It sends six digit codes. It got rejected repeatedly, and the reasons moved between rejections: not enough detail, questions about projected volume, requests for documentation that wasn’t mentioned in the application.

Under A2P 10DLC you register a brand, then register a campaign, describe the use case & wait on approval from the provider and then from the carriers. It’s sold as spam reduction, and what it delivers is fees, delays & a review process nobody can explain to you.

There’s no fast path for the most boring use case on the internet, which is send a code, verify the code, done.

The fees

Brand registration fees, campaign registration fees, per-message surcharges. None of it is much money at enterprise volume, which is presumably who the schedule was written around. Working out what a single OTP actually costs you means reading several documentation pages or talking to a salesperson, and the numbers move.

SMS has gone from a utility to a gated service.

What folks do instead

Authenticator apps, push approvals, passkeys, WebAuthn, FIDO2. All better than SMS, all more resistant to phishing, and the industry was heading that way regardless.

I’ve a feeling the move is going to be faster & messier than anyone planned, because it isn’t the better technology doing the pushing. Developers who can’t reliably send a text will switch to something. Most will pick something stronger. Some will bolt on a weaker fallback or drop the second factor entirely, because the easy path doesn’t run through a phone number any more.

10DLC was introduced to deal with A2P spam. The spam hasn’t gone anywhere. What’s gone is the ability to send a login code without a month of paperwork.

Trevor Perrin’s talk on the TextSecure protocol, what the world now knows as the Signal Protocol, is one of the best things I’ve watched on applied cryptography. He spends most of it on authentication, which gets a lot less attention than the ratchet does.

The discussion around Signal tends to focus on the Double Ratchet, which combines Diffie-Hellman and symmetric ratchets to give you forward and future secrecy. It’s clever and it deserves the attention it gets. But the part I keep coming back to is how the protocol handles authentication, and how honest Perrin is about what authentication can realistically achieve.

Where encryption stops

Signal encrypts messages with keys derived from X3DH (an extended Diffie-Hellman handshake that can set up a session while the other party is offline) and the Double Ratchet. Compromise the long-term keys and past messages stay protected, and future sessions recover once fresh ephemeral keys come into play.

None of that tells you you’re encrypting to the right person. If the key server hands you a malicious public key you’ll happily encrypt a perfectly secure message straight to an attacker. Authentication is a separate problem, and a harder one, because it’s the one place you can’t keep the user out of.

Usable security

PGP tried to solve this with manual key verification and webs of trust. It worked for experts, and it never got near mass adoption, because the process asked far too much of everybody else.

Signal’s answer was to make the encryption invisible. Key generation, prekeys, rotation, session setup, all of it happens without the user thinking about any of it. You install the app and your messages are encrypted.

You can’t pull the same trick with authentication. As Perrin points out, at some stage the user has to be involved, so the question becomes what you do when you already know most people will never complete a verification ceremony.

One option is to insist on it anyway. No verification, no secure channel. In practice that means only a small subset of users get protection, and those users then become identifiable as the security-conscious ones, which is a bad outcome for them.

Signal went the other way and encrypted everything by default, with verification left optional. Everyone gets encrypted transport. Some people scan QR codes or compare fingerprints, most don’t, and an observer can’t tell which is which.

Trust on first use

The first time you fetch a contact’s key you take it and store it. If it changes later you get a warning.

It’s imperfect and I don’t want to oversell it, plenty of people will click straight through that warning without reading a word of it. But the friction lands in the right place. The initial key gets recorded silently and only a change interrupts anybody, so what you’re aiming for is that a suspicious key change gets noticed some of the time, by somebody.

Stronger guarantees are there if you want them, scan the QR code out of band. Skipping it doesn’t weaken the encryption, it means you’re trusting the key directory, and for most conversations that’s a trade I’d take without much thought.

Cryptographic engineering

The primitives here are all well understood. What’s impressive is how they’re composed into something that survives real conditions: asynchronous delivery, key exhaustion, multiple devices, group chats, servers you’d rather not have to trust. I’ve sat in enough design reviews where a scheme that was perfectly sound on the whiteboard fell apart on the second or third of those.

The authentication story shows that gap better than anything else in the protocol does. Signal encrypted everything. The verification is still in the app if you want it, and most people never open that screen. It protects them anyway, because an attacker doesn’t get to know which people those are.

In 1982 AT&T made a short documentary about UNIX. Ken Thompson, Dennis Ritchie and Brian Kernighan explaining what they built and why they built it that way. Thirty five years on, it’s still one of the clearest things I’ve watched on systems design.

Worth the half hour. It’s unpretentious and technical, which is rarer now than it was then.

The pipe

The central idea is composition. Small programs, each doing one thing well, connected through one universal interface. It was a position on how to manage complexity.

Security engineering has the same problem at a different scale. Complex systems are hard to reason about & harder to secure. The instinct is to buy the monolith, the single platform that does authentication, authorization, logging, alerting & compliance, and what you get back is opacity, which suits an attacker fine.

The alternative is smaller components with clear boundaries, explicit interfaces, and pieces you can inspect, replace and compose on their own.

What strikes me in the documentary is how much the designers cared about being able to see what the system was doing. Text as the universal format. Human readable config. Tools you could chain together to ask the system about its own behavior.

ps, ls, grep, awk, find. These are instruments for understanding a running machine, and people were doing security observability with them for decades before anyone had a name for it. I’ve a bias here, but if I had to pick the one design decision that does the most for security, it’s making a system inspectable by the people running it.

Durability

The remarkable thing is the longevity. The technology has changed completely since 1982 and the approach in the film still works.

I think about that when I’m building a security program somewhere growing fast. The tools & vendors will change, the compliance frameworks will change, the threat landscape will change. What’s left is how you decomposed the problem, where you put the boundaries, what you made visible and what you made composable. Which is roughly the list the UNIX people were arguing about in 1982.