为什么叫彩虹桌呢?

发布于 2024-10-18 07:49:56 字数 55 浏览 6 评论 0原文

有人知道为什么叫彩虹桌吗?刚刚记得我们已经了解到有一种称为“字典攻击”的攻击。为什么不叫字典呢?

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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

纵山崖 2024-10-25 07:49:56

因为它包含了整个可能性的“范围”。

字典攻击是一种仅尝试可能性的暴力技术。像这样(python伪代码)

mypassworddict = dict()

for password in mypassworddict:
    trypassword(password)

但是,彩虹表的工作方式不同,因为它用于反转哈希。哈希的高级概述是它有许多 bin:

bin1, bin2, bin3, bin4, bin5, ...

它们对应于输出字符串的二进制部分 - 这就是字符串最终达到其长度的方式。随着哈希的进行,它会以不同的方式影响垃圾箱的不同部分。因此,第一个字节(或接受的任何输入字段)输入影响(简单地说)bin 3 和 4。下一个输入影响 2 和 6。依此类推。

彩虹表是对给定容器的所有可能性的计算,即对于每个容器,该容器的所有可能的逆......这就是它最终如此之大的原因。如果第一个 bin 值是 0x1,那么您需要有一个包含 bin2 的所有值以及 bin3 的所有值的查找列表,通过哈希向后工作,最终给出你一个价值。

为什么不称为字典攻击?因为事实并非如此。

正如我已经看到你之前的问题,让我详细说明你正在寻找的细节。理想情况下,从较小的输入大小到整个文件,加密安全的哈希值都必须是安全的。预先计算整个文件的哈希值将花费很长时间。因此,彩虹表是在一个易于理解的输出子集上设计的,例如所有字符 az 在 10 个字符的字段上的排列。

这就是为什么击败字典攻击的密码建议在这里起作用的原因。您放入哈希输入中的整个可能输入集的子集越多,彩虹表需要包含的内容就越多以进行搜索。所需的数据量最终变得非常大,搜索时间也变得非常大。所以,想一想:

  • 如果您的输入是 [az],包含 5-8 个字符,那么彩虹表还不错。
  • 如果将长度增加到 42 个字符,那就是一个巨大的彩虹表。 每个输入都会影响哈希,从而影响所述哈希的容器。
  • 如果您在搜索要求中添加数字[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)

mypassworddict = dict()

for password in mypassworddict:
    trypassword(password)

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:

bin1, bin2, bin3, bin4, bin5, ...

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 of bin2 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:

  • If you have an input that is [a-z] for 5-8 characters, that's not too bad a rainbow table.
  • If you increase the length to 42 characters, that's a massive rainbow table. Each input affects the hash and so the bins of said hash.
  • If you throw numbers in to your search requirement [a-z][0-9] you've got even more searching to do.
  • Likewise [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.

风为裳 2024-10-25 07:49:56

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.

enter image description here

记忆里有你的影子 2024-10-25 07:49:56

我不知道这个名字从何而来,但区别是:

  • 字典包含一些选定的项目(例如英语单词),而彩虹表包含所有可能的组合。
  • 字典只包含输入,而彩虹表包含输入和输出。
  • 字典用于测试不同的输入以查看输出是否有效,而彩虹表用于反向查找,即找到哪个输入给出特定的输出。

I don't know where the name comes from, but the differences are:

  • A dictionary contains a few selected items (e.g. english words), while a rainbow table contains every possible combination.
  • A dictionary only contains the input, while the rainbow table contains both the input and the output.
  • A dictionary is used to test different input to see if the output is valid, while a rainbow table is used for e reverse lookup, i.e. to find which input gives a specific output.
浪漫之都 2024-10-25 07:49:56

不幸的是,有些说法并不正确。与发布的内容相反,彩虹表不包含给定键空间的所有可能性,而不是我所见过的为使用而生成的可能性。它们可以生成覆盖 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文