我是否应该使用SHA256或Blake2来检查和和并签署scrypt标头？

Question

我使用scrypt作为密钥派生函数(而不是存储密码)。为了传递分离的密钥头，我使用在Colin的scrypt实现(scryptenc.c#L224)中实现的标准编码。

原

密钥头编码

• 二进制将算法标识符("scrypt\0")、logN、r、p和salt编码成48个字节的标头
• 使用SHA-256对这些字节进行校验和，并将校验和的前16个字节附加到标头中。
• 使用HMAC SHA-256对级联的工作因素和校验和进行签名，并将签名附加到报头上。

得到的96个字节构成键头。

我的需求

• 我很少需要得到钥匙，大概每天有十几次。
• 密钥来自人工生成的密码。
• 我的应用程序运行在32位系统(例如智能手机)和64位桌面上。
• 我的项目是Go，它支持SHA-256和Blake2。
• Blake2s和Blake2b的Go实现不提供128位校验和

用Blake2代替SHA-256进行校验和签名对我有什么影响吗？安全方面有什么不同吗？

如果我使用Blake2-256，我会切断16字节的校验和(这似乎是不建议)，使用32字节还是保持它就像使用SHA-256？

谢谢!

Answer 1

请注意，布莱克2‘S的安全目标是SHA-256安全目标的超集：

• Sa-256被推测为抗碰撞、抗预成像和抗第二预成像。
• Blake2被推测为随机预言不可微，这是SHA-256不具备的一个更强的属性，这意味着三个典型的散列函数属性。

所以是的，如果Blake2是安全的，这个替代应该是安全的。有一点要注意的是，对于这一步：

• 使用HMAC SHA-256对级联的工作因素和校验和进行签名，并将签名附加到报头上。

...you不想使用HMAC，因为Blake2有一个内置的键控模式，其目标与HMAC相同。(HMAC-Blake2并不是不安全的-这不是使用Blake2作为MAC的标准方式。)

如果我使用Blake2-256，我会切断16字节的校验和(这似乎是不建议)，使用32字节还是保持它就像使用SHA-256？

您所链接的答案并不是说截断Blake2总是不安全的。其要点是：

• 坚持走自己的老路通常更明智、更安全；如果有一种很好的、标准的方法来实现X，那么这通常应该是你的默认选择。(请注意，这意味着对于您描述的应用程序，您应该坚持使用SHA-256！)
• 当散列到自定义输出大小时，有时使哈希输出依赖于所需的输出大小，以避免攻击，即有人能够在不同的上下文中欺骗系统，使相同的输入散列，但将其截断到不同的长度。(更普遍地说，截断哈希函数是否安全取决于它的使用方式。)

在您的情况下，我将回到这样一个事实:您正在采用一个已经设计的协议，并用Blake2替换它对SHA-256的使用。这意味着，如果协议是安全的，那么您的替换也应该是安全的，因为如果Blake2是安全的，那么它应该具有该协议期望SHA-256提供的所有属性。因此，如果原始协议截断了SHA-256的输出，那么截断Blake2的输出也不会更糟。