Skip to content
ブログに戻る
チュートリアル

SHA-1 vs SHA-256 vs SHA-512：2026 年ハッシュ選択ガイド

SHA-1、SHA-256、SHA-384、SHA-512、SHA-3 をセキュリティ状態・出力サイズ・パフォーマンス・実際のユースケースで比較。決定木と代表的な落とし穴を解説します。

14 分で読めます

SHA-1 vs SHA-256 vs SHA-512: 2026年に選ぶべきハッシュアルゴリズム

TLS 証明書、Git のオブジェクトデータベース、Bitcoin のブロックヘッダー、Linux パッケージマネージャー、Docker イメージマニフェスト — どれを開いても必ず SHA ハッシュが見つかります。しかし、どれも同じ SHA ではありません。SHA-1、SHA-256、SHA-384、SHA-512、SHA-3：このファミリーは 30 年にわたり、2 つの設計系譜と、最も古いメンバーを本番環境で破壊した重大な衝突攻撃を経て発展してきました。

このガイドでは、ファミリー全体をマッピングし、自分のユースケースに合ったアルゴリズムを迷いなく選べるようにします。

決定木：クイックリファレンス

詳細に入る前に、多くの開発者が実際に必要としている 1 枚のサマリーテーブルを示します。

あなたの状況最適な選択肢理由
TLS/HTTPS 証明書SHA-256（最低限）、高セキュリティには SHA-384CA/Browser Forum ベースライン要件で義務付け
JWT 署名（HMAC または RSA）SHA-256（HS256/RS256）汎用サポート；コンプライアンス要件には SHA-384/512
ソフトウェア整合性チェックサムSHA-256業界標準；広く理解されている
長期保存・アーカイブ用整合性SHA-512出力が大きく、今後数十年の安全マージンを確保
コンテンツアドレッシング（IPFS、OCI）SHA-256コンテンツアドレスストレージの事実上の標準
Git（既存リポジトリの読み書き）既存は SHA-1；新規は --object-format=sha256 で SHA-256Git は移行中；SHA-1 がいまだ主流
Ethereum との相互運用Keccak-256（NIST SHA-3 ではない）Ethereum は標準化前の Keccak 実装を使用
多層防御または機密システムSHA-384 または SHA-512NSA Suite B；AES-256-GCM と組み合わせ
新規コード、レガシー制約なしSHA-3（SHA3-256）別設計系譜；長さ拡張脆弱性なし
パスワード保存上記のいずれも不可bcrypt、Argon2id、または scrypt を使用 — SHA は速すぎる

SHA ファミリー一覧

アルゴリズム標準出力ビット16 進数文字数年NIST 状態主な用途
SHA-1FIPS 180-4160401995非推奨（2011 年）、電子署名から廃止Git レガシー、フィンガープリント
SHA-256FIPS 180-4256642001現行TLS、JWT、Bitcoin、チェックサム
SHA-384FIPS 180-4384962001現行Suite B、高セキュリティ TLS
SHA-512FIPS 180-45121282001現行アーカイブ、LUKS、HMAC-SHA-512
SHA-3（全バリアント）FIPS 202224/256/384/512可変2015現行別設計系譜、ハードウェアアクセラレーション

SHA-1 と SHA-2（256/384/512 グループ）は Merkle-Damgård 構造を共有しています。SHA-3 はスポンジ構造を採用しており — この違いは見かけ以上に重要です。後述します。

SHA-1：壊れているが死んでいない

SHA-1 は 2000 年代の主力アルゴリズムでした。SSL 証明書、S/MIME メール、PGP フィンガープリント、Git がすべてこれに集約しました。そして 2017 年 2 月、Google と CWI Amsterdam が SHAttered を公開しました：選択プレフィックス衝突攻撃によって、SHA-1 ハッシュが同一の 2 つの異なる PDF ファイルを生成したのです。この攻撃には約 6.5 × 10^19 回の SHA-1 評価が必要でした — 2017 年時点では高コストでしたが、今日のクラウドコンピューティングでは手の届く範囲です。

NIST はすでに 2011 年に電子署名における SHA-1 を非推奨とし（NIST Special Publication 800-131A）、SHAttered の実証がさらなる整理を加速させました：ブラウザは 2017 年までに SHA-1 TLS 証明書の信頼を停止し、CA/Browser Forum は新規発行において SHA-256 を必須としました。

SHA-1 がいまだ使われている場面：

  • Git オブジェクトデータベース：Git は SHA-1 を高速なコンテンツハッシュとして設計されており、セキュリティプリミティブではありません。リポジトリ形式は 40 桁の 16 進数オブジェクト ID をハードコードしています。SHA-256 への移行パス（git init --object-format=sha256）は存在しますが、ホストプラットフォーム、CI ツール、既存のクローンすべてが同期して移行する必要があるため、採用は遅れています。
  • レガシーシステムのフィンガープリント：古い SSH ホストキーフィンガープリント、PGP キーフィンガープリント、証明書シリアル番号スキームにいまだ SHA-1 の値が露出しています。これらはほとんどの文脈で情報提供的なものであり、セキュリティクリティカルではありません。

対応策：新規のものに SHA-1 を使わないこと。Git については、衝突リスクは典型的なソフトウェア開発ワークフローでは低いです（攻撃者は衝突する両方のファイルを制御する必要があるため）が、新規プロジェクトでは --object-format=sha256 を使うことが長期的に正しい方向です。

ブラウザで SHA-1 ハッシュを生成する：SHA-1 Generator

SHA-256：現代の主力

SHA-256 は 2026 年にインターネットを動かしているアルゴリズムです。公開 CA が発行するすべての TLS 証明書はそのシグネチャハッシュに SHA-256 を使用しています。HS256、RS256、ES256 で署名されたすべての JWT は内部的に SHA-256 を使います。Bitcoin のプルーフ・オブ・ワークはダブル SHA-256 です。Docker のコンテンツハッシュは SHA-256 です。npm パッケージの整合性は SHA-256 を使用します。

理由は実践的なものです：

  • セキュリティマージン：256 ビットの出力は、ブルートフォースプレイメージ攻撃に対して 2^128 回の演算が必要であることを意味します — 予見できる将来においてどんなハードウェアをもってしても不可能です。誕生日界による衝突攻撃（2^128 回の演算）のため実際のセキュリティレベルはわずかに低くなりますが、それでも突破不可能です。
  • ハードウェアアクセラレーション：SHA-256 は、すべての Intel Goldmont+ CPU（SHA-NI 拡張）、すべての Apple シリコンチップ、すべての ARMv8 プロセッサ、ネットワーク機器やストレージコントローラの専用 ASIC にシリコンで実装されています。ハードウェアパスを使用すると、SHA-256 のスループットはより速く見える多くのソフトウェア代替品を上回ります。
  • ライブラリの普遍的サポート：あらゆる TLS ライブラリ、JWT ライブラリ、言語標準ライブラリが SHA-256 を実装しています。互換性の壁に当たることはありません。

コンテンツアドレッシング、整合性検証、そしてほとんどの署名ワークフローにおいて、特定の標準が別途要求しない限り SHA-256 は正しいデフォルトです。

ブラウザで SHA-256 ハッシュを生成する：SHA-256 Generator

SHA-384：TLS の専門家

SHA-384 は SHA-512 を 384 ビットに切り詰めたものです。192 ビットのセキュリティレベル（出力サイズの半分が衝突耐性の下限）を提供するために作られ、AES-256-GCM および P-384 楕円曲線キーと並んで NSA Suite B 暗号に組み込まれています。

SHA-384 が TLS に特に魅力的な 2 つの特性があります：

  1. この出力サイズにおける長さ拡張免疫：SHA-256 と SHA-512 は長さ拡張攻撃に脆弱です — H(secret || message) を知っている攻撃者は、secret を知らずに H(secret || message || extension) を計算できます。SHA-384 と SHA-512/256 は完全な内部状態から切り詰められているため、長さ拡張は適用されません。HMAC の代わりに生の SHA ハッシュを MAC として使っている場合、SHA-384 の方が安全です。
  2. Suite B コンプライアンス：NSA/CNSA（商業国家安全保障アルゴリズム）スイート要件を満たす必要がある組織は、RSA-3072+、ECDH P-384、AES-256 とともに SHA-384 または SHA-512 を使用しなければなりません。顧客が米国連邦機関や FIPS 140-3 要件下で運営する請負業者であれば、SHA-384 が必須となる場合があります。

SHA-384 は、ほとんどのユースケースで SHA-256 よりも意味のある形でセキュアではありません — 現在のコンピューティングレベルでは 128 ビットと 192 ビットの衝突耐性の実際的な差は理論的なものです。コンプライアンスや Suite B との組み合わせが要求する場合に選択してください。汎用利用のためではありません。

ブラウザで SHA-384 ハッシュを生成する：SHA-384 Generator

SHA-512：より多くのビットが必要な場合

SHA-512 は 512 ビット（128 桁の 16 進数）のダイジェストを生成します。64 ビットハードウェアでは SHA-256 より速いことが多いです。なぜなら、アルゴリズムは 32 ビットワードではなく 64 ビットワードで動作するからです — SHA-256 の内部スケジュールは 32 ビット演算を使用するのに対し、SHA-512 は現代の CPU でより効率的にマッピングされる 64 ビット演算を使用します。

64 ビットハードウェアでのベンチマーク（目安；ブラウザ Web Crypto API）：

アルゴリズム概算スループット
SHA-1〜600 MB/s
SHA-256〜500 MB/s
SHA-384〜700 MB/s
SHA-512〜700 MB/s
SHA-3-256〜300 MB/s

注：SHA-384 と SHA-512 は同じ内部圧縮関数を共有しているため、同じ速度で動作します。SHA-256 は 64 ビットでは遅くなります。なぜなら 32 ビットのワードサイズにより、512 ビットのメッセージブロックを処理するためにより多くの反復が必要になるからです。32 ビットまたは制約のあるハードウェアでは SHA-256 の方が速くなります。

SHA-512 は以下に適しています：

  • アーカイブ整合性：数十年にわたって保存されることを意図したチェックサムは、より大きな出力マージンから恩恵を受けます。
  • フルディスク暗号化：Linux LUKS は SHA-512 を鍵導出 PBKDF のデフォルトハッシュとして使用します（スタンドアロンのハッシュではなく PBKDF2 の構成要素として）。
  • HMAC-SHA-512：一部の JWT 署名スキーム（HS512）や、大きな MAC が好まれる API 認証で使用されます。
  • 大量の疑似乱数データ生成：シードをハッシュして多くの出力ビットが必要なアプリケーションは、SHA-512 を使用してハッシュ呼び出し回数を削減できます。

ブラウザで SHA-512 ハッシュを生成する：SHA-512 Generator

SHA-3：異なる設計哲学

SHA-3 は大きな出力を持つ SHA-2 ではありません。Guido Bertoni、Joan Daemen、Michaël Peeters、Gilles Van Assche が設計した Keccak というスポンジ構造に基づく根本的に異なるアルゴリズムです。NIST は 2007〜2012 年の 7 年間にわたる公開コンペ（SHA-2 の Merkle-Damgård 構造に弱点が発見された場合のバックアップとなるハッシュファミリーを生み出すことを目的としていた）の優勝者として選定しました。

スポンジ構造は Merkle-Damgård とは異なる動作をします：

  1. 入力はパディングされてブロックに分割されます。
  2. 各ブロックは大きな内部状態の最初の部分（「レート」）に XOR され、次に Keccak-f 置換で状態全体が置換されます。
  3. すべての入力を吸収した後、出力は状態のレート部分から「絞り出され」ます。

出力は状態の一部のみから抽出され、容量部分が直接露出されることはないため、スポンジ構造は切り詰めなしに長さ拡張攻撃に対して本質的に免疫を持ちます。

SHA-3 標準バリアント（FIPS 202）：

バリアント出力ビットセキュリティレベル
SHA3-224224112 ビット
SHA3-256256128 ビット
SHA3-384384192 ビット
SHA3-512512256 ビット
SHAKE128可変128 ビット
SHAKE256可変256 ビット

実際の SHA-3 と SHA-2 の比較：

SHA-3 は 2015 年以前に設計されたプロトコル（TLS、JWT、ほとんどのインターネットインフラ）ではまだ広く展開されていません。SHA-3 はポスト量子署名スキーム（CRYSTALS-Dilithium、SPHINCS+ は内部的に SHA-3 を使用）、異なる系譜のバックアップを望む新プロトコル設計、および Keccak 置換が高速化するハードウェアで登場しています。純粋なソフトウェアでは、SHA-3 は x86 上で SHA-256 より約 40% 遅くなります。

ブラウザで SHA-3 ハッシュを生成する：SHA-3 Generator

Ethereum の Keccak-256 について

重要な注意点：Ethereum は NIST SHA-3 を使用していません。Ethereum は Keccak コンペが進行中で、NIST が FIPS 202 を最終化する前の時期に設計されました。Ethereum Virtual Machine はオリジナルの Keccak-256 サブミッションを使用しており、最終化された NIST SHA-3 標準とは異なるパディングを使用しています。

具体的には：

  • NIST SHA3-256 は最終ブロックの前に 0x06 パディングを追加します。
  • Ethereum が使用するオリジナルの Keccak-256 は 0x01 パディングを追加します。

同じ入力が異なるハッシュを生成します。NIST SHA3-256 と Ethereum の keccak256 は互換ではありません。ほとんどの言語では両方が提供されています：Python では hashlib.sha3_256() が NIST SHA-3 です；Ethereum が使用する Keccak-256 には pysha3（keccak_256 を実装）のようなライブラリが必要です。JavaScript では、js-sha3 ライブラリが両方を公開しています。SHA-3 Generator は NIST SHA3-256 を実装しています — Ethereum の Keccak-256 ハッシュが必要な場合は、Ethereum 専用のツールを使用してください。

パフォーマンスベンチマーク

以下の数値は、現代の x86-64 ラップトップのブラウザ Web Crypto API における目安です。実際のスループットはハードウェア、メッセージサイズ、プラットフォームがハードウェアアクセラレーションパスを使用するかどうかによって異なります。

アルゴリズムストリーミングスループット（64 ビット）
SHA-1〜600 MB/s
SHA-256〜500 MB/s
SHA-384〜700 MB/s
SHA-512〜700 MB/s
SHA-3-256〜300 MB/s

小さなメッセージ（API トークン、数 KB 未満のチェックサム）では、すべてのアルゴリズムが 2 µs 未満で完了します — 違いは目に見えません。大きなデータ（tarball、ディスクイメージ）では、64 ビットシステムで 64 ビットワードで動作するため SHA-384/512 が SHA-256 を上回ります。SHA-3 は純粋なソフトウェアでは遅くなります；ハードウェア Keccak アクセラレーションが利用できない限り、スループットが重要なコードでは SHA-2 を優先してください。SHA-1 のスループットはそれを使用する理由にはなりません。

代表的な落とし穴

エンコーディングの不一致

SHA はバイト列に対して動作します。ブラウザで JavaScript が文字列 "hello" を UTF-8 ではなく UTF-16 でエンコードする場合、str.encode("utf-8") を使用する Python スクリプトとは異なるダイジェストが得られます。テキストをハッシュする前は必ず UTF-8 に正規化してください。

一貫したパターン：

const encoder = new TextEncoder(); // UTF-8
const data = encoder.encode(inputString);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);

MAC のためのソルトの欠如

生の SHA ハッシュをメッセージ認証コードとして使用すること（H(secret || message)）は、SHA-256 と SHA-512 における長さ拡張攻撃に対して脆弱です。代わりに HMAC（RFC 2104）を使用してください：HMAC-SHA256(key, message)。HMAC は内部および外部のキー付きパッドでハッシュをラップし、拡張攻撃を防ぎます。

SHA-256 における長さ拡張

API 署名を SHA256(secret + payload) として構築している場合、結果のハッシュを知っている攻撃者は secret を知らずに SHA256(secret + payload + attacker_extension) を計算できます。修正方法：HMAC を使用するか、SHA-3（構造上免疫）を使用するか、SHA-384/SHA-512/256（切り詰めによる免疫）を使用してください。

Keccak-256 と NIST SHA-3 の混同

上述の通り：Ethereum は 0x01 パディングの Keccak-256 を使用します；NIST SHA3-256 は 0x06 パディングを使用します。同じ入力から異なる出力が生成されます。Ethereum コントラクトや Solidity ABI エンコーディングと統合する前に、ライブラリがどのバリアントを実装しているかを確認してください。

パスワードに SHA を使用すること

SHA アルゴリズムは高速になるように設計されています。それはまさにパスワード保存に間違った特性です：GPU クラスターは 1 秒間に数十億の SHA-256 ハッシュを計算でき、SHA ハッシュされたパスワードデータベースに対する辞書攻撃を現実的なものにします。パスワードにはメモリハードな鍵導出関数を使用してください：Argon2id（推奨）、bcrypt、または scrypt。たとえソルト付きでも、生の SHA ハッシュでパスワードを保存しないでください。

よくある質問

SHA-1 と SHA-256 の違いは何ですか？

SHA-1 と SHA-256 はどちらも FIPS 180-4 で標準化された Merkle-Damgård ハッシュ関数ですが、SHA-256 は SHA-1 の 160 ビットに対して 256 ビットのダイジェストを生成します。より重要な点として、SHA-1 は破られています：実世界での衝突攻撃（SHAttered、2017 年）によって同じ SHA-1 ハッシュを持つ 2 つの異なる PDF ファイルが実証されました。SHA-256 には既知の衝突攻撃がなく、128 ビットの衝突耐性レベルを提供します。整合性保証が必要なものには SHA-256 を使用し、新規の作業に SHA-1 を使用しないでください。

SHA-512 は SHA-256 より速いですか？

64 ビットハードウェアでは、大きな入力に対して 30〜40% 速いことが多いです。SHA-512 は 64 ビットワード演算を使用しており、現代の CPU はネイティブにこれを処理します。SHA-256 は 32 ビットワード演算を使用するため、同じハードウェアでメッセージブロックあたり 2 倍の演算が必要です。32 ビットプラットフォームや制約のあるマイクロコントローラでは SHA-256 の方が速くなります。短いメッセージ（数 KB 未満）では差は知覚できません。

SHA-1 から SHA-256 に移行すべきですか？

電子署名、TLS 証明書、コード署名においては：はい、絶対に — SHA-1 は非推奨であり積極的に破られています。Git リポジトリについて：移行パス（git init --object-format=sha256）は存在しますが、エコシステムの調整要件により採用が遅れています；典型的なリポジトリ使用での衝突リスクは低いです。情報提供的なフィンガープリント（SSH ホストキー表示）については：セキュリティの露出は最小ですが、SHA-256 に移行することは良い習慣です。

SHA-256 は逆算できますか？

いいえ。SHA-256 は設計上一方向関数です。ハッシュが与えられても、元の入力を数学的に復元することはできません。攻撃者にできることは辞書攻撃やブルートフォース攻撃です：数百万の候補入力をハッシュして比較します。低エントロピーの入力（短い文字列、一般的なパスワード、連番）では、事前計算されたレインボーテーブルがこれを現実的にします。高エントロピーの入力（ランダムな UUID、大きなファイル）では、逆算は計算上不可能です。これが SHA だけではパスワードに不適切な理由です — 低速でソルト付きの鍵導出関数が必要です。

SHA-2 の代わりに SHA-3 をいつ使うべきですか？

SHA-3 が適切なのは：(a) 将来の SHA-2 の弱点に対する保険として異なる設計系譜のハッシュが欲しい場合；(b) プロトコルが HMAC を使わずに長さ拡張免疫を必要とする場合；(c) 内部的に SHA-3 を指定するポスト量子署名スキームを実装している場合；または (d) Keccak のハードウェアアクセラレーションがありスループットが必要な場合。日常的なユースケース（TLS、JWT、チェックサム）のほとんどでは、SHA-256 の方が広いエコシステムサポートを持つ実用的なデフォルトです。SHA-3 は同等の出力サイズで SHA-2 より安全なわけではありません — 長期的なセキュリティに対する異なる賭けです。

なぜ Ethereum は NIST SHA-3 ではなく Keccak-256 を使うのですか？

Ethereum は 2013〜2014 年に設計されており、NIST が FIPS 202（2015 年 8 月）を公開して SHA-3 標準を最終化する前でした。当時、Keccak サブミッションは優勝候補と見られており、Ethereum の設計者はそれを直接使用しました。NIST が標準を最終化したとき、ドメイン分離パディングを 0x01（Keccak オリジナル）から 0x06 に変更し、同じ入力から異なる出力が生成されるようになりました。Ethereum はすでにオリジナルの Keccak パディングで展開されており、変更できませんでした。そのため、「Ethereum keccak256」と「NIST SHA3-256」は同じ基底の Keccak-f 置換を共有しているにもかかわらず異なるアルゴリズムです。

ツールを試してみてください：SHA-1 · SHA-256 · SHA-384 · SHA-512 · SHA-3 — すべてブラウザで動作し、データはあなたのマシンから外に出ません。

タグ: hash sha cryptography security

関連記事

すべての記事を見る
tutorials

curl チートシート：HTTP・API の 40+ コマンド例

開発者向け curl 完全チートシート：GET/POST、ヘッダー、Bearer 認証、ファイルのアップロード/ダウンロード、API テスト。40 以上のコピペ可能な実例。ツールもお試しください。

#curl #http #rest-api
2026年6月2日
14 分で読める
tutorials

Lorem Ipsumとは？意味・由来・プレースホルダーテキストの使い方

Lorem Ipsumを徹底解説。この疑似ラテン語の意味と由来、デザイナーがプレースホルダーテキストを使う理由、各環境での生成方法、本番で使ってはいけない理由まで。無料ジェネレーターをすぐ試せます。

#lorem-ipsum #placeholder-text #dummy-text
2026年6月2日
12 分で読める
tutorials

XML から JSON へ変換：規約・落とし穴・コード例（2026）

XML を正しく JSON に変換する方法。属性・配列・名前空間のマッピング、値が文字列のまま残る理由、JavaScript・Python・ブラウザのコード例を解説します。

#xml #json #data-conversion
2026年6月2日
13 分で読める