Cryptohaze.com

Since we are able to utilize massive chain lengths now it seems we have massive decrease in BFP so I guess it's going to be useless for multihash search, how annoying and if we increase the chain count it seems we're going to have massive merges and f*** loads more work.

Does this mean we should do more tables instead; halving the chain lengths and doubling the number of tables? seems like very little work and high BFP unless i'm wrong?

O god this is sure annoying.

blazer wrote:Since we are able to utilize massive chain lengths now it seems we have massive decrease in BFP

Brute force point is a crude way to measure when to switch to brute forcing. It was off by a lot with the old reduction function because it was so slow. With GRT it's closer. Also the BFP assumes you have to search every table for each hash.

blazer wrote:if we increase the chain count it seems we're going to have massive merges

That's not exactly true. It's a ratio if you generate a rainbow table X chains by Y chain length and perfect it and you get R*X chains (R <= 1) then if you generate a rainbow table Y chains by X chain length and you perfect it you will have R*Y chains.

blazer wrote:Does this mean we should do more tables instead; halving the chain lengths and doubling the number of tables?

Creating more tables than the optimal number of tables will create a less optimal result. Doing your suggestion would double the size of the table set, double the BFP, and generation is 1/4.20 the time. If you just half the chain length then you double the table set size, quadruple the BFP, and generation time is the same as before.
See http://www.freerainbowtables.com/phpBB3 ... f=2#p10969