Panic Mode

Cryptographic self-destruct. Irreversible by design.

What Panic Mode Does

Panic mode is RVNT's emergency data destruction system. When activated, it performs a multi-stage cryptographic wipe that destroys all sensitive data on the device. After panic mode completes, a forensic examiner will find an application with no data -- no messages, no contacts, no keys, no history. The cryptographic material required to reconstruct any of this data no longer exists on any device, anywhere.

Activation Methods

Panic mode can be triggered through multiple methods, depending on configuration:

Destruction Sequence

Panic mode executes the following stages in order. Each stage is designed to be as fast as possible while being thorough enough to resist forensic recovery.

Stage 1: Secure Enclave Key Invalidation (~100ms)

Platform: Apple Silicon (macOS/iOS)
  1. Delete all Keychain items tagged with RVNT service identifier
  2. Invalidate Secure Enclave private keys:
     - SecKeyDelete(identityKey)
     - SecKeyDelete(storageKey)
     - SecKeyDelete(biometricKey)
  3. The Secure Enclave permanently destroys the key material
  4. This is HARDWARE-LEVEL destruction -- the keys cannot be
     recovered even with physical access to the chip

Platform: Android (StrongBox/TEE)
  1. KeyStore.deleteEntry(identityKey)
  2. KeyStore.deleteEntry(storageKey)
  3. Hardware-backed keys are invalidated in the TEE

Platform: Desktop (without hardware security module)
  1. Delete all credential store entries
  2. Overwrite key files with random data
  3. (Less secure than hardware-backed destruction)

Stage 2: SQLCipher Database Destruction (~500ms-2s)

1. Open database with current key (if available)
2. Execute: PRAGMA secure_delete = ON;
3. Execute: DELETE FROM messages;
4. Execute: DELETE FROM contacts;
5. Execute: DELETE FROM sessions;       // Ratchet state
6. Execute: DELETE FROM prekeys;
7. Execute: DELETE FROM skipped_keys;
8. Execute: VACUUM;                     // Reclaim space, overwrite deleted pages
9. Close database
10. Three-pass overwrite of database file:
    Pass 1: Write 0x00 (all zeros)
    Pass 2: Write 0xFF (all ones)
    Pass 3: Write cryptographic random bytes
11. fsync() to flush to disk
12. Delete the file
13. fsync() parent directory

Stage 3: DoD 5220.22-M Overwrite of Key Material (~200ms)

Files targeted:
  - Identity key files
  - Session state files
  - Prekey storage
  - Any temporary key material
  - Salt files

For each file:
  Pass 1: Overwrite with 0x00 (all zeros)
  Pass 2: Overwrite with 0xFF (all ones)
  Pass 3: Overwrite with cryptographic random data
  Verification: Read back and verify each pass
  fsync() after each pass
  Delete file
  fsync() parent directory

DoD 5220.22-M is a US Department of Defense standard for media
sanitization. While modern SSDs may retain data in wear-leveling
blocks, the combination of Secure Enclave invalidation + database
VACUUM + file overwrite makes recovery extremely difficult.

Stage 4: Keychain / Credential Store Wipe (~100ms)

Delete all Keychain/credential store entries:
  - Database encryption key
  - Argon2id salt
  - Biometric access keys
  - Push notification tokens
  - Tor circuit credentials
  - Any stored session tokens

Each entry is individually deleted using platform APIs:
  macOS/iOS:  SecItemDelete(query)
  Android:    KeyStore.deleteEntry(alias)
  Linux:      Secret Service API delete
  Windows:    Credential Manager delete

Stage 5: Media Cache Wipe (~500ms-5s)

1. Enumerate all files in RVNT media cache directory
2. For each file:
   a. Overwrite with random data (single pass, speed priority)
   b. Delete file
3. Enumerate all thumbnail cache files
4. Overwrite and delete each
5. Clear any system-level caches:
   - URLCache (iOS/macOS)
   - WebView cache (if applicable)
   - Temporary directory
6. fsync() all parent directories

Stage 6: State Reset (~100ms)

1. Reset application to first-launch state
2. If duress mode:
   a. Load decoy database (if configured)
   b. Present decoy conversation list
   c. App appears normal to observer
3. If explicit panic:
   a. Present clean first-launch screen
   b. "Welcome to RVNT" setup flow

What Is Recoverable After Panic Mode

SSD Considerations

Modern solid-state drives use wear leveling and garbage collection, which means overwritten data may persist in unmapped blocks. RVNT's defense against this is layered:

1. Encryption key destruction: Even if ciphertext persists on SSD, the decryption key is gone (Secure Enclave). The ciphertext is useless.
2. File overwrite: The operating system's write path goes through the FTL (Flash Translation Layer). The overwritten data replaces the logical sector mapping.
3. TRIM: RVNT issues TRIM/discard hints to the SSD after deletion, which allows the drive to garbage-collect the physical blocks.

Remote Wipe

Remote wipe command format:
  {
    "action": "panic",
    "timestamp": 1712745600,
    "device_id": "target_device_public_key_hash",
    "signature": "Ed25519_signature_of_above_fields"
  }

The command must be signed by a pre-authorized key (configured
during setup). The signature is verified before execution.
An unsigned or incorrectly signed command is silently dropped.

Delivery methods:
  1. Push notification (APNs/FCM) -- fastest, requires network
  2. Peer-to-peer via mesh -- works without internet
  3. Webhook endpoint -- for integration with external systems

Dead Man's Switch

Configuration:
  Interval:    24h / 48h / 72h / 7d / 30d (user-configurable)
  Check-in:    Open the app and authenticate with real PIN
  Failure:     Panic mode activates automatically

Implementation:
  - Timer stored in Secure Enclave (tamper-resistant)
  - Timer runs even if app is not open (background scheduled task)
  - Check-in resets the timer to full interval
  - Duress PIN does NOT count as a check-in (it triggers panic)
  - If device is powered off for longer than the interval,
    panic mode triggers on next boot

Further Reading

• PIN & Duress Mode -- PIN system and duress PIN configuration
• Threat Model -- Physical device seizure analysis