FreeBSD pkg 2.8.0のリリースから段階的にSHA-256が廃止されBlake2bがチェックサムに使われるようです（量子対策？）

5 min

暗号化セキュリティfreebsd雑記
language: ja bn en es hi pt ru zh-cn zh-tw

こんにちは無能です。
freebsd/pkg の Release が Github のタイムラインに流れてきてたまたま目に入ったら Blake2b の文字が。

https://github.com/freebsd/pkg/releases#release-2.8.0

  • Blake2b used everywhere possible for checksums; repositories use blake2 instead of sha256

そもそものこのBlake2b自体、GNU coreutlisには2016年に含まれてリリースされていたようです。

Blake2bがそもそもなんなのか

前にちょろっと調べただけでハッシュアルゴリズムの一つという認識しかなかったので軽く確認

Blake2(Blake2b)をRustで実装してみた #Security - Qiita

Blake2は二種類あって、通常版のBlake2bと縮小版のBlake2s。Blake2bは64bit用でBlake2sは8~32bit。

なるほど

RFC:
RFC 7693 - The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)

Argon2のパスワードハッシュに使われているものでもありココらへんの未来の置き換えはパスワードハッシュは現状bcryptを使っている実装をArgon2で、暗号ハッシュは現状SHA-256使っている実装はBlake2を使っていくことがモダンな設計になっていくのでしょうか？
すでにそれぞれに置き換えられているような実装は直近でもArgon2を利用しているような実装はそれなりに見受けられるのであり得るんじゃないのかなあと思い。かと言って、今も md5sum だとかは軽量な高速ハッシュとして未だ利用されているし簡易的に整合性を取るだけなら便利、なんなら WebSocket も WebSocket Handshake では SHA-1 を使う前提でRFCに記載されていますが WS の場合の実装だとそもそも変える意味がないので記載もされています。

このドキュメントで説明されているWebSocketハンドシェイクは、SHA-1のセキュリティプロパティ（衝突耐性や2番目のプリイメージ攻撃への耐性など）に依存していません（[RFC4270]で説明されています）。

RFC 6455 - The WebSocket Protocol

この疑問をもう壁打ち出来るのでChatGPT(GPT 5.6)に聞いてみました。
結論としては Argon2 への移行はモダン化としては適正だが、暗号ハッシュとしては手段がまた一つ増えたみたいな感じになりそうです。
ただし、FreeBSDが pkg の checksum の利用を切り替えたって結構それなりにびっくりしたことなのでそれなりな先の未来として割と標準的になったりならなかったり？

以下GPT5.6への質問

Q.パスワードハッシュは現状bcryptを使っている実装をArgon2で、暗号ハッシュは現状SHA-256使っている実装はBlake2を使っていくことがモダンな設計になっていくのでしょうか？

A. はい、パスワード保存については bcrypt → Argon2id はかなり「モダン化」と言ってよいです。一方で、汎用暗号学的ハッシュの SHA-256 → BLAKE2 は、必ずしも単純な世代交代ではありません。

パスワードなら現在はだいたい次の優先順位です。

用途 従来 現在の推奨
パスワード保存 bcrypt Argon2id
パスワード保存の代替 PBKDF2 / scrypt Argon2id / scrypt
一般的なハッシュ SHA-256 SHA-256 / SHA-3 / BLAKE2 / BLAKE3
MAC HMAC-SHA256 HMAC-SHA256 / keyed BLAKE2
高速な整合性チェック SHA-256 BLAKE2 / BLAKE3

OWASPも、新規システムでは Argon2idを第一候補とし、bcryptについては主に既存システム向けという位置付けにしています。Argon2idはCPU負荷だけでなくメモリ使用量を攻撃コストに組み込める memory-hard KDFなので、GPU/ASICで大量に試行するパスワードクラックに対してbcryptより設計上有利です。(OWASP Cheat Sheet Series)

たとえば新規実装なら、

password
   ↓
Argon2id(
    salt = random 128bit,
    memory = 64 MiB,
    iterations = 3,
    parallelism = 適宜
)
   ↓
$argon2id$v=19$m=65536,t=3,p=...

のような構成が自然です。RFC 9106もArgon2idを推奨しています。(RFCエディタ)

一方、

SHA-256 → BLAKE2

については少し違います。

SHA-256が古くて危険になったわけではありません。

SHA-256には現在、実用的な衝突攻撃や原像攻撃は知られておらず、普通の暗号学的用途では依然として十分強力です。

BLAKE2の利点は主に、

高速
+ 
安全性が高い
+
keyed hashing を標準で持つ
+
実装しやすい

というところです。

なので、

古い                  モダン

bcrypt      ───────→ Argon2id
                 ↑
             かなり明確

SHA-256     ───────→ BLAKE2
                 ↑
          必ずしも置換ではない

という理解が近いです。

むしろ現在の設計では、

Password
 └─ Argon2id

Cryptographic digest
 ├─ SHA-256
 ├─ SHA-3
 ├─ BLAKE2
 └─ BLAKE3

Message authentication
 ├─ HMAC-SHA256
 └─ keyed BLAKE2

のように用途ごとに選ぶのがモダンです。

特に新しく自分で設計するソフトウェアで、プロトコル互換性などの制約がなければ、私は

Password hashing
→ Argon2id

一般的な高速ハッシュ
→ BLAKE2b / BLAKE3

外部規格・プロトコルとの互換性重視
→ SHA-256

MAC
→ HMAC-SHA256
  または keyed BLAKE2

くらいに考えるのがよいと思います。

そして重要なのが BLAKE2 と BLAKE3です。新規設計で「SHA-256より新しい高速ハッシュを使いたい」という目的なら、2026年時点では BLAKE2だけでなくBLAKE3も候補に入れるべきです。BLAKE3は並列化・SIMD・大きなデータのハッシュで非常に高速です。

ただし、

SHA-256 → BLAKE3

も「セキュリティ上SHA-256を捨てる」というより、

性能やAPI設計上のメリットを取りにいく選択

です。

つまり質問の二つは同列ではなく、

bcrypt → Argon2id

セキュリティ設計として明確に現代化する方向。

SHA-256 → BLAKE2/BLAKE3

セキュリティ必須の移行ではなく、新規設計で性能や使いやすさを考えて選択する方向。

という違いがあります。

もし「2026年にゼロから認証・署名・暗号化・ファイルハッシュまで含めたAPIを設計するなら何を選ぶか」まで広げるなら、Argon2id / BLAKE3 / XChaCha20-Poly1305 / Ed25519 / X25519あたりを軸にすると、かなり現代的な構成になります。

Related Posts