Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F6C8682.4000403@linuxasylum.net>
Date: Fri, 23 Mar 2012 15:19:46 +0100
From: Samuele Giovanni Tonon <samu@...uxasylum.net>
To: john-dev@...ts.openwall.com
Subject: Re: OpenCL formats write-buffer optimisations

On 03/22/12 22:45, magnum wrote:
> Samuele,
> 
> Could you take a look at commit 7c8dcdb and see if you agree with it?

Actually i think it's a good idea, i wish i could have think of thay
myself too :-)

> I'm not sure there's much of a boost but there is no downside. This
> general approach should be considered for all formats. Never do anything
> not needed :)
> 
> The opposite case, many salts, could be optimised too. In this case,
> john will do this:
> 
> set_salt()
> set_key() (millions of times)
> crypt_all()
> set_salt()
> crypt_all() (using same keys)
> set_salt()
> ...
> 
> In this case we should avoid re-transferring the keys as they are
> already there. This might be a noticable boost on systems with slow
> transfer as the key buffer is a lot larger. One way to achive this is
> something like the enclosed patch (untested on GPU as of yet). All
> salted formats could/should do something like this.

yes i totally agree: it's the same approach used on getting full hashes
in cmp_exact and crypt_all .

Cheers
Samuele

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.