SHA-384ハッシュジェネレーター（TLS Suite Bハッシュ）

SHA-384とは？

// Hash text using Web Crypto API (SHA-384)
async function sha384(text) {
  const data = new TextEncoder().encode(text);
  const hash = await crypto.subtle.digest('SHA-384', data);
  return Array.from(new Uint8Array(hash))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');
}

await sha384('Hello, World!');
// → '5485cc9b3365b4305dfb4e8337e0a598a574f8242bf17289e0dd6c20a3cd44a089de16ab4ab308f63e44b1170eb5f515'

SHA-384の使用例

ECDHE-ECDSA-AES256-GCM-SHA384

master secret || client random || server random

CLASSIFIED//TS//SI//NF — Document ID: TSC-2026-0001

POST /api/v2/transfer
Content-Type: application/json
{"amount":10000,"to":"account-XYZ"}

SHA-384ハッシュの生成方法

1. 1

   テキストを貼り付けるかファイルをドロップ

   「テキスト」タブを選択して、ドキュメントID・リクエストボディ・任意の入力など任意の文字列を入力欄に貼り付けてください。SHA-384ハッシュは入力に応じてリアルタイムで更新されます。ファイルの場合は「ファイル」タブに切り替えてドロップゾーンにドラッグしてください。Web Crypto APIを使用してアップロードなしにローカルでハッシュ化されます。大きなファイル（10 MB超）では進捗インジケーターが表示されます。

2. 2

   96文字のハッシュをコピー

   ハッシュ出力の隣にある「コピー」ボタンをクリックしてください。96文字の小文字16進数文字列全体がクリップボードにコピーされ、TLS設定・コンプライアンスレポート・HMAC実装にすぐに貼り付けられます。ターゲットシステムが大文字の16進数を要求する場合は「大文字」トグルを使用してください。

3. 3

   既知のハッシュと比較

   「比較」タブに切り替えて2つのSHA-384ハッシュを並べて貼り付けてください。定数時間比較でタイミング情報を漏洩せずに一致または不一致を報告します。Suite B準拠ハッシュの検証・実装間でのHKDF-SHA-384導出鍵の比較・機密アーカイブ監査でのドキュメントフィンガープリント確認に役立ちます。

技術仕様

アルゴリズム：異なるIVを持つSHA-512、出力を384ビットに切り詰め

SHA-384はSHA-512と構造的に同一です（FIPS 180-4セクション6.5）。両方が最初の80素数の立方根と平方根から導出された定数で80ラウンドの64ビット演算（Ch・Maj・Σ0・Σ1関数）を使用します。初期化ベクトル（8つの64ビットワード）はSHA-512のIVと異なります — SHA-384のIVは9番目から16番目の素数の平方根の小数部から導出されます。処理後、8ワード状態の最初の6つの64ビットワードが出力されます（384ビット）。最後の2ワードは破棄されます。

出力：384ビット、96文字16進数

常に正確に96文字の小文字16進数（384ビット = 48バイト、1バイト2文字）。入力サイズによらず固定長。96文字の長さがSHA-256（64文字）やSHA-512（128文字）と即座に区別できるSHA-384の特徴です。破棄された128ビット — 最後の2つの64ビット状態ワード — がSHA-384を長さ拡張耐性にする要素です。

パフォーマンス：64ビットハードウェアでSHA-512と同一

SHA-384とSHA-512は64ビットCPUで同じ命令シーケンスを実行します。両方が64ビット回転と加算で1024ビット（128バイト）入力ブロックを使用します。スループットはブラウザでのWeb Crypto API使用時に通常500〜900 MB/s（JS VMの外でネイティブC/Rustコードを呼び出します）、ハードウェアSHA拡張を持つネイティブツールで1〜3 GB/s。32ビットハードウェアまたはハードウェアアクセラレーションなしでは、64ビット整数エミュレーションのためSHA-384/512はSHA-256より低速です。

標準：FIPS 180-4、NSA Suite Bレガシー、CNSA現行

FIPS 180-2（2001年）で標準化、現行版FIPS 180-4（2015年）。NSA Suite B（CNSSP-15、2005年）でTOP SECRETに必須、CNSAスイート（2015年）にも残存。TLSのRFC 5246（SHA-384 cipher suiteのTLS 1.2 PRF）・RFC 8446（TLS 1.3署名アルゴリズム ecdsa_secp384r1_sha384）・RFC 5869（HKDF）で指定。NIST SP 800-131A Rev 2の下で2030年以降まですべてのセキュリティ強度レベルでNIST承認済み。

ベストプラクティス

HMACなしに長さ拡張耐性が重要な場合はSHA-384を使用

プロトコルが生のハッシュ出力を公開し、攻撃者がメッセージを延長しようとする可能性がある場合（署名付きURLや特定のチャレンジレスポンス方式など）、SHA-384はSHA-256が持たない固有の長さ拡張耐性を提供します。その他のキー付き用途には、基礎となるハッシュに関わらずHMACを適用してください — HMAC-SHA-256とHMAC-SHA-384はどちらも安全で、HMACはSHA-2バリアントのすべてで長さ拡張攻撃を排除します。

Suite B / CNSA準拠にはAES-256-GCMと組み合わせる

NSA Suite BまたはCNSA要件に準拠するシステムを構築する場合、正規の組み合わせはバルク暗号化にAES-256-GCM、整合性と鍵導出にSHA-384です。TLS 1.2のリファレンスcipher suiteはECDHE-ECDSA-AES256-GCM-SHA384です。TLS 1.3では同等の組み合わせはTLS_AES_256_GCM_SHA384とecdsa_secp384r1_sha384署名アルゴリズムです。TLSライブラリが実際にこれらのcipher suiteをネゴシエートしているか確認してください。Suite B設定のシステムでさえデフォルトがAES-128バリアントを好む場合があります。

TLS 1.2 PRFコンテキストではHMAC-SHA-384を使用

TLS 1.2のPRFは、SHA-384がネゴシエートされたcipher suite向けにHMAC-SHA-384を使用します（RFC 5246セクション5）。TLS 1.2 PRFを実装またはテストする場合：PRF(secret, label, seed) = P_SHA384(secret, label + seed)。SHA-384 cipher suiteコンテキストでHMAC-SHA-256を代用しないでください — cipher suiteネゴシエーションがPRFハッシュを決定し、不一致はハンドシェイク失敗を引き起こします。RFC 5705（鍵マテリアルエクスポーター）やRFC 6070（PBKDF2）のテストベクトルで検証してください。

コードでSHA-384ハッシュを検証する際は定数時間比較を使用

コードで2つのSHA-384ハッシュを比較する場合（ドキュメントフィンガープリントの検証・MACのチェックなど）は、定数時間等値チェックを使用してください：Node.jsの crypto.timingSafeEqual()・Pythonの hmac.compare_digest()・Goの subtle.ConstantTimeCompare()。素の文字列等値比較（=== や ==）はタイミング情報を漏洩し、攻撃者が約768回の比較（96文字 × 8ビット）で期待されるハッシュをバイトごとに再構築できる可能性があります。これは認証システムにとって重要な多層防御措置です。

SHA-384 よくある質問