我有一个问题，也许是一个愚蠢的问题，我想在使用 SHA1 算法散列后将数据存储在数据库中。但是，在未来的某个时间，由于 SHA1 中的 size words 很大，数据库中的大小会增加。
我们可以减小 SHA1 算法的大小，也许是一半。我为我愚蠢的问题和我糟糕的英语感到抱歉。谢谢。:D
我正在使用 JAVA。
问问题
2542 次
3 回答
12
每个哈希 20 字节（假设二进制存储）真的太多了吗？如果您当前使用十六进制编码，则切换到二进制可以为每个散列节省 20 个字节。与十六进制相比，Base64 节省了大约 10 个字节。
如果您只是截断加密散列，它仍然是一个很好的加密散列，但输出大小减小了。您需要的输出大小取决于您的应用程序。
针对随机变化的完整性检查可以使用更短的 32-64 位散列，并且不需要加密散列函数。
如果您需要唯一性，您应该>>2*log_2(entries)在哈希中包含一些位（请参阅生日悖论）。在大约 120 位时，它类似于 GUID/UUID（GUID 有一个基于 sha1 的生成模式）
如果你想要加密强度，我会避免低于 128 位。
于 2011-06-06T10:30:34.143 回答
5
不; 根据定义，SHA-1 哈希的大小为 160 位。我强烈怀疑散列的大小是否会成为问题；我想您的数据库中还有其他数据？您很可能会发现数据的其他部分对数据库大小的贡献更大。您希望这些哈希有多少行？
但是，将哈希存储为字符串（这将占用至少 40 个字节，具体取决于字符串编码）和将其存储为二进制数据（这将占用 20 个字节）之间存在大小差异。
正如其他人所指出的，您可以切换到另一种算法，但从安全角度来看，这可能不是一个好的选择 - 哈希算法的输出长度越短，它就越弱。
于 2011-06-06T10:27:48.043 回答
5
如果你减少它，它就不再是 SHA1 :)。你必须想一个不同的算法
于 2011-06-06T10:28:14.690 回答