Double Ratchetアルゴリズム (英語 : Double Ratchet Algorithm )は、Trevor Perrinとモクシー・マーリンスパイク (英語版 ) が2013年に考案した鍵 管理アルゴリズムである。初回の鍵共有 (英語版 ) 後の短期セッション鍵の更新と管理の手順を規定する。インスタントメッセージング でエンドツーエンド暗号化 を実現する暗号プロトコル (英語版 ) の一部として使用できる。ディフィー・ヘルマン鍵共有 および、ハッシュ関数 などの鍵導出関数 をもとにした「ラチェット」(英語 : ratchet )と呼ばれる機構から構成されるため、二重ラチェット (Double Ratchet)という名称が付いている。以前はAxolotl Ratchet と呼ばれていた[ 1] [ 2] 。
Double Ratchetアルゴリズムは、一定の条件下で通信当事者の鍵が危殆化した場合に未来の通信が攻撃者に解読されるのを防ぐため、自己修復的(self-healing)である[ 3] 。セッション鍵は数回の通信のたびに更新され、一度傍受 されていない鍵共有が起きると攻撃者はそれ以降の通信へのアクセスを失うことになるため、攻撃者はすべての通信を傍受する必要がある。この暗号プロトコルの機能はのちに後方秘匿性 (英語 : future secrecy )またはpost-compromise security と呼ばれるようになった[ 4] 。
通信当事者は、通信相手と対話できる場合はディフィー・ヘルマン(DH)ラチェットを使って、対話できない場合はハッシュラチェットを使って単独でセッション鍵マテリアルを更新する。各ハッシュラチェットは、それぞれDHラチェットから導出した共通の秘密の値でシードされる。メッセージを送受信するたびに、2つのハッシュラチェット(送信用と受信用)のどちらかが1段階進められる。また、可能であれば常にDHラチェットの前進と新しい公開DH値の通信相手への通知を試み、相手から新しいDH値を受け取った場合はDHラチェットを1段階進める。新しい共通の秘密の値が確立されると、ハッシュラチェットが初期化される。
Double Ratchetアルゴリズムは、暗号プリミティブ に以下を使用する。
DHラチェット
楕円曲線ディフィー・ヘルマン鍵共有 (Curve25519 )
メッセージ認証コード
HMAC -SHA256
対称鍵暗号
AES (CBC 、PKCS #5およびCTR 、パディングなし)
ハッシュラチェット
HMAC [ 5]
以下は、Double Ratchetアルゴリズムまたはその独自実装を採用するアプリケーションの一覧である。
^ “Compare Revisions ”. GitHub (2016年3月30日). 2016年4月9日閲覧。
^ “Signal on the outside, Signal on the inside ”. Open Whisper Systems (2016年3月30日). 2016年3月31日閲覧。
^ Marlinspike, Moxie (2013年11月26日). “Advanced cryptographic ratcheting ”. whispersystems.org . Open Whisper Systems. 2021年1月20日閲覧。 “The OTR style ratchet has the nice property of being 'self healing.'”
^ Cohn-Gordon, K.; Cremers, C.; Garratt, L. (2016). “On Post-compromise Security” . 2016 IEEE 29th Computer Security Foundations Symposium (CSF) : 164–178. doi :10.1109/CSF.2016.19 . ISBN 978-1-5090-2607-4 . https://ora.ox.ac.uk/objects/uuid:241da365-1c73-4b6a-826c-f122c4c1e1b8 .
^ Frosch et al. 2014 .
^ “Security ”. Cryptocat. 2016年4月7日時点のオリジナル よりアーカイブ。2016年7月14日閲覧。
^ “You Can All Finally Encrypt Facebook Messenger, So Do It ”. Wired . Condé Nast (2016年10月4日). 2016年10月5日閲覧。
^ Seals, Tara (2015年9月17日). “G DATA Adds Encryption for Secure Mobile Chat ”. Infosecurity Magazine . Reed Exhibitions Ltd.. 2016年1月16日閲覧。
^ “SecureChat ”. GitHub . G Data. 2016年7月14日閲覧。
^ Amadeo, Ron (2021年6月16日). “Google enables end-to-end encryption for Android's default SMS/RCS app ” (英語). Ars Technica . 2022年3月3日閲覧。
^ Perez, Sarah (2023年8月8日). “Google's Messages app will now use RCS by default and encrypt group chats ” (英語). TechCrunch . 2025年3月22日閲覧。
^ “Haven Attributions ”. GitHub . Guardian Project. 2017年12月22日閲覧。
^ “Snowden's New App Uses Your Smartphone To Physically Guard Your Laptop ”. The Intercept . First Look Media (2017年12月22日). 2017年12月22日閲覧。
^ Langley, Adam (2013年11月9日). “Wire in new ratchet system ”. GitHub . 2016年1月16日閲覧。
^ Butcher, Mike (2016年9月19日). “Riot wants to be like Slack, but with the flexibility of an underlying open source platform ”. TechCrunch . AOL Inc.. 2016年9月20日閲覧。
^ “Silent Circle/libzina ”. GitHub . Silent Circle. 2017年12月19日閲覧。
^ “Signal partners with Microsoft to bring end-to-end encryption to Skype ”. Open Whisper Systems (2018年1月11日). 2018年1月11日閲覧。
^ “Viber Encryption Overview ”. Viber (2018年7月25日). 2018年10月26日閲覧。
^ “Forget Apple vs. the FBI: WhatsApp Just Switched on Encryption for a Billion People ”. Wired . Condé Nast (2016年4月5日). 2016年4月5日閲覧。
^ “Wire Security Whitepaper ”. Wire Swiss GmbH (2018年8月17日). 2020年8月28日閲覧。
Cohn-Gordon, Katriel; Cremers, Cas; Dowling, Benjamin; Garratt, Luke; Stebila, Douglas (2016年). "A Formal Security Analysis of the Signal Messaging Protocol" (PDF) . Cryptology ePrint Archive (英語). International Association for Cryptologic Research (IACR).
Frosch, Tilman; Mainka, Christian; Bader, Christoph; Bergsma, Florian; Schwenk, Jörg; Holz, Thorsten (2014年). "How Secure is TextSecure?" (PDF) . Cryptology ePrint Archive (英語). International Association for Cryptologic Research (IACR).
Unger, Nik; Dechand, Sergej; Bonneau, Joseph; Fahl, Sascha; Perl, Henning; Goldberg, Ian Avrum; Smith, Matthew (2015年). SoK: Secure Messaging (PDF) . Proceedings of the 2015 IEEE Symposium on Security and Privacy (英語). IEEE Computer Society's Technical Committee on Security and Privacy. pp. 232–249. doi :10.1109/SP.2015.22 。