[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060407021650.GA16225@openwall.com>
Date: Fri, 7 Apr 2006 06:16:50 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: SYSKEY, John "Pro"
Rembrandt,
These messages just aren't getting any shorter or any closer to the
topic of this list.
I'll respond to stuff which is obviously on topic only.
On Thu, Apr 06, 2006 at 12:16:31PM +0200, rembrandt@...erlin.de wrote:
> Yes but pwdump isn?t system-specific.
All I meant is that pwdump is Windows-specific.
However, you've also raised the topic of its portability across Windows
versions. I am not familiar enough with Windows to seriously discuss
this. From comments that you make, I don't think that you're familiar
enough with it either.
pwdump2 does work on a lot of different Windows systems. There are,
however, also cases when it fails.
I am not sure what you're referring to with "file design" when you say
that it hasn't changed across Windows versions. If you mean file
formats, then they are, as far as I understand, irrelevant to pwdump*
since these programs do not read the files directly (instead, they
inject code which uses API calls to retrieve the information). So the
fact that pwdump2 works on such a wide range of Windows versions does
not imply that a bkhive-like tool will similarly work across that same
range of versions.
Let's end this conversation right here. If anyone who is truly familiar
with Windows, pwdump*, etc. would be willing to share some facts, that
would be helpful. Otherwise, it's just noise on the list.
> I would find it AWESOME if John would show me the already
> cracked charackters of Windowspasswords because then I could GUESS or even
> just figure out if somebody read the guidline for "secure PWs" or not...
Are you referring to implementing automated discovery of case-sensitive
Windows passwords? Yes, it would be great to have this functionality -
also in the main John branch. As I have explained, it just doesn't "fit".
But hopefully I will make it fit eventually.
Another thing that is obvious is that I am simply not spending a lot of
time on John development these days (or should I say, years?) The "Pro"
idea I had mentioned could be one way to address this, although your
(and, I'm sure, others') religious-soviet-communist attitude to this is
a reason to not do that (and let things stay the same for another 7 years?)
Regarding earning money off John:
> That`s not bad but couldn?t this be done during e.g. support contracts?!
There's almost no demand for those so far. I imagine, I could sell a
few if I explicitly offered this off the website, with specific prices,
terms, and online purchase options.
However, I am fairly sure that a "Pro" version could both bring a lot
more money and let me spend a larger portion of the time actually
working on the code. Much of this work would also benefit the main
branch of John.
> > There are indirect profits and costs associated with free software (in
> > the GNU or BSD license sense) as well. So I am already earning money
> > with software such as John and I also have related expenses (primarily
> > lost profit off other work I am not doing or paying others to do while
> > I am working on John or writing this message).
>
> I know the most stuff (costs). ...
I think you misunderstood me. I was not complaining about the costs at
all, or using it as a reason or an excuse for the "Pro". As I have
mentioned, there are indirect profits as well, and they already outweigh
the costs.
> > If you look at the Owl changelog between 1.1 and 2.0,
> > you'll notice that it's been 2 years, yet half of the changes were made
> > in the last 6 months.
>
> Sorry I wont start a flamewar. Linux has a place... even I don?t use it.
I think you misunderstood me on this as well. I was not speaking about
Linux at all; I just happened to pick this example. I know first hand
how Open Source projects advance faster when the work is paid for -
possibly out of profits off other activities. I think the same model
could also work for John, where "Pro" would provide this boost for the
main branch.
Regarding not polluting the code of the main branch of John with
system-specific features:
> Which stuff IS OS-related?
pwdump-like functionality would be an example.
There's no similar functionality in John currently. The existing un*
tools aren't it. Yes, bkhive-like functionality would be similar to
un*, not to pwdump, so I am not referring to it here.
> But do you realy think an Admin using a MAC isn`t interested into cracking
> the PWs of the Windows-Boxes he also maintains? or an Admin on a freaky
> OpenBSD isn`t interested to crack the PWs of a Linux wich uses DES?
Of course, this is useful functionality that John currently has. This
kind of functionality should remain and evolve. I am not sure why you
are even mentioning this.
> Sure the assembly is different... so speedups with specific assembly are
> the only case I can count as "OS"-Specific.
Actually, assembly language optimizations are not as OS-specific as
pwdump. They are less likely to break with a new OS version, etc.
> So why do you think a PRO wouldn`t be needed for OpenBSD, FreeBSD or QNX?
To put it simply, I expect no commercial demand which would justify the
extra effort associated with supporting these systems in "Pro".
For "Pro", the way I envision it, support for an extra system would be
quite different from that in the main branch. Well-tested builds
portable across a range of versions of the OS would need to be made.
With GUI-related libraries, this is not trivial - a combination of
static and dynamic linking would need to be used.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
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.
