考虑到彩虹表的简单性和优雅性，我发现了彩虹表针对密码分析人员的论文的创建者很难接近，因此这是外行的概述。
哈希函数将纯文本映射为哈希，因此您无法从其哈希中分辨出aplaintext。
如果要查找特定哈希的给定纯文本，则有两种简单的方法：-逐个哈希每个纯文本，直到找到哈希。 -逐个散列每个纯文本，但是将每个生成的散列存储在分类表中，以便以后可以轻松查找散列而无需再次生成散列
一张一张地花费很长时间，并且存储每个散列会占用相当数量的内存，而该内存根本不存在（除了最小的纯文本集以外的所有内存）。 Rainbow表是预计算和低内存使用之间的折衷方案。
理解Rainbow表的关键是理解（无用命名）归约函数。哈希函数将纯文本映射为哈希，归约函数将哈希映射为纯文本。
重要的是要注意，它与哈希函数（将哈希映射到纯文本）相反，但它是/ not /反向哈希函数。散列函数的全部目的是无法实现逆散列函数。如果您采用纯文本的哈希值，并进行哈希值的缩减，它将不会给您原始的纯文本；而是其他一些纯文本。
如果明文集是[0123456789] {6}（我们希望彩虹表包含所有长度为6的数字密码），并且哈希函数是MD5（），则明文的ahash可能是MD5（“ 493823”）->“ 222f00dc4b7f9131c89cff641d1a8c50”。在这种情况下，约简函数R（）可能就像从哈希中获取前六个数字一样简单； R（“ 222f00dc4b7f9131c89cff641d1a8c50”）->“ 222004”。现在，我们从先前纯文本的哈希中生成了另一个纯文本，这是归约函数的目的。
散列是单向函数，归约函数也是如此。组成彩虹表的链是单向哈希和归约函数的链，它们从某个纯文本开始，并以某个哈希结束。彩虹表中的链以任意明文开头，哈希表将哈希简化为另一个明文，然后对哈希表进行哈希处理。新的明文，依此类推。该表仅存储起始明文，以及您选择结束的最终哈希，因此仅包含一个起始明文和一个结束哈希就可以表示“包含”数百万个hashe的链。
生成许多链后，表可能看起来像：iaisudhiu-> 4259cc34599c530b1e4a8f225d665802 oxcvioix-> c744b1716cbf8d4dd0ff4ce31a177151 9da8dasf-> 3cd696a8571a843cda453a229d741843 [...] sodifo8d
现在可以使用链条了。我们有一个带有未知明文的哈希值，我们想检查它是否在生成的链中。
算法为：如果存在哈希循环，请在最终哈希列表中查找哈希。
如果哈希值与最终哈希值之一匹配，则哈希值与最终哈希值匹配的链包含原始哈希值。
现在，您可以获取该链的起始纯文本，并开始对其进行哈希处理和归约，直到您知道已知的哈希及其秘密纯文本为止。
通过这种方式，您可以遍历链表中的散列，这些散列实际上并没有存储在磁盘上的任何地方，方法是从链表的最后一列开始，从链的最后一列向后遍历，直到起始的明文，然后逐列进行迭代。
如果要检查所减少的任何链的最后一列中是否存在哈希，然后对给定的哈希进行一次哈希，请对照链末哈希检查生成的哈希。
您可以通过减少和哈希两次来检查倒数第二列，然后根据链端哈希检查生成的哈希。
然后通过减少和哈希三次来检查第三个，然后对照链端哈希检查生成的哈希。
假设一个链的末端匹配生成的哈希，匹配的链末端可能包含该哈希。可以减少和散列与结束哈希一起存储的起始明文，直到在链中找到正确的明文为止。
碰撞是Rainbow Tables唯一的问题。具有讽刺意味的是，对于哈希算法而言，冲突被认为是一件坏事，但是在Rainbow Tables的情况下，定期生成冲突的哈希算法将更加安全。给定的散列可能由多个纯文本生成（这称为冲突），这对于链来说是个大问题，因为它会导致开始时不同的链会聚为一个。此外，您还会得到循环，这是将散列简化为在链中上一个点进行散列的纯文本时引起的。
由于存在这些冲突问题，因此无法保证会有纯文本的散列减少到其他给定的纯文本。如果您有一个哈希表和对应的明文的简单列表，那么集合中的每个明文都将知道，如果您在生成的哈希表中找不到哈希，则生成哈希的明文不在集合中。如果您有一个链表，其中归约函数将阴影减少到纯文本集中，则可能会生成数万亿条链，但是您可能仍未生成要检查的每个明文。您只能说一个链表包含某个明文的可能性有多大，它可以接近1，但可能永远不会达到1。如果您的彩虹表有10个链，长度为100，则您可以散列1000个明文，即使存在一组所需的纯文本中只有100个纯文本，您在链中拥有的1000个哈希可能未包含所有所需的哈希。
处理碰撞的方式使Rainbow Tables与1980年开发的前身有所不同。
以前的版本解决了某些明文从未通过使用许多小表而减少的问题。每个小表使用不同的归约函数。这不能完全解决问题，但可以帮上忙。为了解决链合并和循环，每个链都以“不同点”结尾；该散列在某种程度上是唯一的，例如散列，其中前4个字符为0。这些链一直持续到到达一个不同点为止。如果两个链条在相同的不同点结束，则该链条中的某处会发生碰撞，并且丢弃其中一个链条。如果生成链的时间异常长而没有到达一个明确的点，则可能会怀疑存在循环（哈希链会减少并哈希到链中的前一个哈希）。如果存在冲突，则可能存在冲突整个分支，必须将其切断，并且不能将其插入链中，而循环将导致丢弃链中循环之前的所有哈希。而且，花费在生成该链上的所有时间都将被浪费，并且仅通过在不同点结束，您就拥有了可变长度的链。这意味着您可能必须在其他链结束后很长的一段时间内继续检查哈希是否特别长。
Rainbow表的不同之处在于，它们不使用具有不同归约功能的多个表，而仅使用一个表。但是，在彩虹表中，每列使用不同的归约函数。这样就不需要具有不同归约函数的不同表，因为在同一表中使用了不同的归约函数。希望的集合中的所有纯文本都不太可能被散列，但是对于给定数量的链，机会更大。链合并要少得多，因为冲突必须发生在同一列上。对于长度为l的链，导致合并的碰撞几率减少到1 / l。循环也得到了解决，因为如果链中的ahash与先前的哈希相同，则不会减少为相同的明文。
之所以将它们称为Rainbow Tables是因为每一列都使用不同的归约函数。如果每个归约函数是不同的颜色，并且您在顶部具有开始的纯文本，在底部具有最终的哈希，则它看起来像彩虹（垂直方向很长很细）。通过使用Rainbow Tables，剩下的唯一问题是您无法确定链条包含所有所需的哈希值，要从给定的Rainbow Table获得更高的成功率，您必须生成越来越多的链条，并获得递减的收益。
我希望通过解释彩虹桌，我并没有让他们变得更美好...
本节可能会超出一些门外汉所熟悉的范围，但是如果您对以上理论的实际应用感兴趣或对密码学有兴趣的话。
Rainbowcrack应用程序是大多数人了解Rainbow Tables的方式，因为正是这种应用程序将上述理论纳入了代码。它已经非常成功，许多网站致力于生成Rainbowcrack哈希表并允许用户搜索它们。
但是，从某种意义上来说，可以很轻松地改进此应用程序的一种很明显的方法，即所生成的表将占用更少的磁盘空间，但在打破哈希值方面同样有效：
记住上面，当您想要生成某个链时，您将从任意哈希开始。这只是意味着选择从哪里开始都没有关系。 rainbowcrack应用程序从随机生成的64位数字开始。然后使用该数字生成一条链，该链最终以128位哈希结束，该哈希被减少为另一个64位数字。
为什么要使用随机生成的数字作为起点？伪随机数生成器可以从单个输入数字生成大量看似随机的数字。为什么不制作一个随机输入数字，然后存储生成伪随机数的数字索引呢？
因此，例如，像RC4这样的密码就是伪随机数生成器。假设单个输入数字（即“种子”）为18092398。RC4生成的前64位可能会给出一个数字“ 091358029384092”，以启动链接。第二个64位可能会给出多个“ 123793582983480”，以启动第二个链接。对于第三条链，third64位可能会给出“ 1089324083486”，对于数十亿条链来说可能依此类推。
就像Rainbowcrack一样，这与为每个链存储一个随机的64位数字有什么区别？只需简单地将Rainbowcrack表中的起点存储为随机生成的64位数字即可。使用随机数生成器的起点仅需要单个输入数字（“种子”）和链号。因此，在上面的示例中引用第三条链时，如果您想知道“ 1089324083486”的起点，则只需要知道“种子”号，它是生成的第三个64位号。那就是数字“ 18092398”和数字“ 3”。要知道第四条链的起点，您只需要知道“种子”（“ 18092398”）和数字“ 4”即可。
如果您有2 ^ 64个链（1,844,674,407,370,955,616,616），则不会有任何区别，但这将是4194304 terrabytes，远大于曾经生成的任何Rainbow Table。对于具有2 ^ 28（268,435,456）链的更现实的Rainbow表，您只需要一个28位数字，而不是像Rainbowcrack当前那样存储64位数字。从每条链的（64位+64位）到每条链（28位+64位），再加上每张表一个64位“种子”数，这是一个改进。当您谈论数百万条链时，对于具有相同散列破坏能力的数据，这是非常大的减少。
在此示例中，rainbowcrack表将为2 ^ 28 *（64位随机起始编号+ 64位链结束编号）（4096 MB）。使用伪随机数生成器，该表将为2 ^ 28 *（28位非随机起始数字+ 64位链结束数字）+ 64位“种子”数字（3264 MB）
当您将差异扩大到巨大尺寸时，Rainbowcrack表可以节省大量资金，并且最终得到整个硬盘阵列的纯随机产生的chain-start数字数据，更不用说移动使用的带宽了。周围的数据。考虑到琐碎的代码更改，这是一个巨大的浪费。