Date: Mon, 12 Nov 2007 02:13:59 +0100 From: Andrea Arcangeli <andrea@...share.com> To: Solar Designer <solar@...nwall.com> Cc: john-users@...ts.openwall.com, cpushare-devel@...share.com Subject: Re: CPUShare port of John MD5 brute force Hi Solar, On Sun, Nov 11, 2007 at 11:53:28AM +0300, Solar Designer wrote: > I am really sorry for not commenting on this earlier. In case this is a > valid excuse, I had hoped my e-mails stack would not grow to 2 months > when I postponed your messages at first. I appreciate your effort a > lot, as well as your posting about it to john-users. Thank you! You're welcome, no problem with the delay, my time for CPUShare is still very limited too. > My understanding is that your added source files can stay LGPL'ed (as if > they were "libraries"), whereas your changes to JtR's files that you > got under GPL v2 fall under GPL v2 terms. I actually appreciate your > using LGPL rather than GPL v2 here as this leaves more flexibility for > others who might update this code. Ok. The only file modified should be the makefile to add the cpushare target. > I've been planning to re-work JtR source code before I add support for > more hash types, etc. If I ever find the time for that (and I hope so!), > then I'll definitely consider merging CPUShare support. Sounds good, ideally I should port it better to support the other hash types too, the sell side is very easy using the John API, the problem in supporting all hash methods is the C code that should run on top of the buy client. So I started simple with md5 default of /etc/passwd in current distro. The same way you'll be re-working your JtR source code, I'll also be changing the CPUShare on the wire protocol pretty soon to move to a full p2p model (currently it's p3p, the server always act as proxy between the two peers). The buy api.py may be altered too over time, I'm not caring about backwards compatibility at all, I just need to cook the better protocol possible as long as the number of users is low. JtR could easily run in p3p model because the traffic is so low, but for other apps like raytracing the internet overhead of proxying the ssl connection would be too high to justify the benefits of p3p. > For now, I'd rather list a contributed patch on JtR homepage and place > it on the FTP - but I see that you've already included the patch in your > cpushare tarball, which everyone who uses CPUShare will download anyway, > right? Yet we should probably mention CPUShare on JtR homepage in some Exactly, I included it because it's fairly small and it's the only complete example of an app running on top of CPUShare. But over time I'll probably be cleaner to move the John porting patch outside the core tarball. > way and maybe mirror your tarballs under /pub/projects/john/contrib on > the FTP - to make sure that JtR users are aware of this project. That's fine, a link in the web would be appreciated, thanks! > Also, I'd want to try this stuff out before I decide on it, and I just > could not find the time for that during these two months... Sure. To test it for free, you only need to run the cpushare sell client for a couple of hours then you will accumulate CPUCoins that you can use to run John on other computers that accepts transactions paid with CPUCoins (there are a couple 24/7). This will provide you a quickstart on how to run it: https://www.cpushare.com/wiki/cpushare/JohnTheRipper > Wouldn't Python be too slow when cracking fast hashes? Do you have to > do it in Python, and why? Well, the cpu intensive part is what runs on the sell computers, the C code that doesn't encrypt but only manages the new ranges to test isn't cpu intensive. Python only collects the results and decides the next ranges to test, and tracks if a client disconnects and resends the range to another client, and then stops printing in the logs the cleartext as soon as one client successfully finds the cleartext. > I think that at this stage it's fun - which is fine! Yes, to me it's especially fun to think the potential mflops/mips CPUShare will be able to emit if it will grow ;-). -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ