[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120320224323.GB26784@openwall.com>
Date: Wed, 21 Mar 2012 02:43:23 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoc] JtR GUI
Hi Dominique,
Thank you for bringing this to the list.
On Tue, Mar 20, 2012 at 04:33:50PM +0100, Dominique Heer wrote:
> It seems like several incomplete approaches for a GUI are existing, for
> example Aleksey's or Shinnok's, and I'm a little bit confused which of
> them is the one we want to continue working on. I took a look at
> Shinnoks GUI called 'johnny' and found it quite promising (and I
> referred to it in my last mail, sorry if you were talking about
> something different),
There's just one current version: the one started by Shinnok and
continued by Aleksey. Yes, it is called Johnny.
> although it is somehow 'too much'.
What do you mean by that?
> However, I now understand the performance issue, and it is also an issue
> of clearness: in my opinion, when the user loads one million hashes or
> even more, it doesn't make very much sense to show them all in a single
> table. Maybe we can use some kind of sorting or a hierachical tree view
> (as shown here:
> http://qt-project.org/doc/qt-4.8/images/windowsxp-treeview.png) that
> allows the user to expand and collapse certain rows. Don't know if Qt
> supports this and if its easy to implement ...
I did not mean to emphasize this performance and scalability issue - I
merely answered your question (off-list) on what it was about. That
said, speaking of a possible hierachical tree view, a difficulty is in
deciding how to reasonably turn the list of password file entries into a
tree. We could simply use a two-level hierarchy, with the top level
having collapsible entries, say, for each 1000 of the original list's
entries (so they'd be called e.g. 1-1000, 1001-2000, and so on). Or we
could group/split them e.g. by the first character of the username (then
we'd have the original problem back e.g. if an artificial sample file
has all entries with the same username). Or we could have separate
sub-trees for fully-cracked/partially-cracked/not-cracked passwords
(just 3 or 2 of them, depending on hash type). Or we could have
separate sub-trees by hash type (if multiple hash types are present at
once). Or we could combine several of these approaches (then we'd have
more than two hierarchy levels). Maybe these should be optional
alternatives to the obvious flat list approach, which I think we should
support either way.
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.
