NIST、SHA-1 を 2030 年いっぱいで全廃する計画

headless 曰く、

米国立標準技術研究所 (NIST) は 15 日、限定的な場面で使われている SHA-1 アルゴリズムをより新しくセキュアなアルゴリズムに置き換えるよう IT プロフェッショナルに勧告すると発表した (ニュースリリース、 The Register の記事)。

SHA-1 は 2017 年に現実的な時間でハッシュの衝突を生成する方法が公開されるなど、十分な安全性が確保できないとして置き換えが進められている。NIST は今回、SHA-1 を 2030 年 12 月 31 日までに廃止すべきだと発表し、SHA-1 にセキュリティを依存するすべての人に対して可能な限り早く SHA-2 または SHA-3 へ移行することを推奨している。

NIST はこれに伴い、2030 年 12 月 31 日までに SHA-1 仕様を削除した FIPS 180-5 を発行し、SHA-1 廃止計画を反映するため SP 800 131A などの出版物を改訂、暗号モジュールとアルゴリズムを検証するための戦略を作成・発行する。これにより、2030 年以降は米連邦政府機関で SHA-1 を使用するモジュールの購入も禁じられることになる。

米連邦政府機関

[Anonymous Coward]

Gitは購入じゃないからいいんだもん!

Re:

[Anonymous Coward]

単なるハッシュだからね

SHA-3まだ?

[Anonymous Coward]

実装してみたけど使い所がないよ

2030年まで持つの？

[Anonymous Coward]

1995年初版、2017年衝突攻撃成功、2030年廃止。
既に時代遅れ感があること考えれば、かなり持ってるように思える。
そして過去スラドで話題になったけどZipCryptだって既知平文攻撃でもなくパスワードが多少長くて複雑なら解析は割に合わない程度の安全性はあるし、まぁ用途次第という感。

GitはなぜSHA-1なのかという自然な疑問は2017年の軽い記事 [zdnet.com]があるけど納得。
それでもSHA-256にしとけよと言いたくなるけど、単純にSHA-256は長いから識別用にサクッと使うなら「どうせ衝突しないし」というのは割と分かる。

以下チラシ裏。
個人的に「同一ファイルっぽいか軽く目で確認」って状況として使うが、CRC32/CRC64/SHA1/SHA256の中でしっくりくるのは…SHA256かなぁ(Windows版7zipのエクスプローラー拡張にあるから)。
並べるとSHA1は中途半端な印象。でもSHA1がしっくりくるって意見も絶対ある。
とはいえどうせ最初と最後数文字しか比較しないし、全部確認する気になるのはCRC32までだから実質無意味。
SHA拡張命令があって(今確認したら非対応CPU)軽いらしいと念の為CRC代わりに使ってるわけだがあんまり頭良い使い方ではない感は実際ある。
まぁISOファイルのダウンロード成功判断とかでは普通の用途に近いけど、それは一応中間者攻撃対策的な意味があるから実はそうでも…まぁなんでもいいわ。
書き込み済みベリファイ済みファイル削除時とかなら操作ミス怖さにファイルサイズ確認も使うけどそれよか確実だけど遅い。

Re:

[Anonymous Coward]

文字列が長いのに同意です。
ファイルが同じっぽいなーというときは
$ cat hoge | sha512sum | md5sum
とかやって、ハッシュのハッシュとって先頭とおしりの数文字見て比較してますｗ

ＶＰＮではまだトリプルＤＥＳ使ってます（恥

Re:

[Anonymous Coward]

同一ファイルっぽいか軽く目で確認

そういう用途にMD5使っているんですけど駄目なんですかね……

TOTPどうなる？

[Anonymous Coward]

secretは変えずハッシュ関数だけ変えればいいのだろうけど。新旧どちらの値も受け付ける移行期間を設けて、設定変更を促すのだろうか。

Re:TOTPどうなる？

[ogino (1668)]

secretは変えずハッシュ関数だけ変えればいいのだろうけど。新旧どちらの値も受け付ける移行期間を設けて、設定変更を促すのだろうか。

ちょっと検索してみたましたが、RFC6238: TOTP: Time-Based One-Time Password Algorithm [ietf.org]には、HMAC-SHA-256/512 を使っても良いことになっていて、Test Vectors にも SHA1/256/512 の3通りが載っています。

TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions,
based on SHA-256 or SHA-512 [SHA2] hash functions, instead of the
HMAC-SHA-1 function that has been specified for the HOTP computation
in [RFC4226].

で、このダイジェスト関数（アルゴリズム）はQRコードなどで渡す Key Uri Format の algorithm パラーメータで決まっている（デフォルトがSHA1）ので、「新旧」など複数の値が生成されることは無い（初期化時に決定済）という理解です。

Google Authenticator の wiki:Key Uri Format#algorithm [github.com]をみると、otpauth://totp/ ... &algorithm=SHA256 とか書けば良いわけですが、もちろんユーザがIIJ SmartKey [iij.ad.jp]のようにこれに対応したアプリ等を使用する必要があります。Google Authenticator でもせめて未対応エラーになってほしいところですが、無視するとは…

Algorithm

OPTIONAL: The algorithm may have the values:

• SHA1 (Default)
• SHA256
• SHA512

Currently, the algorithm parameter is ignored by the Google Authenticator implementations.

どのアルゴリズムを利用するにせよ、認証自体は通常6桁（10進）しか使わないわけで、あんまり長いbit数を出力するかどうかには安全性は影響されない気がしますが、どうだろう。

Re:

[Anonymous Coward]

RFC上はSHA-2を利用してもいいことになってるけど、最終出力のPINが数字6桁とかなんだから意味ないでしょ

RFC 6238 - TOTP: Time-Based One-Time Password Algorithm [ietf.org]

TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions, based on SHA-256 or SHA-512 [SHA2] hash functions, instead of the HMAC-SHA-1 function that has been specified for the HOTP computation in [RFC4226].