【发布时间】：2014-07-28 02:31:52
【问题描述】：
我正在研究不同处理器上 SHA1 、 SHA-256 、 SHA-512 的速度（计算哈希的时间）
这些散列算法可以分解为跨多个内核/线程运行吗？
【问题讨论】：
标签： multithreading hash sha
【发布时间】：2014-07-28 02:31:52
【问题描述】：
如果您想知道并行计算单个哈希的执行（无论风味 1、256 还是 512），那么答案很遗憾是否定的。这是因为 SHA 变换函数的定义方式。它对固定大小的块进行操作，但每个块的转换输出是 next 需要的，因此您不能并行运行计算。
显然，对于不同的输入字符串，可以并行运行多个哈希，但我假设你已经知道了。
如果您只想使用底层 SHA 转换为大型输入生成摘要，您可以定义任意方案来分割输入，然后为每个段并行生成摘要块。然后结合这些等等..
类似这样的：
| ------------------ large input ---------------------------------------------|
| b0 | b1 | b2 | | | | bn |
您可以并行生成H(b0), H(b1), .. H(bn)。
然后，生成H_OUT = H(H(b0) + H(b1) + .. + H(bn))（其中+ 符号可以是串联或简单的异或，但这些很可能不是具有加密强度）。
此方法将受益于多核，但H_OUT 将不等同于计算原始大输入的单个哈希。
【讨论】：
-
在这里使用 XOR 会很糟糕。黑客可以将两个块交换在一起，制作一个具有相同哈希值的损坏文件，或者如果文件中的一个块重复，他可以只更改两个块并仍然获得相同的哈希值。如果你使用 XOR，你应该做一些诸如 H(bn xor n) 而不是 H(bn)，
-
是的，关于简单的 XOR 不适合加密，你是绝对正确的。我已经更新了答案
-
即使
H(bn xor n)也容易受到攻击，如果块本身恰好包含抵消计数器的递增数字。坏人可以构造这样的文件来产生冲突，但即使没有坏人，递增数字在现实世界的输入中也很常见。 -
如果输入太大以至于您也想并行化最终的连接步骤，您可以使用 Merkle 树而不是更简单的哈希列表。
-
我对这种说法感到困惑：这些很可能不是密码学强大的。你的意思是 XOR 在密码学上不强，或者并行散列的方式在密码学上不强？