Security Architecture & Technical Documentation
Version 1.0 - February 2026
Reserved is a luxury anonymous messaging platform built with privacy and security as foundational principles. This document outlines the technical security architecture, encryption implementation, and privacy-preserving design decisions that ensure user communications remain confidential and ephemeral.
1.1 Core Security Principles
• End-to-End Encryption: All messages encrypted on sender device, decrypted only on recipient device
• Zero-Knowledge Architecture: Server cannot access message plaintext
• Ephemeral by Design: Automatic 24-hour message deletion
• Anonymous Authentication: No personal identifiers collected or stored
• Minimal Data Collection: Only what's essential for functionality
1.2 Technology Stack
• Platform: iOS 15+ (Swift/SwiftUI)
• Encryption: iOS CryptoKit (AES-256-GCM)
• Backend: Firebase Realtime Database (Google Cloud Platform)
• Authentication: Firebase Anonymous Authentication
• Transport: HTTPS/TLS 1.3
2.1 Encryption Algorithm
Reserved implements AES-256-GCM (Galois/Counter Mode) authenticated encryption through Apple's CryptoKit framework. This provides:
• 256-bit symmetric encryption (industry standard)
• Authentication tag for message integrity verification
• Protection against tampering and replay attacks
• NIST-approved cryptographic standard (FIPS 140-2 compliant)
2.2 Key Derivation
Encryption keys are derived from room codes using HKDF (HMAC-based Key Derivation Function) with SHA-256:
• Input: Room code (e.g., "MONACO")
• Salt: Application-specific constant
• Output: 256-bit symmetric key
• Deterministic: Same room code always generates same key
This ensures all users with the same room code can encrypt and decrypt messages without key exchange, while maintaining cryptographic strength.
2.3 Encryption Process
Message Sending:
1. User composes message in plaintext
2. App derives encryption key from current room code
3. Message encrypted using AES-256-GCM with random nonce
4. Ciphertext + nonce + authentication tag encoded to Base64
5. Encrypted payload transmitted to Firebase
Message Receiving:
1. Encrypted payload retrieved from Firebase
2. Base64 decoded to extract ciphertext, nonce, and tag
3. App derives decryption key from current room code
4. Message decrypted and authenticated
5. Plaintext displayed to user (if authentication succeeds)
2.4 What Cannot Be Decrypted
Without the correct room code, encrypted messages are cryptographically secure:
• Firebase administrators: Cannot decrypt (no access to room keys)
• App developers: Cannot decrypt (keys never leave user devices)
• Network observers: Cannot decrypt (see only ciphertext over TLS)
• Law enforcement: Cannot decrypt without room code from participants
3.1 Authentication Architecture
Reserved uses Firebase Anonymous Authentication, which generates a unique identifier without requiring any personal information:
• No email, phone number, or username required
• UID generated locally on device
• UID persists across app sessions (unless app is deleted)
• Multiple devices = multiple independent UIDs
3.2 Screen Name System
Screen names are chosen by users without verification:
• Not unique: Multiple users can use the same screen name
• Not verified: No identity validation
• Not linked to authentication: UID and screen name separate
• Stored locally: Screen name saved only on user's device
4.1 What Is Stored
In Firebase Realtime Database:
• Encrypted message ciphertext (Base64-encoded)
• Screen name (plaintext, user-chosen)
• Timestamp (Unix epoch)
On User Device:
• User's chosen screen name
• Anonymous authentication UID
• Known room codes (local only)
4.2 What Is NOT Stored
• Message plaintext (encrypted before transmission)
• Encryption keys (derived on-demand, never persisted)
• IP addresses or location data
• Device identifiers or advertising IDs
• Email addresses, phone numbers, or real names
• Usage analytics or tracking data
4.3 Automatic Deletion
All messages automatically expire after 24 hours:
• Deletion performed by Firebase timestamp-based rules
• No user action required
• No recovery mechanism exists
• Neither users nor administrators can restore deleted messages
5.1 Transport Layer Security
All data transmission uses industry-standard encryption:
• TLS 1.3 (latest protocol version)
• HTTPS for all API communications
• Certificate pinning enforced by iOS
• Protection against man-in-the-middle attacks
5.2 Firebase Security Rules
Database access controlled by Firebase Security Rules:
• Read/write requires valid authentication token
• Unauthenticated requests rejected
• External access (outside app) prevented
• Data validation enforced server-side
6.1 Protected Against
✓ Network eavesdropping (TLS encryption)
✓ Server-side data breaches (messages stored encrypted)
✓ Database administrator access (zero-knowledge encryption)
✓ Message tampering (authenticated encryption)
✓ Replay attacks (nonce-based encryption)
✓ Long-term message retention (automatic 24-hour deletion)
6.2 Known Limitations
✗ Device compromise (malware can access plaintext on infected device)
✗ Screenshot/screen recording (iOS limitation, cannot be prevented)
✗ Room code compromise (anyone with code can read messages)
✗ Physical device access (if device unlocked, messages visible)
✗ Forward secrecy (past messages readable if room code later compromised)
While Reserved implements strong security measures, users must also practice security hygiene:
• Protect room codes (treat like passwords)
• Use device passcode/biometric lock
• Keep iOS updated with latest security patches
• Only share room codes with trusted individuals
• Be aware that screenshots/photos can be taken of messages
For security-related concerns or to report vulnerabilities, please contact:
Email: info@reservedvip.com