Ultimate rainbow

From ThisBlueWiki

Jump to: navigation, search

Django app backed by postgres to display rainbow tables generated from dictionaries with inclusions, single, double and triple word based keys.

  • blue + moon
    • bluemoon
    • bluemoon1
    • 1bluemoon
    • blue1moon
    • 1blue1moon
    • blueamoon
    • abluemoon (note the free article and suffix/prefix possibilities by doing all inclusions of up to 3 letters)
    • moonblue
    • ...

Generate all combinations up to some max length, perhaps 16 chars. Then generate hashes (MD5, SHA-1, SHA-256 etc) for all the combos in the most common character sets (ascii, latin-1, utf-8?) and store them in 2 tables, indexed by key, and indexed by hash, with some good Postgres index. (Don't use varchar for fixed-length hashes!)

Note: the above is size inefficient -- napkin math for storing a 256 bit hash for n2 combinations of n words where n is 1 million is almost 30 terabytes. Rainbow tables must be used. Is it feasible to generate chunks of the total hash space by key using rainbow tables, so that Google et al can be used to store the tens of terabytes of output? This question must be answered. Answer: no, as far as I can tell without a special set of reduction functions that map back to passwords in the dictionary, rainbow tables are not appropriate for reducing the storage space needed, since it appears they are generally designed to cover the entire keyspace for a given set of characters. This may not in fact be the case but I still need to read the paper.

Then make a django app to display all hashes broken up into pages by the first e.g. 3 letters of the key, so aaa-aab, aac-aad, etc. pulling them from the database as needed. Or, just dump it to files, but this would be a big pain to regenerate every time there were updates.

Load it up on a firewalled VPS, slap Adbrite full screen ad code on it, put in a delay mechanism based on IP (e.g. after the first 10 requests from an IP in a day, subsequent requests are delayed to an increasing degree to prevent bot abuse) and perhaps reCAPTCHA after X requests, and go.

This page was last modified on 9 April 2009, at 22:10. This page has been accessed 165 times.