CIPHER 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):

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

# 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

# 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):

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

# 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)

# 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)

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

# 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

# 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