[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130503035841.GA10298@openwall.com>
Date: Fri, 3 May 2013 07:58:41 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: zip-opencl
On Fri, May 03, 2013 at 07:47:15AM +0400, 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), and 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).
>
> 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.
The CPU "zip" format (zip_fmt.c) has the same shortcoming with computing
more of PBKDF2 output than it actually needs.
Alexander
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.
