Date: Tue, 10 Dec 2013 01:42:19 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: md5crypt-opencl On 2013-12-10 01:31, magnum wrote: > On 2013-12-10 01:00, Lukas Odzioba wrote: >> 2013/12/10 magnum <john.magnum@...hmail.com>: >>> Eventually we should come up with an idea how to best (quick, simple, >>> safe) >>> sort candidates per length. This would be a very good boost for >>> rar-opencl >>> too but I have yet to come up with an idea simple enough to be >>> interesting. >>> I really want it simple and beautyful or I'll leave it alone. >> >> What about counting/bucket sort with logic inside set_key/crypt_all. >> It should be dead simple with mostly 1 memcpy overhead. This way we >> can easily "compress" candidates too. > > Yes, but the devil is (or might be) in the details. What if we need 1M > keys to get good performance so we set KPC to 1M, but the candidates > come in 10 different lengths? We might get just 100K keys per length. Or > worse: 990K of one length and VERY low numbers of some other lengths. So > should we bump KPC a *lot*? That has drawbacks. And still, your length 8 > bucket may be "full" while the length 9 bucket has too few candidates. > At one point I played with the thought that set_key() should decide when > to call crypt_all() - and for what candidate bucket... but that starts > to get far too complicated. No wait... maybe it isn't that complicated. Actually, core calls set_key() and then forgets all about that key - the *format* is responsible for recalling that key when needed. So in theory, we could wait for hours filling a particular seldom-used-length if we really wanted to. And/or we can re-order keys however we want (except the current self-tests will get mad about it so we'd need to fix that). This never occured to me until now. magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.