[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Jul 2014 14:55:03 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: ZedBoard: bcrypt
On Sun, Jul 06, 2014 at 11:22:48AM +0200, Katja Malvoni wrote:
> On 6 July 2014 10:15, Solar Designer <solar@...nwall.com> wrote:
>
> > I guess you're computing 64 bits per hash only, correct? This is
> > sufficiently unlikely to cause false positives that we can go with it.
>
> That's correct. But I transfer 64 32-bit values per hash from FPGA after
> computation is done because array being transferred contains structure
> aligned in such way that higher address bits select bcrypt core so
> everything is done with one call to memcpy(). I tried avoiding unnecessary
> transfers but performance is a bit lower 3744 c/s, I assume because of
> overhead of multiple calls to memcpy().
Maybe you can use pairs of 32-bit integer or individual 64-bit integer
reads in place of multiple memcpy()'s.
> > > I tried measuring Zynq voltage during computation and it does drop so
> > > initial assumption is correct. Voltage drops from 960 mV to around 890 mV
> > > during computation when Zynq FPGA is fully utilized.
> >
> > Is this on my ZedBoard or on yours? Does the code even work on yours?
> > Even if not, can you nevertheless obtain a voltage reading from it, or
> > does it crash the board? Same question about your Parallella board.
>
> It's on mine Parallella board. ZedBoard's device tree doesn't have entry
> for XADC so it's not possible to measure voltage. I'd have to modify and
> recompile device tree and change boot image for this to work. But my
> ZedBoard and Zedboard on Parallella behave the same when FPGA is fully
> utilized, both are unreliable and although self test is passed, actual
> cracking doesn't work because not all hashes are cracked.
> Another approach would be to use PL to access XADC but I think it's simpler
> and less time consuming to recompile device tree and change boot image.
In other words, the drop from 960 mV to around 890 mV corresponds to
unreliable cracking, and you don't know what the voltage is when the
cracking is reliable (which it is on my ZedBoard only), right?
> > How many bcrypt instances and cores is this? Still 2 cycles/round,
> > right? What clock rate?
>
> One instance per core, 70 cores, limited by available BRAM. Yes, still 2
> cycles/round. Clock rate is 71.4 MHz, limited by routing delay not by logic.
Perhaps you can achieve a higher clock rate by introducing an extra
cycle of latency per data transfer during initialization and maybe
during transfer of hashes to host as well? Anyway, maybe it's better
to consider that after you've implemented initialization within each
core as I suggested. It depends on which of these things you feel
you'll have ready before your trip to the US.
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.
