Arc Protocol

1. Designprinzipien

2. Kryptographische Grundlage

Arc uses libsignal-client v0.65.2 (Rust, via FFI) — the same library used by Signal Messenger — for core protocol operations.

3. PQXDH: Hybrider Schlüsselaustausch

Quantencomputer, die X25519 brechen können, könnten in 10-15 Jahren existieren. "Jetzt ernten, später entschlüsseln"-Angriffe bedeuten, dass heute erfasste verschlüsselte Daten in Zukunft entschlüsselt werden könnten. Arc begegnet dem durch die Kombination von klassischem X25519 mit Post-Quanten ML-KEM-1024 — derselbe Ansatz, den Signal im September 2023 eingeführt hat.

Alice → Bob:
1. Fetch Bob's PreKey Bundle (Identity + Signed PreKey + One-Time PreKey + PQ PreKey)
2. 4× X25519 DH computations
3. ML-KEM-1024.Encaps(Bob's PQ Public Key) → (pq_ciphertext, pq_shared_secret)
4. Root Key = HKDF-SHA256(DH1‖DH2‖DH3‖DH4‖pq_shared_secret)
5. Send: Alice's keys + PQ ciphertext (1,088 bytes) + encrypted message

Ein Angreifer muss sowohl X25519 als auch ML-KEM-1024 brechen, um den Schlüsselaustausch zu kompromittieren.

4. Double Ratchet: Vorwärtsgeheimnis

Nach der Sitzungseinrichtung über PQXDH verwenden alle nachfolgenden Nachrichten den Double-Ratchet-Algorithmus, der Vorwärtsgeheimnis und Einbruchswiederherstellung bietet.

DH Ratchet (direction change):
  New Root Key = HKDF-SHA256(current_root_key, X25519_DH_output)

Symmetric Ratchet (per-message):
  Message Key  = HMAC-SHA256(chain_key, 0x01)
  Next Chain   = HMAC-SHA256(chain_key, 0x02)

Every message uses a unique, independently derived key. Chain keys are immediately deleted after deriving the next key. Maximum 1,000 skipped message keys cached per session.

5. AES-256-GCM: Nachrichtenverschlüsselung

Jede Nachricht wird mit einem einzigartigen Message Key aus dem Double Ratchet mittels AES-256-GCM authentifizierter Verschlüsselung verschlüsselt.

Ciphertext = AES-256-GCM.Encrypt(
  key:   message_key (32 bytes),
  nonce: random (12 bytes, never reused),
  aad:   ratchet_public_key ‖ prev_chain_length ‖ message_number,
  plaintext: message content
)

Per-message overhead: nonce (12B) + auth tag (16B) = 28 bytes

6. AEGIS: Nachrichtenauthentifizierung

XEdDSA Signing (via libsignal):
  payload   = senderId ‖ "|" ‖ timestamp ‖ "|" ‖ content
  signature = XEdDSA.Sign(payload, X25519_private_key)
  → 64 bytes attached to message
  (Converts X25519 key to Ed25519 internally — no separate Ed25519 key needed)

Verification:
  XEdDSA.Verify(payload, signature, sender_X25519_public_key)
  → verified | failed | noSignature

7. Sealed Sender: Absender-Anonymität

Sealed Sender verhindert, dass der Server weiß, wer eine Nachricht gesendet hat. Signals Implementierung verwendet ein Absenderzertifikat und Zustellungs-Token. Arc verwendet einen einfacheren ephemeren X25519-ECDH-Umschlag ohne serverseitige Token-Validierung.

Sender:
1. Generate ephemeral X25519 keypair
2. DH = X25519(ephemeral_private, recipient_identity_public)
3. AES_Key = HKDF-SHA256(DH, info="Arc Sealed Sender v1")
4. Envelope = AES-256-GCM(senderId + "\0" + payload, AES_Key)

→ Sealed Message = ephemeral_pub(32B) ‖ nonce(12B) ‖ ciphertext ‖ mac(16B)

Available for 1:1 chats where both participants have the Intelligence plan.

8. Gruppenverschlüsselung: Sender Keys

Arc verwendet den Sender-Key-Mechanismus des Signal-Protokolls für effiziente Gruppenverschlüsselung.

Encryption (libsignal group_encrypt):
  Chain Key → Message Key → AES-256-GCM  (libsignal internal)
  HMAC signature                          (libsignal internal)
  → Output: SenderKeyMessage bytes

Decryption (libsignal group_decrypt):
  Signature verify → Replay detect → Decrypt (libsignal internal)

All crypto operations delegated to libsignal — no custom primitives.

9. Schlüsselverwaltung

Private keys are stored in iOS Keychain / Android EncryptedSharedPreferences. Never in Hive, SharedPreferences, plain files, or cloud storage.

10. Key Sync: Multi-Gerät

Arc uses independent key sets per device (no primary/linked hierarchy). To decrypt messages from the original device on a new device, users scan a QR code containing an ephemeral X25519 public key. Both devices perform ECDH, derive an AES-256-GCM key via HKDF, and securely transfer identity keys. Session TTL: 5 minutes.

11. BLE Mesh: Offline-E2EE

Arcs BLE-Mesh-Netzwerk ermöglicht E2EE-Kommunikation ohne Internet — einzigartig unter den großen Messengern.

12. Bedrohungsmodell

13. Standardkonformität

14. Vergleich mit Signal & WhatsApp

15. Fazit

Das Arc-Protokoll baut auf dem bewährten Signal-Protokoll auf und erweitert es um drei proprietäre Sicherheitsschichten:

Wir begrüßen Sicherheitsforschung und verantwortungsvolle Offenlegung.