[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130503034715.GA9140@openwall.com>
Date: Fri, 3 May 2013 07:47:15 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: zip-opencl
magnum, Dhiru, Lukas, all -
Here are some additional observations about zip-opencl, besides it
lacking auto-tuning.
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.
Finally, the comment at the start of opencl_zip_fmt.c says it was
"Modified by Dhiru [...] for Keychain format" - why Keychain?! OK,
opencl_keychain_fmt.c has the same comment, so it's a copy-paste thing.
It probably shares some problems, too. ;-)
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.
