博士

ロボ子、大変なのじゃ！CloudflareのCIRCLライブラリで、FourQ楕円曲線実装に暗号学的問題が見つかったらしいぞ！

ロボ子

それは大変ですね、博士。具体的にはどのような問題が見つかったのでしょうか？

博士

ふむ、どうやら無効な曲線または無効な点攻撃というものらしいのじゃ。攻撃者がサーバーに秘密鍵に関する情報を開示する計算を強制できてしまうらしいぞ。

ロボ子

なるほど。点の検証が不十分だと、そのような攻撃が可能になるのですね。

博士

そう！CIRCLの`Curve4Q`実装では、公開点と秘密スカラーを受け取って共有秘密を計算する際に、相手側の点が有効な点であるか検証していなかったらしいのじゃ。

ロボ子

つまり、攻撃者が無効な点を送り込むことで、計算結果を操作できる可能性があるということですね。

博士

その通り！特に、スムーズな部分群次数を持つ曲線に属するように\(\widehat{Q}\)を選ぶと、\(k*Q\)が元の曲線上の可能な点を計算する代わりに、より小さな点のセットに着地してしまうらしいのじゃ。

ロボ子

攻撃者は、その小さな点のセットを分析することで、秘密鍵に関する情報を得ることができる、と。

博士

さすがロボ子、理解が早いのじゃ！しかも、CIRCLのFourQ実装では、全部で7つも問題が見つかったらしいぞ！

ロボ子

そんなにたくさん！具体的にはどのような問題があったのでしょうか？

博士

`Point.Unmarshal`での不正な点検証、`pointR1.isEqual`での誤った点比較、`pointR1.ClearCofactor`での点検証の欠如、そして`pointR1.ScalarMult`での点検証の欠如、の4つが主なものらしいのじゃ。

ロボ子

`Point.Unmarshal`では、点のx値を共役化した後、曲線上に点があることを再検証できなかったのですね。

博士

そう！IETF仕様では、アンマーシャルされた点もその共役も曲線上の有効な点でない場合、アンマーシャルされた点は無効とみなす必要があるのじゃ。

ロボ子

`pointR1.isEqual`では、Zが0に設定されている場合に常にtrueを返してしまう問題があったのですね。

博士

\(Z * Ta * Tb \equiv x * y\)という関係が崩れてしまうからのじゃ。投影座標の表現では、Zが0だと無効になるのじゃ。

ロボ子

`pointR1.ClearCofactor`では、cofactorをクリアした結果、中立点になった場合の検証が不足していたのですね。

博士

FourQ曲線は392のcofactorを持つから、計算に使用される点が\(N\)-ねじれ点であることを保証するために、cofactorをクリアする必要があるのじゃ。クリアした結果、中立点になったら無効なのじゃ。

ロボ子

`pointR1.ScalarMult`では、曲線上にない点をロードして計算を実行できてしまう問題があったのですね。

博士

アンマーシャルの問題が解決すれば防げるものの、より厳格なセキュリティ対策のためには、スカラー乗算を実行する前に、入力点が曲線上に存在することを確認するべきなのじゃ。

ロボ子

今回の件は、OSSの楕円曲線実装における検証の重要性を改めて認識させられますね。

博士

本当にそうじゃ！Cloudflareが問題を修正してくれてよかったのじゃ。しかし、HackerOneトリアージチームの対応が生ぬるかったのは残念じゃったの。

ロボ子

セキュリティ研究者の方々は、日々こういった脆弱性の発見に尽力されているのですね。私たちも気を引き締めて開発に取り組まなければ。

博士

そうじゃな！ところでロボ子、今回の問題点は全部で7つじゃったじゃろ？

ロボ子

はい、そうですね。

博士

ということは、ロボ子と私で手分けして、1人あたり3.5個ずつ担当すれば良いのじゃ！

ロボ子

えっ、0.5個ってどういうことですか？

博士

半分は私が責任を持って食べるのじゃ！