Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 29 Apr 2011 08:15:14 +0400
From: Solar Designer <>
Subject: Re: Bcrypt functionalities implementation in hardware

On Thu, Apr 28, 2011 at 04:18:10PM -0300, Yuri Gonzaga wrote:
>  Thank you for your answer.

You're welcome.  Next time, I suggest that you quote a little bit of
context for others on the list.  Just a few most-relevant lines.

> EksBlowfishSetup(cost, salt, key)
> >    state <- InitState()
> >    state <- *ExpandKey*(state, salt, key)
> >  *  repeat(2^cost)
> > **      state <- ExpandKey(state, 0, salt)
> > **      state <- ExpandKey(state, 0, key)
> > *   return state

BTW, there appears to be an error in the original bcrypt paper.  I think
actual implementations have the two ExpandKey() calls in the loop
swapped.  Did you also notice this?  Or am I wrong?

> I have a question:
> If I already have the hardware available to compute ExpandKey(), why don't I
> compute in hardware the call outside the loop as well?

This makes sense.  You may do it if it doesn't cost you much logic
(doesn't affect the number of bcrypt cores you can fit in a chip).

> On the other hand, InitState() can take advantage of software and
> communication and avoiding storage of initial PI value in hardware.
> What do you think about it?

I think that you're right.



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.