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.