使用 HMAC 和胡椒对来自有限域的输入进行哈希处理是否合适

Question

我有一个来自有限域的有效负载

p

。我想对

p

进行哈希处理以生成唯一的签名并存储它。这将允许检测我稍后可能收到的重复

p

。

由于

p

来自一个小域，并且有些敏感，我计划在散列时使用pepper来防止彩虹表攻击（如果有更好的方法来处理有限的域数据，我欢迎建议）

当散列

p

时，是否优选通过HMAC算法计算散列。根据这篇post，

HMAC-SHA256(pepper, p)

似乎比

SHA256(concat(p, pepper))

更可取。

Answer 1

假设

p

是一个 16 位长的数字。您的系统应该判断它是否收到了过去见过的

p

值，而不存储

p

本身，并且始终为相同的输入

p

返回相同的值。 为此，它将

H(p)

以及与每个

H(p)

关联的另一个纯随机且唯一的标记一起存储在表中 - 这些是返回值。

此类系统的攻击者可能对两件事感兴趣：

1. 给定

   p

   的有效性。猜测

   p

   是可能的，因为它具有特定的已知格式和长度。为了验证，他们需要知道系统是否知道生成的哈希值。虽然这可以通过在线系统上的定时攻击实现，但在任何情况下都需要知道秘密

   s

   ，并且使得离线攻击不可行（除非攻击者也获得了

   s

   ）。
2. 系统之前见过的

   p

   的原始值。 这就是系统首先存储派生

   H(p)

   的原因。

攻击者显然没有兴趣证明他们知道

p

的一些其他秘密输入，因为该系统不用于身份验证。 因此，无论是在可行性（

p

的固定输入格式）还是如何使用生成的哈希（重复检测，而不是基于知识证明的身份验证）方面，提到的“伪造”相同输出的输入扩展攻击都不是问题。

据我了解，

P

（所有

p

的空间）的有限大小为10^16，这意味着哈希函数的抗碰撞性（SHA256 为 128 位，SHA512 为 256 位）也不是问题。

决定时的实际考虑

H()

除了所选哈希函数的理论和实际安全性之外，可能还有其他因素。

• 如何确保

  s

  不会在

  H(p)

  的桌子旁边泄漏？
• 您可以将现有值从普通的旧

  H_old(p)

  升级到新的

  H(p)

  而无需

  p

  本身吗？如果系统从不带胡椒的哈希升级到更安全的带胡椒的哈希，那么这一点特别令人感兴趣。这通常可以通过不直接使用

  p

  而是使用

  H(secret || H_old(p))

  来解决。 HMAC 也是如此。
• 是否有任何监管或其他要求表明任何特定功能优于其他功能？ 即使没有严格要求，它也可能使解释系统变得更容易。 例如，PCI DSS 4.0 要求 3.5.1 在其指南中列出了基于 NIST 出版物的 HMAC、CMAC 和 GMAC。虽然您可以使用不同的机制实现“密钥加密哈希”，但通过使用上述机制之一可能会更容易获得对需求的复选标记。