Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jul 2015 20:14:20 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: ztex 1.15y boards, pre-development

On Mon, Jul 27, 2015 at 06:56:42PM +0200, Katja Malvoni wrote:
> On 27 July 2015 at 18:15, Aleksey Cherepanov <lyosha@...nwall.com> wrote:
> 
> > On Mon, Jul 27, 2015 at 06:02:03PM +0200, Katja Malvoni wrote:
> > > On 27 July 2015 at 17:49, Aleksey Cherepanov <lyosha@...nwall.com>
> > wrote:
> > > > I tried to write several times and to write more in 1 pack (but not
> > > > both). I get results only in fifth reading. So I removed printf and
> > > > added cycle so:
> > > >
> > > > 5000 times:
> > > >   modify sent[]
> > > >   write 64 bytes
> > > >   read till length == 34 or up to 6 times
> > > >   fail if read 6 times
> > > >   check results
> > > >
> > > > It does not fail. 5k iteration take 6.1 seconds, so transfer speed is
> > > > 52kb/s. Code attached.
> > > >
> > >
> > > Cool! But I have one question: did you modify FPGA code? Because internal
> > > FPGA buffer has size of 256 bits which is 32 bytes. Actually, now when I
> > > look at host code, it seems you're writing 32 bytes, right?
> >
> > You're right: Above, I wrote "64 bytes" wrongly. It should be "32
> > bytes". I did not modify fpga code.
> >
> > So the speed is 26kb/s.
> >
> 
> I can reproduce the same behavior.
> 
> But I'm afraid 26 kb/s is too slow. Each FPGA chip on Ztex board has 268
> BRAMs which is enough to calculate 104 bcrypt hashes on a single chip (or
> 208 hashes but twice slower). For each hash it is necessary to transfer 148
> bytes to FPGA (64 for P-box, 64 for expanded key, 16 for salt and 4 for
> cost) and 64 bytes from FPGA as result. That gives us 212 * 104 * 4 = 88192
> bytes or ~86 KB. So that's 3.3 seconds for 416 (104 per chip * 4 chips)
> bcrypt hashes. If I'm not mistaken, in this case, communication speed
> limits performance to 126 c/s. Since zedboard has 140 BRAMs and it is
> possible to fit 56 bcrypt instances to get 66.4 c/s at cost 12, if we say
> that Ztex is approximately twice bigger, expected performance is ~ 64*2*4 =
> 512 c/s. So even if using cost 12, data transfers at this speed would limit
> performance seriously.
> 
> But I'm still not sure which device in communication fails - is it FPGA
> logic that is wrongly configured, is it microcontroller firmware or
> something on the host side.

... or a strange combination. I'll look into that more.

I am curious: are there problems to generate candidates on fpga? For
instance, overstrike 1 byte of key with new char for each byte of key
for each char in ascii. It is not so good for slow hashes but it may
be great for faster hashes.

I hope we'll improve speed till the contest. InTraffic example gives
~30Mb/s (fpga->host transfer).

Thanks!

-- 
Regards,
Aleksey Cherepanov

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.