Talk:Rainbow table

Please rewrite article

Someone needs to rewrite much of this article. It is very poorly articulated. Unless one is already very familiar with rainbow tables, it is almost impossible to be able to understand the bulk of this article. I have a background in computer science and I am having trouble following this, but upon reading an article from another source, these concepts are now very clear.

I can rewrite this article when I have time, but I can't rewrite every article on Wikipedia that is written this poorly! Comprehensible explanations are a fundamental purpose of these articles. Just because the authors of an article are not English majors does not mean that clear and articulate explanations should not be expected. —Preceding unsigned comment added by 174.118.8.187 (talk)

[Comment removed. -- intgr [talk] 20:09, 5 November 2010 (UTC)]

Whoa whoa whoa. Off your high horse there, buddy. I'll tell you what makes Anon, above, so important: Anon represents the readership of Wikipedia. The readership is who we, the editors, are responsible to. Wikipedia is for everyone. Anon has the right to say "hey, this article needs work, it's difficult to understand". However, you don't have the right to say "what have you done for Wikipedia". That's not how it works around here. By the way, when you answer someone like Anon, you're representing the project. Your defensive attitude is not the way to do that.

I've tagged the article as needing work. — Hex (❝?!❞) 14:38, 5 November 2010 (UTC)

You're right, I read it now and I'm not proud of what I wrote there. -- intgr [talk] 20:09, 5 November 2010 (UTC)

How about rewriting the opening so that it reads something like this: "A rainbow table is a table of all possible hash values for a particular character set. Helpmethinkofaname

I rephrased the lead, hopefully it reads better now. The definition you gave is not accurate though, rainbow tables are heavily compressed and don't cover all possible values, usually they have 95% or 98% coverage. PS: Type ~~~~ to sign your posts. -- intgr [talk] 03:52, 20 February 2011 (UTC)

+1. When is this article going to actually start talking about rainbow tables?? Anyone coming here probably already knows what hashing and salts and passwords are. If not there are other pages on Wikipedia that already explain all that, better.

Untitled

This page was moved in accordance with a request on Wikipedia:Requested moves. —Cleared as filed. 01:01, 22 November 2005 (UTC)

Revisions

I revised the article to remove the reference to DES, which seemed like a distracting tangent, to eliminate mention of "tokens" and just talk about salt instead (the term salt is not used exclusively with DES as opposed to one-way hashes — see the salt article), and to clean up the writing a bit. For instance, I eliminated the ellipses after the formulas. I also changed "md5sum" in the formulas to just "MD5". There is no need to bother the reader with a particular program for doing MD5 hashes when we are just talking about the abstract concept of hashing. The only change I am uncertain of is replacing "success probability of the table" with "probability of the table successfully cracking the password". The two seem equivalent to me, but I am not familiar with rainbow tables and the term "success probability" could be a term of art. I would appreciate opinions either here or on my talk page. --DavidConrad 03:41, 13 January 2006 (UTC)

Found it. This page [1] defines "success probability" as "the probability you can find the plaintext of the ciphertext". So my restatement of it is essentially correct, but I will incorporate this definition into the article. --DavidConrad 03:54, 13 January 2006 (UTC)

Common uses

The common use section should talk about the common use of Rainbow tables which is what this article is about, not salts in hashes.187.37.49.76 (talk) 11:59, 3 July 2009 (UTC)

Strength of double hashing

Would doing a double hash be just as good as a salt? If you know the salt then you could generate rainbow tables for it. Which brings us to the same problem again. —Preceding unsigned comment added by 198.54.202.210 (talk • contribs)

Hashing passwords twice would not prevent attacker from using this table - he would just generate table by hashing twice instead of once. Ofcourse it would double the time for preparation of attack. Ad salt: salt is meant to be different for each user. Efectivity of rainbow table lies in its reusability: once the table is generated, it used to lookup unlimited amount of hash values. But if system uses the same salt for all users, then atacker can prepare table using this salt and mount attack the usual way.--Alvin-cs ✉ 13:01, 12 March 2006 (UTC)

No, I think he's right, let's take a look at MD5 for example. Cracking what is essentially a 32 character password is insane, no matter how much space you have to store the tables, and how many eons you have to calculate them. I ran the numbers and even just with numeric passwords, it didn't matter how high I put the settings, I couldn't get the probability of a successful recovery above 0.00% without the disk space calculator overflowing (which happens around the 500 petabyte mark, mind you). Now, I've heard that PHPBB hashes each user's password with MD5 100 times before storing/checking it, so unless rainbow table generators can work around that, I really don't see how one could crack one of those hashes. Even for LM, with only 16 byte hashes, with 1.5 PB of disk space and insanely long chain lengths, I'm looking at 3,700 years of cryptanalysis time for each hash before it fails to find anything with the table's .38% success rate. Oh yeah, and it still wont finish precomputation before the heat death of the universe. So yeah, I'd say multiple hashing works pretty well. —Preceding unsigned comment added by 24.56.210.251 (talk) 22:55, 7 December 2008 (UTC)

No, he's not correct. The issue is that you don't need to generate a table to cover all 32 character hashes; instead, you only have to generate a table covering all hashes that are hashes of valid passwords under consideration. To put it another way, when you apply a hash a fixed number of times that is independent of the user, that's just like applying a single hash function implemented by running the original hash function k times in a row. Nothing changes except the time needed to compute the hash, and to even guarantee that much you need to ensure the hash is nonlinear. Dcoetzee 23:13, 7 December 2008 (UTC)

Further, a double hash such as MD5^2 is ultimately going to be a weaker hash function overall because you've just increased the number of collisions. It now accepts any p where MD5(p) = MD5(pass) as usual, but also any p where MD5(MD5(p)) = MD5(MD5(pass)). The only advantage is that most precomputed work on dehashing these values has been done on MD5 and not MD5^2. MD5^2 is however, in theory, easier to find collisions for and consequently easier to crack. Because of this, salting the pass is a much better solution. Using MD5^100 as mentioned above actually might increase the number of collisions quite significantly and is probably a terrible idea. 71.42.216.123 (talk) 04:54, 9 February 2011 (UTC)

No, you are wrong about collisions:

1) Unless someone is actually trying to find one, MD5 collisions occur with a ridiculous probability, so that's a non-issue.

2) In the ridiculously unlikely event of a MD5 collision, with unsalted hashed passwords, there would be no real danger: some user Bob would be able to log-in with the password of another user Charles (and vice-versa), but only someone looking at the hash database would be able to learn this fact, and unless this person happens to be Bob or Charles he would have no other information about either Bob or Charles' password.

3) In the ridiculously unlikely event of a MD5 collision, with salted hashed passwords, there would be no theoretical consequences at all.

4) No one is trying to find MD5 collisions to "crack" passwords!

5) You are probably confusing MD5 as a non-invertible function (used for storing passwords more safely) and MD5 as a collision-free function (used for digital signatures). MD5 as a collision-free function has been proved unsafe a few years ago, with practical attacks possible and even effective against real world use of SSL certificates. MD5 as a non-invertible function is perfectly safe today, the published theoretical attack against MD5 as a non-invertible function requires insane computing power.

WPcorrector (talk) 05:28, 17 September 2011 (UTC)

Double hashing is now a useless algorithm. Rainbow tables by themselves can handle this - see my first link that will be removed by this team.. In that hash cracking utility, you can reverse the md5 to another md5, then reverse that md5 to the password - as many levels of md5 as you want can be overtaken. I say this is now useless because this can be done only with a rainbow table lookup, and no cracking is required..

Salts

I changed the top section of the article as I thought it was a) confusing and b) inaccurate. I think the description of the effect of a salt is somewhat incorrect. I think (and someone correct me if I'm wrong) that the addition of a salt would require the tables to be generated for every single possible salt to reach the same effectiveness against a salted hash as the rainbow table has against a salt-less hash. Basically the salt makes it so that intead of a single hash generator, there are 2ⁿ generators, where n is the number of bits in the salt. Thoughts? —Bradley 19:53, 9 June 2006 (UTC)

Agreed. I was going to post exact same comment. This part - "To recover the password, a password cracker would have to generate every possible salt for every possible password" is just plain wrong. Care to reword it ? Alex Pankratov 04:57, 26 June 2007 (UTC)

I took a liberty of removing the above statement. I made few attempts at correcting it, but in a reworded form it did not carry genuinely useful information as it was redundant to the paragraph that follows. Alex Pankratov 06:21, 26 June 2007 (UTC)

I believe the discussion of salts is wrong. Hash tables can still be precomputed if the salt is appended to the hash, as opposed to being prepended saving some of the work, so normally the password entry is actually

    hashed = salt . hash( salt . password)

and not

    hashed = hash( password . salt )

as described in the document. nuffin (talk) 19:15, 31 May 2008 (UTC)

How can hash tables be precomputed for salted passwords? You would have to precompute it for each possible salt, which is not feasible. 201.216.245.25 (talk) 17:35, 14 December 2009 (UTC)

For salts, the current attack is to use an md5 cracking algorithm that takes into account the salts. See my links to such tools after it is removed and moved into the discussion space, where it should be.. — Preceding unsigned comment added by 76.23.56.190 (talk) 00:12, 20 May 2012 (UTC)

Dictionary vs Brute Force Attacks

The password "guesses" in a rainbow table are generated by the reduction function, which applies a transform to the hash of the previous password guess. They are not based on word lists or lists of most-likely passwords and hence the attack is closer to brute force attack than it is a dictionary attack. —Bradley 14:47, 19 June 2006 (UTC)

Brute force and dictionary are the really same things. Only the a priori knowledge about the password, which determines the search space, is different:

"Dictionary" means "clever", while "brute force" means "stupid", where "clever" means assuming cultural knowledge of the person choosing the password (language spoken, spelling variations, prefix and suffix used) and "stupid" means you only assume an upper bound on key length and a set of possible characters.

But ultimately you just have defined some key space that you must then explore, which is really a "brute force" thing. WPcorrector (talk) 05:42, 17 September 2011 (UTC)

Where's the "rainbow" name from?

I heard the origin of the name somewhere, but can't recall it and can't find a source. Someone who knows this, please add. --(unsigned)

I believe it comes from the multiple reduction functions. Martin Hellman's original idea had only one reduction function -- these tables would be 'monochromatic'. Athulin (talk) 07:13, 3 April 2008 (UTC)

I've been trying to find the name's origin for a while too and I'm surprised that no one has added anything about it to the article in the two years+ since this question was asked.

One explanation I've encountered was an off-hand remark by Steve Gibson on the Security Now podcast that the name came from Rainbow Technologies' dongles (the "Sentinel" license manager) -- presumably from successful crack attacks aimed at them. The transcript is here, but some painful googling didn't bear that out at all. In fact, the only real reference I could find was a story that noted such a query/response table would take thousands of years to compile on current versions of the dongle and so cracking groups abandoned that in favor of removing all calls to the Sentinel from the software itself.

Besides, the "Making a Faster Cryptanalytic Time-Memory Trade-Off" paper doesn't treat the term "rainbow" as a proper pronoun. After describing Hellman's previous method, it introduces the term with the sentence "We call our chains rainbow chains" which is the first mention of the word in the paper. This is in the context of the "reduction function" as stated above, but I wish someone could explain the metaphor to us simpletons. Msgohan (talk) 08:11, 27 June 2010 (UTC)

Hmm. I've always thought "rainbow" came from the multiple tables needed to handle each salt. As I recall, the first rainbow tables I heard about were for Unix passwords, which uses 4098 different salts. Around this time we also uses the Rainbow Series to refer to a collection of books. Consequently, I feel that the concept that a salt will defeat a rainbow table is really incorrect. A salt makes the task harder because you need a separate table for each salt. However, I have not found any references that correspond to my recolections. BruceBarnett (talk) 11:07, 6 May 2011 (UTC)

Reduce?

What is the 'reduce' function? --Apoc2400 01:40, 30 October 2006 (UTC)

Someone in the last day decided to turn some of the text descriptions into equations. Here are the original paragraphs:

A rainbow table is constructed by building chains of possible plaintext passwords. Each chain is developed by starting with a randomly selected "guess" of the plaintext password and then successively applying the one-way hash followed by a reduction function. The reduction function takes the results of the hash-function and turns it into another plaintext password guess. The intermediate password guesses are then discarded and the first and last are stored in the rainbow table. This table takes time and memory to build, but must only be built once at which point, it can then very quickly recover unknown passwords.

Recovery of plaintext passwords is then done by taking the hash password, applying the reduction function, and looking-up the result in the rainbow table. If no match is found, then the hash and reduction functions are applied again and that result is then looked-up. This is repeated until a match is found. Once a match is found, the chain that resulted in the match is reconstructed to find the previously discarded intermediate value, which is then a plaintext password for the given hash.

It sounds like a "reduction function" is just any function (not specified here) that "takes the results of the hash-function and turns it into another plaintext password guess". I am not an expert on this; perhaps Oechslin's papers would shed more light on this. --Spoon! 02:03, 30 October 2006 (UTC)

I have just added a smal explaination of this kind of function. Feel free to expand it; I'll also try to help if my explaination is still unclear. --DerGraph 13:18, 16 November 2006 (UTC)

Here's the part that's extremely unclear:

The reduction function takes the results of the hash-function and turns it into another plaintext password guess.

After further reading, my understanding is that the reduction function simply picks a random password from P, using the hash as kind of a pseudorandom seed. Am I correct? This is obliquely implied in the current article, but it's easy to infer that the reduction function does some kind of special magic, when in fact it plays only a minor role. 95.88.6.44 (talk) 22:30, 30 May 2009 (UTC)

Why there is a reduction function is pretty clear; the hash function is a function that maps from password space into hash space. Although the elements of these two spaces are both pieces of data; the spaces are often very different. For example, the input password space in one case could be restricted to alphanumeric text with lengths from 1 to 8. And the output hash space depends on the hashing algorithm, but might be, say, an arbitrary 128-bit binary string. The sizes of the two spaces are very different, so you can't just take the output hash, and somehow use it directly as a password guess. So you need a function to map back from hash space into password space for the next iteration. The function doesn't have to be special or random or anything; pretty much any decent function that maps from hash space into your password space should do, preferably one whose outputs are somewhat well-distributed over the password space. The person who uses your rainbow table will also need to know what reduction function you used. --76.173.203.58 (talk) 23:22, 30 May 2009 (UTC)

I think it would be very helpful to include some of what you just said about reduction function - "any function that maps from hash space into your password space should do, preferably one whose outputs are somewhat well-distributed over the password space" Andreid76 (talk) 20:41, 16 April 2014 (UTC)

The part about the sample reduction function seems wrong to me - 4 characters would not constitute a valid password in that example (6 character alpha passwords). Am I missing something? Andreid76 (talk) 20:41, 16 April 2014 (UTC)

Could someone at least specify the reduction function used in this article? The one for which f(281DAF40)=sgfnyd, how was it defined? I hope it wasn't just by enumeration... The whole article uses the function's results as if it was known, did the writer just forget to mention it?--147.32.31.193 (talk) 00:20, 11 October 2018 (UTC)

Relevant Linking

The link to www.freerainbowtables.com has been removed a number of times. I am sorry I did not read this earlier:

If the link is to a relevant and informative site that should otherwise be included, please consider mentioning it on the talk page and let neutral and independent Wikipedia editors decide whether to add it. This is in line with the conflict of interests guidelines.

I believe the site is relevant to the topic, as it is the largest community based rainbow tables generation project. Many table sets are also available for download from this site. More so for free than any other site. I will not personally replace the link as I do not want to break the rules of Wikipedia. —Preceding unsigned comment added by 203.214.3.248 (talk • contribs)

I am a member of the freerainbowtables.com community so take this comment as it is. However, I'd also like to support the addition of the link to this article. The site is a community oriented and a community supported rainbow tables site. All the tables are open to the public to download at will with no strings attached. It is quickly becoming the most viable place on the web to get rainbow tables and though other sites may have more, this site will overtake them all. 66.93.244.36 04:01, 27 February 2007 (UTC)

There are many different free rainbow table sites available, but I wouldn't say any one will "overtake them all". Communities should work together; thats the purpose of distributed rainbow table generation. As said, since the communities should have a clear link to eachother of information and interest, if one link is posted for these type of rainbow table collaborative projects, the others should be posted as well, in the interest of open communication and cooperation of parties. --Silivrenion 12:07, 21 April 2007 (UTC)

The obvious problem here is that Wikipedia is not a link directory, and it shouldn't [have to] link to all projects. I would much rather not deal with checking external links at all — in a perfect world, we would offload that responsibility to some established link directory web sites. This is already encouraged by the external links guideline. Unfortunately, DMOZ does not have a category for rainbow table communities/web sites, and I am not aware of any others. (I have already placed a "directory request" template in the header of this talk page) -- intgr 12:21, 21 April 2007 (UTC)

At this time the link to freerainbowtables.com/faq is broken and the site is not responsive. Has it gone away completely? If it is dead then shouldn't the link be removed. BobProulx (talk) 17:08, 5 February 2009 (UTC)

The reference link to Oechslin, Philippe (Mar-Apr 2005). "Password Cracking: Rainbow Tables Explained". (ISC)2 Newsletter. https://www.isc2.org/cgi-bin/content.cgi?page=738. does not resolve to a meaningful page. I think the reference should stay but the url be removed. BobProulx (talk) 17:08, 5 February 2009 (UTC)

History section?

Is the "history" section really necessary? It takes up a good chunk of the article, and ultimately is NOT describing Rainbow Tables, but is instead describing the concept that predated Rainbow Tables. Maybe it is better to just link to an article on the older concept, and keep this article JUST about Rainbow Tables. Konky2000 19:47, 5 November 2007 (UTC)

Is there such article ? If there's not, then I suspect it's going to be quickly deleted on a lack of notability grounds if created. I'd say, the history section should be renamed and trimmed down a bit, but ultimately kept here. Alex Pankratov 20:30, 5 November 2007 (UTC)

Articles on specific companies, products, people, etc. get speedy deleted; technical articles are not. -- intgr [talk] 08:45, 6 November 2007 (UTC)

Cleaned up Overview

I'm planning to replace existing Overview section, which I find to be too chatty and somewhat confusing, with the following.

Overview

A rainbow table is a compact representation of related plaintext password sequences (or chains). Each chain starts with an initial password, which is passed through a hash function. Resulting hash is then fed into a reduction function, which produces different plaintext password. The process is then repeated for a fixed number of iterations. Initial password and the last hash value of the chain comprise a rainbow table entry.

Recovering a password using a rainbow table is a two step process. First, the password hash is run through the above reduce-hash sequence. The structure of the table and its reduction function guarantee that the running hash will match a final hash of one of the chains. This yields the initial password of the chain. Second, the iteration is repeated starting with this initial password until the original hash is found. The password used at the last iteration is the password being recovered.

The table content does not depend on the input of the algorithm. It is created once and then repeatedly used for the lookups unmodified.

Increasing the length of the chain decreases the size of the table. It also increases the time required to iterate over each chain, and this is the time-memory trade-off of the rainbow table. In a simple case of one-item chains, the lookup is very fast, but the table is very big. Once chains get longer, the lookup slows down, but the table size goes down.

Any feedback is appreciated. Thanks, Alex Pankratov (talk) 22:09, 21 November 2007 (UTC)

I'm updating the Overview as per above. Please use this thread to discuss any issues with new version. Thanks, Alex Pankratov (talk) 23:05, 24 November 2007 (UTC)

Should it not say "is equivalent to the password being recovered"? After all, more than one password can have the same hash - or are typical password-hashes longer than all feasible passwords? How could this be clearly formulated? PJTraill (talk) 23:03, 9 March 2008 (UTC)

You are right indeed: although the search space of any realistic brute force attack is much smaller than the hash values set, a hash collision is possible (yet unlikely). And h(x) = h(y) defines an equivalence condition. WPcorrector (talk) 06:14, 17 September 2011 (UTC)

It is not clear from this text that there are several reduction functions -- which is the fundamental idea of the rainbow tables. Nor do I think that the second sentence of the last paragraph is correct: the time-memory tradeoff as I understand is that vs a full look-up table. It's much faster than a rainbow table, but also takes much more space -- the tradeoff then is trading off lookup-time to improve storage space. This is not something unique to rainbow tables -- it was part of Martin Hellman's original idea.79.102.100.41 (talk) 07:07, 3 April 2008 (UTC)

Table Entry

According to the Overview, the initial password and the last hash value of the chain comprise a rainbow table entry. But from the figures and the example a table entry ends with a password, not a hash value.

84.126.102.72 (talk) 02:42, 9 February 2008 (UTC)

Yeah, there seems to be something wrong with the picture Porttikivi (talk) 14:07, 13 February 2008 (UTC)

Quadratic lookup

Concerning the use of variable reduction function in rainbow tables vs. the older constant reduction functions, the article points out that the newer method avoids redundant chains due to collisions (which is obviously true); however, it also states As well as increasing the probability of a correct crack for a given table size, this use of multiple reduction functions approximately doubles the speed of lookups. which I don't believe.

Given a chain length of N=100,in the older scheme, a lookup would consist of 100 reduction–hash steps. In the rainbow table proper, however, one would have to run a chain of length one starting with the last reduction function R(100), then a chain of length two starting with R(99), and so on, up to a chain of length hundred starting with R(1). This makes alltogether around N²/2=5000 reduction–hash steps. The quadratic behaviour will tremendously increase the lookup procedure for large chain length.

Did I misunderstand something, or is the article wrong? 77.5.124.57 (talk) 22:43, 6 April 2008 (UTC)

Good question - in short, you're right that the behavior is quadratic. The argument about this is in the original paper on page 6. The subtle point not being addressed here is that when using simple hash chains, it's necessary to divide tables into many smaller tables to remain efficient, whereas with rainbow tables they can be t times as large with no adverse effect. The consequence is a factor of t less lookups. Dcoetzee 05:53, 8 December 2008 (UTC)

You are correct and I've edited this sentence accordingly. Markus Kuhn (talk) 13:12, 23 January 2018 (UTC)

Self-reference in diagram

Just suggesting eliminating the needless Wikipedia references in the diagram, per Wikipedia:Avoid self-reference. Dcoetzee 00:38, 6 October 2008 (UTC)

Link dead

The link to the (ISC)2 Newsletter in the reference section displays the generic homepage for the site and I can't find the article mentionned ("Password Cracking: Rainbow Tables Explained". (ISC)2 Newsletter. https://www.isc2.org/cgi-bin/content.cgi?page=738).

--212.198.246.189 (talk) 10:29, 24 March 2009 (UTC)

Why does chain count equal chain length?

The article says that if the chains are k elements long (because there are k reduction functions) , you need k chains. Why?174.110.172.156 (talk) 23:13, 14 July 2010 (UTC)

This is when you try to find a hash in the table, I assume. The first use of the word 'chains' refers to the chains actually in the rainbow table (but which have to be recreated, as they are not stored explicitly). The second use refers to the chains created during the look-up operations, when that recreation is done. Athulin (talk) 18:11, 31 July 2010 (UTC)

Faster lookup?

"this use of multiple reduction functions approximately doubles the speed of lookups." - why?

Assuming the "Average" position in the chain (The middle value is the average lookup time for both rainbow and normal tables though rainbow tables get anything towards the end faster and towards the beginning slower), we take a hash 4882 and run it through a 5 iteration chain...

The original table runs it through 2 reductions and 2 hashes and finds the end of the chain, then looks it up for another 2 hashes 2 reductions... total 4 hashes 4 reductions

The rainbow table runs it through Rk-1, 1/1 calculations and Rk-2, 2/2 calculations to find the end of the chain, then another 2 hashes 2 reductions to get the plaintext: total 5 hashes 5 reductions...

What am I missing here? By my math the only time a rainbow lookup is even the same speed as a normal table is when the hash just happens to be at the very end of the chain... In fact the RT should be incrementally slower the further away from the end of the chain the hash lies...

A 5k column chain with the hash at the beginning should be approx 2500 times slower with rainbow tables... Where is my math wrong?—Preceding unsigned comment added by 87.195.101.155 (talk) 20:35, 14 September 2010 (UTC)

Just an idea: single-function chains degenerate easier. Once a hash value has been reached for the second time during a lookup, performing the remaining operations on that chain are wasted, becuase they have already been done before. With the rainbow tables, this happens much less often -- it needs to occur in the same position in the chain. So perhaps 'speed' does not refer tocount of operations, but count of significant operations? Where tracing a chain tail that has already been traced would count as non-significant. Athulin (talk) 10:09, 10 January 2011 (UTC)

Space-Time Tradeoff

Hey, folks! I think the bit in the very beginning of the article might be backwards. It reads:

"It is a practical example of a space-time tradeoff, using more computer processing time at the cost of less storage when calculating a hash on every attempt, or less processing time and more storage when compared to a simple lookup table with one entry per hash."

Calculating a hash on every attempt would take _no_ storage and _lots_ of processing time, a simple lookup table would take _little_ processing time and _lots_ of space. A rainbow table is a compromise, taking less processing time than calculating every hash, and less storage than a full lookup table. Maybe that's what the bit above meant, but I found it a bit unclear. Thanks! 141.213.55.122 (talk) 17:29, 1 March 2013 (UTC)Scott (sawalls at umich dot edu)

"Rainbow Tables" Subheading

It seems like in an article called "Rainbow Table", "Rainbow Tables" is NOT an appropriate subheading.

Billiam1185 (talk) 18:12, 20 August 2013 (UTC)

Removed Sections Due to Guideline Restrictions

There were several sections here, an unverifiable hashing/cryptography suggestion unrelated to rainbow tables, several opinionated topics - that violates wikipedia talk page guidelines in virtually every category. Namely, I have removed sections that are not on topic, that are meant to criticize or vent about the subject, argue personal points of view that also do not cite reliable sources of information, that are not based on verifiable facts, includes insults or personal details between various parties, and is voilates the 'living person' mandate. 97.88.168.200 (talk) 01:28, 22 March 2015 (UTC)

Misleading illustration: Colors in the "rainbow" correspond to columns, not rows

The "rainbow" (as in rainbow table) corresponds to multiple different reduction functions (dubbed "colors") being used to avoid collisions, as opposed to Hellman tables that use a single reduction function. The main illustration of the article uses different color for different rows, which is wrong and misleading. 147.251.44.46 (talk) 12:12, 27 March 2018 (UTC)

Possible Improvement for explaining Step 4

In Step 4, it is stated that "one generates a chain and compares at each iteration the hash with the target hash".

Is a comparison with the target hash at step 4 really needed for all iterations? Basically, the steps before partly recreate the rainbow table row generation process (and we know the exact langth of that part). Hence, in step 4, we should know in which "column" of the chain selected in step 3 we have to look for the password. Or is there something i misunderstood? — Preceding unsigned comment added by Lowercaseonly (talk • contribs) 22:51, 11 September 2018 (UTC)

Precomuted hasg chains: finding collisions

The article says "Because previous chains are not stored in their entirety, this is impossible to detect efficiently". This is not clear. If while computing the chain all internal steps don't collide with other end point, then the new chain doesn't overlap behind. And to verify that is doesn't overlap ahead, you need to continue k more iterations past your end point and see you don't collide with other end point - is this what's not efficient?! The extra k iterations? --Itaj Sherman (talk) 18:51, 4 November 2018 (UTC)