Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Jul 2013 04:28:33 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Katja's weekly report #6

Hi Katja,

On Mon, Jul 22, 2013 at 11:59:43PM +0200, Katja Malvoni wrote:
> Accomplishments:
> 1. Integration with JtR finished

Cool.  Just how confident are we that it's working reliably, though?
Yes, the 2-hour run has succeeded, but if e.g. one in 10k hashes were
not computed/transferred correctly then chances are that this would not
be noticed in a run that is only supposed to get 3k passwords cracked.

My concern is that, if I understood Yaniv correctly, the data transfers
to/from Epiphany do not have to complete in-order, yet your code relies
on the flags being seen strictly before/after the data.

Maybe you can test similar data transfers in a dummy application that
would do very little computation (so it'd spend most of its time on the
transfers back and forth), but would instead deliberately try to detect
cases of out-of-order arrival?

In a password cracker, we'd only detect false negatives (a correct
password not resulting in the hash getting cracked) and false positives
(very unlikely: if a wrong password somehow happens to result in the
correct hash value, e.g. if two computed hash values somehow got swapped
in transfer).  The problem is that we won't detect cases where a false
negative is the correct outcome (this is true most of the time!), yet
the computed hash value is different from what it should be.  So we
don't actually test whether most of the computed hash values are correct -
we only test a small minority of them.  This is why I suggest that you
implement an actual stress-test, where any data transfer error would be
detected (unlike in a password cracker, where most would go undetected).

> Priorities:
> 1. Optimize Epiphany bcrypt implementation
> 2. Start with bcrypt implementation on FPGA

Yes, please - and please keep john-dev aware of your progress (more
often than weekly, in addition to the weekly reports).

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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