Hash 以时间换空间

Hash 以时间换空间,hash,compression,computer-science,Hash,Compression,Computer Science,只要花一点钱,一台服务器就可以制造出35万亿次的速度。这大约是每秒2^45次操作,考虑到开销和其他因素,我认为生成32-40位信息可以在一秒钟内完成。一个1MB的文件可能需要70个小时才能生成,每秒32位 我有一个特定的用例,在这个用例中,花700小时从100KB“解压缩”1MB文件是很有用的。我熟悉鸽子洞原理、生日悖论以及为什么递归压缩实际上不可能。然而,我们固执地认为,我们可以列举所有32位的可能性,找到一些哈希函数输出或某种蛮力方法的匹配项,并利用数学的本质来帮助缩小问题空间 我最初是通过

只要花一点钱,一台服务器就可以制造出35万亿次的速度。这大约是每秒2^45次操作,考虑到开销和其他因素,我认为生成32-40位信息可以在一秒钟内完成。一个1MB的文件可能需要70个小时才能生成,每秒32位

我有一个特定的用例,在这个用例中,花700小时从100KB“解压缩”1MB文件是很有用的。我熟悉鸽子洞原理、生日悖论以及为什么递归压缩实际上不可能。然而,我们固执地认为,我们可以列举所有32位的可能性,找到一些哈希函数输出或某种蛮力方法的匹配项,并利用数学的本质来帮助缩小问题空间

我最初是通过使用sha-256或其他一些尚未发现冲突的散列函数来思考这个问题的(尽管与任何给定鸽子洞的散列函数都有无限多的冲突,如果我碰巧与sha-256发生冲突,那么至少对研究来说是重要的)

提供224位原始数据以及256位散列。最后32位信息被枚举,直到找到哈希的匹配项。现在,存储224+256位信息以返回256位并不是任何类型的数据压缩,但这是首先想到的方法

最大的开销是发送散列,所以我尝试研究像CRC32这样的32位散列函数,但是冲突的概率太高了。看起来普通散列是不可行的,您需要散列的输出小于我们可以合理计算的值(~40位),并且没有足够的散列空间来避免冲突。现在,如果我们可以进行2^256次计算(quantum?),那么256位散列可以被使用,因为冲突的概率很低,可以使用

我稍微研究了一点局部性敏感的哈希函数,希望在给定局部性的情况下,即使哈希大于32位,我也可以将问题空间限制为2^32计算,但这并没有真正显示出希望

我正在寻找关于如何验证和生成数据的想法/建议,假设您有大约100天的时间来解压缩/生成当前的计算能力(设备不足1万美元,但ASIC/FPGA是公平的游戏)。可以理解的是,我可能在追求一些不可行甚至不可能的东西,但探索这些想法并扩展我的计算机科学知识比整天玩电子游戏要好得多。

(顺便说一下,我部分理解这个问题)

这个问题类似于从斐波那契序列中求出项。如果我让某人算出斐波那契序列的第四项,他们会把第二项和第三项相加,但要做到这一点,你需要算出第三项和第二项。你可以看到这花费的时间太长了。您可以尝试将您正在做的任何事情分解为更小的步骤,使其更简单,这样您就有更多的空间或使用更少的空间来实现较慢的解决方案

我不知道这是否有帮助,但如果有,我希望一切都会成功

祝你好运