Unspkn Security Whitepaper

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

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 style-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 style 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).

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.

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 Styles

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 style-themed decoy text instead of the encrypted payload. Depending on the selected style, 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 style engine transforms the plaintext into themed output (for visual styles) 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.

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.

9. Cryptographic Primitives Summary

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:

• 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 styles and decoy personas)

• 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.app

We take all security reports seriously and will respond within 48 hours.