数字签名应用中使用中间散列优于全散列的优点

Question

中间散列的

描述

中间(或部分)散列是摘要状态的规范形式，可以从一个哈希实现传输到另一个哈希实现，以便另一个有限的设备(例如智能卡芯片)能够使用剩余的数据完成哈希计算。该方案用于创建一个由执行计算的设备组成的签名生成系统。

所以：

1. 终端通过处理消息的第一I块生成中间哈希；
2. 终端向智能卡发送中间散列；
3. 智能卡使用最后的(N )数据块完成散列；
4. 智能卡创建签名并发送回终端；
5. 把签名发回。

而不是：

1. 终端产生全散列；
2. 终端将全部散列发送到智能卡；
3. 智能卡创建签名并发送回终端；
4. 把签名发回。

显然，如果要散列的数据很大，让智能卡生成一个完整的散列在性能方面有缺点。这仍然是一个选项，例如，当签名是在签名属性而不是内容本身上生成时。

在SHA-1、SHA-2或SHA-3标准中没有指定中间散列.

使用中间散列

的可能原因

在我的前一个问题中，我已经询问过其他协议是否使用部分散列。由于反馈数量有限，我可能不得不得出结论，它们不是经常使用的。

我想过，中间散列可能被用来避免秘密通道，即在签名生成中插入哈希以外的数据。不过，我不确定这是否会构成重大威胁(因为哈希的提供者也可以提供任何其他哈希)。

问题

使用中间/部分散列代替终端提供的全散列有什么密码原理？

Answer 1

有两点我可以想象，在协议中的部分散列可能是有用的。

来自同一起点的

大规模并行计算

如今，使用中间状态作为PoW的基础，似乎已成为比特币专用集成电路的标准做法，其速度将提高几十%。从技术上讲，您可以在下一个块中预先计算您想要的内容，然后将它发送给ASIC，以便它们执行最后的压缩函数调用，并查找正确的属性。

管理限制/可信签名的数据显示

可能会有类似“可信计算设备已经看到实际事务数据”的管理限制，其中签名在发送方、收件人和金额上。现在标准要求您在卡片/读卡器控制的可信显示器上显示收件人和数量，但是您可以通过为不需要额外评估的部分预计算散列来节省一些计算时间。在这里，安全的好处在于，卡实际上知道它签名的内容，而不仅仅是一些随机的blob (这也可能是一个恶意的交易！)。

Answer 2

目前，我有一个有点类似的要求。

其任务是为事务数据提供硬件签名(智能卡、远程HSM)。其特点是，在签名期间，必须将签名计数(每个证书)和时间戳添加到有效载荷中。另一方面，细节事务数据应该保持私有，只有一个>intermediate<哈希应该显示给签名设备。

签字过程将是：

被请求者: hash0 =Hash.update(数据).intermediate()

通过HSM:散列= Hash.resume(hash0).update(signCount+signTime).digest()

             signature = Certificate.sign(hash)

核查将是：

     hash = Hash.update(data+signCount+signTime).digest()

     result = Certificate.verify(hash, signature)

目前，这只能通过两步哈希来实现。这并不是一个真正的问题，但解决方案并不像可能的那样优雅。