# Unspkn Security Whitepaper **Version 1.0 — March 2026** **Document Classification: Public** --- ## Executive Summary Unspkn is an encrypted messaging platform designed from the ground up with a single principle: your conversations belong to you. This document details the cryptographic architecture, data handling practices, and privacy guarantees that make that principle real. We do not store your messages in readable form. We cannot read your messages. We do not collect your name, email, or phone number. If served with a legal request, we can only produce encrypted data that we have no ability to decrypt. This is not a marketing claim. This document explains exactly how our system works so that security researchers, privacy advocates, and users can verify our commitments. --- ## 1. Identity and Registration ### 1.1 Handle-Based Identity Unspkn does not require a phone number, email address, or any personally identifiable information to create an account. Users register with: - A **handle** (username) — the only identifier visible to other users - A **display name** (optional) - An **avatar** (emoji-based or visual style selection) Authentication is managed through anonymous authentication with Firebase, meaning no email or phone number is linked to your account at the platform level. ### 1.2 What We Know About You | Data | Stored? | Details | |------|---------|---------| | Name | No | Not required or collected | | Email | No | Not required or collected | | Phone number | No | Not required or collected | | IP address | No | Not logged or stored by Unspkn | | Handle | Yes | User-chosen, not linked to real identity | | Device tokens | Yes | For push notifications only, rotated by OS | | Subscription status | Yes | For feature gating, not linked to real identity | --- ## 2. Message Encryption ### 2.1 Encryption Standard All messages are encrypted using **AES-256-GCM** (Advanced Encryption Standard, 256-bit key, Galois/Counter Mode). This is the same encryption standard used by governments, financial institutions, and military applications worldwide. It provides both confidentiality (nobody can read the data) and integrity (nobody can tamper with the data without detection). ### 2.2 How Message Encryption Works **Sending a message:** 1. You type a message on your device. 2. Your device encrypts the message using AES-256-GCM with a conversation-specific symmetric key. 3. A unique random 96-bit nonce (number used once) is generated for each message, ensuring identical plaintext produces different ciphertext. 4. The encrypted payload (nonce + ciphertext + authentication tag) is uploaded to our server. 5. A cipher-themed **decoy text** is generated locally on your device and stored alongside the encrypted payload for use in stealth mode. 6. The original plaintext **never leaves your device** in readable form. **Receiving a message:** 1. Your device downloads the encrypted payload from the server. 2. Your device decrypts the message locally using the conversation key stored in your device's secure keychain. 3. The decrypted plaintext is displayed on screen and exists only in device memory. 4. Decrypted content is never written back to the server. ### 2.3 What the Server Stores For each message, our server (Firebase Firestore) stores: - `encrypted_blob` — The AES-256-GCM encrypted payload. **We cannot decrypt this.** - `nonce` — The 96-bit nonce used for encryption. This is not secret but is unique per message. - `decoy_text` — A fake message generated by the cipher theme engine for stealth mode display. - `message_type` — Whether the message is text, photo, GIF, meme, or voice. - `sender_id` — The anonymous user ID of the sender (not a real name or phone number). - `timestamp` — When the message was sent. - `delivered` / `read` — Delivery and read status flags. - `reactions` — Emoji reactions (user IDs + emoji, not encrypted). - `expires_at` — Automatic expiry timestamp (messages expire after 30 days). **What the server does NOT store:** - The original plaintext message - Encryption keys - Any data that would allow decryption of the message ### 2.4 Encryption Versioning Messages include an `encryption_version` field to support forward-compatible upgrades to the encryption scheme. Current version: `1` (AES-256-GCM). Legacy messages (version `0`) from early development were stored as plaintext and have been migrated to version 1. --- ## 3. Key Management ### 3.1 Key Generation and Storage Encryption keys are generated and stored exclusively on your device using platform-native secure storage: - **iOS:** Apple Keychain Services (hardware-backed on devices with Secure Enclave) - **Android:** Android Keystore System (hardware-backed on supported devices) Keys are set to accessibility level "when unlocked," meaning they cannot be extracted even by a forensic tool when the device is locked. ### 3.2 Key Exchange (1-on-1 Conversations) When two users connect, a shared encryption key is established using: 1. **X25519 Elliptic Curve Diffie-Hellman (ECDH)** key agreement 2. **HKDF-SHA256** key derivation with conversation-specific salt Each user generates a Curve25519 key pair. The public key is shared via the server. The private key never leaves the device. Both parties independently derive the same symmetric key using their private key and the other party's public key. This symmetric key is then used for AES-256-GCM encryption of all messages in that conversation. The server facilitates the public key exchange but never has access to the derived symmetric key. ### 3.3 Group Key Management Group conversations use a dedicated group key system: 1. The group creator generates a random AES-256 symmetric key. 2. This group key is individually wrapped (encrypted) for each participant using pairwise ECDH-derived wrapping keys. 3. Each participant's wrapped copy is stored on the server. Only they can unwrap it using their private key. 4. All group messages are encrypted with the shared group key. This ensures that the server stores only wrapped (encrypted) copies of the group key and cannot derive the actual key. ### 3.4 Key Backup Conversation keys can be backed up via iCloud Keychain (iOS) or Google Backup (Android), which are themselves encrypted by the respective platform's end-to-end encryption systems. Unspkn does not operate its own key backup infrastructure. If a user loses their device and does not have a cloud keychain backup, message history cannot be recovered. This is a deliberate security decision: we would rather lose data than compromise encryption. --- ## 4. Media Encryption Photos, GIFs, memes, and voice messages follow the same encryption pipeline as text: 1. Media is captured or selected on the device. 2. The raw media data is encrypted using AES-256-GCM with the conversation's symmetric key. 3. The encrypted blob is uploaded to Firebase Storage. 4. A storage reference (path to the encrypted file) is stored in the message document. 5. On the receiving device, the encrypted media is downloaded and decrypted locally. Temporary files (such as voice recordings before encryption) are deleted from the device immediately after encryption and upload. The server stores only encrypted media blobs. Thumbnail generation, format conversion, and any processing happen on-device, not server-side. --- ## 5. Stealth Mode and Visual Ciphers ### 5.1 How Stealth Mode Works Unspkn includes a stealth mode designed so that conversations appear innocuous if someone else views your phone. When the app is locked: - Text messages display **cipher-themed decoy text** instead of the encrypted payload. Depending on the selected cipher theme, messages may appear as Greek text, binary code, runic script, Morse code, foreign language translations, or other visual disguises. - Photos, GIFs, and voice messages display as normal text bubbles with decoy text. No media indicator is visible. - The conversation list shows decoy text previews. When unlocked via biometric authentication or gesture, the real decrypted messages are displayed. ### 5.2 Decoy Text Generation Decoy text is generated entirely on-device at send time. The cipher theme engine transforms the plaintext into themed output (for visual cipher themes) or selects from persona-appropriate message pools (for decoy persona mode). The decoy text is stored alongside the encrypted payload so it can be displayed without decryption. Decoy text is not derived from the actual message content in any recoverable way. A Greek-themed decoy does not encode the real English message in Greek — it generates independent text that matches the visual pattern. ### 5.3 Decoy Personas Users can assign a "decoy persona" to each conversation (e.g., Coworker, Family, Gym Buddy, Partner). When stealth mode is active, the conversation displays realistic-looking messages appropriate to that persona type, making it indistinguishable from a normal conversation. --- ## 6. Server Architecture ### 6.1 Zero-Knowledge Design Our server infrastructure is designed on a zero-knowledge principle: the server facilitates message delivery but cannot access message content. - **Firebase Firestore** stores encrypted message documents. It indexes on metadata (timestamp, sender ID, conversation ID) but the `encrypted_blob` field is opaque binary data. - **Firebase Cloud Functions** handle push notification delivery, using the `decoy_text` field for notification content — never the actual message. - **Firebase Storage** stores encrypted media blobs with no server-side processing. - **Firebase Authentication** manages anonymous user sessions with no PII linkage. ### 6.2 Cloud Function Behavior Cloud Functions in our architecture serve as stateless proxies. They: - Receive encrypted data and route it - Send push notifications using decoy text - Do not log, cache, or store message content - Do not have access to encryption keys ### 6.3 Data Retention - Messages are automatically deleted 30 days after creation via the `expires_at` field. - Users can manually delete messages at any time (delete for self or delete for everyone). - "Delete for everyone" overwrites the encrypted blob, decoy text, reactions, and edit history on the server, leaving only a tombstone record. - Account deletion removes all user data from Firestore. --- ## 7. Access Control ### 7.1 Firestore Security Rules Our database security rules enforce participant-scoped access: - **Conversations:** Only participants listed in the conversation document can read or write messages. - **Messages:** Only conversation participants can create, read, or modify messages. The sender ID must match the authenticated user. - **User profiles:** Only the account owner can modify their own profile. Admin fields (such as admin status and suspension) cannot be self-modified. - **Group keys:** Only conversation participants can read or write group key documents. These rules are enforced server-side by Firebase and cannot be bypassed by a modified client. ### 7.2 No Admin Access to Content Our administrative tools provide visibility into user accounts (handles, subscription status, account creation dates) and aggregate platform statistics. Administrators cannot read, decrypt, or access message content. The admin interface does not expose `encrypted_blob` fields. --- ## 8. What Happens If We Receive a Legal Request If Unspkn receives a valid legal request (subpoena, court order, or government demand) for user data, we can only produce: - **User profile:** Handle, avatar style, account creation date, subscription status. No name, email, or phone number (because we don't collect them). - **Message metadata:** Timestamps, anonymous sender IDs, conversation participant lists, delivery/read status. - **Encrypted message payloads:** AES-256-GCM encrypted blobs that we cannot decrypt. - **Decoy text:** The fake stealth-mode text, which is not the actual message content. We **cannot** produce: - Plaintext message content (we don't have the keys) - Encryption keys (stored only on user devices) - User identity information beyond the self-chosen handle - IP address logs (we don't maintain them) --- ## 9. Cryptographic Primitives Summary | Function | Algorithm | Standard | |----------|-----------|----------| | Message encryption | AES-256-GCM | NIST SP 800-38D | | Key agreement | X25519 ECDH | RFC 7748 | | Key derivation | HKDF-SHA256 | RFC 5869 | | Nonce generation | Cryptographically secure random | Platform CSPRNG | | Key storage | iOS Keychain / Android Keystore | Platform-native hardware-backed | | Group key wrapping | AES-256-GCM over ECDH-derived key | Composed from above | All cryptographic operations use platform-native libraries: - **iOS:** Apple CryptoKit framework - **Android:** Android security-crypto library We do not implement custom cryptographic algorithms. All primitives are industry-standard, peer-reviewed, and maintained by platform vendors. --- ## 10. Known Limitations and Threat Model We believe in honest security communication. Here is what our encryption does and does not protect against: **Protected against:** - Server-side data breaches (encrypted data is useless without device keys) - Unspkn employees reading your messages (we can't) - Legal requests for message content (we can only provide encrypted blobs) - Man-in-the-middle interception (ECDH key exchange + TLS transport) - Casual phone snooping (stealth mode with cipher themes and decoy personas) **NOT protected against:** - Physical access to an unlocked device (if someone has your unlocked phone, they can read your messages — this is true for all messaging apps) - Device compromise via malware or spyware (if your device is compromised at the OS level, encryption cannot help) - Screenshots taken by the recipient (we cannot prevent a conversation partner from capturing your messages) - Metadata analysis (timestamps, message frequency, and participant lists are visible on the server, though not linked to real identities) - Loss of encryption keys (if you lose your device without a keychain backup, messages cannot be recovered) **Reaction and status metadata:** Emoji reactions and read/delivery status are stored as metadata on message documents and are not encrypted. This is a deliberate trade-off for real-time UI responsiveness. Reactions reveal that a user interacted with a message, but do not reveal the message content itself. --- ## 11. Future Security Roadmap We are committed to continuously improving our security posture: - **Independent third-party security audit** of our encryption implementation - **Open-source publication** of our core encryption modules for community review - **Transparency reports** detailing any legal requests received and our responses - **Bug bounty program** to incentivize responsible disclosure of vulnerabilities - **Post-quantum cryptography** migration planning as quantum computing advances --- ## 12. Contact For security inquiries, vulnerability reports, or questions about this document: **Email:** security@unspkn.com **PGP Key:** [To be published] We take all security reports seriously and will respond within 48 hours. --- *This document describes the security architecture of Unspkn as of March 2026. It will be updated as our security practices evolve. The most current version is always available at unspkn.com/security.*