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.