crypt-dev - Re: Bcrypt functionalities implementation in hardware

Openwall GNU/*/Linux 3.0 - a small security-enhanced Linux distro for servers

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 29 Apr 2011 08:15:14 +0400
From: Solar Designer <solar@...nwall.com>
To: crypt-dev@...ts.openwall.com
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.

Thanks,

Alexander