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 字符小写十六进制字符串将复制到剪贴板——可直接粘贴到 TLS 配置、合规报告或 HMAC 实现中。如果目标系统需要大写十六进制，可使用「大写」切换。

3. 3

   与已知哈希值进行比对

   切换到「对比」选项卡，并排粘贴两个 SHA-384 哈希值。工具使用恒定时间比较报告匹配或不匹配，不会泄漏时序信息。适用于验证 Suite B 合规性哈希值、比较跨实现的 HKDF-SHA-384 派生密钥，或核查机密档案审计中的文档指纹。

技术细节

算法：SHA-512 使用不同 IV，输出截断为 384 位

SHA-384 在结构上与 SHA-512 完全相同（FIPS 180-4 第 6.5 节）。两者均使用 80 轮 64 位运算（Ch、Maj、Σ0、Σ1 函数），常数由前 80 个素数的立方根和平方根派生。初始化向量（八个 64 位字）与 SHA-512 的 IV 不同——SHA-384 的 IV 由第 9 到第 16 个素数平方根的小数部分派生。处理后，八字状态中的前六个 64 位字（384 位）作为输出；最后两个字被丢弃。

输出：384 位，96 个十六进制字符

始终恰好为 96 个小写十六进制字符（384 位 = 48 字节，每字节编码为 2 个十六进制字符）。无论输入大小，输出长度固定。96 字符长度是区分 SHA-384（64 字符的 SHA-256 和 128 字符的 SHA-512）的即时标志。被丢弃的 128 位——最后两个 64 位状态字——正是 SHA-384 对长度扩展免疫的原因。

性能：在 64 位硬件上与 SHA-512 相同

SHA-384 和 SHA-512 在 64 位 CPU 上执行相同的指令序列。两者均使用 1024 位（128 字节）输入块，以 64 位旋转和加法处理。吞吐量通常在浏览器中使用 Web Crypto API（在 JS 虚拟机外调用原生 C/Rust 代码）达到 500–900 MB/s，在有硬件 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 年）要求绝密级使用，CNSA Suite（2015 年）中仍然存在。在 RFC 5246（TLS 1.2 PRF 与 SHA-384 密码套件）、RFC 8446（TLS 1.3 签名算法 ecdsa_secp384r1_sha384）和 RFC 5869（HKDF）中有规定。根据 NIST SP 800-131A Rev 2，NIST 批准在 2030 年及以后的所有安全强度级别使用。

最佳实践

在需要不使用 HMAC 的长度扩展免疫性时使用 SHA-384

如果你的协议暴露原始哈希输出，且攻击者可能尝试扩展消息（例如某些签名 URL 或挑战响应方案），SHA-384 提供 SHA-256 所没有的内在长度扩展免疫性。对于所有其他带密钥的用途，无论底层哈希如何，均应使用 HMAC——HMAC-SHA-256 和 HMAC-SHA-384 都是安全的，HMAC 消除了任何 SHA-2 变体的长度扩展攻击。

与 AES-256-GCM 配对以符合 Suite B / CNSA 合规性

如果你正在构建必须符合 NSA Suite B 或 CNSA 要求的系统，标准配置是 AES-256-GCM 用于批量加密，SHA-384 用于完整性和密钥派生。TLS 1.2 配合 ECDHE-ECDSA-AES256-GCM-SHA384 是参考密码套件。TLS 1.3 的等效项是 TLS_AES_256_GCM_SHA384 配合 ecdsa_secp384r1_sha384 作为签名算法。确认你的 TLS 库实际协商了这些密码套件——某些默认配置即使在 Suite B 配置的系统上也会优先选择 AES-128 变体。

在 TLS 1.2 PRF 场景中使用 HMAC-SHA-384 作为带密钥 MAC

TLS 1.2 的 PRF 对协商了 SHA-384 的密码套件使用 HMAC-SHA-384（RFC 5246 第 5 节）。如果你正在实现或测试 TLS 1.2 PRF：PRF(secret, label, seed) = P_SHA384(secret, label + seed)。不要在 SHA-384 密码套件上下文中用 HMAC-SHA-256 替换——密码套件协商决定 PRF 哈希，不匹配会导致握手失败。使用 RFC 5705（密钥材料导出器）或 RFC 6070（PBKDF2）的测试向量进行验证。

在代码中验证 SHA-384 哈希值时使用恒定时间比较

如果你在代码中比较两个 SHA-384 哈希值——验证文档指纹、核查 MAC——请使用恒定时间等值检查：Node.js 的 crypto.timingSafeEqual()、Python 的 hmac.compare_digest()、Go 的 subtle.ConstantTimeCompare()。简单的字符串等值比较（=== 或 ==）会泄漏时序信息，允许攻击者通过约 768 次比较（96 字符 × 8 位）逐字节重建预期哈希值。这是任何认证系统的关键纵深防御措施。

SHA-384 常见问题