我正在创建一个存储文档的应用程序，并根据一些内容（包括时间戳）的SHA1摘要为每个文档提供一个UID。摘要有很多字符，我想允许用户使用完整摘要的前x个字符来识别文档。如果文档的数量可能在10K到100K左右，那么x的值是多少？
答案 0 :(得分：20)
根据wikipedia for the Birthday problem调整公式，您可以将碰撞概率估算为e^(-n^2/(2^(b+1)))，其中n是文档计数，b是位数。 Graphing this formula with n=100,000，看起来你想要b＆gt;至少45。我更倾向于使用64来使它成为一个漂亮的圆形数字。那就是说，如果发生碰撞，确实有处理碰撞的计划（可能会略微改变时间戳，或者添加一个nonce？）
就此而言，如果sha1不仅仅基于文档的内容，为什么不简单地将它作为随机ID？在这种情况下，碰撞不是一个问题，因为你总是可以生成一个新的随机数并再试一次（然而，与单次尝试碰撞的概率是相同的）。
答案 1 :(得分：2)
小心截断，因为没有证据表明较小的散列是安全的。见Kelsey的http://csrc.nist.gov/groups/ST/hash/documents/Kelsey_Truncation.pdf。 Kelsey给出了相同的启发式参数（“相关散列输出”和“近碰撞”）。 Biham / Chen提供近碰撞的例子;和Knudsen演示了Truncated Differentials。
最后，您可能希望将数据输入HMAC 截断大小（大小也由HMAC消化），然后使用截断的HMAC。
答案 2 :(得分：1)
这确实没有价值;使SHA成为良好的通用哈希算法的部分原因是类似的数据不一定产生类似的散列值。您最好的选择（不知道有关您的系统的任何其他内容）只是搜索其哈希值以用户提供的值开头的文档列表，然后向其显示可供选择的文档列表或直接转到文档如果只有一个。
答案 3 :(得分：1)
这是generalization的the birthday problem。在你的情况下， n 是文档的数量，而不是常量365，你可以获得截止值给你的多种可能性（因此对于k位，它是2 k ）。
当然，精确计算是不可能的，但您可以使用approximation。
答案 4 :(得分：0)
嗯，这可能是一个过于简单的答案..
如果使用完全sha1，你会得到大约1 ^ 2 ^ 160的碰撞几率，那么通过截断一个角色，你可以将碰撞几率提高16（截断字符的所有可能值）......即2 ^ 4。那么，如果你截断x个字符，你会得到1 ^ 2（160 - 4 * x）碰撞的机会..对吗？