Arc Protocol

1. 設計原則

2. 暗号基盤

ArcはSignal Messengerと同じライブラリであるlibsignal-client v0.65.2（Rust、FFI経由）をコアプロトコル操作に使用しています。

3. PQXDH: ハイブリッド鍵交換

X25519を破る量子コンピュータは10〜15年以内に出現する可能性があります。「今傍受して後で解読する」攻撃は、今日キャプチャされた暗号化データが将来解読される可能性を意味します。Arcは古典的なX25519とポスト量子ML-KEM-1024を組み合わせることで対処しています。これはSignalが2023年9月に先駆けたアプローチと同じです。

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

攻撃者が鍵交換を破るには、X25519とML-KEM-1024の両方を突破する必要があります。

4. Double Ratchet: 前方秘匿性

PQXDHによるセッション確立後、すべてのメッセージはDouble Ratchetアルゴリズムを使用します。前方秘匿性（現在の鍵が漏洩しても過去のメッセージを復号できない）と侵入回復（漏洩は数メッセージ後に自動的に修復される）を提供します。

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)

各メッセージは固有の独立した派生鍵を使用します。チェーン鍵は次の鍵を派生した直後に削除されます。セッションごとに最大1,000個のスキップされたメッセージ鍵をキャッシュ。

5. AES-256-GCM: メッセージ暗号化

各メッセージはDouble Ratchetから派生した固有のMessage Keyを使用し、AES-256-GCM認証付き暗号化で暗号化されます。

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: メッセージ認証

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: 送信者匿名性

Sealed Senderはサーバーがメッセージの送信者を知ることを防ぎます。Signalの実装は送信者証明書とデリバリートークンシステムを使用します。Arcはサーバー側のトークン検証なしに、よりシンプルなエフェメラルX25519 ECDHエンベロープを使用します。

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)

Intelligenceプランの両者による1:1チャットで利用可能。

8. グループ暗号化: Sender Keys

ArcはSignal ProtocolのSender Keyメカニズムを使用して効率的なグループ暗号化を実現します。各メンバーが個人のSender Keyを生成し、暗号化された1:1チャネル経由で配布します。メッセージは1回だけ暗号化されます（N人のメンバーに対してN回ではなく）。

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. 鍵管理

秘密鍵はiOS Keychain / Android EncryptedSharedPreferencesに保存されます。Hive、SharedPreferences、プレーンファイル、クラウドストレージには決して保存されません。

10. Key Sync: マルチデバイス

Arcはデバイスごとに独立した鍵セットを使用します（プライマリ/リンクの階層なし）。新しいデバイスで元のデバイスのメッセージを復号するには、エフェメラルX25519公開鍵を含むQRコードをスキャンします。両デバイスがECDHを実行し、HKDFでAES-256-GCM鍵を派生して安全にID鍵を転送します。セッションTTL: 5分。

11. BLE Mesh: オフラインE2EE

ArcのBLE Meshネットワークは、Bridgefy SDKトランスポート暗号化によりインターネットなしでも安全な通信を可能にします — 主要メッセンジャーの中で唯一の機能です。BLE距離制限（10-30m）が物理的なセキュリティレイヤーとして機能し、Signal Protocolはこのユースケースでは不要です。自然災害、遠隔地、プライバシーが重要な環境に最適です。

12. 脅威モデル

13. 標準準拠

14. Signal・WhatsAppとの比較

15. 結論

Arc Protocolは実績あるSignal Protocolを基盤とし、3つの独自セキュリティレイヤーで拡張しています：

セキュリティ研究および責任ある脆弱性報告を歓迎します。