[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110429041514.GB26349@openwall.com>
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
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.
