Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 Jul 2014 10:19:08 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: ZedBoard: bcrypt

Katja,

On Sun, Jul 20, 2014 at 10:33:11PM +0200, Katja Malvoni wrote:
> On 20 July 2014 19:08, Solar Designer <solar@...nwall.com> wrote:
> > 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:

OK.  Maybe you're not setting bit 9 reliably for reads of initial values,
so you sometimes read the previous S-box contents instead?

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

I think you might reduce utilization by introducing separate states (and
switching to those based on "ptr == ..." comparison, which is probably
cheaper than comparison for "more than" or "less than", as these imply
subtraction and thus a carry chain), and resetting ptr to 0 each time
(instead of having to subtract a constant from it to compute addresses).

> addra_S2[8:0] <= ptr - 'd530;

If the first 18 are a separate state, then you'd have a bit flip here,
not subtraction.

> These assignments before if statement are replacing default statement.
> Otherwise the tool would complain there exist undefined states in the
> process.

OK.  I hope so.

Now you have a choice: debug this or maybe try the 10 BRAMs approach
instead (with initial S-box values in unused portions of P-box BRAMs),
since it has better clock rate potential anyway (for when you add more
instances, as it would permit).  This 5 BRAMs thing is a known dead-end
anyway (need to switch to 10 BRAMs to try increasing the number of
instances to 112, and the clock rate).  If 5 BRAMs with initial values
worked right away, that would have been great, but since it needs
debugging that time might be better spent on 10 BRAMs.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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