Executive Summary
Snugg implements end-to-end encryption for all user content using modern, well-audited cryptographic primitives. This document describes our encryption architecture, key management approach, and the threat model we protect against.
Encryption Architecture Overview
Snugg uses a hybrid encryption approach combining asymmetric and symmetric cryptography to provide both security and performance.
Asymmetric Encryption (Public-Key)
Each user has a unique keypair (X25519). The public key is shared with our servers; the private key never leaves the user's device. Used for initial key exchange and securing group keys.
Symmetric Encryption (Shared Secret)
Each group has a symmetric key (XSalsa20-Poly1305) shared only among group members. This key encrypts all content within the group, providing fast encryption/decryption.
Hybrid Approach
When you join a group, the group key is encrypted with your public key and sent to you. Your device decrypts it with your private key, giving you access to group content. This combines the security of asymmetric crypto with the efficiency of symmetric crypto.
Key Management
Secure key management is critical to our encryption architecture. Here's how keys are generated, stored, and used:
Key Generation
When you create an account, your device generates a cryptographically secure keypair using the Web Crypto API or TweetNaCl.js. Keys are generated locally—they never pass through our servers.
Key Storage
Private keys are stored in encrypted local storage (IndexedDB) on your device, protected by a key derived from your account credentials using PBKDF2 with 100,000 iterations.
Key Distribution
When you join a group, existing members encrypt the group key with your public key. This encrypted bundle is stored on our servers and can only be decrypted by your private key.
Key Rotation
Group keys are rotated when members leave to ensure forward secrecy. Departed members cannot decrypt new content even if they retained the old key.
Cryptographic Primitives
We use well-established, audited cryptographic algorithms:
| Purpose | Algorithm | Library |
|---|---|---|
| Key Exchange | X25519 (Curve25519 ECDH) | TweetNaCl.js |
| Symmetric Encryption | XSalsa20-Poly1305 | TweetNaCl.js |
| Digital Signatures | Ed25519 | TweetNaCl.js |
| Hashing | SHA-256 | Web Crypto API |
| Key Derivation | PBKDF2 (100k iterations) | Web Crypto API |
Data Flow: How Content is Encrypted
Here's what happens when you post content to a group:
Threat Model
Understanding what we protect against—and what we don't—is essential for users to make informed decisions.
What We Protect Against
- Server compromise: An attacker who gains access to our servers sees only encrypted ciphertext
- Rogue employees: Snugg staff cannot read user content—we don't have the keys
- Government demands: Even if legally compelled, we can only provide encrypted data
- Network eavesdropping: All connections use TLS 1.3; content is additionally E2E encrypted
What We Don't Protect Against
- Compromised devices: If an attacker controls your device, they can read decrypted content
- Group member screenshots: Members can screenshot or copy decrypted content
- Metadata analysis: We can see who is in which groups and when they post (but not content)
Security Audits & Verification
We believe in verifiable security, not security through obscurity:
Don't trust us—verify. Our source code is available at github.com/snugg-social
Technical References
For more information on the cryptographic standards we use:
- •TweetNaCl.js: A port of the well-audited NaCl cryptographic library
- •Curve25519: Elliptic curve designed by Daniel J. Bernstein for key exchange
- •XSalsa20-Poly1305: Authenticated encryption from the NaCl family
- •PBKDF2: Password-Based Key Derivation Function 2 (RFC 8018)
Security Questions or Responsible Disclosure?
If you have questions about our security architecture or want to report a vulnerability, we'd love to hear from you.
security@snugg.socialLast updated: February 1, 2026