Re: [john-users] 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 ;-).
-- 
cpushare-devel_X_at_X_cpushare.com mailing list - http://www.cpushare.com/
To unsubscribe, send mail to cpushare-devel-unsubscribe_X_at_X_cpushare.com