What is threat modeling?#

Threat modeling is the process of understanding your adversary, identifying information or attack vectors they might exploit, and then finding ways to mitigate those attacks. The outcome of that process is your threat model. Everyone has a different threat model and may approach it differently.

How do you develop a threat model?#

You need to know three things:

1. Who your adversary is
2. What they are capable of
3. What their goal is

Once you know this, think about what attacks your adversary might use to reach their goal, then identify how to prevent or mitigate those attacks.

A basic example: the FBI trying to deanonymize a Tor user. The FBI is known to use NITs (drive-by downloads). If you think about how to defeat a NIT, you may choose to use Tails or Whonix instead of plain Tor Browser. This is a simple example, but it shows how your adversary changes your decisions. Security is a moving target, so re-evaluate your threat model over time.

You can also use structured methods such as STRIDE, the CIA Triad, or Attack Trees. These frameworks are useful, but they still require you to know your adversary.

STRIDE#

STRIDE is a Microsoft threat modeling process that can be applied broadly. It stands for:

• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Escalation of Privileges

STRIDE works well as a question-and-answer process. For example, for Spoofing you ask, “Can my adversary spoof an identity?” If yes, you find how they would do it and how you would prevent or detect it.

CIA Triad#

The CIA Triad stands for Confidentiality, Integrity, and Availability. These represent the three core things you want to protect.

For example, on a website with a login form:

• The password database must remain confidential.
• It must have integrity so attackers can’t change passwords.
• It must remain available so users can log in.

Attack Trees#

Attack trees map out how an adversary might achieve a goal and how you can mitigate those paths. They also break down the steps required to execute an attack, which helps you defend against it.

Example:

1
Adversary: FBI, Goal: De-anonymize Tor user
2
    NIT (drive by download) - Mitigate by using Whonix or Tails
3
        Target downloads the NIT
4
        Execute the NIT
5
        Gather identifying information
6
    OSINT - Keep anonymous life completely separate from public life
7
        Link Tor user to clear net user
8
        Research clear net user

Attack trees are flexible and help track multiple attack paths over time.

Threat model checklist#

• What exactly am I protecting?
• Who is my adversary?
• What are their capabilities and resources?
• What are the most likely attack paths?
• What mitigation actually reduces risk (not just effort)?
• How often should I revisit this model?

Tor / Tor Browser#

Tor and Tor Browser are effective tools for anonymity when used properly. Tor routes traffic through volunteer-run relays around the world so that users look alike, and traffic is encrypted inside the Tor network.

The limitation is that traffic is only encrypted inside the Tor network. Exit nodes can see traffic as it leaves. If you are not using HTTPS on clearnet sites, an exit node can see or even modify it. Use HTTPS when browsing clearnet sites with Tor. This does not apply to onion services, where traffic stays inside the Tor network end-to-end.

Tor Browser is a more common target than Tor itself. It disables many dangerous browser capabilities that could deanonymize you. For example, WebRTC is restricted to prevent IP leaks, and canvas fingerprinting is mitigated by randomization. JavaScript is still enabled by default, and many Tor Browser exploits involve JavaScript. The Security Level settings (shield icon) help reduce risk:

• Safer restricts CSS to reduce fingerprinting and disables WebAssembly and the JS JIT compiler.
• Safest disables most active content. JavaScript is disabled and CSS is heavily restricted.

Tor can keep you relatively anonymous, but it does not protect all communications. Routing XMPP over Tor can improve anonymity, but it does not automatically make messages private.

XMPP with OMEMO#

XMPP is a messaging protocol that allows users on different servers to communicate. Messages are not private by default. OMEMO is an end-to-end encryption protocol designed for XMPP and improves on older OTR-based approaches.

OMEMO offers offline delivery, confidentiality, deniability, integrity, authentication, and forward secrecy. However, if a man-in-the-middle swaps keys during exchange, OMEMO can be compromised. Users should verify OMEMO fingerprints through a separate channel.

OMEMO keeps messages private, but neither OMEMO nor XMPP provides anonymity by itself. They can be used with Tor. OMEMO cannot protect you if an endpoint is compromised.

Whonix#

Whonix uses a two-VM approach: one VM handles networking and the other runs your applications. To deanonymize you, an adversary would need a Tor Browser exploit and a VM escape, which is significantly harder.

All traffic is forced through Tor because the networking VM is separate. Whonix also includes the Vanguards Tor plugin to reduce guard discovery and other traffic analysis attacks.

Limitations include poor identity separation if you reuse the same Workstation VM for multiple purposes. Many users also forget to change the default sudo password, which makes local compromise easier (even if it does not allow VM escape). Use separate Workstation VMs per identity, or use live mode for daily activities.

Tails#

Tails is a live system designed to leave no traces on the computer it runs on. It is a bootable USB OS that includes Tor and GnuPG (via Kleopatra). The Tor Browser in Tails includes an ad blocker and extra hardening with AppArmor.

If Tor Browser is exploited, AppArmor can limit what it can access. Tails also routes all traffic through Tor; anything that tries to bypass Tor is dropped.

Tails makes it obvious you are using Tails, and its Tor Browser setup is unique. Tails is not immune to vulnerabilities. Some apps (email client, media player, browser) have been exploited in the past, though typically in targeted attacks. Tails works well against generic attacks (like a NIT), but if you are being actively targeted, Whonix is often a better choice.

Disabling JavaScript is still commonly recommended on Tails. For casual browsing, it may be unnecessary, but for higher-risk scenarios it is still a reasonable precaution.

VeraCrypt#

VeraCrypt is a maintained fork of TrueCrypt. It can encrypt an entire device or partition, or create an encrypted file container. VeraCrypt also supports hidden volumes, which can make it extremely difficult to prove that hidden data exists.

VeraCrypt containers appear as random data with no signature. It supports variable PIM values and multiple hash functions to make password cracking significantly harder. You can also use key files for additional security.

VeraCrypt cannot protect you if you use weak or reused passwords. Use a strong passphrase, such as a 7 to 8 word Diceware passphrase that is unique to VeraCrypt. It also cannot protect you if files are left unencrypted elsewhere. To avoid leaks, encrypt the entire OS or use a live system.

Full Disk Encryption (FDE)#

FDE encrypts an entire storage medium, including file metadata. Common implementations include BitLocker, LUKS/dm-crypt, and VeraCrypt. A properly encrypted disk reveals no information other than the fact it is encrypted.

With strong secrets (like a random Diceware passphrase), decrypting a drive without the user’s secret is extremely difficult. Security can be improved with key files. Ideally, overwrite a drive with random data before encryption and use long, memorized secrets.

File Based Encryption (FBE)#

File-based encryption encrypts individual files or chunks of files. Examples include Picocrypt and CryFS. It provides strong confidentiality, but metadata (filenames, sizes, directory structure) may still leak unless the system is designed to hide it.

File encryption is useful where FDE is not practical, such as cloud storage. Many file encryption systems include authenticated encryption, which detects tampering. Unauthenticated encryption (like CBC without authentication) can lead to attacks such as padding oracles; authentication with HMAC or AEAD prevents this.

Message Encryption#

Protocols like Signal and OMEMO protect message confidentiality so only you and the intended recipient can read the content. They use symmetric ciphers like AES and asymmetric cryptography like ECC (e.g., Curve25519).

As long as key exchanges are not compromised and endpoints are not compromised, messages are highly resistant to interception. Verification (OMEMO fingerprints or Signal safety numbers) is essential. Security can be improved by deleting messages after they are read.

Algorithms#

Choosing a cipher is less important than using a correct implementation. Most modern software uses secure defaults such as AES or ChaCha20. AES is widely used due to extensive analysis and hardware acceleration. ChaCha20 is a strong alternative, often used in TLS.

Other AES finalists such as Serpent, Twofish, RC6, and MARS are considered secure but see less analysis and lack hardware acceleration, so they are slower. If AES were ever broken, these would be strong alternatives.

Ciphers to avoid#

These ciphers should be avoided due to severe weaknesses or known breaks:

• RC4 (broken stream cipher)
• DES (56-bit keys can be brute-forced)
• Triple DES (64-bit block size enables birthday attacks after large volumes)
• Blowfish (64-bit block size enables birthday attacks after large volumes)
• IDEA (64-bit block size enables birthday attacks after large volumes)
• Kuznyechik (S-Box generated with a hidden algorithm)

Kuznyechik’s hidden S-Box structure has raised suspicion of a backdoor, though this is debated. Similar concerns existed with DES, where the NSA modified S-Boxes to resist differential cryptanalysis without public disclosure. The Kuznyechik designers may have done something similar.