不确定这是否可行,但我希望能够以字符串开头,然后找出输入必须进入crypt
以便将此字符串输出。
或者也许这是不可能的,这无论如何都是事情的全部目的?
是的,代码中有一个盐,我正在尝试这个。
答案 0 :(得分:14)
根据设计意图,crypt()
是单向散列。正如大家所说,这意味着意图是发现产生相同哈希的明文字符串在计算上是不可行的。
有几个因素会对设计意图产生影响。
计算比<{1}}设计时的批次便宜。更糟糕的是,没有预料到计算成本降低的速度,所以它现在比它想象的要便宜很多。
DES并没有像人们想象的那样坚持下去。然而,鉴于当时公众的知识状况,这可能是最好的选择。
即使计算还不够便宜,无法自行破解,互联网云已经为你做了很多工作。人们一直在计算和发布Rainbow Tables,这使得快速反转特定哈希所需的大量计算成为可能。 (Jeff had a blog post on rainbow tables too。)Salt有助于防止彩虹表(因为你需要为盐的每个可能值设置一个表),但crypt()
的经典实现中使用的盐的大小只是12位,因此不像希望的那么大。
更糟糕的是,对于某些高价值的哈希函数(例如LM hash为旧的Microsoft Lan Manager密码发明但在Vista之前的所有版本的Windows中用于短密码)几乎完整的哈希及其反转词典存在
答案 1 :(得分:4)
如果它是crypt(3)
的旧实现,使用DES,那么你几乎可以(但不是完全)暴力破解它。
在该方案中,输入被截断为8个字符,每个字符为7位,这意味着要搜索的是不同密码的56位空间。
仅对于DES,您可以在价值10万美元的FPGA(http://en.wikipedia.org/wiki/Data_Encryption_Standard#Brute_force_attack)上搜索整个空间大约18天,因此预计时间为9天。但我假设你没有花10万美元来解决这个问题。再过几年,谁知道DES破解者是否会在PC的GPU上运行合理的时间。
即便如此,crypt(3)
传统上涉及25轮DES,对基于盐的算法稍作修改,因此您可以预期它至少比蛮力慢25倍。
crypt(3)
的较新实现超出了蛮力,因为它们基于更好的哈希算法,而不是基于DES的旧crypt(3)
使用的哈希算法。
当然如果字符串不是随机的(例如,如果它是某人选择的密码),那么你可以获得比蛮力更好的预期时间。
答案 2 :(得分:2)
不,这就是单向散列函数背后的想法,但在某些情况下你可以使用google来帮助你。
要回答对此答案的评论(如果有盐,谷歌将无济于事)我说:是和否。盐增加了解决方案的空间,使得完整字典的创建变得不那么容易(因为对于每个单词,您必须为每个可能的双字母盐计算和存储一个加密版本)。如果你假设互联网是一个巨大的数据库,并谷歌它的索引,谷歌做的是搜索是否在网络中出现加密字符串的某处。盐的存在减少了你找到它的机会,但是如果你足够幸运的话,这个事件存在,并且它也与明文一起,那么你有密码。
结论:盐将降低在网络上找到特定加密字符串的机会,这是真的,但谷歌对任何数量的盐都无动于衷,并且如果你碰巧幸运的话,它仍然可以帮助(因为它是我给的情况。)
答案 3 :(得分:1)
没有
crypt()不是一种可逆算法(它使用单向函数),通过向加密值添加盐,使其更难以暴力破解。
根据评论编辑。
答案 4 :(得分:0)
不可以看看这个网站(假设你使用的是GNU C库)http://www.gnu.org/s/libc/manual/html_node/crypt.html
地穴被盐腌的方式几乎可以保证您尝试做的事情无法发挥作用。
答案 5 :(得分:0)
单向的功能是世界上每个密码方案的支柱。如果这里的任何人都回答“是的,而且这里是怎样的......”,政府将被迫立即删除他们的评论,烧毁他们的房子,并将他们带到一个秘密地点。
简而言之,没有。
答案 6 :(得分:-1)
不,这是一个单向的功能。