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

Your e-mail address:

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