Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 11 Nov 2007 11:53:28 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Cc: cpushare-devel@...share.com
Subject: Re: CPUShare port of John MD5 brute force

Hi Andrea,

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!

On Tue, Sep 18, 2007 at 06:25:06AM +0200, Andrea Arcangeli wrote:
> I'm unsure about the license requirement, currently I used LGPL but it
> may very well be I need to make the C part GPL, any advice is
> welcome. I know LGPL may also be upgraded (or downgraded depending on
> your point of view ;) to GPL at any time without my consent (this is a
> property of the LGPL itself). Not sure if that matters in this case?

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.

> I'd also like to know if something remotely like the below could be
> merged into john of if it has to remain separated (I included the
> patch it in the cpushare core package for now). It's not so
> invasive. However CPUShare is still in alpha status, the buy protocol
> may change a lot over time and that will require updates ...

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.

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
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.

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...

> The only mode implemented is actually a brute-force python-mode in
> charset order (inferior to the john incremental mode), but the python
> code can be changed to implement other modes, no change to the C code
> should be required. Only the encryption code of john is being run remotely.

Wouldn't Python be too slow when cracking fast hashes?  Do you have to
do it in Python, and why?

> Hope somebody finds this useful ;), or if nothing else fun!!

I think that at this stage it's fun - which is fine!

Thanks again,

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15  fp: B3FB 63F4 D7A3 BCCC 6F6E  FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments

-- 
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ