首先,我必须发布散列未签名的标准注释。数字签名是一个涉及密钥和验证者的过程。在这里,您只想散列一些数据并将散列值保存在“安全”的地方,以便您可以将散列值的完整性扩展到散列数据:确保散列值未被篡改,并且,通过重新计算数据元素的哈希值并找到相同的哈希值,您可以确信字段元素没有被篡改。
然后我必须发布第二个标准评论,即在实际条件下适当衡量之前没有性能问题。散列很快。即使使用不那么快的哈希函数,一台基本的 PC 也将能够每秒执行数百万次哈希运算。
现在,我看到您想使用“盐”。盐是一段公共数据,其目的是为每个实例区分,以防止解密成本分摊。这在有一些加密数据的设置中是有意义的;据我从您的描述中可以看出,您的问题中没有任何加密内容。
...除非您实际上意味着您将保密您的“盐”,并将哈希值与数据字段一起存储。在这种情况下,我们不再谈论散列。您的“盐”更适合称为“钥匙”,因为它是为了保密。而且您不需要哈希,而是MAC。有时,MAC 被称为“签名”。这是不恰当的,但比将哈希称为“签名”更不恰当。如果您想要的是 MAC(并且您的 salt 确实是一把钥匙),那么您不应该使用任何一种结构。构建 MAC 并不容易:许多手工制作的结构在安全性方面完全失败。幸运的是,有一个标准的 MAC,叫做HMAC. HMAC 使用底层散列函数(使用 SHA-256)和以智能方式将它们转换为 MAC 的密钥。许多加密库都支持 HMAC。