[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+EaD-YvsHc4j-hCeoLxK_9Y8JiuwCN0sWEHWVZ=QUcaF1b3hQ@mail.gmail.com>
Date: Sun, 20 Jul 2014 22:33:11 +0200
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: ZedBoard: bcrypt
ᐧ
On 20 July 2014 19:08, Solar Designer <solar@...nwall.com> wrote:
>
> > > I'll go for 5 BRAMs/instance with storing initial S-box values across
> > > unused halves of 4 BRAMs holding S-boxes. This way, initialization will
> > > require 256 clock cycles. I'm storing 2 S-boxes in higher half of each
> of 4
> > > BRAMs. Initialization data is stored twice but I can copy it in
> parallel
> > > for both instances. I don't use additional BRAMs and although
> utilization
> > > will be higher, it won't impact max core count (wider buses were used
> in
> > > 112 instances approach and core count was limited by available BRAM).
> >
> > This is harder than it looks like... The first time I run john, first
> hash
> > is computed correctly and the next one is wrong (fails on get_hash[0](1).
> > After that, it fails on get_hash[0](0) and computed hash is different
> every
> > next run. If I reload the bitstream, computed hashes follow the same
> > pattern as in previous runs so it seems as initial S-box values have been
> > changed. However, in simulation initial values do not change during
> > computation and every time I store something to BRAM, I set only address
> > bits 8 to 0 to make sure only lower half is modified. Also, before
> anything
> > is assigned to address bus, it's set to 0 so bit 9 is zero anytime I
> write
> > to BRAM. I tried two approaches - using readmemh function with my code
> > which infers BRAM and using Coregen to generate IP cores with initial
> BRAM
> > values.
>
> Weird. Are you sure you're not leaving bit 9 floating at any time that
> you access BRAM? "before anything is assigned to address bus, it's set
> to 0" doesn't feel like necessarily implying "so bit 9 is zero anytime I
> write to BRAM".
>
I am. That code is implemented as combinatorial logic and looks like this:
always @(*)
begin
...
addra_S1 <= 0;
addrb_S1 <= 0;
addra_S2 <= 0;
addrb_S2 <= 0;
addra_S3 <= 0;
addrb_S3 <= 0;
addra_S4 <= 0;
addrb_S4 <= 0;
...
else if(state == STORE_L_R) begin
if(ptr < 'd18) begin
...
end
else if (ptr >= 'd18 && ptr < 'd1042) begin
if((ptr - 'd18) < 'd512) begin
...
addra_S1[8:0] <= ptr - 'd18;
addrb_S1[8:0] <= ptr - 'd17;
addra_S3[8:0] <= ptr - 'd18;
addrb_S3[8:0] <= ptr - 'd17;
end
else begin
...
addra_S2[8:0] <= ptr - 'd530;
addrb_S2[8:0] <= ptr - 'd529;
addra_S4[8:0] <= ptr - 'd530;
addrb_S4[8:0] <= ptr - 'd529;
end
end
end
end
These assignments before if statement are replacing default statement.
Otherwise the tool would complain there exist undefined states in the
process.
Katja
Content of type "text/html" skipped
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.
