相关疑难解决方法(0)

给定两个不同的字符串S1和S2(S1!= S2)可能是:

SHA1(S1) == SHA1(S2)

是真的？

1. 如果是 - 有什么概率？
2. 如果没有 - 为什么不呢？
3. 输入字符串的长度是否有上限,获取重复的概率为0？OR是SHA1的计算(因此重复的概率),与字符串的长度无关？

我想要实现的目标是散列一些敏感的ID字符串(可能与其他字段(如父ID)连接在一起),这样我就可以使用散列值作为ID(例如在数据库中).

例:

Resource ID: X123
Parent ID: P123

我不想公开我的资源标识的性质,以允许客户端看到"X123-P123".

相反,我想创建一个新的列散列("X123-P123"),让我们说它是AAAZZZ.然后客户端可以请求ID为AAAZZZ的资源,而不知道我的内部id等.

我正在开发一个搜索系统的后端应用程序.搜索系统将文件复制到临时目录并为其提供随机名称.然后它将临时文件的名称传递给我的应用程序.我的应用程序必须在有限的时间内处理每个文件,否则它将被关闭 - 这是一种看门狗般的安全措施.处理文件可能需要很长时间,所以我需要设计能够处理这种情况的应用程序.如果我的应用程序在下次搜索系统想要索引同一文件时关闭,它可能会给它一个不同的临时名称.

显而易见的解决方案是在搜索系统和后端之间提供一个中间层.它会将请求排入后端并等待结果到达.如果请求在中间层超时 - 没问题,后端将继续工作,只有中间层重新启动,并且当搜索系统稍后重复请求时,它可以从后端检索结果.

问题是如何识别文件.他们的名字随机变化.我打算使用像MD5这样的哈希函数来散列文件内容.我很清楚生日悖论,并使用链接文章中的估计来计算概率.如果我假设我有不超过100 000个文件,那么具有相同MD5(128位)的两个文件的概率大约为1,47x10 ^-29.

我应该关心这种碰撞概率还是假设相等的散列值意味着相同的文件内容？

我想在数据库表中使用PHP生成的唯一ID,该表可能永远不会超过10,000条记录.我不希望创建时间可见或使用纯数值,所以我使用:

sha1(uniqid(mt_rand(), true))

使用哈希作为唯一ID是错误的吗？不是所有的哈希都会导致碰撞,或者是否有机会如此遥远以至于在这种情况下不应该考虑它们？

还有一点:如果要散列的字符数小于sha1散列中的字符数,它是否总是唯一的？

说我有一个5000字符的文字.我通过散列程序运行它并生成一个40 char长的散列.现在我运行另一个文本blob,10000个字符.它仍然会产生40个字符长的哈希值.对于任何长度的文本都是如此.

我的问题是,如果哈希值都是唯一的,我不能将任何东西压缩成40个字符串吗？

我正在建立一个网站,将存储数百万图像,所以我需要每个图像的唯一ID.什么密码术最适合存储图像.现在这是我的代码看起来像使用SHA1.

是否在sha1旁边使用了标准哈希,两个图像是否可能具有相同的哈希码？

 Image img = Image.FromFile("image.jpg");

 ImageConverter converter = new ImageConverter();
 byte[] byteArray = (byte[])converter.ConvertTo(img, typeof(byte[]));

 string hash;

 using (SHA1CryptoServiceProvidersha1 = new SHA1CryptoServiceProvider())
 {
     hash = Convert.ToBase64String(sha1.ComputeHash(byteArray));
 }

我需要生成可以在文件名中使用的唯一标识符，并且可以在给定相同的输入值的情况下进行复制。我需要生成数百万个这样的标识符，因为源输入有数百万种组合。

为简单起见，我将在示例中使用一个小的集合，但实际的集合可能会相当大（数百，也许数千个项目）；大于可以手动编码为文件名。

我注意到生成 UUID 的第 5 种方法允许您提供字符串输入。

> input_set = {'apple', 'banana', 'orange'}
> uuid.uuid5(uuid.NAMESPACE_URL, pickle.dumps(input_set)).hex
'f39926529ad45997984643816c1bc403'

文档说它SHA1在幕后使用。碰撞风险是否太高？有没有更好的方法来可靠地散列唯一标识符？

每次进行提交时，git / hg都会生成一个SHA来在存储库的历史记录中唯一标识该提交。

假设我要合并两个存储库（我们没有关于哪个存储库的信息）。这就提出了一个问题：如果有人想要提交相同合并仓库的特定提交，会不会有重复的SHA哈希值在引起评论时混淆git？如果不是这样，git会做什么？

最终，我猜问题还是：全世界的每个存储库都有重复的哈希值吗？

使用我的webapp，我将使用散列生成的文件名将缓存的文件存储在各个子目录中，以优化性能水平。我知道可以提高性能的一种方法是，确保生成的名称遵循8.3文件名结构，这样NTFS不必生成短文件名（我将无法在注册表中进行设置）。

为了做到这一点，尽管我必须将哈希（我在想SHA1）修剪为8个字符，但是显然这将大大增加冲突的可能性。我想知道碰撞的可能性是多少？

我在这里看到了完整的SHA1哈希冲突率的答案，但是我的数学很糟糕，因此计算值远远超出了我的范围。