Did you know The Moms of Furries will be hosting their Young Furry Chill Space
at CFF this year? Carrie and Joelle are so excited to bring their expertise and fun to the con! You’ll be able to find their minor focused space in our Meadow and you’ll see them hosting special events over the weekend!
To learn more visit their website: https://mofurries.com/home
Original post written by Ahmar Wolf
A friendly reminder from our Safety team: we do not allow attendees wearing tactical or tactical-style gear, or any accessories that may be perceived as real. Props brought into the convention space must also be inspected and peace-bonded.
More details: https://anthrocon.org/standards-of-c
Original post written by Ahmar Wolf
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.
For context, this was commissioned during the era of anti-vaccine losers claiming to “do their own research” briefly co-opting the word “threat model” as a buzz word.
I just still find it kind of funny even without this context.
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.
Art: Harubaki
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:
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.
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.
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:
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.
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:
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.
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.
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:
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.
The next example is more interesting, but also a little more advanced.
There are currently two proposals for end-to-end encryption for direct messages that are being discussed by cryptography experts and decentralization nerds:
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.
My proposal for key transparency is one way to solve this problem without creating a centralized authority.
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.
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.
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.
Okay, if you’ve read this far, hopefully you understand:
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?
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
Or, possibly the silliest one so far:
Do not publish this document. Enabling state SIGINT harms everyone.
– Willow
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.
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”.
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.
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.
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.
Original post written by Soatok
Our mysterious stranger introduced himself to Yuri, claiming his name to be Benito McFish, who had traveled a long road to bring us confidential information.
Stay tuned, because Benito is getting ready to announce something important tomorrow!
Original post written by Ahmar Wolf
Original post written by Ahmar Wolf
Got this bit of news from Animation World Network: “Academy Award nominee and Golden Globe winner Michael J. Fox will voice Dougie, the scrappy, big-hearted lead character in ICON Creative Studio’s upcoming CG animated family feature, Dragoons. The film follows Dougie, an overlooked, ordinary worker at WizCorp, until a freak accident awakens something extraordinary within his new apprentice, Dart. Transformed into mighty dragons, Dougie and Dart uncover an impossible truth: Their kind were once legendary rulers of the skies, until the ruthless wizard-CEO Hex shrank them, erased their memories, and stole their power to build his empire. With the truth in front of their eyes and in their hearts, Dougie and Dart must find the courage to rise, awaken their kind, and prove that even the smallest spark can light up the sky.” No word on a release date yet, but the film is directed by Shea Wageman. ICON Creative Studio are the folks who recently gave us this year’s Charlie the Wonderdog.
image c. 2026 ICON Creative Studio
Original post written by rodney
 sticker</p>
<p>” data-large-file=”https://i0.wp.com/soatok.blog/wp-content/uploads/2020/09/soatoktelegrams2020-08.png?fit=512%2C512&ssl=1″ src=”https://i0.wp.com/soatok.blog/wp-content/uploads/2020/09/soatoktelegrams2020-08.png?resize=512%2C512&ssl=1″ alt=”High Paw (high five) sticker” class=”wp-image-1333″ style=”width:auto;height:256px”/><figcaption class=)
Art: 
