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.