- Signalは Sparse Post Quantum Ratchet（SPQR、疎なポスト量子ラチェット） を導入し、Signalプロトコルの安全性を大幅に向上させるとともに、将来の量子コンピューティングの脅威に対する耐性を強化しながら、既存の Forward Secrecy（FS） と Post-Compromise Security（PCS） の保証も維持
- Signalプロトコル は、世界中で数十億人が日々やり取りするプライベートな通信に エンドツーエンド暗号化を提供する暗号学的仕様群 であり、2013年の発表以降、Signalアプリだけでなく他の主要なメッセージング製品でも採用
- 以前に発表された PQXDH は、チャットセッションの設定時に量子耐性のある暗号化秘密を統合することで harvest-now-decrypt-later 攻撃から保護したが、SPQRは会話が続く中で侵害の影響を最小化し回復する FSとPCSの保証を量子安全な方法 で実現
- SPQRはSignalの既存の Double Ratchet と組み合わされ、Triple Ratchet と呼ばれる構成を形成し、ユーザー体験を変えることなく、すべての会話が自動的に新プロトコルへ移行して現在と将来の通信の両方を保護
- 学術研究（Eurocrypt 25、USENIX 25 論文）、erasure code ベースのチャンク化、形式検証（ProVerif、hax/F*）を通じて、プロトコルの正しさとセキュリティ特性を機械的に検証し、CIパイプラインで変更のたびに再検証して、開発プロセスの動的な一部として維持
概要
- Signalは Sparse Post Quantum Ratchet（SPQR） の導入により、Signal Protocolの安全性を一段引き上げた
- SPQRは既存の強力な安全性を土台に、将来の量子コンピューティングの脅威へ対応し、前方秘匿性（Forward Secrecy、FS） と 侵害後の回復性（Post-Compromise Security、PCS） の保証構造をさらに強化する
- ユーザーが変化を感じないほど自然にシステム全体へ適用され、量子コンピュータが実現しても会話内容が安全に保護される環境を確保
既存のSignal Protocolの状況
- Signal Protocolは日常的に使われる エンドツーエンド暗号化 メッセージング標準である
- 既存プロトコル内のダブルラチェット構造は、ハッシュ関数（量子安全）によって前方秘匿性を、楕円曲線Diffie-Hellman（ECDH） によって侵害後の回復性を実現してきた
- ECDHは現在は高い安全性を持つが、将来的には量子コンピュータによって脆弱になるおそれがある
- ラチェットとは、会話の途中ごとに新しい秘密鍵を生成し、過去または将来のメッセージ内容の露出を防ぐ技術である
- AliceとBobは定期的に新しいECDH秘密情報に合意し、セッションを更新する
量子安全要素を混合する必要性
- 量子コンピュータは、ECDHのような従来の非対称暗号方式を無力化できる可能性がある
- これに備え、最初の導入方式であるPQXDHでは、セッション開始時に量子安全な秘密情報を混合した
- 会話中にも継続的に、量子安全アルゴリズムベースの Key Encapsulation Mechanism（KEM） による鍵交換の必要性が高まった
- KEMはDiffie-Hellmanのように共有秘密を生成するが、順序付けられた非対称メッセージ の交換を必要とする
- ML-KEMのような標準化されたKEMを活用して、セッション中に連続的な量子安全秘密を生成する
状態機械と帯域幅の最適化
- KEM方式は鍵交換データのサイズが大きいため（約1000バイト）、通信帯域幅の最適化 が重要な課題となる
- 状態機械（State Machine）のロジックを活用し、AliceとBobがどのデータ（Encapsulation Key、Ciphertext など）をいつやり取りするかを管理する
- データのチャンク化 と 消去符号（Erasure Codes） の活用により、大きなデータを小さな断片に分割し、メッセージ損失や欠落時にも復旧しやすく保つ
- 攻撃者が鍵交換チャンクだけを選択的にドロップしてプロトコル停止を引き起こすことも難しいよう設計されている
- これにより、メッセージ損失、再順序化、遅延など、実際のモバイル環境を効果的に処理できるようになった
効率と安全性のトレードオフおよび最適化
- 共有秘密（Shared Secret）の生成速度を無条件に速くすると、かえってある時点のすべての秘密情報が攻撃時に露出する危険がある
- Signalは多数の状態機械シミュレーションを実行し、並列転送と直列転送の間で安全性と効率の均衡点を見いだした
- ML-KEMの詳細な過程の分析や チャンクの分割・同時送信 などにより、帯域幅の利用効率を最大化した
- この過程をML-KEM Braidと名付け、自社プロトコルの1モジュールとして活用している
Triple Ratchet 構造
- Double Ratchet（既存） と SPQR（新規、量子安全） を同時に動作させ、鍵を結合してハイブリッド方式の暗号鍵を生成する
- Triple Ratchet 方式では、2つのアルゴリズムの両方が破られた場合にのみメッセージ露出の危険が生じるため、安全性が飛躍的に向上する
- 実際の実装では、Double RatchetとSPQRそれぞれから暗号鍵を受け取り、鍵導出関数でさらに結合して利用する
- Triple Ratchet構造は、過去と将来のメッセージに対して量子安全性と従来の安全性の両方を保証する
段階的導入と互換性への対応
- アップグレードが段階的に適用されるため、SPQR未対応ユーザーとの互換性問題が生じる可能性がある
- 初期メッセージのネゴシエーション過程では一時的なダウングレードを許容し、両ユーザーが相互に互換性のある方式で通信できるよう設計されている
- メッセージにSPQRデータを添付する際は認証コードで保護され、攻撃者によるダウングレード強制を防ぐ
- いったん双方が互換性ネゴシエーションを完了すると、その後はセッション全体でSPQRの使用決定が固定される
- すべてのユーザーがSPQR対応バージョンへアップグレードされた後は、旧セッションを保管または終了し、新セッションから完全にSPQRを適用する予定である
プロトコルの安全性検証と検証ツール
- プロトコル設計段階から 学術研究者、PQShield、AIST、NYU などと活発に協力してきた
- Eurocrypt 25、USENIX 25 などの学会論文を通じて、プロトコルが理論上、量子安全性と従来の保証要件を満たすことを証明した
- 提案された6種類のポスト量子ラチェットプロトコルのうち、SPQRとKatana（KEM活用の新規プロトコル）が生き残った
- 形式検証（Formal Verification） はCryspen、ProVerif、hax、F* などのツールとCIパイプラインで常時自動化管理されている
- Rust実装と検証モデルの同期により、設計と実コードの一致性を保証する
- 実装過程では不変条件（assertion）もコードに積極的に導入し、エラー発生時にはアプリが停止することで潜在的脆弱性を未然に防ぐ
検証と継続的開発の並行
- 形式検証手順は一度きりの作業ではなく、コードベースに変更があるたび自動で繰り返し実行される
- 新しいコードのマージ時に検証が失敗すれば、ビルドも不可能になる
- 実際の経験上、境界値エラーや事前条件・事後条件を明確に管理するだけでも、保守性が高まり、プロトコルの完成度も最大化できる
要約結論
- Signalは信頼性の高い Triple Ratchet（Double Ratchet + SPQR）構造を導入し、すべてのメッセージに量子耐性のあるセキュリティ を提供することを目指す
- プロトコル移行は段階的に進められ、サービス中断やユーザーの不便なく実施される予定である
- 追加のデータ転送量は最小限で、モバイル環境におけるコスト負担はほとんどない
- プロトコルは、攻撃者が改ざんしようとするとサービス拒否状態を引き起こさなければならないため、中間者（MITM）攻撃にも強い
- コードと設計は体系的に形式検証され、今後も継続して安全性を維持する
- Signalユーザーの立場からは、プロトコルの変化や量子コンピュータの脅威を意識することなく保護される環境が保証される見込みである
1件のコメント
Hacker Newsの意見
Signalは本当に優れた暗号化論文を出し続けているのに、製品面では何が成功するのかわからず手当たり次第に試しているように感じる。ポスト量子ハンドシェイク、ストーリー、送金など新しい試みをしている一方で、SDK、API、ボット対応は依然として存在しない。公式ライブラリも未完成で、ドキュメントもない。機能の多くがいまだにクライアントの中に隠れている。プロトコル仕様は公開しているが、それで自分でライブラリを作れというのは、実際の製品運用のやり方とかけ離れた無責任な態度だ。何百万人も使うプラットフォームなのに、この程度の基本が整っていない。WhatsAppやiMessageのようなアプリは開発者に何かしら開いているのに、Signalは開発者関連を徹底的に排除している雰囲気がある。プロダクト担当者がいないのではないかと思うほど、明確な戦略が見えない。長年のSignalユーザーで積極的に勧めてもきた立場からすると、Signalは派手な暗号技術を継ぎはぎした、Appleのエコシステム以上に開発者へ閉じたメッセンジャーに感じる。それでもプロダクトを作った人たちには感謝している
同感。特に「ストーリー」機能は、本当に何か当たるかとりあえず投げてみた感じが強かった。Signalはアナーキズム志向の非営利団体の出身なので、目標そのものが普通の会社とは違うのだと思う。アプリが本来の任務には忠実なのでそれでよいが、SDKがあれば本当にうれしい
APIやビジネスボットのような機能が本当に重要なのか気になる。WhatsAppやiMessageにはビジネス向けAPIがあるが、一般ユーザーとして実際にそれで企業とやり取りしたことはない。その代わり、たまにボットに煩わされる経験はあった。Signalで本当の問題なのは、アプリが静かに旧バージョンになったり更新が止まったりしても通知がなく、メッセージを完全に取りこぼす状況だ。メッセンジャーの核心的な使命なのに、それができていない
むしろAPIやボットがないことは、私にとっては長所だ
私はそういう機能なしで、今のように安全で実用的なメッセンジャーを作ることに集中してほしい
Signalで本当に腹が立つのは、発信者が聞く呼び出し音が、実際には受信者の電話で鳴っていなくても鳴る点だ。以前から意図的にこうしているとして擁護してきた公式方針だ。昔の潜水艦みたいな音をなくして以降、ずっとそうだ
Signalのプロトコル名がSPQRで驚いた。SPQRはラテン語で「Senatus Populusque Romanus」の略だ Wikipedia参照。すごくかっこいい
未来志向のプロトコル名にSPQRを使うのは、オジマンディアス(Ozymandias)っぽさがある
とても巧妙なネーミングだ。BBCのミニシリーズ『Rome』でローマ軍団兵の入れ墨としてよく出てきたのでよく知っている RomeのWikipedia
Strength and Honor（強さと名誉）
こういうユーモアはHacker Newsでしか見られないと思う。昔の「数学者が自分のロッカー番号を覚える方法」を扱った漫画を思い出す。（「1975? それは3,900,625の平方根だよ!」）
もしかすると単に「SPQR」が「Speaker」みたいに聞こえるから、チャットアプリに合うのでそう名付けたのでは？ 何でもローマと結びつける必要はない
Signalの最大の弱点は、電話番号で身元を区別する方式だ。ハッカーだけでなく権威主義的な政府の立場でも、いつでも電話番号を乗っ取れる。未来の脅威を考えるのも重要だが、優先順位が違う
まだ知らない人がいるかもしれないので共有する: Signalでユーザー名により電話番号を非公開にする機能の紹介（2024年2月）
多くのセキュアメッセンジャーは電話番号なしでも動作し、メタデータまで消し込みながらサービスを提供している。電話番号とSIMカードが個人に結び付く国では、Signalの方式は参入障壁だ
電話番号の要求はスパム防止の面があるので、簡単でなおかつ信頼できる方法だ
電話番号で本人確認すること自体が致命的な問題だとは感じない。権威主義的な政府が番号を乗っ取っても、メッセージ履歴まで得られるわけではない。通知を受けたユーザーはすでに警告を受けることになる。Signalが問題のない存在だというわけではなく、批判と基準提示は必ず必要だが、それでもなお一般人が使える唯一の完全なエンドツーエンド暗号化とメタデータ保護を備えたメッセンジャーだ。より強いセキュリティ・プライバシーを持つサービスもあるが、私の祖母でも使えるという点が本当に重要だ。Signalはセキュリティは十分固めたので、次はプライバシーに集中してほしい。批判しつつも、今でも強く勧めているし、友人たちにも積極的に勧めている。寄付も何度もした Signalの透明性レポート参照
Signalには「登録ロック」という機能があり、パスワードを設定すればSIM乗っ取りによるアカウント奪取を防げる
Signalが今回SPQR（量子耐性ラチェット）を適用したことで、iMessageのPQ3と比べてどの位置にあるのか気になる。CyphやSimplexによる過去の量子耐性メッセージングの試みについての考察も聞いてみたい。 iMessage PQ3の紹介 / Cyph - Post-Quantum Castle / Simplex - 量子耐性機能
SignalのSPQRはPQ3と同様にML-KEMベースのラチェット構造だが、鍵の伝送方式が異なる。ML-KEMの鍵長が大きいため、PQ3は鍵をたまにだけ定期送信し、Signalはメッセージと一緒に分割して送る方式だ。隠れた帯域やセキュリティの観点では、このchunkingのほうがむしろ安全かつ効率的だという判断だ。誤り訂正符号のため全体帯域は増えるかもしれないが、各メッセージのサイズは一定になる。Appleはネットワーク制御権がより強いので、積極的な再鍵交換防御はやりやすいはずだ
iMessageが実際に今の環境で意味があるのか疑問だ。というのも、ほとんどのiPhoneユーザーはiCloudバックアップをE2Eなしで使っており、完全暗号化バックアップは任意オプションだからだ。つまり法執行機関から要請が来ればAppleが復号できるので、量子コンピュータを待たなくてもすでに十分脆弱だ
SPQR（Sparse Post-Quantum Ratchet）という名前を見て、Signalチームにローマ史オタクがいるのではと思った
みんなローマ帝国のことをどれくらいの頻度で考えるんだろう？
もしかすると、チャットアプリに最適な単語「Speaker」の変奏として名付けたのかもしれない
Signalの最大の弱点は電話番号ベースの本人認証だ。ハッカーだけでなく権威主義的な政府にも、いつでも番号の所有権を奪われる危険がある。未来の脅威もよいが、優先順位を見直すべきだ
Signalがメッセージ伝送基盤、つまり「トランスポートバス」になってほしい。たとえば特定の連絡先（妻など）に自分の位置情報を安全に要求したり渡したりできれば、Googleを通さずに済む。本人確認はすでに解決しているのだから、今度はSignal上でアプリを作ることを後押しすべきだと思う。2FAもSignalでやればSMSより安全だと思う
現代のSignal ProtocolとMatrix、MLSのようなものとの比較もぜひ見たい。急速に進化していて追いかけにくいので、現時点での関係図が知りたい
Matrixはオープンスタンダードで、Olm+Megolm（ダブルラチェット+グループ鍵ラチェット）の組み合わせを使い、メタデータはサーバーに見える構造だ（グループ構造のサーバー露出、属性値の平文保存などで、改善作業中: Elementブログ - ルームメタデータ暗号化計画）。分散構造なので誰でもサーバーを立てられる。
最後にMLS（RFC 9420）はグループメンバーシップ・鍵交換プロトコルで、ダブルラチェットの代替になり得て、最近はPQ適用の提案もある。性能はグループあたり O(log N) で効率的だ。まだ成熟しておらず、ダブルラチェットに比べて複雑だ。普及は遅めだが、IETF標準としてGoogleはRCS、Discord/WebexのVoIPなどで導入している。メタデータ隠蔽や暗号学的否認性（deniability）は提供しない
この記事は、私が見た暗号関連の記事の中でも最高水準にうまく書かれている。暗号についてある程度は理解しているつもりだが、似たテーマの他の記事では途中で本当に目が疲れたのに、今回はまったく馴染みのない話題でも流れを完全に追えた
量子暗号の脅威に詳しい人が、今のSignalの最新プロトコルでどう安全性が高まったのかをわかりやすく説明してくれないだろうか。読んでも、なぜより安全になったのか正確にはわからない。実際に体感できる速度低下があるのかも気になる
簡単に言えば、味方の敵が「今は解読できないが、いつか量子コンピュータが実現したら、将来、現在集めている暗号文をまとめて解読する」というのが標準的な脅威シナリオだ。いわゆる「Harvest and decrypt」モデルだ。Signalで今の秘密を長く保持したい、あるいは今後も安全に守りたいなら、今日からPQ鍵合意が必要になる。だからPQXDHのような新しいプロトコルが必要なのだ。
PQラチェットが重要なのは、攻撃者が長期的に暗号文を収集するだけでなく、将来デバイスのハッキングや特定実装の欠陥による鍵漏えいが起こり得るという非常に現実的な脅威があるからだ。Forward secrecyとpost-compromise securityという二重の防御が必要になる。瞬間ごとに鍵を継続的に更新すれば、一度攻撃にさらされても過去のメッセージや未来のメッセージまで危険にはならない。この防御を量子暗号環境でも正しく機能させるには、ラチェット全体の構造までPQで完成させなければならない。そうしないと攻撃者はラチェット部分だけを狙えばよくなり、すべての安全性が崩れる
既存のSignalの耐量子暗号実装にはPCS（侵害後セキュリティ）がなかった。今回はそれが提供される。やっとPCSの意味がわかってよかった。新しい概念かと期待したが、OTR（Off-the-Record）プロトコルでもすでに使われていた方式だという点は少し拍子抜けした。この鍵交換は頻繁に起こるものではないので、実際の性能低下はほとんどない
公式ブログ要約:
Sono pazzi, questi Romani（ローマ人は本当におかしい）