Arc / SECURITY

Arquitectura E2EE multicapa

Un producto de seguridad comercial con una dirección técnica publicada

ILLUSTRATED 1:1 FLOW · 10-SECOND PREVIEW

Encrypted here.Opened there.

A message between people. Private keys stay on the devices; servers carry ciphertext and delivery data.

  1. 01
    Encrypt on device

    The message is encrypted before it leaves.

  2. 02
    Transport ciphertext

    Firestore carries ciphertext and delivery data.

  3. 03
    Open on device

    The recipient’s device decrypts the message.

FunctionsExpiry & notifications
FCMPush notification

Concept animation of one delivery path, not a recording of the app. Other paths, server-visible metadata and exceptions are documented below.

ARCHITECTURE

Arc system architecture

Explore the system diagram

Private keys are stored in the device Keychain / Keystore and never sent to servers. Messages to other people are encrypted on the device before they are sent. Phoenix hands out public PreKeys, Firestore carries ciphertext, receipts and delivery data, and Cloud Functions handle expiry deletion and notifications. Mesh bypasses servers.

One role at a time.

Open full-size diagram

Devices (iOS / Android / macOS)

Arc Protocol

1:1 · libsignal v0.96.2 · Rust FFI

  • PQXDH
  • Kyber-1024
  • Double Ratchet
Private keys
Keychain / Keystore
Decrypted text
SQLite / Hive

Message text and private keys never go to servers (except AI chats, link previews)

Explore the message flows

The dots move in the numbered order. On each of these paths, message text is encrypted on the device before it is sent.

Follow one path at a time.

Open full-size diagram
1:1 message. Post-quantum. First time: fetch B's keys. Encrypt on the device. Send ciphertext only. Notify (no content). Decrypt on B's device. Read / decrypt receipts. Only A's and B's devices can read the text

Post-quantum

1:1 message

  1. First time: fetch B's keys
  2. Encrypt on the device
  3. Send ciphertext only
  4. Notify (no content)
  5. Decrypt on B's device
  6. Read / decrypt receipts

Only A's and B's devices can read the text

On smaller screens, scroll within the diagram. Open the original using the link above.

1:1 is post-quantum (PQXDH). Group messages are not (shared key + X25519 ECIES). On Mesh, nearby Arc phones may forward the ciphertext without being able to read it. Routed relay is in development.

Arc Protocol — 1:1 encryption pipeline

Phase 1

PQXDH

Key agreement with X25519 + Kyber-1024 (post-quantum)

Phase 2

Double Ratchet

A new key for every message

Phase 3

AES-256-GCM

Encrypts message bodies and media

Technology stack

Flutter 3.47
Dart
Riverpod 2.6
Rust
Arc Protocol

App

Flutter 3.47 / Riverpod 2.6 / Rust FFI (libsignal v0.96.2)

Elixir
Phoenix
Cloud Run

Key distribution API

Elixir / Phoenix on Google Cloud Run (europe-west1)

Authentication
Firestore
Storage
Functions
Messaging
App Check
Crashlytics

Delivery and auth

Firebase (Auth / Firestore / Storage / Functions / FCM / App Check / Crashlytics)

Android
Kotlin
Swift

Mesh

BLE implementation (Dart + Android Kotlin + iOS Swift, in-house, beta)

Arc Protocol v1.0 Cryptographic State Machine

Arc Security & BLE Mesh Interactive State Machine

Strict verification of Post-Quantum PQXDH, Sealed Sender, offline BLE Mesh Store-and-Forward, and Cryptographic Message Retirement.

Wire Frame Hierarchy (Click to inspect)
Cryptographic Field Inspector
ML-KEM-1024 + X25519 Hybrid

Implements hybrid key agreement combining NIST FIPS 203 ML-KEM-1024 lattice cryptography with classical X25519 for 1:1 chats, countering 'Harvest Now, Decrypt Later' quantum threats.

• Security Category: NIST Level 5 (Highest)
• Fail-Closed: Rejects classical-only downgrade
• KDF: HKDF-SHA256 (Dual-Entropy Extraction)

Technical specifications

The four encryption layers

Arc core specification

Arc's core specification is ML-KEM-1024/PQXDH, E2EE for 1:1 and group chats, IGF, and offline Mesh. This Security page documents the scope and technical details.

01

Intercambio de claves PQXDH

Un producto de seguridad comercial con una dirección técnica publicada

02

Double Ratchet

Un producto de seguridad comercial con una dirección técnica publicada

03

Cifrado AES-256-GCM

Un producto de seguridad comercial con una dirección técnica publicada

04

Firmas XEdDSA (libsignal)

Un producto de seguridad comercial con una dirección técnica publicada

Parámetros ML-KEM-1024

POST-QUANTUM

Mecanismo de encapsulación de claves post-cuántico estandarizado NIST FIPS 203.

AlgoritmoML-KEM-1024 (via libsignal-client)
Nivel de seguridad NISTSecurity category 5
Seguridad clásica2^128 bit (X25519)
Seguridad cuánticaNIST security category 5
FundamentoModule Lattice (FIPS 203)
Tamaño de clave pública1,568 bytes
Tamaño de clave secreta3,168 bytes
Tamaño del texto cifrado1,568 bytes

DefenseTech Runtime Hardening (Passkey, Zero-Knowledge Key Backup, Zeroization & Secret Mode)

PASSKEY × ZK BACKUP

Passkey (WebAuthn) × Zero-Knowledge Key Backup

Phishing-resistant Passkey (WebAuthn) authentication and biometric unlock. Zero-Knowledge Key Backup (PBKDF2-HMAC-SHA256 600,000 iterations + HKDF-SHA256 + AES-256-GCM AAD owner binding) integrates ML-KEM-1024 (Kyber) TOFU pin state with monotonic merge protection for quantum-resistant key continuity across devices. Stateless WebAuthn Challenges enforce Fail-Closed HMAC verification and a strict 300-second TTL ceiling.

FAIL-CLOSED MEDIA & ZEROIZATION

Fail-Closed E2EE Media Engine & Immediate Memory Zeroization

Enforces Fail-Closed E2EE (XChaCha20-Poly1305 / AES-256-GCM) across all voice, image, PDF, and video attachments with zero plaintext fallback. Upon playback completion, widget disposal, or reload, decryption keys, nonces, and decrypted buffers are immediately zeroized in memory via fillRange(0, len, 0).

0MS SECRET MODE SEAL

Secret Mode Instant Shield (0ms Release Seal & OS Switcher Protection)

Seals content in 0ms the instant the finger is released (zero transition afterimage) and automatically shields the screen on iOS/Android App Switcher, screen recording, and background lifecycle transitions (AppLifecycleState.inactive / paused / hidden).

O(1) IGF CLOCK

O(1) IgfCountdownClock Consolidation (Zero-Jank 1Hz Architecture)

Consolidates all chat and group IGF (auto-vanish countdown) and Mutual Burn timers into a single unified 1Hz clock (IgfCountdownClock), delivering O(1) power efficiency and zero UI jank regardless of message volume.

SOVEREIGN BLE MESH

Sovereign BLE Engine Arc-Protocol-Mesh (L2CAP CoC & Zero Location Permission)

Powered by Atlas Associates' sovereign Arc-Protocol-Mesh v1.0.4 engine with zero third-party mesh SDKs. Combines BLE L2CAP Connection-Oriented Channels (primary) + GATT fallback, 1:1 stateless 2-DH X25519 ECIES (arcms1:) with in-person QR hard-pinning, group AES-256-GCM + Ed25519 certificates (arcmg1:), and a 32,768-entry (frameId, fragIndex) multi-hop dedup ring—requiring zero location permission on iOS and Android 12+.

Cumplimiento y estándares

NIST CSF 2.0

Marco NIST. 6 funciones para gestión sistemática de ciber-riesgos.

NIST SP 800-53

Controles de seguridad federales. Base de FedRAMP.

FIPS 140-3

Un producto de seguridad comercial con una dirección técnica publicada

NIST SP 800-175B

Guía de selección de algoritmos criptográficos. Basado en FIPS 203.

ISO/IEC 27001

Certificación SGSI internacional. Base de confianza B2B/B2G.

GDPR

Reglamento General de Protección de Datos de la UE. Estándar de protección más alto del mundo.

UK Cyber Essentials+

Certificación de ciberseguridad certificada por el gobierno del Reino Unido.

NCSC Cloud Security

14 Principios del NCSC del Reino Unido. Estándar de evaluación de seguridad en la nube.

Diseñado tomando como referencia las guías publicadas por el NIST de EE. UU., el GDPR de la UE, el NCSC del Reino Unido e ISO. No es una certificación ni una auditoría de terceros.