【发布时间】：2013-06-27 14:41:51
【问题描述】：
当使用 SHA-256 对字符串（如密码）进行哈希处理时，我正在哈希处理的字符串的长度是否有限制？例如，对小于 64 个字符的字符串进行哈希处理是否“安全”？
【问题讨论】：
【发布时间】：2013-06-27 14:41:51
【问题描述】：
技术上存在限制，但非常大。用于 SHA-256 的填充方案要求输入的大小（以位为单位）表示为 64 位数字。因此，最大大小为 (264-1)/8 字节 ~= 2'091'752 TB。
这使得限制几乎完全是理论上的，而不是实际的。
无论如何，大多数人都没有存储几乎那么多数据的存储空间，但即使他们有，连续处理所有数据以生成单个散列也将花费大多数人认为令人望而却步的时间。
粗略的计算表明，即使是目前最快的企业级 SSD1 列在 Tom 的硬件上，并将它们条带化 16 宽以提高带宽，仅读取该数量的数据仍然需要大约 220 年。
1. 截至 2016 年 4 月。
【讨论】：
-
分组密码技术可以应用于大于等于 2^64 字节的输入。
-
@ErkinAlpGüney：SHA-256 不是分组密码（或任何其他类型的密码）。这是一个哈希。当然，散列也可以应用于大型输入——但大于 2^64 位（更不用说 2^64 字节）并不是大多数人需要担心的事情。那些这样做的人将需要使用 SHA-256 以外的东西来这样做（尽管根据他们的需要，他们唯一需要更改的部分很可能是填充）。
没有这样的限制，除了最大消息大小为 264-1 位。 SHA2 经常用于为可执行文件生成哈希值，这些哈希值往往比几十个字节大得多。
【讨论】：
-
我试图理解您的回答：您的意思是 2^{64}-1 位还是 65 位长度？ 2^64 是相当多的位。
-
前者，@Stefan。是的，这是很多位。 :-)
-
哈哈 - 好吧，我不需要那么多位，但很高兴知道。谢谢！
上限在 NIST 标准FIPS 180-4 中给出。上限的原因是the padding scheme 以对抗Merkle-Damgard 构造的神器的MOV 攻击。消息长度l 最后在填充期间附加到消息中。
然后附加等于用二进制表示的数字
l的64位块
因此，根据 NIST 标准，可以使用 SHA-256 进行哈希处理的最大文件大小为 2^64-1（以位为单位）（大约 2.305 艾字节 - 接近 the lower range of the estimated NSA's data center in UTAH，因此您无需担心）。
NIST 启用大小为零消息的散列。因此消息长度从0 到2^64-1。
如果您需要对大于 2^64-1 的文件进行哈希处理，请使用具有 2^128-1 限制的 SHA-512 或使用没有限制的 SHA3。
【讨论】：
-
没关系，或多或少 1 EB ;)，删除 cmets。