[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Oct 2013 19:12:21 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: ZedBoard: bcrypt
Katja,
On Wed, Oct 30, 2013 at 03:50:06PM +0100, Katja Malvoni wrote:
> On Wed, Oct 30, 2013 at 2:07 PM, Katja Malvoni <kmalvoni@...il.com> wrote:
> > On Wed, Oct 30, 2013 at 10:17 AM, Solar Designer <solar@...nwall.com>wrote:
> >> If so, does anything prevent you from optimizing this to? -
> >>
> >> Cycle 0: compute new R; swap L and R; initiate 4 S-box lookups
> >> Cycle 1: wait
> >>
> >> ... except possibly for the special cases of the first and the last
> >> round? In the first round, bypass some of the logic. After the last
> >> round, invoke the same logic, but bypass the S-box lookups.
> >
> > As far as I can tell nothing prevents me to do that, I'm on it now.
>
> Actually I can't do that - I need L to know which element from S-box to
> fetch
Sure.
> and I have to compute it one cycle before initiating S-box lookups.
Why can't you compute it on the same cycle when you initiate the S-box
lookups? You just need to have the address lines to the BRAM settle
before the clock signal transition, no? This might reduce the maximum
clock rate, but other than that I think it should be possible to do some
computation of the lookup address on the same cycle that you initiate
the lookup. (I am no expert in this, by far. This is just from common
sense on what I think should be possible - it definitely would be
possible e.g. with discrete components, so I don't see why not in FPGA.)
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.
