如果我有 3 个字段“以明文形式”公开，并且我想对这些字段进行数字签名，以确保它们不会被使用安全散列函数篡改。我有两个选择：
显然，方法 1 会比方法 2 更快，但方法 2 会更“强大”，以防止人们通过对来自各种输出的输入进行逆向工程来发现盐的价值（我相信是这样，但是值得额外的CPU成本）？
使用 HMAC（基于散列的消息验证码）而不是尝试自己编造。它将更加安全，并且几乎任何平台都已经有一个免费的实现，您可以使用它来开发、测试和维护其他人。
谁能说它是否“值得额外的cpu成本”？你会多久做一次？你真的需要购买更多的CPU吗？你付多少电费？另一方面，如果有人成功篡改了受自制算法“保护”的数据，你会付出什么代价？
首先，我必须发布散列未签名的标准注释。数字签名是一个涉及密钥和验证者的过程。在这里，您只想散列一些数据并将散列值保存在“安全”的地方，以便您可以将散列值的完整性扩展到散列数据：确保散列值未被篡改，并且，通过重新计算数据元素的哈希值并找到相同的哈希值，您可以确信字段元素没有被篡改。
然后我必须发布第二个标准评论，即在实际条件下适当衡量之前没有性能问题。散列很快。即使使用不那么快的哈希函数，一台基本的 PC 也将能够每秒执行数百万次哈希运算。
现在，我看到您想使用“盐”。盐是一段公共数据，其目的是为每个实例区分，以防止解密成本分摊。这在有一些加密数据的设置中是有意义的；据我从您的描述中可以看出，您的问题中没有任何加密内容。
...除非您实际上意味着您将保密您的“盐”，并将哈希值与数据字段一起存储。在这种情况下，我们不再谈论散列。您的“盐”更适合称为“钥匙”，因为它是为了保密。而且您不需要哈希，而是MAC。有时，MAC 被称为“签名”。这是不恰当的，但比将哈希称为“签名”更不恰当。如果您想要的是 MAC（并且您的 salt 确实是一把钥匙），那么您不应该使用任何一种结构。构建 MAC 并不容易：许多手工制作的结构在安全性方面完全失败。幸运的是，有一个标准的 MAC，叫做HMAC. HMAC 使用底层散列函数（使用 SHA-256）和以智能方式将它们转换为 MAC 的密钥。许多加密库都支持 HMAC。