Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Jul 2014 11:22:48 +0200
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: ZedBoard: bcrypt

ᐧ
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().


>
> > 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.


> 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.

Katja

Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

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