Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ