「ECC+PQ」vs「PQ単独」—バグが決めるセキュリティの明暗
Bugs happen: The easy way to compare solo PQ to ECC+PQ
cr.yp.toのブログで、Daniel J. Bernstein氏が、ECCベースのプロトコルをECC+PQにアップグレードするのと、PQ単独に切り替えるのとではどちらが良いかを、最もシンプルな観点から論じています。それは「ソフトウェアにはバグがつきものであり、PQソフトウェアにも脆弱性が頻発する」という事実です。ECC+PQなら、ECC層がバグによる被害を軽減する一方、PQ単独ではその保険がありません。さらに、ECCのコストはPQに比べれば無視できるほど安く、ECCを捨てる言い訳はないと主張します。具体的には、ML-DSAやML-KEMの実装で過去に起きたバグやタイミングリーク（KyberSlashなど）を例に挙げ、PQソフトウェアの品質がまだ低いと指摘。solo PQ推進派の主張を反駁し、ECC+PQの優位性を明確にしています。
「PQソフトウェアにはしばしば欠陥があり、その一部は悪用可能です。ECC+PQの一部としてECCを維持することで、単独PQを使うよりも、そうした脆弱性による被害を軽減できます。」
- Retr0id
以前はハイブリッド方式に賛成だったが、最近はどちらかと言うと賛否両論だ。ECCソフトウェアにも欠陥はあり得るが、例えば2つの異なるECC実装をハイブリッド化することを真剣に提案する人はいないと思う。
- rot256
その主張には賛成しない。この種のものは十分に単純で、正式に検証し、非常に注意深く監査できる。さらに、NISTは先見の明があって全てのアルゴリズムを非ランダム化したので、例えば正しい実装が特定のシードで何を生成するかを確認できる。これは大きな意味がある。なぜなら、偏ったナンスや再利用されたナンスなどのECDSAのバグの多くが、そのようなテストや非ランダム化で簡単に検出されるからだ。要するに、バグは他の場所にあるだろう。
- libeclipse
なぜハイブリッドRSAとECCを使わないのか？ あるいはハイブリッドAESとChaCha20は？ ソフトウェアのバグは新しいハイブリッド標準の弱い論拠であり、追加の複雑さを正当化するものではない。