为什么叫彩虹桌呢?
有人知道为什么叫彩虹桌吗?刚刚记得我们已经了解到有一种称为“字典攻击”的攻击。为什么不叫字典呢?
Anyone know why it is called rainbow table? Just remembered we have learned there is an attack called "dictionary attack". Why it is not call dictionary?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
因为它包含了整个可能性的“范围”。
字典攻击是一种仅尝试可能性的暴力技术。像这样(python伪代码)
但是,彩虹表的工作方式不同,因为它用于反转哈希。哈希的高级概述是它有许多 bin:
它们对应于输出字符串的二进制部分 - 这就是字符串最终达到其长度的方式。随着哈希的进行,它会以不同的方式影响垃圾箱的不同部分。因此,第一个字节(或接受的任何输入字段)输入影响(简单地说)bin 3 和 4。下一个输入影响 2 和 6。依此类推。
彩虹表是对给定容器的所有可能性的计算,即对于每个容器,该容器的所有可能的逆......这就是它最终如此之大的原因。如果第一个 bin 值是 0x1,那么您需要有一个包含
bin2
的所有值以及 bin3 的所有值的查找列表,通过哈希向后工作,最终给出你一个价值。为什么不称为字典攻击?因为事实并非如此。
正如我已经看到你之前的问题,让我详细说明你正在寻找的细节。理想情况下,从较小的输入大小到整个文件,加密安全的哈希值都必须是安全的。预先计算整个文件的哈希值将花费很长时间。因此,彩虹表是在一个易于理解的输出子集上设计的,例如所有字符 az 在 10 个字符的字段上的排列。
这就是为什么击败字典攻击的密码建议在这里起作用的原因。您放入哈希输入中的整个可能输入集的子集越多,彩虹表需要包含的内容就越多以进行搜索。所需的数据量最终变得非常大,搜索时间也变得非常大。所以,想一想:
[az]
,包含5-8
个字符,那么彩虹表还不错。[az][0-9]
,您将需要进行更多搜索。[A-Za-z0-9]
。最后,坚持[\w]
,即您能想到的任何可打印字符,同样,您正在查看一个巨大的表格。因此,使密码变得又长又复杂使得彩虹表开始采用蓝光大小的数据光盘。然后,根据您之前的问题,您开始添加加盐和哈希派生函数,并为哈希破解困难(呃)制定通用解决方案。
这里的目标是在可用的计算能力方面保持领先。
Because it contains the entire "spectrum" of possibilities.
A dictionary attack is a bruteforce technique of just trying possibilities. Like this (python pseudo code)
However, a rainbow table works differently, because it's for inverting hashes. A high level overview of a hash is that it has a number of bins:
Which correspond to binary parts of the output string - that's how the string ends up the length it is. As the hash proceeds, it affects differing parts of the bins in different ways. So the first byte (or whatever input field is accepted) input affects (say, simplistically) bins 3 and 4. The next input affects 2 and 6. And so on.
A rainbow table is a computation of all the possibilities of a given bin, i.e. all the possible inverses of that bin, for every bin... that's why it ends up so large. If the first bin value is
0x1
then you need to have a lookup list of all the values ofbin2
and all the values of bin3 working backwards through the hash, which eventually gives you a value.Why isn't it called a dictionary attack? Because it isn't.
As I've seen your previous question, let me expand on the detail you're looking for there. A cryptographically secure hash needs to be safe ideally from smallish input sizes up to whole files. To precompute the values of a hash for an entire file would take forever. So a rainbow table is designed on a small well understood subset of outputs, for example the permutations of all the characters a-z over a field of say 10 characters.
This is why password advice for defeating dictionary attacks works here. The more subsets of the whole possible set of inputs you put into your input for the hash, the more a rainbow table needs to contain to search it. The data sizes required end up stupidly big and so does the time to search. So, think about it:
[a-z]
for5-8
characters, that's not too bad a rainbow table.[a-z][0-9]
you've got even more searching to do.[A-Za-z0-9]
. Finally, stick in[\w]
i.e. any printable character you can think of, and again, you're looking at a massive table.So, making passwords long and complicated makes rainbow tables start taking blue-ray sized discs of data. Then, as per your previous question, you start adding in salting and hash derived functions and you make a general solution to hash cracking hard(er).
The goal here is to stay ahead of the computational power available.
Rainbow 是字典攻击的一种变体(准确地说是预先计算的字典攻击),但它比完整字典占用的空间更少(以在表中查找键所需的时间为代价)。这种空间与内存权衡的另一端是全面搜索(暴力攻击=零预计算,大量时间)。
在彩虹表中,预先计算的密钥-密文对字典被压缩在链中。链中的每个步骤都是使用不同的压缩函数完成的。而且桌子上有很多链条,看起来就像彩虹一样。
在这张图中,不同的压缩函数 K1、K2、K3 具有彩虹般的颜色:
存储在文件中的表仅包含第一列和最后一列,因为中间列可以重新计算。
Rainbow is a variant of dictionary attack (Pre-computed dictionary attack to be exact), but it takes less space than full dictionary (at the price of time needed to find a key in table). The other end of this space-memory tradeoff is full search (brute force attack = zero precomputation, a lot of time).
In the rainbow table the precomputed dictionary of pairs key-ciphertext is compressed in chains. Every step in chain is done using different commpression function. And the table has a lot of chains, so it looks like a rainbow.
In this picture different compression functions K1, K2, K3 have a colors like in rainbow:
The table, stored in the file contains only first and last columns, as the middle columns can be recomputed.
我不知道这个名字从何而来,但区别是:
I don't know where the name comes from, but the differences are:
不幸的是,有些说法并不正确。与发布的内容相反,彩虹表不包含给定键空间的所有可能性,而不是我所见过的为使用而生成的可能性。它们可以生成覆盖 99.9,但由于哈希函数的随机性,无法保证覆盖每个明文。
每个链都由链接或步骤组成,每个步骤都由哈希和归约函数组成。如果您的链有 100 个链接长,您将使用该数量的哈希/归约函数,然后丢弃除开始和结束之外的所有内容。
要找到给定哈希的明文,您只需执行链长度的减少/哈希 x 量即可。因此,您运行该步骤一次,并检查端点,如果未命中,您将重复...直到您走完链的整个长度。如果存在匹配,您可以从起点重新生成链,并且您也许能够找到平原。如果再生后不正确,则这是误报。发生这种情况是由于归约哈希函数引起的冲突。由于该表包含许多链,因此您可以在每一步对所有链端点进行大量查找,这本质上就是实现速度的神奇之处。这也会导致误报,因为您只需要重新生成匹配的链,您可以通过跳过不必要的链来节省大量时间。
它们不包含字典......好吧,不是传统的表格,而是彩虹表的变体,其中包含字典的使用。
就是这样。这个过程有很多优化的方法,包括删除合并/重复链和创建完美的表,并将它们存储在不同的包装中以节省空间和加载时间。
Unfortunately some of the statements are not correct. Contrary to what is bring posted rainbow tables DO NOT contain all the possibilites for a given keyspace well not the ones generated for use that I've seen. They can be generated to cover 99.9 but due to the randomness of a hash function there in no gurantee that EVERY plaintext is covered.
Each chain is made up of links or steps and each step is made of a hashing and reduction function. If your chain was 100 links long you would go that number of hash/reduction functions then discarding everything in between except the start and end.
To find the plain for a given hash you simply perform the reduction / hash x amount of the length of your chain. So you run the step once and check against the endpoint if it's a miss you would repeat... Until you have stepped through the entire length of your chain. If there is a match you can then regenerate the chain from the start point and you may be able to find the plain. If after the regeneration it is not correct then this is a false alarm. This happens due to collisions caused by the reduction hashing function. Since the table contains many chains you can do a large lookup against all the chain endpoints each step, this is essentially where the magic happens allowing speed. This will also lead to false alarms, since you only need to regenerate chains which have matches you save lots of time by skipping unnecessary chains.
They do not contain dictionaries.... Well not the traditional tables there are variants of rainbow tables which incorporate the use of dictionaries though.
That's about it. There are many ways which this process has been optimized including removing merging / duplicate chains and creating perfect tables and also storing them in differing packing to save space and loading time.