4. Security Considerations (セキュリティ上の考慮)

4. Security Considerations (セキュリティ上の考慮)

ChaCha20 暗号は 256 ビットのセキュリティを提供するよう設計されている。

Poly1305 認証器は, 2^64 件の正当なメッセージを送った後でも, 長さ 16n バイトのメッセージに対して偽造メッセージが 1-(n/(2^102)) の確率で拒否されるよう設計されており, [AE] の用語では SUF-CMA (strong unforgeability against chosen-message attacks, 選択メッセージ攻撃に対する強い偽造不可能性) である。

これらいずれの安全性を証明することは本ドキュメントの範囲外である。そのような証明は引用されている学術論文 ([ChaCha], [Poly1305], [LatinDances], [LatinDances2], [Zhenqing2012]) で得られる。

本ドキュメントを実装する際の最も重要なセキュリティ上の考慮は, ChaCha20 で用いる nonce の一意性である。カウンタと LFSR (linear feedback shift register, 線形フィードバックシフトレジスタ) はどちらも一意な nonce を生成する許容される方法であり, DES のような 64 ビットブロックサイズのブロック暗号でカウンタを暗号化する方法も同様である。128 ビットまたは 256 ビットブロックのブロック暗号で暗号化したカウンタの切り捨てを用いることは許容されない。なぜならそのような切り捨ては短時間で繰り返し得るからである。

nonce を繰り返した場合の帰結: nonce が繰り返されると, ワンタイム Poly1305 鍵とキーストリームの両方がメッセージ間で同一になる。平文の XOR が暴露される。なぜなら平文の XOR は暗号文の XOR に等しいからである。

Poly1305 鍵は攻撃者にとって予測不能でなければならない。鍵をランダムに生成すればこの要件を満たすが, Poly1305 は通信プロトコルでよく用いられるため, 受信者も鍵を知っている必要がある。カウンタを暗号化するなどの擬似乱数生成は許容される。秘密鍵と nonce を用いた ChaCha の使用も許容される。

ここに示すアルゴリズムは, サイドチャネル脆弱性を避けるため定数時間で実装しやすいよう設計されている。ChaCha20 で用いる演算はすべて加算, XOR, 固定 roll である。これらはすべて, かつすべきとして, 定数時間で実装できる。ChaCha 状態へのオフセットへのアクセスと演算回数は鍵のいかなる性質にも依存しないため, キャッシュミスのタイミングを通じた鍵情報の漏えいの可能性は排除される。

Poly1305 では, 128 ビットを超える数に対する加算, 乗算, 剰余の演算である。これは定数時間で行えるが, 素朴な実装 (汎用の多倍長ライブラリを用いるなど) は定数時間にならない。例えば乗算を剰余演算から分離して行うと, 結果が 2^256 未満になる場合と超える場合がある。実装者はこれらの演算の適切な実装を用いて, Poly1305 のタイミング・サイドチャネルに注意すべきである。

メッセージの真正性の検証は, 計算したタグと受信したタグのビット単位の比較を伴う。多くの利用場面では, 正当なメッセージを受信するまで nonce と AAD の内容は "消費" されない。これにより攻撃者は, タグ比較に通るまで異なるタグを付けた同一メッセージを複数送れる。攻撃者が 2^128 通りのタグをすべて順に試さなければならない場合は困難である。しかしタグ比較のタイミングが, 計算タグと受信タグの一致するプレフィックスの長さを漏らす場合, 必要なメッセージ数は大幅に減る。したがってオンラインプロトコルでは, 実装は memcmp() のような最適化されているが安全でないライブラリ関数に頼るのではなく, 定数時間比較関数を用いなければならない。

さらに, 本アルゴリズムを用いるプロトコルは, 偽造の機会を最小化するために完全なタグを含めなければならない。タグの切り捨てはしてはならない。