After a long day of exhausting conversations about Hybrid Post-Quantum Cryptography, random jackasses trying to play gotcha with endpoint attacks against end-to-end encrypted messaging apps, and message board discussions in the wake of dumb politicians pushing more “age verification” bullshit on us all, it’s become abundantly clear to me that the phrase “threat model” is a foreign concept to most people.

Except, y’know, as a buzzword.

To be up front: If you’re here looking for an academic resource with over 100 citations on how to write a formal threat model document for your new startup which involves multiple blockchains, this probably isn’t the gay furry blog for you. Maybe start with STRIDE and system theory.

But if you’re looking to build an intuition for what questions a good threat model should answer, and you’re starting from zero, you’re probably in the right place.

So let’s talk about threat modeling.

Threat Modeling For Neophytes

At a high level, don’t overthink this too much.

While a threat model is a formal cybersecurity process that some infosec folks actually specialize in, you can run informal threat models in the design and architecture phases of developing a new product or service and no one can stop you. You might just end up with a better result.

A threat model should, at minimum, answer these basic questions:

1. What are we even protecting to begin with?
   • If you can’t answer this, you have a lot of ground work to do.
2. Who/what wants to harm what we’re protecting?
   • Hackers, activists, cyber-stalkers, social media harassment networks
   • Natural disasters / bad karma
   • Underpaid and overworked employees who get fed up
   • Idiotic legislatures paid by large corporate lobbyists to pass stupid laws that hurt everyone
   • Nation State Adversaries!!!!1oneon
3. How might (2) attack (1)?
   • Attack scenarios go here
   • Murphy’s Law goes here
4. What will we do to prevent (3) from happening?
   • Murphy’s Law also goes here!

And, like, okay. If you can check those off, you can call your document a threat model in some sense.

However, this is often useless in practice because some crucial details are omitted.

5. How are the assets (1) related / connected?
   • Think in graphs, not lists.
   • Not all targets are equal value.
6. What assumptions are we making, especially with (4) and (5)?
   • I’ll say more about this below.
7. What threats are we deliberately not addressing?
   • You literally cannot address every possible attack that any person will ever imagine in the unforeseeable future, so don’t pretend to.

Too many people take assumptions (6) for granted, ironically, but it’s incredibly important to be as clear about what your assumptions are.

If one of your assumptions is wrong, then your model is incomplete (at best), or your list of accepted risks (7) needs to be reconsidered.

For example: The Invisible Salamanders attack breaks abuse reporting in some end-to-end encrypted messaging designs, but only if you introduce abuse reporting.

The attack is possible because one of the assumptions that went into the AEAD schemes in question (AES-GCM, ChaCha20-Poly1305) is that there is only one valid key for a given message. The second you introduce multiple valid keys for a given message (or confused deputies for that matter), you’ve gone outside the security guarantees of your algorithm–which, as an attacker, makes for a fun trick.

Being clear about your assumptions allows you to identify your own unknown unknowns. You don’t have to be perfect.

In fact: Threat models are supposed to be living documents, not point-in-time snapshots. Update them whenever you deem appropriate.

Example: My Own Work

You may or may not already be aware that I’m working on delivering key transparency to the Fediverse. The work is being tracked on publickey.directory if you’re curious about the state of it after this blog post goes live.

This work began with a specification, which includes a prominently featured threat model.

The threat model is organized into the following sections:

1. Assumptions (stated up front)
2. Assets
3. Actors (both attackers and people we want to protect), given role names
4. The risks, which have one of four statuses attached
   • Prevented by design: Attack simply won’t work lol 😀
   • Mitigated: Attacks shouldn’t succeed, unless an assumption is wrong. Most interesting for researchers to focus on.
   • Addressable: There’s a way to mitigate the risk, but it requires effort or care. Operators should be aware of this.
   • Open: This is a risk we cannot or will not mitigate. These are the attacks that will succeed.

This threat model isn’t perfect, of course. I didn’t perfectly relate the assets and actors to each other in a human-readable graph. There might be blind spots in the risks section I never considered. I might have forgotten to write down some assumption that matters for the security of the system.

If you can look at my project’s threat model and see its shortcomings, you probably understand the assignment well enough to write your own.

But enough thinly-veiled shameless self-promotion. You won’t learn much only looking at my example of fur-in-the game. We also need an example of a bad threat model doc, and boy howdy do I have one ready.

Bad Example: Matrix’s Threat Model

I’ve picked on Matrix before (twice), so if you’ve read those blogs, this won’t be news to you.

This is Matrix’s threat model (latest, v1.18):

9. Security Threat Model

9.1 Denial of Service

The attacker could attempt to prevent delivery of messages to or from the victim in order to:

• Disrupt service or marketing campaign of a commercial competitor.
• Censor a discussion or censor a participant in a discussion.
• Perform general vandalism.

9.1.1 Threat: Resource Exhaustion

An attacker could cause the victim’s server to exhaust a particular resource (e.g. open TCP connections, CPU, memory, disk storage)

9.1.2 Threat: Unrecoverable Consistency Violations

An attacker could send messages which created an unrecoverable “split-brain” state in the cluster such that the victim’s servers could no longer derive a consistent view of the chatroom state.

9.1.3 Threat: Bad History

An attacker could convince the victim to accept invalid messages which the victim would then include in their view of the chatroom history. Other servers in the chatroom would reject the invalid messages and potentially reject the victims messages as well since they depended on the invalid messages.

9.1.4 Threat: Block Network Traffic

An attacker could try to firewall traffic between the victim’s server and some or all of the other servers in the chatroom.

9.1.5 Threat: High Volume of Messages

An attacker could send large volumes of messages to a chatroom with the victim making the chatroom unusable.

9.1.6 Threat: Banning users without necessary authorisation

An attacker could attempt to ban a user from a chatroom without the necessary authorisation.

9.2 Spoofing

An attacker could try to send a message claiming to be from the victim without the victim having sent the message in order to:

• Impersonate the victim while performing illicit activity.
• Obtain privileges of the victim.

9.2.1 Threat: Altering Message Contents

An attacker could try to alter the contents of an existing message from the victim.

9.2.2 Threat: Fake Message “origin” Field

An attacker could try to send a new message purporting to be from the victim with a phony “origin” field.

9.3 Spamming

The attacker could try to send a high volume of solicited or unsolicited messages to the victim in order to:

• Find victims for scams.
• Market unwanted products.

9.3.1 Threat: Unsolicited Messages

An attacker could try to send messages to victims who do not wish to receive them.

9.3.2 Threat: Abusive Messages

An attacker could send abusive or threatening messages to the victim

9.4 Spying

The attacker could try to access message contents or metadata for messages sent by the victim or to the victim that were not intended to reach the attacker in order to:

• Gain sensitive personal or commercial information.
• Impersonate the victim using credentials contained in the messages. (e.g. password reset messages)
• Discover who the victim was talking to and when.

9.4.1 Threat: Disclosure during Transmission

An attacker could try to expose the message contents or metadata during transmission between the servers.

9.4.2 Threat: Disclosure to Servers Outside Chatroom

An attacker could try to convince servers within a chatroom to send messages to a server it controls that was not authorised to be within the chatroom.

9.4.3 Threat: Disclosure to Servers Within Chatroom

An attacker could take control of a server within a chatroom to expose message contents or metadata for messages in that room.

(Yes, I excerpted the whole section in the scrolling box above.)

A few things you might notice, scrolling through this:

1. This is just a list of different attack types.
2. There is no list of assumptions.
3. There is no list of assets, nor their relationships to other assets.
4. The list of attacks is woefully incomplete.
   • Despite folks evangelizing Matrix over other E2EE messengers, their threat model says nothing about cryptography or key management.
5. Bonus observation for anyone that read it live from the Matrix website: It has largely remained unchanged since v1.1 (published in 2021), despite both my vulnerability disclosures and two additional cryptographic attacks by Lotte.

As annoying as this is, and as tempting as it might be to fail Matrix entirely, at least they have a threat model.

Signal, by contrast, gives you a bunch of technical specifications and expects you to figure the threat model out for yourself. This is one of the many things about Signal that annoys me.

So to Matrix’s threat model author, I award the following:

A shitty threat model beats not having a threat model.

How Threat Models Help You Build Better Stuff

There are a lot of infosec truisms that you’ll hear early in your career. Things like, “Defenders have to get it right all the time, attackers only need to get it right once.”

Yeah, but well-equipped defenders can decide the terrain. Put that in your Art of War pipe and smoke it.

Every security practitioner from here to seclists preaches defense-in-depth, but doing actual defense in depth means understanding your threat model well enough to force attackers into predictable dead ends.

Let me give you a practical example, then a more interesting one.

Preventing Credential Stuffing

Credential stuffing is a stupid simple attack that’s unreasonably effective in most real world scenarios.

Why? Because people reuse passwords.

Why do people reuse passwords? Because they can only be assed to remember so many passwords, and asking them to create a unique, secure password for your app is laughable.

To mitigate this risk, there was a long period of time when password managers were the right answer to this problem. These days, they’re still okay (but not Lastpass), but passkeys are better.

Why? Because passkeys are a more user-friendly (note: not totally user friendly) way to get users to use asymmetric cryptography for authentication. In the best case, they’re using hardware security tokens (e.g., SoloKeys or YubiKeys). In the average case, their OS or password manager is providing this for them.

Following a chain of “why?” questions like this is one way to get a feel for the threats inherent to a (deeply flawed) security control. But it does come with the inherent risk of falling into rabbit holes, so be careful with that.

If you want to avoid credential stuffing and related trivial attacks:

1. Design your application to require passkeys.
2. Require users to enroll multiple passkeys (or at least one for backup purposes).
3. Give administrators a way to break glass add a new passkey for another user if they lose all their credentials. Log these actions in a way the administrators cannot censor.
4. Do not support passwords for authentication at all if you can avoid them.
   • Passwords for deriving encryption keys is fine, as I wrote here.

As an added bonus, passkeys are not phishable either–due to the protocol cryptographically binding each credential to a domain name during registration.

Whatever it costs you to onboard your users to passkeys, you’ll save loads more on the support burden caused by credential stuffing and phishing (and completely avoid the ill-advised “phishing tests” that don’t measurably improve outcomes).

By removing the unreasonable expectation of humans to memorize, and also never reuse, a high-entropy secret for your service, you kill off multiple classes of attack and improve usability. A good threat modelling exercise can lead to this discovery independent of my blog post.

Security at the expense of usability comes at the expense of security.

Avi Douglen

The next example is more interesting, but also a little more advanced.

Distributed End-to-End Encryption

There are currently two proposals for end-to-end encryption for direct messages that are being discussed by cryptography experts and decentralization nerds:

1. The ActivityPub E2EE specification, which aims to deliver private DMs for Fediverse software (e.g., Mastodon).
2. Projects like Germ Network that want to do the same for ATProto (e.g., BlueSky).

Both projects have, at some point, considered using MLS as their E2EE conversation key management protocol.

However, there are two important caveats with MLS in a non-centralized system that make security less straightforward.

1. MLS specified an abstract concept called an Authentication Service which the SimpleX lead misunderstood in publicly embarrassing ways.

   My proposal for key transparency is one way to solve this problem without creating a centralized authority.

2. Message ordering is important for the security of ratcheting trees, which underpin the epochs in MLS.

For ActivityPub, if they adopt key transparency for the first caveat, they just need to be explicit how to handle races from multiple proposed KeyUpdate messages, especially across different servers. Not trivial, but solvable.

But the situation is trickier for ATProto / BlueSky.

Why ATProto Makes This More Difficult

ATProto doesn’t have instances like the Fediverse does. This is partly because ATProto was designed by Bitcoin-pilled developers on Jack Dorsey’s payroll who decided that having “global state” was a good service design choice. And blockchain is the worst kind of global state to stabilize because you have many writers.

Instead of just building a thing that clients use to encrypt messages they pass to their instance (like with ActivityPub), you basically have to treat everything as peer-to-peer (or damn close to p2p, anyway) when making your security analysis.

This means you need to figure out another complex protocol to guarantee message ordering in a distributed system (e.g., something like the Raft consensus algorithm), or you skip MLS in favor of pairwise E2EE and forego the group abstraction entirely.

How Threat Modelling Helps

If you consider the confidentiality of messages passed between users to be a security goal of your project, and you want your hosting to be decentralized, the blockchain-inspired design of ATProto is actually an impediment towards using the most efficient group key agreement protocol standardized today.

Yes, it is an impediment that several excellent engineers are currently cleverly working around today, but you could have avoided their mistakes when you were still at the drawing board.

Impractical Uses For Threat Models

Okay, if you’ve read this far, hopefully you understand:

1. What a threat model is
2. What a good threat model should encapsulate
3. How to spot bad threat models
4. How threat modelling can help you build better stuff

And that’s all practical, useful stuff, but it can get a bit dry and boring.

What if I told you that leveling up your threat modelling skills could make you better at sniffing out bullshit in technical discussions?

Threat Modelling for Post-Quantum Cryptography

I recently wrote a blog post about hybrid post-quantum constructions, which talked about signatures rather than Post-Quantum KEMs.

As luck would have it, there’s a Last Call happening on the TLS working group mailing list at IETF right now, which Daniel J. Bernstein unhelpfully decided to try to astroturf by summoning Twitter randos and other conspiracy theorists to bark condemnation towards.

I’m not exaggerating. Posts like this precipitated DJB’s post:

I vehemently object to the NSA’s proposition.

Patrick Timothy Dalrymple
Founder & CEO, LYRIA

IETF TLS mailing list archive

Or, possibly the silliest one so far:

Do not publish this document. Enabling state SIGINT harms everyone.

– Willow

IETF TLS mailing list archive

Aside from the obviously unreasonable people (and unwelcome sex pests like Jacob Appelbaum who I refuse to communicate with), I did ask many of the folks DJB summoned to the thread to elaborate on what specific security concerns they had.

Unsurprisingly, they were following the same black-and-white thinking (“hybrids good! pure PQ bad!”) that I suspected, but you always got to probe in case there’s an unexpected reason!

To apply our understanding of threat modelling to this situation, we need to establish some facts.

1. ML-KEM is not a NSA design.
   • Its principal submitter was Peter Schwabe, who collaborated with Daniel J. Bernstein on the NaCl cryptography library and lives in Germany.
   • The other submitters live all over Europe.
2. Information theory rules out a ML-KEM backdoor.
   • See: Sophie Schmieg.
3. ML-KEM was chosen for standardization by a very public decade-long international effort.
4. NIST / FIPS / NSA demands non-hybrid ML-KEM / ML-DSA in classified systems.
   • If there was a NOBUS backdoor in these algorithms, it would be patently fucking stupid for them to be in a hurry to move everything over to those algorithms.

Anyone who disagrees with these facts is simply rejecting reality. To that avenue of discourse, I say simply, PoC || GTFO.

The IETF discussion in question is about publishing an RFC that establishes a code point for non-hybrid ML-KEM.

The non-hybrid RFC draft is marked Recommend=N, while the hybrid KEM RFC will be marked Recommend=Y. This is because hybrid KEMs are preferred over non-hybrid KEMs. If the IETF produces an RFC that specifies ML-KEM, there will be no reduction in security to system configured to always use hybrid KEMs.

Google Chrome already supports non-hybrid ML-KEM. If the IETF effort fails to produce an RFC, there will be no real benefit.

So you might be wondering, “What’s the point of an RFC if it seemingly doesn’t do anything?”

Well, it does do something, just not for most of us: If you’re an organization whose engineers are being told by lawyers that a) you must adhere to CNSA 2.0 and/or FIPS 140-3 (or possibly other weird rules), and b) any designs you specify must have a stable IETF RFC number rather than merely be an Internet Draft, then this unblocks you from a lot of bullshit red tape.

Is that a stupid problem to have? Absolutely.

Is that a common problem for some business verticals, especially who sell to government customers? Certainly.

Objecting to the RFC for ideological reasons effectively only leaves those people out in the rain without an umbrella. This is the exact opposite of harm reduction.

But what about technical objections? Isn’t Hybrid PQ+T better than pure PQ?

Well, this is where your threat modelling skills need to come in. If we use Q-Day as the short-hand for “once a cryptography-relevant quantum computer is built by an adversary”, we can think through the risks clearly.

Reminder: The risk we face for KEMs is Harvest Now, Decrypt Later rather than “wait for Q-Day to happen then break crypto”.

• Pure ECDH (no PQ) is broken retroactively at Q-Day, regardless of whether other attacks materialize.
• Pure PQ is not broken at Q-Day, assuming the PQ algorithms are not broken first.
• Hybrid PQ+ECDH is a hedged bet against an algorithm break before Q-Day, but is utterly fucking useless over Pure PQ once Q-Day occurs.

DJB has been whipping up people who haven’t participated in any of the background discussion to object to Pure PQ in favor of Hybrid PQ+ECDH, and his call to action is full of NSA FUD and other fearmongering.

But here’s the rub: If you’re actually worried about the security of ML-KEM, why would ECDH + ML-KEM help if, on Q-Day, the ECDH contribution is effectively zero security?

Arguing for ECDH + ML-KEM today is acknowledging that ML-KEM is actually a secure algorithm to choose in the long run, modulo rare implementation flaws (most which are catchable by robust test vectors).

If you really chew on this problem, it should be clear that PQ+PQ hybrids are the only way to hedge your bets in a way that will remain resilient to a cryptography relevant quantum computer. Optional: Throw ECDH in there to ensure the status quo security is perserved.

None of the people opposing the RFC have, to my knowledge, advocated for ML-KEM + HQC + ECDH three-way hybrids, when that would be the most intellectually honest thing to argue for.

• ML-KEM is a lattice-based KEM, and is believed by world-class cryptography experts to be impervious to quantum attacks.
• HQC is a code-based KEM, and is believed by world-class cryptography experts to be impervious to quantum attacks.
• ECDH is what we already use today, but is susceptible to quantum attacks.

But, really, the objections to this RFC are often silly and generally poorly thought out… which makes these threads a great opportunity to exercise your bullshit detector.

Closing Thoughts

There are many guides on the Internet that will give you a formal treatment of threat models and the methodologies that are useful to approaching them. But where’s the fun in that?

Hopefully, you will walk away from this blog post with a vague smoke test for the quality and efficacy of a threat model document, and maybe even feel inspired to tackle this topic more seriously.