Security Architecture & Cryptographic White Paper
The formal technical foundation of Sync Superapp: zero-knowledge verification, non-custodial key hierarchies, and coercion defense under the Fortress Principle.
Abstract
Sync Superapp ("Sync") is a privacy-first, non-custodial communication and encrypted state platform engineered under the Fortress Principle: zero-knowledge, zero-trust, and complete client cryptographic sovereignty. This paper details the cryptographic architecture, threat models, protocol specifications, and operational controls of Sync. Sync combines X25519 ECDH key exchange, AES-256-GCM and ChaCha20-Poly1305 authenticated symmetric encryption, Argon2id memory-hard key derivation (m=64MiB, t=2, p=4), and Ed25519 digital signatures. It introduces Obsidian Core for zero-knowledge multi-device key escrow, GhostWire for volatile in-memory ephemeral transit, and Protocol Zero for emergency duress PIN-activated cryptographic shredding.
1. System Philosophy: The Fortress Principle
Mainstream modern superapps bundle messaging, social graphs, financial payments, and productivity tools under a monolithic, custodial umbrella. This introduces structural vulnerabilities: centralized data aggregation, mandatory phone numbers that facilitate SIM swapping and surveillance, and cloud chat storage with server-held decryption keys.
Sync operates under the Fortress Principle:
- Server Blindness (Mode 2 E2EE): In end-to-end encrypted conversations, the backend functions strictly as an untrusted ciphertext relay and blind mailbox. The server does not possess the cryptographic keys needed to inspect or decrypt message payloads or vault backups.
- Client Sovereignty: Private identity keys and vault passphrases are generated on client devices. On mobile, keys reside in platform hardware-backed secure storage (iOS Keychain, Android Keystore); on web, session and E2EE keys reside in browser local storage. Keys leave devices solely as master-key encrypted ciphertext for multi-device vault recovery.
- Cryptographic Provenance: All cryptographic operations rely on established, peer-reviewed primitives implemented via audited native libraries (
libsodium,ring,argon2, andcryptography_flutter). - Zero Mandated Identifiers: Users can register pseudonymously without linking a phone number or revealing their email address to peers.
2. Formal Threat Model & Security Boundaries
In alignment with the Privacy Guides evaluation framework, Sync explicitly defines its adversary boundaries:
- Server Database Compromise: Leaked SQL dumps contain only opaque ciphertext payloads in Mode 2 and salted Argon2id hashes.
- Network Eavesdropping & ISP Surveillance: TLS 1.3 transport plus independent AES-256-GCM payload encryption for Mode 2 messaging.
- Cloud Storage Snooping: Object storage holds media with opaque sealed storage keys (
msk1...); server message rows never persist plaintext media URLs. - Physical Coercion & Device Inspection: Protocol Zero secondary Duress PIN triggers an atomic local wipe sequence (
ShredderService), purging databases and resetting to a clean fresh-install state.
- Endpoint OS Compromise: Kernel-level rootkits or Pegasus-style spyware capturing keystrokes or screen buffers before encryption.
- Traffic Timing Analysis: An adversary monitoring TCP/IP traffic can observe packet timing, packet sizes, and public endpoints.
- Unverified Public Keys: Protection against an active MITM server substituting public keys requires out-of-band fingerprint verification.
- Total Passphrase Loss: Sync is non-custodial. Losing both device keys and the recovery phrase results in permanent data loss.
3. Cryptographic Primitives
| Function | Primitive | Standard / Parameters | Purpose |
|---|---|---|---|
| Key Exchange | X25519 | RFC 7748 / Curve25519 ECDH | Peer-to-peer session key agreement (Mode 2) |
| Mobile E2EE Messaging | AES-256-GCM | NIST SP 800-38D (256-bit key, 96-bit nonce) | Client-to-client encrypted chat messages on mobile |
| Master Vault Encryption | ChaCha20-Poly1305 | RFC 8439 (AEAD, 256-bit key, 96-bit nonce) | Wrapping E2EE private keys for cloud sync |
| Ephemeral Messaging | XChaCha20-Poly1305 | Extended 192-bit nonce AEAD | GhostWire ephemeral packet encryption |
| Key Derivation | Argon2id | RFC 9106 (m=64MiB, t=2, p=4) | Vault master key derivation from PIN |
| Key Expansion | HKDF-SHA256 | RFC 5869 | Deriving message and media keys |
| Signatures | Ed25519 | RFC 8032 | Identity verification and delta sync signing |
4. Core Architectural Protocols
4.1 End-to-End Encrypted Messaging (Mode 2)
In Mode 2, messaging is end-to-end encrypted on the client device:
- Sender fetches the recipient's published X25519 public key.
- Sender derives a shared secret S = ECDH(PrivKey_A, PubKey_B).
- Sender generates a 12-byte cryptographically secure random nonce.
- Sender encrypts the payload using AES-256-GCM.
- The server stores and forwards the opaque ciphertext without possessing the decryption key.
- Recipient decrypts the payload locally using ECDH(PrivKey_B, PubKey_A) and persists it in sandboxed local SQLite storage.
4.2 Obsidian Core: Zero-Knowledge Multi-Device Vault
Obsidian Core resolves the dilemma of multi-device synchronization without custodial key compromise. When a user creates a vault, a 256-bit Master Vault Key is derived via Argon2id (m=64MiB, t=2, p=4). The E2EE private key is encrypted with this master key and escrowed on the server. A new device entering the Master PIN can derive the master key and recover the E2EE private key without the server ever seeing the plaintext key.
4.3 Protocol Zero: Emergency Duress Shredding
When subjected to physical coercion, entering a secondary Duress PIN triggers an atomic wipe sequence (ShredderService). The application immediately tears down database connections, overwrites and deletes local SQLite database files, purges platform Secure Storage entries, and returns the app to a clean, unauthenticated login interface (identical to a fresh installation), providing vital plausible deniability.
4.4 GhostWire: Volatile In-Memory Transit
For ultra-sensitive sessions, GhostWire bypasses persistent database storage completely. Messages are encrypted client-side with XChaCha20-Poly1305 and queued in an in-memory Redis cluster (with memory DashMap fallback), defaulting to a 24-hour TTL and purged immediately upon recipient acknowledgment.
5. Audit Status & Responsible Disclosure
In compliance with industry security transparency standards:
Architecture Verification: The cryptographic specifications, primitive selections, and protocol flows detailed in this white paper reflect the production implementation of Sync Superapp.
External Audit Status: Formal third-party cryptographic audits are currently in the Request for Proposal (RFP) stage. Audit reports and findings will be published openly upon completion.
Vulnerability Reporting: We operate a responsible disclosure policy. Researchers may contact our security team at security@syncsuperapp.com.