<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
<!-- NERF is a trademark of defconxt. -->
# NERF Training: Privacy, OSINT & Forensics Deep Knowledge

Generated: 2026-03-14
Sources: Signal-Server, Signal-Desktop, VeraCrypt, awesome-osint, sherlock, maigret, privacyguides.org, sops, awesome-privacy
---
## 1. SIGNAL PROTOCOL ARCHITECTURE

### 1.1 Protocol Stack Overview

Signal implements a layered cryptographic protocol stack:

| Layer | Protocol | Purpose |
|-------|----------|---------|
| Key Agreement | X3DH / PQXDH | Initial shared secret establishment |
| Message Encryption | Double Ratchet | Per-message forward secrecy |
| Session Management | Sesame | Multi-device asynchronous session handling |
| Metadata Protection | Sealed Sender | Sender anonymity from server |
| Key Verification | Key Transparency | Auditable identity key directory |
| Post-Quantum | ML-KEM Braid | PQ forward secrecy via sparse KEM ratchet |
| Signatures | XEdDSA / VXEdDSA | EdDSA-compatible signatures on X25519 keys |

### 1.2 X3DH (Extended Triple Diffie-Hellman) Protocol

**Purpose**: Asynchronous key agreement between two parties who may not be online simultaneously.

**Key Types**:
- **IK (Identity Key)**: Long-term X25519 key pair, persists for account lifetime
- **SPK (Signed PreKey)**: Medium-term key, rotated periodically, signed by IK
- **OPK (One-Time PreKey)**: Single-use ephemeral keys, uploaded in batches to server
- **EK (Ephemeral Key)**: Generated fresh per session initiation

**Protocol Flow**:

```
Bob publishes to server: IK_B, SPK_B, Sig(IK_B, SPK_B), {OPK_B_1..n}

Alice fetches Bob's prekey bundle, then computes:
  DH1 = DH(IK_A, SPK_B)     -- mutual authentication
  DH2 = DH(EK_A, IK_B)      -- mutual authentication
  DH3 = DH(EK_A, SPK_B)     -- forward secrecy
  DH4 = DH(EK_A, OPK_B)     -- forward secrecy (optional, if OPK available)

  SK = HKDF(DH1 || DH2 || DH3 [|| DH4])  -- 32-byte shared secret
```

**Security Properties**:
- Forward secrecy: Compromising IK_A or IK_B does not reveal past session keys (due to EK, OPK)
- Deniability: No publishable cryptographic proof of communication
- If server withholds OPK, forward secrecy degrades (DH4 absent) but protocol still functions

**PQXDH Extension**: Adds ML-KEM (Kyber) encapsulation to the key agreement for post-quantum resistance. The KEM ciphertext is sent alongside the X3DH initial message.

### 1.3 Double Ratchet Algorithm

**Core Design**: Three interlocking KDF chains provide continuous key evolution.

```
Root Chain ──────> Sending Chain ──────> Message Keys
    |                                        |
    |          DH Ratchet Step               v
    |          (new DH exchange)         Encrypt/Decrypt
V
Root Chain ──────> Receiving Chain ────> Message Keys
```

**KDF Chain Properties**:
1. **Resilience**: Output keys appear random without KDF key knowledge
2. **Forward security**: Past output keys remain secure if current KDF key leaks
3. **Break-in recovery**: Future outputs recover security after compromise + new entropy

**Symmetric-Key Ratchet** (per-message):
```
Chain Key_n ──KDF──> Chain Key_{n+1}, Message Key_n
Message Key_n used for AES-256-CBC + HMAC-SHA256 (or AEAD equivalent)
Message Key_n deleted after use
```

**DH Ratchet** (per round-trip):
```
On receiving new ratchet public key from peer:
  1. DH_output = DH(our_ratchet_private, their_new_ratchet_public)
  2. New receiving chain key = KDF(root_key, DH_output)
  3. Generate new ratchet key pair
  4. DH_output_2 = DH(new_ratchet_private, their_new_ratchet_public)
  5. New sending chain key = KDF(root_key, DH_output_2)
```

**Post-Compromise Security**: After attacker loses access, next DH ratchet step introduces uncompromised entropy, healing the session.

**Skipped Message Keys**: Stored with configurable MAX_SKIP limit to handle out-of-order delivery without sacrificing security. Stored keys should have TTL and be cleaned up.

**Post-Quantum Extensions**:
- **ML-KEM Braid**: Sparse continuous KEM ratchet for PQ forward secrecy
- **Triple Ratchet**: Combines classical Double Ratchet + PQ KEM for hybrid security

### 1.4 Sealed Sender (Metadata Protection)

**What the server sees**:
- Message destination (recipient address)
- Recipient delivery token (96-bit, derived from profile key)
- Message size and timing
- IP address of sender (mitigated by Tor/VPN)

**What the server does NOT see**:
- Sender identity
- Message contents (E2EE)
- Contacts, social graph, conversation lists, location, avatar, profile name

**Implementation**:
```
1. Client obtains short-lived sender certificate from server:
   Certificate = {phone_number, identity_key, expiration_timestamp}
   Signed by server's certificate authority key

2. Encryption layers:
   Inner: Signal Protocol ciphertext (Double Ratchet)
   Outer: Ephemeral X25519 DH with recipient's identity key

   Sealed envelope = Encrypt(sender_cert || inner_ciphertext,
                             DH(ephemeral, recipient_IK))
```

**Abuse Prevention**:
- Delivery tokens: Derived from profile keys, required for sealed sender delivery
- Profile key exchange happens over existing encrypted Signal sessions
- Blocking a sealed-sender contact triggers profile key rotation
- Optional "allow from anyone" mode for maximum privacy (accepts abuse risk)

### 1.5 Server Architecture (from source code analysis)

**Storage Layer**: FoundationDB + DynamoDB + Redis

**Account Model** (from Account.java):
- UUID (ACI - Account Identifier)
- Phone Number Identifier (PNI) - separate from ACI
- Phone number (E.164)
- Username hash (optional, for discovery without phone number)
- Encrypted username link
- Identity key (per ACI)
- Phone number identity key (per PNI)
- Unidentified access key (16 bytes, for sealed sender)
- Discoverability flag (`discoverableByPhoneNumber`)
- Registration lock (salted token hash)
- Backup credentials

**Key Management** (from KeysManager.java):
```
Per device, per identity (ACI and PNI):
  - EC signed prekey (repeated use, currently active)
  - KEM signed prekey (last resort, repeated use)
  - EC one-time prekeys (single use, batch uploaded)
  - KEM one-time prekeys (paged, single use, stored in S3)
```

**Message Handling** (from MessagesManager.java):
- Messages stored in Redis cache first, then persisted to DynamoDB
- Messages are Envelope protobuf: type UNIDENTIFIED_SENDER for sealed sender
- Multi-recipient messages use shared payload with per-recipient views
- Server stores messages until retrieved, then deletes
- No server-side message content access (E2EE)

**Key Transparency** (from KeyTransparencyServiceClient.java):
- Separate gRPC service for auditable key directory
- Operations: Search (lookup key by ACI), Monitor (watch for changes), Distinguished (get tree head)
- Merkle tree based: clients verify consistency proofs
- Binds ACI to identity key, optional username hash and E164

### 1.6 Signal Desktop Local Storage

**SQLCipher Integration** (from Server.node.ts):
```typescript
import SQL from '@signalapp/sqlcipher';  // SQLCipher fork
```

- Uses `@signalapp/sqlcipher` -- a custom fork of better-sqlite3 with SQLCipher encryption
- Database encrypted at rest with AES-256
- Key derived from user's registration credentials
- Migrations system for schema updates (numbered migration files)
- Stores: messages, conversations, identity keys, prekeys, sessions, sticker packs, badges, call history, attachment metadata

**Crypto Module** (from Crypto.node.ts):
- HKDF for key derivation (3x32-byte output segments)
- Profile key: 32 bytes, used to derive profile encryption keys
- Profile encryption: AES-256-GCM with 12-byte IV
- Padded lengths for name (53/257), about (128/254/512), emoji (32), payment address (554)
- Attachment encryption: AES-256-CBC + HMAC-SHA256 with digest
- Group v2 migration: GV1 ID -> HKDF -> master key
---
## 2. VERACRYPT ENCRYPTION ARCHITECTURE

### 2.1 Encryption Algorithms

**Single Ciphers** (all 256-bit keys, XTS mode):

| Cipher | Key Size | Block Size | Origin |
|--------|----------|------------|--------|
| AES | 256-bit | 128-bit | NIST standard |
| Serpent | 256-bit | 128-bit | AES finalist |
| Twofish | 256-bit | 128-bit | AES finalist |
| Camellia | 256-bit | 128-bit | NESSIE/CRYPTREC |
| Kuznyechik | 256-bit | 128-bit | GOST R 34.12-2015 (Russian) |

**Cascade Combinations** (data encrypted sequentially by each cipher):

| Cascade | Key Size | Notes |
|---------|----------|-------|
| AES-Twofish | 512-bit | Two independent keys |
| AES-Twofish-Serpent | 768-bit | Three independent keys |
| Camellia-Kuznyechik | 512-bit | |
| Camellia-Serpent | 512-bit | |
| Kuznyechik-AES | 512-bit | |
| Kuznyechik-Serpent-Camellia | 768-bit | |
| Kuznyechik-Twofish | 512-bit | |
| Serpent-AES | 512-bit | |
| Serpent-Twofish-AES | 768-bit | |
| Twofish-Serpent | 512-bit | |

**Encryption Mode**: XTS (XEX-based Tweaked-codebook with Ciphertext Stealing)
- 512-byte encryption data units
- 16-byte blocks per XTS block (32 blocks per data unit)
- Sector-level encryption with tweakable block cipher

### 2.2 Key Derivation Functions (PKCS5)

**Available Hash Functions for KDF**:

| Hash | Digest Size | Non-Boot Iterations (PIM=0) | Boot Iterations (PIM=0) |
|------|-------------|---------------------------|----------------------|
| SHA-512 | 64 bytes | 500,000 | N/A (not used for boot) |
| SHA-256 | 32 bytes | 500,000 | 200,000 |
| BLAKE2s-256 | 32 bytes | 500,000 | 200,000 |
| Whirlpool | 64 bytes | 500,000 | N/A |
| Streebog | 64 bytes | 500,000 | 200,000 |

**PIM (Personal Iterations Multiplier)**:
```
Non-boot: iterations = 15000 + (PIM * 1000)
Boot:     iterations = PIM * 2048
```
- PIM=0 uses defaults above
- Higher PIM = more iterations = slower mount = harder brute force
- Lower PIM = faster mount = weaker against brute force

**Salt**: 64 bytes, randomly generated, stored in volume header (unencrypted area)

**Key Derivation Flow**:
```
Password + Salt + PIM -> PKCS5-HMAC-[hash] -> Header Key (variable size)
Header Key decrypts volume header -> Master Key extracted
Master Key used for XTS data encryption
```

### 2.3 Volume Layout and Hidden Volumes

**Standard Volume Layout (V2)**:
```
Offset 0:        Volume header (64-byte salt + encrypted header data)
Header size:     512 bytes total (TC_VOLUME_HEADER_SIZE)
Data area:       Starts at Header->EncryptedAreaStart
Backup header:   At end of volume (negative offset: -TC_VOLUME_HEADER_GROUP_SIZE)
```

**Hidden Volume Architecture**:
```
[Outer Volume Header] [Outer Volume Data...] [Hidden Volume Header] [Hidden Volume Data] [Outer Backup Header] [Hidden Backup Header]

Hidden header location: bytes 65536-131071 of the container
(appears as random data when no hidden volume exists)
```

**Plausible Deniability Mechanism**:
1. Outer volume created normally, free space filled with random data
2. Hidden volume created within outer volume's free space (end-aligned)
3. Password determines which volume mounts:
   - VeraCrypt tries standard header first with entered password
   - If fails, tries hidden header area (bytes 65536-131071)
   - Hidden header is indistinguishable from random data
4. No signature, no identifier -- cannot prove hidden volume exists
5. Partition table never modified (no VeraCrypt signature/ID)

**Hidden Operating System**: Entire OS runs from hidden volume, with decoy OS in outer volume. Boot loader attempts both passwords.

**Protection of Hidden Volumes**: When outer volume mounted with hidden volume protection enabled, writes that would overwrite hidden volume area are blocked.

### 2.4 Anti-Forensics Considerations

**RAM Considerations**:
- Master keys stored in RAM while volume is mounted
- VeraCrypt 1.24+ supports RAM encryption for master keys (5-15% overhead)
- On unmount: master keys erased from RAM
- On crash/power loss: keys NOT erased (cold boot attack risk)
- Recommendation: Power off completely, wait several minutes before leaving device
- RAM data decay: 1.5-35 seconds at normal temps, hours when cooled to -50C

**Key Forensic Indicators**:
- VeraCrypt driver loaded in kernel (Windows)
- Volume mount timestamps in registry/logs
- System encryption: unencrypted boot loader on first drive track
- Hibernation file may contain master keys (disable hibernation!)
- Page/swap files may contain decrypted data
- File-hosted containers: files containing only random data are suspicious
- Partition-hosted: random data on partition is plausibly "secure erase"

**Operational Security for VeraCrypt**:
```
1. Use cascade ciphers (AES-Twofish-Serpent) for defense in depth
2. Set high PIM (>485 for non-boot gives >500K iterations)
3. Use keyfiles in addition to password
4. Enable RAM encryption (v1.24+)
5. Disable hibernation and page files on encrypted systems
6. Use hidden volumes when duress scenarios are realistic
7. Power off (don't sleep/hibernate) when leaving device
8. On system encryption: enable "erase keys on new device" option
```
---
## 3. OSINT METHODOLOGY AND TOOLS

### 3.1 Username OSINT: Sherlock vs Maigret

**Sherlock** (sherlock-project):
- Detection methods: `status_code`, `message` (string match), `response_url` (redirect check)
- ~400 sites in data.json
- Threaded requests via `requests-futures` (max 20 workers)
- URL template: `https://site.com/users/{}` with username substitution
- Regex validation per site before request (`regexCheck`)
- Probe URL can differ from profile URL (`urlProbe`)
- Supports GET, HEAD, POST, PUT methods per site
- False positive exclusion list maintained separately

```bash
# Basic usage
sherlock username1 username2

# With output
sherlock --output results.csv --csv username

# Specific sites
sherlock --site GitHub --site Twitter username

# With proxy/tor
sherlock --proxy socks5://127.0.0.1:9050 username
```

**Maigret** (soxoj/maigret) -- Advanced Sherlock Fork:
- 3000+ sites (6x more than Sherlock), top 500 searched by default
- Async aiohttp-based (much faster than Sherlock's threading)
- Profile page parsing via `socid_extractor` -- extracts personal info from found pages
- Recursive search: finds new usernames/IDs on discovered profiles, then searches those
- Multiple ID types: `username`, `yandex_public_id`, `gaia_id`, `vk_id`, `ok_id`, `steam_id`, etc.
- Tag-based filtering by site category and country
- Censorship and captcha detection
- Tor/I2P site support
- DNS resolution for domain checks
- Proxy support via aiohttp-socks

```bash
# Basic usage
maigret username

# Recursive search (follow discovered usernames)
maigret username --recursive

# Filter by tags
maigret username --tags us,social

# With proxy
maigret username --proxy socks5://127.0.0.1:9050

# All sites (not just top 500)
maigret username -a

# Parse specific URL for IDs
maigret --parse https://example.com/profile/user123

# Multiple output formats
maigret username --html --pdf --csv --json

# Generate graph report
maigret username --graph
```

**Site Database Structure** (Maigret):
```yaml
SiteName:
Url: "https://example.com/user/{username}"
Url_main: "https://example.com"
Check_type: "status_code" | "message" | "response_url"
Presense_strs: ["Profile found"]       # strings indicating account exists
Absence_strs: ["404", "not found"]      # strings indicating no account
Regex_check: "^[a-zA-Z0-9_]{3,25}$"    # valid username pattern
Tags: ["social", "us", "dating"]
Alexa_rank: 12345                        # for priority ordering
Engine: "WordPress"                      # CMS engine detection
Headers: {"Accept-Language": "en-US"}    # custom headers
Disabled: false
Similar_search: false                    # true if results are fuzzy
```

### 3.2 OSINT Methodology Workflow

**Phase 1: Initial Reconnaissance**
```
1. Target identification: name, username, email, phone, photo
2. Username enumeration: sherlock/maigret for broad sweep
3. Email enumeration: Epieos, Castrick, Predicta Search
4. Phone lookup: phone number research tools
5. Breach data: HaveIBeenPwned, CredenShow, StealSeek
```

**Phase 2: Deep Dive by Platform**

| Platform | Key Tools | Data Points |
|----------|-----------|-------------|
| Google | GHunt | Google ID, reviews, maps contributions, photos |
| Twitter/X | Xquik, ExportData | Tweet history, followers, engagement metrics |
| Facebook | FB Friend List Scraper, SearchIsBack | Friends, groups, check-ins |
| LinkedIn | Standard search + Google dorking | Employment, education, skills |
| Instagram | Profile analysis tools | Posts, followers, tagged locations |
| Reddit | Reddit search + user analyzers | Post history, subreddit activity |
| GitHub | Octosuite, code search | Repos, commits, email from commits |
| Telegram | Various search bots | Groups, channels, messages |
| Steam | Steam ID lookup | Games, friends, activity |

**Phase 3: Infrastructure Reconnaissance**

| Category | Key Tools |
|----------|-----------|
| Domain/IP | Shodan, Censys, FOFA, ZoomEye, Criminal IP |
| DNS | DNSx, BGP.tools, BGP.he.net |
| Certificates | crt.sh, CertKit |
| Subdomains | Subfinder, BBOT |
| Web Archives | Internet Archive, Wayback Machine |
| Code Search | grep.app, GitHub Code Search, SearchCode, PublicWWW |

**Phase 4: Geospatial and Image Analysis**
```
1. Reverse image search: Google Images, TinEye, Yandex Images
2. EXIF data extraction from discovered photos
3. Geolocation from photos: landmarks, signs, sun position
4. Social media geotags and check-ins
5. Street-level imagery correlation
```

**Phase 5: Correlation and Reporting**
```
1. Cross-reference discovered accounts (same avatar, bio, links)
2. Timeline construction from post dates
3. Location pattern analysis
4. Network mapping (who interacts with target)
5. Confidence tagging per finding (confirmed/inferred/uncertain)
```

### 3.3 Key OSINT Search Engines

**Network Intelligence**:
- **Shodan**: IoT/device search, banner grabbing, CVE correlation
- **Censys**: Certificate and host search, TLS configuration analysis
- **FOFA**: Chinese-origin asset search, web component fingerprinting
- **ZoomEye**: Cyberspace search engine, device/service discovery
- **GreyNoise**: Separates targeted attacks from internet background noise
- **Criminal IP**: CVE-correlated attack surface discovery

**Data Breach Intelligence**:
- **HaveIBeenPwned**: Breach notification and credential check
- **CredenShow**: Compromised credential discovery
- **StealSeek**: Breach data analysis engine
- **Intelligence X**: Dark web, paste, and leak search

**Threat Actor Intelligence**:
- **MISP Galaxy**: Adversary group tracking with TTP mapping
- **Malpedia**: Malware and actor encyclopedia
- **ETDA APT Groups**: Comprehensive threat group database
- **SOCRadar LABS**: Actor profiles and TTP tracking

### 3.4 Google Dorking for OSINT

```
# Find exposed files
site:target.com filetype:pdf | filetype:xlsx | filetype:docx

# Find login pages
site:target.com inurl:login | inurl:admin | inurl:dashboard

# Find exposed directories
site:target.com intitle:"index of"

# Find email addresses
site:target.com "@target.com"

# Find subdomains
site:*.target.com -www

# Find exposed configs
site:target.com filetype:env | filetype:yml | filetype:conf

# Find social profiles
"firstname lastname" site:linkedin.com | site:twitter.com | site:facebook.com

# Find cached/removed content
cache:target.com/sensitive-page
```
---
## 4. SOPS SECRETS MANAGEMENT ARCHITECTURE

### 4.1 Core Architecture

**Design Principle**: Encrypt values only, leave keys/structure visible. This enables:
- Git diff on encrypted files shows which keys changed
- Code review of configuration structure without decrypting
- Partial file editing without full decryption

**Supported Formats**: YAML, JSON, ENV, INI, BINARY

**Encryption**: AES-256-GCM per value
```yaml
# Encrypted YAML example
database_password: ENC[AES256_GCM,data:p673w==,iv:YY=,aad:UQ=,tag:A=]
api_key: ENC[AES256_GCM,data:Ea3kL5O5U8=,iv:DM=,aad:FKA=,tag:EA==]
sops:
Kms:
    - arn: arn:aws:kms:us-east-1:...:key/...
Enc: CiC....Pm1Hm
```

### 4.2 Key Management Backends

| Backend | Key Type | Use Case |
|---------|----------|----------|
| AWS KMS | AES-256 envelope encryption | AWS-native workloads |
| GCP KMS | Cloud KMS keys | GCP-native workloads |
| Azure Key Vault | RSA/EC keys | Azure-native workloads |
| HashiCorp Vault Transit | RSA-4096, RSA-2048, ChaCha20-Poly1305 | Multi-cloud, on-prem |
| HuaweiCloud KMS | KMS keys | HuaweiCloud workloads |
| age | X25519 | Simple, modern, recommended over PGP |
| PGP/GPG | RSA, various | Legacy, widely supported |

### 4.3 age Integration (Recommended)

```bash
# Generate age key
age-keygen -o keys.txt

# Encrypt with age
sops encrypt --age age1yt3tfqlfrwdwx0z0ynwplcr6qxcxfaqycuprpmy89nr83ltx74tqdpszlw \
Secrets.yaml > secrets.enc.yaml

# Key file locations (auto-discovered):
# Linux: $XDG_CONFIG_HOME/sops/age/keys.txt (~/.config/sops/age/keys.txt)
# macOS: ~/Library/Application Support/sops/age/keys.txt
# Windows: %AppData%\sops\age\keys.txt

# Override with env vars:
export SOPS_AGE_KEY_FILE=/path/to/keys.txt
export SOPS_AGE_KEY="AGE-SECRET-KEY-..."
export SOPS_AGE_KEY_CMD="vault read -field=key secret/age"

# SSH key support (ed25519 and rsa):
sops encrypt --age "ssh-ed25519 AAAA..." secrets.yaml > secrets.enc.yaml
```

### 4.4 .sops.yaml Configuration (GitOps Pattern)

```yaml
creation_rules:
  # Environment-specific encryption
  - path_regex: \.dev\.yaml$
Age: age1dev...

  - path_regex: \.staging\.yaml$
Kms: arn:aws:kms:us-east-1:...:key/staging-key
Age: age1staging...

  - path_regex: \.prod\.yaml$
Kms: arn:aws:kms:us-east-1:...:key/prod-key-1,arn:aws:kms:eu-west-1:...:key/prod-key-2
Pgp: 85D77543B3D624B63CEA9E6DBC17301B491B3F21

  # Vault transit for on-prem
  - path_regex: \.onprem\.yaml$
Hc_vault_transit_uri: "https://vault.internal:8200/v1/sops/keys/prod"

  # Default catch-all
  - age: age1default...
```

### 4.5 Key Operations

```bash
# Edit encrypted file (decrypt -> edit -> re-encrypt)
sops edit secrets.enc.yaml

# Decrypt to stdout
sops decrypt secrets.enc.yaml

# Encrypt from stdin (pipe-friendly for CI/CD)
echo 'db_pass: secret123' | sops encrypt --filename-override secrets.yaml > secrets.enc.yaml

# Rotate data encryption key (when removing key access)
sops rotate -i --rm-pgp OLD_FINGERPRINT secrets.enc.yaml

# Add new key recipient without rotating data key
sops updatekeys secrets.enc.yaml

# Extract single value
sops decrypt --extract '["database"]["password"]' secrets.enc.yaml

# Multiple key backends (redundancy)
# File encrypted with BOTH AWS KMS and age -- either can decrypt
```

### 4.6 GitOps Integration Patterns

```bash
# CI/CD: Decrypt at deploy time
sops decrypt k8s/secrets.enc.yaml | kubectl apply -f -

# Terraform: Use sops provider
# terraform-provider-sops reads .sops.yaml automatically

# Helm: Decrypt values before template
sops decrypt values.enc.yaml | helm upgrade --install myapp ./chart -f -

# ArgoCD: Use ksops or argocd-vault-plugin
# Flux: Built-in sops decryption support
```
---
## 5. PRIVACY ARCHITECTURE PATTERNS

### 5.1 Threat Modeling Framework (Privacy Guides)

**Five Core Questions**:
1. What do I want to protect? (Assets)
2. Who do I want to protect it from? (Adversaries)
3. How likely is it that I will need to protect it? (Risk)
4. How bad are the consequences if I fail? (Impact)
5. How much trouble am I willing to go through? (Cost/Effort)

**Common Threat Categories**:
- Surveillance Capitalism (ad-tech, data brokers)
- Mass Surveillance Programs (government/NSA)
- Targeted Attacks (against specific individuals)
- Passive Attacks (network eavesdropping)
- Service Provider Access (cloud/email providers)

### 5.2 VPN Evaluation Criteria

**Required Properties**:
- WireGuard protocol support (modern, fast, audited)
- OpenVPN support (fallback, widely compatible)
- No logging policy (independently audited)
- Anonymous payment (cash, Monero)
- Open source clients
- Independent security audit

**Recommended Providers** (Privacy Guides):

| Provider | Countries | WireGuard | Anonymous Pay | Key Feature |
|----------|-----------|-----------|---------------|-------------|
| Proton VPN | 127+ | Yes | Cash | Stealth protocol for censorship bypass |
| IVPN | 41+ | Yes | Monero, Cash | Multi-hop, anti-tracking |
| Mullvad | 49+ | Yes | Monero, Cash | IPv6, account-number-only (no email) |

**VPN Limitations** (critical understanding):
- VPN does NOT provide anonymity (use Tor for that)
- VPN does NOT add security to HTTP traffic
- VPN shifts trust from ISP to VPN provider
- "No logging" policies are unverifiable promises
- VPN provider sees your real IP and traffic destinations
- Most VPN review sites are advertising vehicles

**When VPN is NOT enough**: Use Tor Browser for actual anonymity. VPN + Tor is possible but complex.

### 5.3 Browser Privacy Architecture

**Anti-Fingerprinting Approach** (Mullvad Browser):
- Based on Tor Browser with Tor network removed
- All users share identical fingerprint
- Permanent private browsing mode (no persistent state)
- Pre-installed uBlock Origin + NoScript (do NOT modify)
- Must use with VPN for crowd-blending effect
- Do NOT customize beyond security level slider

**Firefox Hardening** (Arkenfox user.js):
- Enhanced Tracking Protection
- Disable telemetry, studies, crash reports
- HTTPS-only mode
- Warning: Download tokens from Mozilla website contain unique identifiers (use FTP instead)

**Browser Fingerprinting Defense Hierarchy**:
```
1. Tor Browser (strongest -- crowd of identical fingerprints via Tor)
2. Mullvad Browser + Mullvad VPN (strong -- shared fingerprint via VPN)
3. Firefox + Arkenfox (moderate -- reduced fingerprinting surface)
4. Brave (moderate -- built-in fingerprint randomization)
```

### 5.4 Encrypted Communication Recommendations

**Signal** (top recommendation):
- Signal Protocol: forward secrecy + post-compromise security
- Phone number required but can be hidden via username
- Sealed Sender for metadata protection
- Private groups: server has no record of membership/titles
- Contact list encrypted with Signal PIN (server cannot access)
- Profile encrypted, only shared with chat contacts

**Hardening Signal**:
```
1. Set up username, hide phone number (Privacy > Phone Number > Nobody)
2. Enable registration lock (prevents re-registration attacks)
3. Verify safety numbers with contacts (detect MITM)
4. Enable disappearing messages for sensitive conversations
5. On Android: Consider Molly (encrypted local DB, Tor routing, RAM shredding)
```

### 5.5 Disk Encryption Recommendations

| Platform | Recommended | Notes |
|----------|-------------|-------|
| Cross-platform cloud | Cryptomator | AES-256, file-level, cloud-sync safe |
| Cross-platform disk | VeraCrypt | Full disk/volume, hidden volumes, plausible deniability |
| Windows | BitLocker + TPM+PIN | Hardware-backed, enable via Group Policy |
| macOS | FileVault | Hardware security module (T2/Apple Silicon) |
| Linux | LUKS | dm-crypt, full disk encryption |

**Critical Practice**: Shut down devices when not in use. Sleep/hibernate leaves keys in memory.

### 5.6 Top Privacy Tools by Category (awesome-privacy)

**Password Managers**:
- Bitwarden (open source, cloud-sync, self-hostable via Vaultwarden)
- KeePassXC (offline, gold standard, no cloud dependency)
- ProtonPass (integrated with Proton ecosystem)

**2FA Authenticators**:
- 2FAS (open source, encrypted backup, cross-device sync)
- Aegis (Android, open source, vault export)
- Tofu (iOS, minimal, open source)

**Email**:
- ProtonMail (E2EE, Swiss jurisdiction)
- Tutanota/Tuta (E2EE, German jurisdiction)

**Cloud Storage**:
- Cryptomator + any cloud provider (client-side encryption layer)
- Tresorit (zero-knowledge, E2EE)

**DNS**:
- NextDNS (privacy-focused, customizable filtering)
- Pi-hole (self-hosted, network-wide ad blocking)
---
## 6. OPERATIONAL PROCEDURES

### 6.1 OSINT Investigation Workflow

```
PHASE 1: SCOPE DEFINITION
  - Define target identifiers (name, username, email, phone)
  - Set boundaries (legal jurisdiction, authorized scope)
  - Document starting point and authorization

PHASE 2: PASSIVE ENUMERATION
  - Username sweep: maigret -a target_username --html --json
  - Email search: Epieos, Hunter.io
  - Breach check: HaveIBeenPwned API
  - Social media discovery across platforms
  - Google dorking for target-specific information
  - WHOIS/DNS for domain-related targets
  - Wayback Machine for historical content

PHASE 3: ACTIVE ANALYSIS
  - Parse discovered profiles (maigret --parse URL)
  - Extract metadata from public photos (EXIF)
  - Map social connections (followers, friends, interactions)
  - Timeline reconstruction from public posts
  - Geolocation from photo/post metadata

PHASE 4: CORRELATION
  - Cross-reference accounts by avatar, bio, linked accounts
  - Identify alternate usernames/handles
  - Map network graph of relationships
  - Validate findings with multiple sources
  - Tag confidence levels (confirmed/inferred/uncertain)

PHASE 5: REPORTING
  - Structured findings with evidence links
  - Confidence ratings per finding
  - Source documentation (screenshot + URL + timestamp)
  - Chain of custody for legal contexts
```

### 6.2 Secrets Management in GitOps

```
SETUP:
  1. Generate age keys for each environment
  2. Create .sops.yaml with path-based creation rules
  3. Encrypt all secrets before committing
  4. Store age private keys in secure KMS/vault (NOT in repo)

WORKFLOW:
  1. Developer edits: sops edit secrets.enc.yaml
  2. Commit encrypted file to git
  3. PR review: structure visible, values encrypted
  4. CI/CD pipeline decrypts at deploy time
  5. Secrets never stored unencrypted on disk

KEY ROTATION:
  1. Add new key: sops updatekeys -y secrets.enc.yaml
  2. Remove old key: sops rotate -i --rm-age OLD_KEY secrets.enc.yaml
  3. Commit rotated file
  4. Revoke old key access in KMS

MULTI-ENVIRONMENT:
  .sops.yaml creation_rules target different keys per path:
Dev/**  -> dev team keys
Staging/** -> staging + dev keys
Prod/** -> prod keys only (restricted access)
```

### 6.3 VeraCrypt Operational Procedure

```
CREATING HIDDEN VOLUME:
  1. Create outer volume with sensitive-looking decoy files
  2. Use strong, different passwords for outer and hidden
  3. Outer: files you'd reluctantly reveal under duress
  4. Hidden: files you actually want to protect
  5. Never write to outer volume after hidden volume creation
     (or use hidden volume protection mode)

MOUNTING:
Veracrypt --text /path/to/volume /mnt/point
  # Password determines which volume (outer vs hidden) mounts

  # With hidden volume protection (prevents outer writes damaging hidden):
Veracrypt --text --protect-hidden /path/to/volume /mnt/point

SYSTEM ENCRYPTION:
  # Full disk encryption with pre-boot authentication
  # Hidden OS: decoy OS + hidden OS on same drive
  # Boot password determines which OS loads

DISMOUNTING:
Veracrypt --text --dismount /mnt/point
  # Then: power off system, wait several minutes (RAM decay)
```

### 6.4 Signal Server Metadata Profile

**What Signal's server architecture reveals it CAN see**:
- Account exists (phone number registration)
- Device count per account
- Last connection time (from websocket connections)
- IP addresses of connections (mitigate with VPN/Tor)
- Message delivery timestamps
- Message sizes
- Push notification timing
- Rate limit counters (message send frequency)

**What Signal's server architecture reveals it CANNOT see**:
- Message content (E2EE via Signal Protocol)
- Contact lists (encrypted with PIN)
- Group membership/names/avatars (encrypted)
- Profile name/avatar (encrypted with profile key)
- Sender identity (Sealed Sender)
- Call content (E2EE)

**Privacy Engineering Takeaway**: Signal's architecture demonstrates the principle of minimum viable metadata -- the server stores only what is required for message routing and abuse prevention, with cryptographic enforcement rather than policy promises.
---
## 7. DETECTION OPPORTUNITIES AND FORENSIC INDICATORS

### 7.1 VeraCrypt Forensic Indicators

```
INDICATORS OF VERACRYPT USE:
- veracrypt.exe/veracrypt binary present
- VeraCrypt driver loaded (Windows: veracrypt.sys)
- Registry entries: HKLM\SYSTEM\CurrentControlSet\Services\veracrypt
- Mount point artifacts in filesystem journals
- Volume shadow copies may contain unencrypted data
- Prefetch files (Windows): veracrypt.exe-*.pf
- USB device insertion logs (if container on removable media)
- Browser history: veracrypt.fr visits

INDICATORS OF HIDDEN VOLUME:
- Cannot be proven from encrypted volume alone (by design)
- Behavioral: user mounts same file but accesses different data
- Timing: different mount times (hidden volume = different PIM/hash)
- Outer volume never written to (suspicious if monitoring write patterns)
- Multiple passwords observed (if keylogger present)

COLD BOOT ATTACK VECTORS:
- RAM contents survive 1.5-35 seconds at room temperature
- Cooling extends to hours
- Master keys in RAM during mount
- Mitigation: VeraCrypt 1.24+ RAM encryption, or power off + wait
```

### 7.2 OSINT Tool Fingerprints

```
SHERLOCK/MAIGRET DETECTION (from target's perspective):
- Burst of profile page visits from same IP in short timeframe
- User-agent: "Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0" (Sherlock default)
- HEAD requests to profile URLs (Sherlock status_code check)
- Requests to non-existent usernames (probing pattern)
- Consistent timing between requests

MITIGATION FOR OSINT OPERATORS:
- Use rotating proxies or Tor
- Randomize request timing
- Customize user-agent strings
- Use maigret's proxy support: --proxy socks5://127.0.0.1:9050
- Limit concurrent requests to avoid rate limiting
```

### 7.3 Signal Forensic Artifacts (Desktop)

```
DATABASE LOCATION:
- Linux: ~/.config/Signal/sql/db.sqlite
- macOS: ~/Library/Application Support/Signal/sql/db.sqlite
- Windows: %AppData%\Signal\sql\db.sqlite

KEY MATERIAL:
- SQLCipher key derived from registration credentials
- Key stored in OS keychain/credential manager
- Without key, database is AES-256 encrypted (SQLCipher)

RECOVERABLE ARTIFACTS (if device compromised while running):
- Message database (if SQLCipher key extracted from memory)
- Attachment files (decrypted on disk while app running)
- Draft messages in memory
- Contact/conversation metadata from decrypted DB

ARTIFACTS SIGNAL DOES NOT LEAVE (by design):
- No plaintext message logs
- No unencrypted local backup (unless user explicitly creates)
- Disappearing messages removed after timer expires
- Profile keys rotated on contact block
```
---
## 8. PRIVACY ENGINEERING PRINCIPLES

### 8.1 Zero-Knowledge Architecture Pattern

Demonstrated by Signal, Cryptomator, Bitwarden:
```
1. Client generates encryption keys locally
2. Data encrypted before leaving client
3. Server stores only ciphertext
4. Server never possesses decryption keys
5. Key derivation from user credentials (password/PIN)
6. Server cannot comply with data access requests (nothing to provide)
```

### 8.2 Metadata Minimization Pattern

Demonstrated by Signal's Sealed Sender:
```
1. Encrypt message metadata alongside content where possible
2. Use delivery tokens instead of authenticated sender identity
3. Separate routing information from identity information
4. Short-lived certificates instead of persistent authentication
5. Rate limiting by token rather than by identity
```

### 8.3 Plausible Deniability Pattern

Demonstrated by VeraCrypt hidden volumes:
```
1. Encrypted data indistinguishable from random
2. Multiple valid decryption results from same container
3. No structural signatures that prove encryption exists
4. Decoy content provides plausible explanation
5. Forensic analysis cannot prove hidden content exists
```

### 8.4 Defense in Depth for Secrets

Demonstrated by SOPS multi-backend:
```
1. Multiple encryption keys from different providers
2. Any single key can decrypt (availability)
3. Key rotation without re-deploying applications
4. Separation of key management from secret storage
5. Audit trail via KMS provider logging
6. Path-based access control via .sops.yaml rules
```
