Arc Protocol

1. Design Principles

2. Cryptographic Foundation

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

3. PQXDH: Hybrid Key Exchange

Quantum computers capable of breaking X25519 may exist within 10-15 years. "Harvest now, decrypt later" attacks mean encrypted data captured today could be decrypted in the future. Arc addresses this by combining classical X25519 with post-quantum ML-KEM-1024, the same approach pioneered by Signal in September 2023.

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

An attacker must break both X25519 and ML-KEM-1024 to compromise the key exchange.

4. Double Ratchet: Forward Secrecy

After session establishment via PQXDH, all subsequent messages use the Double Ratchet algorithm, providing forward secrecy (compromise of a current key cannot decrypt past messages) and break-in recovery (compromise is automatically healed after a few messages).

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: Message Encryption

Each message is encrypted with a unique Message Key from the Double Ratchet using AES-256-GCM authenticated encryption.

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: Message Authentication

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: Sender Anonymity

Sealed Sender prevents the server from knowing who sent a message. Signal's implementation uses a sender certificate and delivery token system. Arc uses a simpler ephemeral X25519 ECDH envelope without server-side token validation.

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. Group Encryption: Sender Keys

Arc uses Signal Protocol's Sender Key mechanism for efficient group encryption. Each member generates a personal Sender Key, distributed via encrypted 1:1 channels. Messages are encrypted once (not N times for N members).

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. Key Management

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

10. Key Sync: Multi-Device

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

Arc's BLE Mesh Network enables encrypted offline communication via Bridgefy SDK transport encryption — unique among major messengers. The BLE range limitation (10-30m) provides an additional physical security layer, making Signal Protocol unnecessary for this use case. Ideal for natural disasters, remote areas, and privacy-critical environments.

12. Threat Model

13. Standards Compliance

14. Comparison with Signal & WhatsApp

15. Conclusion

Arc Protocol builds on the proven Signal Protocol foundation and extends it with three proprietary security layers:

We welcome security research and responsible disclosure from the community.