我试图了解比特币协议,有时会看到类似这样的指令:


TransactionId由SHA256(SHA256(txbytes))


or


通过对公钥执行SHA256哈希,然后对结果执行RIPEMD160哈希,并使用Big Endian表示法来生成公钥的哈希。该函数可能如下所示:RIPEMD160(SHA256(pubkey))


出于什么目的,两次计算了哈希?

评论

另请参阅crypto.stackexchange.com/questions/779/…(也许重复?)

bitcoin.stackexchange.com/questions/9202/…

#1 楼

进行两次哈希的一个常见原理是防止哈希的长度扩展属性(如果具有该属性,则与SHA-3之前的许多哈希一样)。对于SHA-256,此属性允许知道$ \ operatorname {SHA-256}(X)$和$ X $的长度,从而计算$ \ operatorname {SHA-256}(X \ | Y \ | Z)$一些简短的$ Y $函数仅具有$ X $的长度,而某些函数具有给定的$ Z $(无论未知的$ X $可能是什么)。这可能是个问题,请参阅此问题。

另外,使用SHA-256和RIPEMD-160的基本原理可能是:


第一个-对两个散列中的任何一个进行的映像前攻击(能够反转散列)不太可能破坏组合,可以说提高了对未来可能发生的攻击的弹性。
因为第二个散列比第一个散列短,所以结果分布更近随机(用相同的哈希值进行两次哈希处理的缺点是未达到输出值的三分之一;但这无法通过计算检测到。)
防止对迭代到相同哈希值的攻击在某些假设的工作量证明协议中两次;参见Yevgeniy Dodis,Thomas Ristenpart,John Steinberger,Stefano Tessaro:要再次哈希还是不再哈希? Hrypto和HMAC的可区分性结果,在Crypto 2012程序中,以及我的反托拉斯。
现有的蛮力搜索装置不太适合;新颖性安全性只能在很短的时间内起作用,但可能会使那些对设计决策有较深了解的人提前一些时间。
这是使用这4个属性指定160位哈希的一种简洁方法

请注意,第二个哈希的输入很短,因此速度很快;对于第一个和整个哈希的大量输入,构造效率仅比单个哈希稍低。

评论


$ \ begingroup $
很有道理,但我要补充一点,SHA3的后继产品SHA3可以抵抗长度扩展攻击。因此,将来也许可以避免这种双重SHA-256计算。
$ \ endgroup $
– juhist
17年7月10日在13:19

$ \ begingroup $
@juhist:我不知道SHA3是如何工作的,但是我认为它可能在最后进行了内部额外的最后一轮哈希运算,实际上等效于此……是正确的吗?
$ \ endgroup $
–user541686
17年7月11日,0:15



$ \ begingroup $
@Mehrdad:SHA-3使用海绵构造,其中消息在至少一个回合中首先被“吸收”,并且在最后“压缩”回合中(可能为零)提取结果。 )。由于不输出状态(c)的一部分,因此与SHA-512 / 256一样,它固有地不受长度扩展攻击的影响。
$ \ endgroup $
–fgrieu♦
17年7月11日在3:47



$ \ begingroup $
@fgrieu:嗯,是的,听起来像他们像我期望的那样在开头和结尾基本上增加了另一轮,所以无论如何内部都已经发生了。太好了,谢谢!
$ \ endgroup $
–user541686
17年7月11日在3:55