0

I've been reading the documentation of RainbowCrack and older source code, and I can't locate where the developer(s) hash reduce to a 64-bit integer, which can hold UINT64_MAX plain texts.

Doc: https://project-rainbowcrack.com/file_format.htm

Excerpt:

Both the start point and the end point are 64-bit unsigned integer in little endian, representing a plaintext.

In this example, the charset is "abcdefghijklmnopqrstuvwxyz0123456789" with the plaintext length range from 1 to 7. So 0 stands for plaintext "a", 1 stands for plaintext "b", 35 stands for plaintext "9", 36 stands for plaintext "aa", and 80603140211 stands for plaintext "9999999".

Somewhere there must be a description of how to generate all possible plaintexts (size 80,603,140,211 in the example above, 36 possible characters, lengths 1 to 7) or more probable, a subset from the reduction function. Given a hash, perhaps SHA1 with 160 bits of output, it reduces to some integer, take 64 bits, then generate a plaintext in the charset [a-z0-9] of length 1 to 7.

I suppose what I mean to ask is, given the process is deterministic and has to produce the same hash reductions from a starting point, how would a good distribution from 0 to plaintext length N happen without introducing randomness? Try and jig the numbers a bit from the reduction, so this can index into a character set, select character c (repeat N times), for plaintext length N?

Notes: I've looked at base N to base N conversions, I've checked for integers modulo N (charset size), written small programs with lookup tables, stepped through code of dozens of toy rainbow table programs and examined how the reductions are done, but none of these help with this specific question, or the next on trying to produce a reasonable difference in each plaintext.

So whoever voted this down for showing little or no research effort, there you go. You might have just considered me dull rather than someone who doesn't actually try to do any research or make progress before asking a question.

JYG
  • 39
  • 1
  • 10
  • Hi Maarten, so this information distilling rainbow tables into terms for laymen at http://kestas.kuliukas.com/RainbowTables/ is essentially wrong? From what I have seen so far, in info-sec forums, documentation and software implementations, apparently the reduction is taking the hash of a plaintext, and using that to generate a new plaintext. Maybe the whole point is that this is one example of a few ways to generate rainbow tables, and it's perhaps easier to understand than other methods, whatever they might be. – JYG Oct 14 '18 at 00:22
  • Sorry, I was wrong myself. Why would base conversion not work? You have base 62 there, generating a text using anything base 62 would be easy right? Each "digit" is an index in the alphabet in that case. However, generally the reduction function should try and find *more likely* passwords. If you have fully random passwords, it would make less sense. From Wikipedia: "Only when the attacker has a good idea of what the likely plaintexts will be they can choose a function R that makes sure time and space are only used for likely plaintexts, not the entire space of possible passwords. " – Maarten Bodewes Oct 14 '18 at 00:46
  • That's very helpful, thanks. I did understand the closer you could make a reduction function choose a likely plaintext, the better the rainbow table would be. What had me really confused was probably an implementation detail that I didn't understand, leaving me with attempting a R(h) -> new plaintext producing garbage. So essentially anything from the hash as an integer modulo 64 would provide me with a good index into the plaintext alphabet I could use. The hard parts: sufficiently differing plaintexts from R/several R, and "biasing" the R(h) to try for more likely plaintexts. – JYG Oct 14 '18 at 01:28

0 Answers0