[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 1 Apr 2011 04:18:53 +0400
From: Solar Designer <solar@...nwall.com>
To: crypt-dev@...ts.openwall.com
Subject: Re: Answering and asking some of the first questions
Hi Yuri,
On Thu, Mar 31, 2011 at 01:00:08AM -0300, Yuri Gonzaga wrote:
> Now, using the mailing list.
Yes, and I am inviting more people in here.
> Unfortunately, I don't have access to any Xilinx boards. Only Altera's.
> I agree with David that it is quite possible to move from one vendor to
> another.
> However, I think it is better to start with Altera's and focus in the
> problem itself since I am already used to work with them.
I agree.
> About my availability, unlike the U.S., the Brazilian calendar sets the
> holiday period between July and August. So, now, I will have to combine the
> GSoC's activities and my Master's studies. Anyway, I plan to reserve 15-20
> hours per week to GSoC. On my vacation, I can work harder.
> How much time do you think I should spend in the project?
This is difficult to estimate. The expected amount of "clean"/"final"
code to write is small, but most time will be spent on research, you
learning tools, algorithms, etc., testing/benchmarking, discussions,
documentation, and maybe a paper and/or a conference presentation.
> By now, could you please send some links or reference materials about the
> bcrypt?
http://www.usenix.org/events/usenix99/provos.html
http://www.openwall.com/crypt/
However, bcrypt is not exactly what we will need here. I suggested it
to you as sort of a qualification task. If you implement it in an FPGA
and integrate that with JtR, this will achieve several things:
- prove that you're in fact well suited for the project;
- get you started with programming a password hashing method in FPGA and
interfacing to it;
- demonstrate to you (and to all of us) just what is wrong with bcrypt
for this purpose (we readily know this, but a first-hand demo won't hurt);
- provide a useful contribution to JtR (although you'll need to
implement multiple bcrypt cores per chip for this to be efficient);
- provide a baseline to compare our future hashing method against (with
FPGA implementations for both).
Blowfish has already been implemented in FPGAs. bcrypt has not (as far
as I'm aware).
http://sourceforge.net/projects/blowfishvhdl/
We may skip this step (we know that bcrypt won't be right for us, except
for JtR), but I think it is good for the reasons listed above, as well
as because your work on it can proceed while we discuss further steps
and while you're waiting for guidance on issues relating to further steps.
> At first sight, I see a server receiving so much requests of user's
> authentication.
> In this context, the external hardware in the FPGA will accelerate the
> hashing of each password freeing the server from these calculations.
> Is this idea correct?
Yes, but with bcrypt in particular there's not enough parallelism in the
algorithm to fully make use of a modern FPGA chip for computation of
just one instance of a bcrypt hash. Your one bcrypt core will occupy
only a fraction of the FPGA's logic. That's a major limitation of bcrypt
for this purpose.
On a server authenticating lots of users per second, you could have
server software route different authentication attempts to different
ones of the bcrypt cores. But that's a workaround usable in a special
case only. One of our goals for this project (when we get beyond
bcrypt) will be to design a hashing method where the entire FPGA chip
(and maybe more) will be usable for just one computation of a hash.
> So, How much fast should be the FPGA to make sense?
There are no specific requirements on the FPGA speed grade, etc. for
this project.
However, as I tried to explain above, just one bcrypt core won't be very
fast anyway. It will be slower than a software implementation on a
modern CPU. For JtR, a speedup may be achieved by implementing a large
number of bcrypt cores that will work in parallel. For our main
project, that will generally not work (it will only work in the special
case mentioned above). So we'll have this baseline, and we'll move on
to the real project.
> Next week I will have to apply to the GSoC.
> Do you have any recommendations?
You just need to submit your application in time. Please fill out our
application template. As to you making a specific proposal for how to
approach this project, I think that will depend on how deeply (or not)
we discuss it in the following few days. I think a specific proposal is
not required by Google as long as the mentoring organization (us) is OK
with that. For us, you completing or at least making good progress at
the qualification task suggested above in the following couple of weeks
will be enough reason to accept you for the project. (Your application
deadline is April 8. Our acceptance deadline is April 22. I suggest
that we take care of these things sooner, though - who knows what may
break on the last day.)
How does this sound to you?
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.
