[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+EaD-YE950n+tTKTLgRxUWgJh5HQBQErPYi7XDJ+M2YV+7pLg@mail.gmail.com>
Date: Wed, 30 Oct 2013 17:26:15 +0100
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: ZedBoard: bcrypt
On Wed, Oct 30, 2013 at 4:12 PM, Solar Designer <solar@...nwall.com> wrote:
> 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?
Yes, you're right, I made a mistake.
L is a register so I'm able to read computed value only on the next rising
edge but I should be able to compute corresponding byte from BRAM output
lines. Although it still doesn't work in simulation - I must have a bug
somewhere.
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.
