Security Analysis and Threat Model

Security Properties

Message Security (a.k.a What MLS Guarantees)

Confidentiality: Only group members can decrypt messages.
Authenticity: Messages are cryptographically signed by the sender.
Integrity: Tampering is cryptographically detectable.
Forward Secrecy: Past messages are secure even if current keys are compromised.
Post-Compromise Security: Key rotations help recover from breaches.

Identity Security (Device-Centric)

Non-Repudiation: Senders cannot deny sending signed messages.
Identity Verification: Public key fingerprints enable manual verification.
Key Consistency: Devices can detect key changes.
No PII Required: No phone numbers, emails, or identifying information.

Threat Model

Attacks We Prevent

Attack	Description	Protection	Limitation
Network Eavesdropping	Passive monitoring of network traffic	All message content encrypted with MLS	Message timing and size patterns observable
Server Compromise	Malicious or compromised server operators	Servers cannot decrypt messages or forge identities	Can deny service or correlate delivery addresses
Active Network Attacks	Man-in-the-middle attacks on message delivery	End-to-end MLS encryption prevents tampering	Can block or delay messages
Identity Impersonation	Attacker claims to be someone else	Cryptographic signatures prevent forgery	Initial contact exchange is vulnerable to MITM
Address-Based Tracking	Long-term tracking via delivery addresses	Address rotation prevents correlation	Timing analysis may still reveal patterns

Attacks We Mitigate

Attack	Mitigation	Limitation
Traffic Analysis	Minimal routing metadata, no sender addresses in federated messages	Message timing patterns may reveal relationships
Key Compromise	MLS provides post-compromise security and forward secrecy	Requires key rotation to recover security
Social Engineering	Clear trust indicators in the UI	Users may ignore security warnings

Privacy Analysis

Cryptid’s privacy model balances strong cryptographic protections with practical spam prevention. This section analyzes what privacy guarantees Cryptid provides and what limitations exist.

Privacy Threat Model

Cryptid’s privacy guarantees vary by adversary capability:

Adversary Type	Can Observe	Cannot Observe
Network Observer	Message timing, sizes, IP addresses, deliver addresses	Content, recipients, device identity, groups
Compromised Server	Account age, message volume, online status, delivery addresses, KeyPackage consumption	Content, device identity linkage, social graph
Federation Peer	That your server exchanges messages, destination servers	Which users, specific addresses, content, relationships
Malicious Group Member	Messages in their groups, your device_id	Messages in other groups, your other contacts, your delivery addresses

What’s Protected (Privacy Guarantees)

Strong Protections (Cryptographic)

Message content: MLS encryption prevents access by anyone except group members
Message authenticity: Signatures prevent forgery and ensure sender accountability
Forward secrecy: Past messages secure even if current keys compromised
Post-compromise security: Key rotations recover security after breaches

Architectural Protections (Design)

Sender privacy: Servers don’t know which device sent a message (sender address not transmitted)
Social graph privacy: No contact lists or relationship tracking server-side (though timing correlation can infer relationships)
Group privacy: Servers don’t know what groups you’re in or who’s in them (social graph privacy against content inspection)
Identity privacy: No PII required, addresses are cryptographically derived (pseudonymous)
Content confidentiality: All message content is MLS encrypted end-to-end

Behavioral Privacy (Minimal Metadata)

Activity patterns: Servers track account age and message volume for spam prevention
Online status: Servers know when you’re active (for delivery optimization)
Federation domains: Servers see which domains you communicate with

What’s Exposed (Metadata Limitations)

Server Observable

Delivery addresses: Servers see recipient addresses for routing (but they’re pseudonymous, rotatable)
Device-to-address mapping: Servers link device_id to delivery addresses (24-hour retention, not exposed via API)
KeyPackage consumption: Servers observe aggregate group addition frequency (not specific groups)
Message timing: Servers observe when messages are sent/received
Message sizes: Approximate message length visible
Account age: Registration time tracked for progressive trust
Message volume: Aggregate send/receive counts for rate limiting

KeyPackage Privacy Impact

Servers storing KeyPackages can observe:

Total KeyPackages uploaded per device
Total KeyPackages consumed (approximate group addition frequency)
Timing of KeyPackage consumption

Example: Server knows “device X consumed 50 KeyPackages in 30 days” (~1.6 groups/day).

What Servers CANNOT observe:

Which specific groups the device joined
Who else is in those groups
Message content or recipients

Privacy analysis:

This reveals aggregate social activity level but not:

Specific group memberships
Individual conversation patterns
Relationships with other users

See Blind KeyPackage Distribution for how handle derivation removes device_id from KeyPackage storage.

Network Observable

Traffic patterns: Communication timing and volume visible to ISP/network
Server connections: Which Cryptid servers you connect to
Connection duration: How long you’re online

Important: This metadata does NOT reveal message content or sender identity. Only that communication occurs.

Address Rotation and Privacy

Cryptid’s multiple delivery address system provides proactive privacy protection:

Prevents long-term tracking:
- Network observer sees different addresses over time
- Cannot build long-term profile without correlating other metadata
Isolates contexts:
- Compromise of one address doesn’t affect others
- Each context has separate pseudonym
Enables spam prevention:
- Alice’s public address gets spammed
- Alice burns the address and creates a new one
- Spammer loses routing information
- New address is unknown to spammer

What Address Rotation Does NOT Hide

Device identity in groups:
- Group members know your device_id (MLS requirement)
- Address rotation doesn’t change your device_id
- Group members can always message you (have your device_id)
Server-side patterns:
- Server tracks device_id -> addresses mapping (24h retention)
- Can observe address rotation patterns (how often you rotate)
- Can correlate timing across addresses (same device_id)
Network-level patterns:
- Connection timing (when you’re online)
- Traffic volume (how much you communicate)
- Server domains (which servers you use)

Privacy Trade-offs

Privacy Goal	Mechanism	Limitation
Hide delivery endpoint	Address rotation	Device_id still known to contacts
Prevent spam	Burn compromised addresses	Must share new address with contacts
Context isolation	Multiple addresses	Server knows all belong to same device
Long-term tracking	Regular rotation	Timing correlation may still work

Best practices for maximum privacy:

Rotate public addresses frequently (weekly or after each use)
Use separate addresses for different contexts
Burn addresses that receive spam immediately
Use different servers for different contexts (multi-homing)

Privacy Comparison with Other Systems

System	Identity Required	Server Sees Recipients	Server Sees Content	Server Tracks Behavior
Discord/Slack	Email/username	Full visibility	Full access	Extensive
WhatsApp	Phone number	Full visibility	E2EE	Metadata tracking
Signal	Phone number	Sealed sender	E2EE	Minimal
Matrix (E2EE)	Username	Room metadata	E2EE rooms	Room/federation metadata
Email (PGP)	Email address	Full headers	PGP encrypted	Email headers
Cryptid	None (keys only)	Recipient visible (rotatable), sender hidden	MLS E2EE	Aggregate patterns (device_id) + KeyPackage consumption

Cryptid’s Positioning

Better than:

Discord, Slack, WhatsApp: No content access, no sender tracking
Traditional email: No identity requirement, no header metadata
Matrix: Less metadata, no room state visibility

Comparable to:

Signal: Similar E2EE strength, similar design around sender privacy

Trade-off vs.:

Pure anonymity systems (Tor): Less anonymous but more practical and lower latency

Privacy Design Decisions

Decision 1: Unlinkable Authentication over Behavioral Metadata

What we do: Meter actions with PrivacyPass tokens rather than tracking per-device behavior. Servers enforce rate limits at issuance, where identity is known, and learn nothing about who spends a token at redemption.

Rationale: Earlier revisions of this spec tracked aggregate per-device message volume and spam reports, on the reasoning that a pure zero-state server cannot resist spam flooding. Unlinkable authentication removes that tradeoff because now scarcity replaces attribution. A device cannot exceed its budget no matter how many addresses it holds, and the server never needs to know which device acted.

Rate limiting binds to issuance, not to observed behavior
Servers retain a spent-token nonce set, not a per-device behavioral profile
Servers derive no per-device abuse signal from the traffic they carry
Abuse reports aggregate per origin server, never per device
Federated abuse is bounded at the federation boundary rather than by identifying senders

What’s preserved: Content confidentiality, sender privacy, and social graph privacy against content inspection.

What this costs: A server cannot find a bad device on its own, and nothing in the protocol tells it about one. Abuse response works through uniform issuance budgets, per-origin federation limits, and client-side blocking - the layer that does not depend on the server at all. An operator who learns of abuse out of band can still block a device at issuance.

Privacy impact: The server learns how many tokens a device took, and roughly when. It does not learn what any of them were spent on.

Decision 2: Rotatable Pseudonymous Addresses

What we do: Devices have multiple rotatable pseudonymous addresses rather than single permanent addresses or full anonymity.

Architecture:

Device identity (device_id): Permanent cryptographic identity
Delivery addresses: Ephemeral routing endpoints (rotatable)
Separation enables privacy (rotate addresses) + accountability (stable device_id)

Rationale:

Stable device identity enables:
- Persistent group membership (groups need stable member identifiers)
- Blocking and moderation (based on cryptographic identity)
- Trust decisions (verify fingerprints, build reputation)
Rotatable delivery addresses enable:
- Privacy via address rotation (prevent long-term tracking)
- Spam prevention (burn compromised addresses)
- Context isolation (different addresses for different purposes)
This hybrid approach balances:
- Accountability: device_id provides stable identity for trust/blocking
- Privacy: delivery addresses are ephemeral and rotatable

What’s preserved:

Device_id is cryptographic, contains no PII
Delivery addresses are derived from per-group mailbox keypairs, not from device_id.
Cannot link addresses to device_id without server cooperation
Address rotation prevents long-term address-based tracking

Privacy impact:

Contacts/groups know your device_id (for MLS and blocking)
Network observers see delivery addresses (rotatable for privacy)
Servers link device_id to addresses (24h retention, not exposed)

Comparison with alternatives:

Approach	Privacy	Accountability	Complexity
Single permanent address	Low	High	Simple
Fully anonymout (Tor)	High	None	Complex
Cryptid	Medium-High	Medium-High	Moderate

Cryptid chooses the balanced middle ground: enough privacy for most use cases and enough accountability for community health.

Decision 3: No Phone Numbers or Email

What we do: Identity is purely cryptographic (Ed25519 keypairs). No phone numbers, emails, or personal information required.

Rationale: Phone numbers and emails are:

Privacy-invasive (reveal real identity)
Centralized (controlled by telecoms/email providers)
Surveillance-friendly (can be subpoenaed)
Not necessary for secure communication

What’s preserved: Complete pseudonymity. The server never learns your real identity.

Privacy impact: You can use Cryptid completely anonymously. Your device address is just a derived cryptographic identifier.

Enhanced Privacy Options (Future Work)

The protocol architecture supports optional enhanced privacy features in future versions:

Relay Networks: Undecided

Route messages through multiple servers to hide server-to-server relationships
Similar to Tor, but specifically for Cryptid federation
Trade-off: Increased latency, more complexity

Message Padding: Undecided

Normalize message sizes to reduce size-based inference
Prevents distinguishing “Hi” from “Here’s my tax documents”
Trade-off: Increased bandwidth usage

Traffic Mixing: Undecided

Batch and delay messages to obscure timing patterns
Makes it harder to correlate “Alice sent message” with “Bob received message”
Trade-off: Increased latency

These features are intentionally left to future specifications to maintain initial protocol simplicity while keeping the door open for enhanced privacy.

Privacy Guarantees Summary

What Cryptid Guarantees:

No one but group members can read your messages (E2EE)
Servers don’t know who sent you a message (sender privacy)
Servers don’t know what groups you’re in (social graph privacy against content inspection)
No personal information required (pseudonymity)
Delivery addresses are rotatable (prevents long-term address-based tracking)
Device identity separate from routing (privacy + accountability)

What Cryptid Does Not Guarantee:

Complete anonymity from network observers (traffic timing visible)
Near-zero metadata (account age and report counts retained for abuse response)
Perfect unlinkability (mailboxes remain correlatable by source address and delivery timing)
Perfect forward secrecy forever (requires periodic key rotation)
Address rotation doesn’t hide device_id (contacts and group members know your device_id)