[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130503094717.GA18814@localhost.localdomain>
Date: Fri, 3 May 2013 15:17:17 +0530
From: Dhiru Kholia <dhiru.kholia@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: zip-opencl
On 05/03/13 at 07:47am, Solar Designer wrote:
> While crypt_all() checks 2 bytes of PBKDF2 output only (and it can't
> quickly check more), it computes the full PBKDF2 output right away.
> cmp_exact() simply returns 1. This means that we both incur the false
> positives (and don't filter them out!) and incur the performance hit of
> computing the full PBKDF2 output. Instead, we should have the PBKDF2 on
> GPU compute only the 160-bit portion of PBKDF2 output that contains the
> required 2 bytes. We'll compute the rest of PBKDF2 output on CPU in
> cmp_exact() if necessary (usually it won't be)
>
> If I parse our test vectors right, it looks like for one of them we
> currently compute 2x160-bit of PBKDF2 output and for the other 4x160-bit,
> in both cases instead of just 1x160-bit that we actually have to compute.
This optimization is now implemented in the CPU "zip" format.
However, we would need to revert it in case we decide to implement
decryption and decompression later on.
> we'd need to implement a check to weed out the false positives (the
> CPU "zip" format lacks it too, though - so we need it for both).
I am guessing that we would need to do partial decryption and
decompression to reduce / eliminate the false positives.
Jim and magnum seem to be the right guys for this ;)
--
Dhiru
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.
