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.