6/01/2017

多分、SHA-3はスキップする

Googleのアダム・ラングレイのブログより。

2005年と2006年に、一連の重要な結果がSHA-1 [1][2][3]に対して公開された。これらの繰り返された突破口は暗号学者が我々はそもそもハッシュ関数を作る方法を知っているのかどうかという疑問を呈し、ちょっとした信用の危機を引き起こした。結局のところ、1990年代の多くのハッシュ関数はまだ古くなっていなかった。

これを受けて、NISTはSHA-2の危険性を回避するため、SHA-3を開発するコンテストを発表した(PDF)。2012年に、Keccak (ケチャックと発音する、と思う)が勝ち(PDF)、SHA-3になった。しかし、コンテスト自身はハッシュ関数を構築する方法を知っていることを証明した: 2005年の一連の結果はSHA-2にまで及ばなかったし、SHA-3の過程は多くのハッシュ関数を生み出し、それら全てが分かる範囲で安全である。従って、それが存在する時まで、SHA-3が必要であることはもはや明らかではなかった。しかし、SHA-3はその数がより大きため、SHA-2よりも優れていなければならないと想定する自然な傾向がある。

前述したように、暗号プリミティブの多様性は費用が掛かる。これはテストと強化が必要となる組み合わせの数が指数関数的になる。複数プラットフォームは通常、別々の最適化されたコードが必要となるため、限られた開発者リソースを利用する。そして、モバイル時代には再びコードサイズが心配となる。SHA-3は更に処理が遅く、すでに暗号プリミティブの中で比較すると遅くなっているSHA-2よりも更に遅い。

SHA-3は有用なもの、SHAKEアルゴリズムの形式での拡張可能な出力関数(XOFs)も取り入れている。XOFでは、入力がハッシュ化され、その後、(実質的に)無制限の量の出力が生成される。これは便利だが、HKDFを使用した限られた量の出力に対して、あるいはChaCha20やAES-CTRを実行してキーをハッシュ化することで、同じ効果が得られる。

従って、私はSHA-3はおそらく使用されるべきではないと思う。SHA-2と比較して魅力的な利点はなく、多くのコストが掛かる。私が信じることができる唯一の根拠は、バックアップのハッシュ関数を持つのはいいことだが、SHA-256やSHA-512の両方が一般的にサポートされており、異なるコアを持っている。従って、すでに2つの安全なハッシュ関数がデプロイされており、私は別のハッシュ関数が必要だと思わない。

BLAKE2はもう一つの新しい安全なハッシュ関数だが、少なくともSHA-2よりもスピードがかなり改善されている。スピードが重要である。暗号化に要するCPU時間が短く済むだけでなく、暗号化を以前にはできなかった場所で経済的にデプロイできる。しかし、BLAKE2はバージョンが多過ぎる。現在の数は8である(BLAKE2(X)?[sb](p)?)。スピードに関する不満に応じて、Keccakチームは現在、KangarooTwelveとMarsupilamiFourteenを持ち、より優れたパフォーマンスにベクトルベースの設計を用いている(ベクトルベースの設計はSHA-2の高速化に使うことはできるが)。

そして、SHA-2の将来、より高速な置き換えのためのいくつかの興味深い可能性がある。しかし、SHA-3自体にそれらは一つもない。

Hacker News 12Cryptologie