[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160427012722.GB17182@openwall.com>
Date: Wed, 27 Apr 2016 04:27:22 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: USB-FPGA development
Denis,
Thank you for bringing this in here, finally. And thank you for all of
your work so far!
On Tue, Apr 26, 2016 at 09:20:54PM +0000, apingis@...nwall.net wrote:
> So far I didn't implement parallel processing of several boards. I'm considering usage of asynchronous USB transfer functions, or usage of OpenMP, or several threads or processes. So far it's a standalone test application and I'm yet unsure how exactly it would integrate into JtR code. Any suggestions are welcome.
I think async functions will likely give us the most flexibility.
On a related note, I've been planning an enhancement to JtR's formats
interface to make it async. Right now, the current batch of hashes has
to be fully computed by the time crypt_all() returns.(*) The change
I've been envisioning is to support having two batches of hashes in
flight at a time, with only the previous batch (not the latest batch)
required to be fully computed by the time a crypt_all() call returns.
We don't have this yet, but when we do it would benefit from having
async I/O and async computation off-loading functions.
(*) This isn't exactly correct: it may be possible to postpone finishing
computation until cmp_all() returns, if it's called, or split computation
across get_hash*() functions. But that's a detail not essential to the
above paragraph, hence the footnote.
I also think you may want to switch to implementing the actual password
hashing (descrypt or/and bcrypt) along with your current I/O framework
now (blocking functions), and only then approach improving the I/O.
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.
