🔐 Seenly Social — End-to-End Encryption (E2EE) Specification
Seenly's messaging subsystem is built with True End-to-End Encryption (E2EE)* using standard, audited cryptographic algorithms via the browser's native *WebCrypto API (`window.crypto.subtle`).
---
1. Cryptographic Principles & Guarantees
- Zero Server Knowledge: Plaintext messages and private encryption keys never touch the Seenly server memory, disk, or logs. - No Backdoors: There are no master keys, admin decryption tokens, or developer escrow mechanisms. - Standardized Cryptography: Zero custom or home-brewed ciphers. All operations utilize standard W3C WebCrypto API primitives.
---
2. Cryptographic Primitives
| Component | Specification | | :--- | :--- | | Asymmetric Key Agreement | ECDH (Elliptic Curve Diffie-Hellman) | | Curve | NIST P-256 (secp256r1) | | Symmetric Cipher | AES-GCM (Galois/Counter Mode) | | Key Length | 256-bit | | Initialization Vector (IV) | 96-bit (12 bytes) cryptographically random per message | | Key Serialization | SPKI (SubjectPublicKeyInfo) Base64 |
---
3. Key Exchange & Message Flow
``` Alice (Device A) Bob (Device B) │ │ ├── 1. Generate ECDH KeyPair (P-256) │ ├── 2. Export Alice Public Key (SPKI) │ │ │ │─────────────── 3. Transmit Public Key ───────────────►│ │ │ │ ├── 4. Generate ECDH KeyPair (P-256) │ ├── 5. Derive Shared AES-256 Key │◄────────────── 6. Transmit Bob Public Key ────────────┤ │ │ ├── 7. Derive Shared AES-256 Key │ │ │ ═══════════════════ SECURE ENCRYPTED CHANNEL ESTABLISHED ═══════════════════ │ │ ├── 8. Encrypt(Plaintext, SharedKey, RandomIV) │ │ │ │────────────── 9. Relay Ciphertext + IV ──────────────►│ │ │ │ ├── 10. Decrypt(Ciphertext, SharedKey, IV) ```
---
4. Key Management & Storage
- Private Keys: Stored exclusively in local device memory or client-side storage (`IndexedDB` / `localStorage`). - Shared Secret Derivation: Both devices independently compute the identical 256-bit AES-GCM key from their respective private key and the peer's public key. - Ciphertext Format: `[12-byte IV] + [AES-GCM Ciphertext + 16-byte Auth Tag]` encoded in standard Base64.
---
5. Public Clip Sharing Architecture
When a user shares a public Clip within an encrypted chat: 1. The client constructs a structured reference card: `[SHARED_POST:{"id":"clip_123","is_reel":true}]`. 2. The reference string is encrypted using the shared AES-GCM key. 3. The recipient decrypts the payload and renders a live interactive card linked to the original Clip ID. 4. Result: Zero video duplicating, preserving bandwidth and cryptographic integrity.