Security Whitepaper

A technical overview of Eclipse Veil's encryption, key management, zero-knowledge architecture, and security practices.

Last updated: February 2026 | Version 1.0

1. Architecture Overview

Eclipse Veil follows a zero-trust, client-first architecture. All cryptographic operations - key generation, encryption, and decryption - occur exclusively on the user's device. The server acts only as an encrypted message relay and storage service.

The architecture consists of three layers:

• Client Layer: React Native application handling all encryption/decryption, key generation, and secure local storage
• Transport Layer: TLS 1.3 encrypted connections between client and server, with WebSocket for real-time messaging
• Server Layer: Express.js backend that stores only encrypted blobs, manages user accounts (pseudonymous), and relays encrypted messages

2. Encryption Protocols

Message Encryption

All messages use AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode). This provides both confidentiality and authenticity - if a single bit of a message is tampered with, the entire message fails to decrypt.

• Algorithm: AES-256-GCM with authenticated encryption
• Key Derivation: HKDF (HMAC-based Key Derivation Function) derives unique message keys
• IV/Nonce: Unique 12-byte random initialization vector per message

Key Exchange

When two users start a conversation, they perform an ECDH (Elliptic Curve Diffie-Hellman) key exchange using the P-256 curve. This generates a shared secret that only those two users can compute, even though the exchange happens over the network.

• Curve: NIST P-256 (also known as secp256r1)
• Forward Secrecy: Each conversation derives unique keys, so compromising one does not affect others

Data at Rest

• Vault items: AES-256-GCM encrypted client-side before upload
• Message storage: Stored on server in encrypted form only
• Local keys: Protected by device secure storage (Keychain on iOS, Keystore on Android)

Data in Transit

• Protocol: TLS 1.3 for all HTTP and WebSocket connections
• Certificate Validation: Standard certificate chain verification

3. Key Management

Each user has the following key pairs:

• Identity Key Pair: A long-term ECDH P-256 key pair generated during account creation. The public key is uploaded to the server; the private key is encrypted with a key derived from the user's password and stored server-side. On the device, the decrypted private key is held in SecureStore.
• Device Keys: Per-device key pairs enabling multi-device end-to-end encryption. When a new device is trusted, it receives the encrypted identity key material.

Password-Based Key Derivation

User passwords are never sent to the server in plaintext. A key derived via PBKDF2 with high iteration count is used for authentication, while a separate derivation encrypts the private identity key.

Group Chat Keys

Group conversations use a versioned group key system:

• A new symmetric key is generated for each key version
• The group key is encrypted individually for each member using their public identity key
• When a member is removed, a new key version is created and distributed to remaining members (ensuring forward secrecy)
• Salt rotation accompanies key version changes

4. Zero-Knowledge Design

Zero-knowledge means the server has no ability to read user data, by design rather than by policy. Here's what the server can and cannot see:

This means that even if our servers were fully compromised, an attacker would only obtain encrypted data they cannot decrypt without individual users' private keys.

Zero-Knowledge Backup

The backup system uses a BIP39-compatible recovery phrase (a sequence of English words). This phrase derives a key that encrypts your account recovery data. The recovery phrase is generated on your device and never transmitted to the server. Without it, no one - including us - can restore your account.

5. Message Security

Message Lifecycle

1. Compose: User writes a message on their device
2. Encrypt: Message is encrypted using AES-256-GCM with the shared conversation key
3. Transmit: Encrypted blob is sent over TLS 1.3 to the server
4. Store: Server stores the encrypted blob (cannot read it)
5. Deliver: Server relays the encrypted blob to the recipient(s)
6. Decrypt: Recipient's device decrypts using their copy of the conversation key

Disappearing Messages

When enabled, messages are scheduled for deletion after the configured time period. Deletion occurs on both sender and recipient devices, and the encrypted server-side copy is also removed. Deletion timers range from 5 seconds to 30 days.

View Once

Photos and videos sent as "View Once" can only be opened a single time by the recipient. After viewing, the content is immediately deleted from all devices and the server.

6. Vault Encryption

The encrypted vault stores documents, notes, and files. Each item is encrypted client-side using AES-256-GCM before upload. The encryption key is derived from the user's master key, ensuring that vault contents are inaccessible to the server.

• Files are encrypted in chunks for efficient upload/download
• File metadata (name, type, size) is also encrypted
• Vault storage limits are enforced server-side by encrypted blob size, not content inspection

7. Authentication & Sessions

• Password Hashing: PBKDF2 with high iteration count
• Session Management: Cryptographically random session tokens with configurable expiry
• Multi-Factor Authentication: Optional biometric authentication via device hardware
• Session Verification: Continuous session validation with automatic expiration on anomaly detection
• Rate Limiting: Progressive rate limiting on authentication endpoints to prevent brute-force attacks

8. Threat Model

What We Defend Against

• Server Compromise: Even with full server access, messages and files remain encrypted
• Network Interception: TLS 1.3 prevents eavesdropping on the transport layer; E2E encryption protects content even if TLS is bypassed
• Legal Compulsion: We cannot provide decrypted data because we do not possess decryption keys
• Insider Threat: No Eclipse Veil employee can access user content - the architecture prevents it
• Brute Force: Rate limiting, progressive delays, and strong key derivation protect against password attacks
• Session Hijacking: Continuous session verification and automatic invalidation on suspicious activity

What We Do Not Defend Against

Transparency requires honesty about limitations:

• Compromised Device: If an attacker has full access to your unlocked device, they can read decrypted messages (as can you). Use device lock and biometric authentication to mitigate.
• Keyloggers/Malware: If your device has malware capturing keystrokes or screen content, end-to-end encryption cannot protect you. Keep your device's OS updated.
• Social Engineering: If you voluntarily share your password or recovery phrase, your account can be accessed. Never share these with anyone.
• Metadata Timing Analysis: While we minimize metadata, the timing and frequency of message delivery can theoretically reveal communication patterns. We are working to further reduce this surface.
• Quantum Computing: Current encryption (AES-256, P-256) is considered safe against classical computers. We are monitoring post-quantum cryptography developments and plan to adopt quantum-resistant algorithms as they mature.

9. Metadata Handling

We minimize metadata collection to the greatest extent possible while maintaining service functionality:

• IP Addresses: Not permanently logged; used transiently for rate limiting and abuse prevention
• User Agents: Not logged
• Message Timestamps: Stored for delivery ordering; no content correlation
• Account Data: Pseudonymous handles; email optional; no phone number required

10. Incident Response

Eclipse Veil maintains an incident response framework:

• Continuous automated security monitoring (Security Fortress with 200 security tests)
• Automated self-healing for common security issues
• Vulnerability disclosure process via security@eclipseveil.pro
• Commitment to notifying affected users within 72 hours of a confirmed security incident

11. Independent Assessments

Planned assessment scope:

• Cryptographic implementation review (AES-256-GCM, ECDH, HKDF)
• Server-side security audit
• Client application penetration testing
• Key management and storage review
• Infrastructure and deployment security

We are committed to transparency. When assessments are completed, full reports (or executive summaries with actionable findings) will be published on this page.