Date: Tue, 6 Jan 2015 11:40:55 -0500 From: Matt Weir <cweir@...edu> To: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com> Subject: Re: PRINCE approach from hashcat >>PRINCE is intended for slow hashes That's not my impression from watching the Passwords14 talk and conversing with Atom. It was my understanding he went over slow hashes as a way of saying we can't just blindly bruteforce the entire keyspace. That being said, I don't want to put words in his mouth and regardless it's a bit a side track since the real question is if PRINCE is useful and if so how, not how it was intended to be used. I don't think there's any debate, (and if there is please correct me!), with really slow hashes. In that case targeted dictionary attacks are the way to go. >> In fact, zoom-ins for first 1 billion and first 100M guesses would be interesting to see. I can certainly get you those graphs later tonight or I can send you the raw data. Going back to my earlier comment though I'm actually more interested in going the other direction as I'm worried my test cracking sessions represented too short of a cracking session. If you can make less than 100M guesses it seems like you are still in the area where dictionary attacks are a better bet than PRINCE or Incremental. >> I am also curious about the lengths distribution among cracked passwords. I am too! Basically I need to re-run the tests, save the cracked passwords and perform some analysis on them. >> Then, what's the total percentage of passwords cracked by PRINCE and JtR's incremental combined? While I can certainly run that test, (actually I will when I save the results of both cracking sessions), this is starting to get into the much more difficult question of what is the "optimal" way to use PRINCE in a real advanced cracking session. By that I mean you can certainly use PRINCE to crack a lot of passwords, (just like you can use Incremental on its own as well), but if you are taking the time to run multiple attacks how should you allocate your resources? This may be the academic in me but I'm hesitant to get into that right at this second since there's so many unanswered questions I have about PRINCE itself still. For example I still have serious questions about what a good input dictionary for PRINCE would be. Yes the full RockYou set does better than the top 100k Rockyou passwords, but why? Also, the --element-min --element-max options have a lot of potential for tweaking as well. >> Finally, you write: "JtR Incremental=UTF8, (equivalent to "ALL" in the older version of JtR)" That was a boneheaded mistake on my part. One of the selfish advantages of writing blog posts like this is it's really helping me kick the dust off my password cracking skills considering I haven't done much cracking at all over the last year ;p Long story short, there's a lot of unanswered questions I have when it comes to PRINCE so please keep the experiment suggestions coming. That being said, there's a lot of other stuff I want to look into as well such as updating this old post on Hashcat's Markov mode http://www.openwall.com/lists/john-users/2012/12/11/1. It may be a while before I loop back around and get to them. Matt On Tue, Jan 6, 2015 at 2:34 AM, Solar Designer <solar@...nwall.com> wrote: > On Mon, Jan 05, 2015 at 01:21:34PM -0500, Matt Weir wrote: > > I ran some tests with PRINCE and posted the results here: > > http://reusablesec.blogspot.com/2014/12/tool-deep-dive-prince.html. I > need > > to model a longer cracking session but I was pleasantly surprised with > how > > well it did. > > Thanks! Your "Experiment 3) PRINCE and JtR Wordlist + Incremental mode > targeting the MySpace list" is interesting and relevant. PRINCE does > perform surprisingly well there. Something to note, however, is that > per atom's Passwords14 talk, PRINCE is intended for slow hashes, whereas > per your test results it performed slightly worse than JtR incremental > during the first 1 billion guesses (which is often more than would be > tested against slow hashes in a non-targeted attack). It did crack 1.5% > more of the passwords than JtR's incremental by 10 billion guesses. So > it appears to be a good thing to have in the arsenal, but not exactly a > slow hash focused mode. In fact, zoom-ins for first 1 billion and first > 100M guesses would be interesting to see. (Less than 100M would be > interesting too, but then you'd need to perform extra test runs with > less wordlist pre-cracking, because it's kind of pointless to compare > PRINCE vs. incremental at less than 100M when you pre-crack ~100M with a > wordlist. To simulate attacks on slow hashes, the amounts of > pre-cracking and PRINCE/incremental need to stay sane with respect to > each other.) > > I am also curious about the lengths distribution among cracked > passwords. I guess with PRINCE the average cracked password length is > higher than with JtR's incremental. Is this so? Especially if you > exclude the wordlist pre-cracked passwords from the length statistics. > > Then, what's the total percentage of passwords cracked by PRINCE and > JtR's incremental combined? You got PRINCE to 72.5% and incremental to > 71%, but if you combine the two at the 10 billion mark, would you get > e.g. 75%? What about 5 billion mark (so 10 billion total for both, thus > comparable to the end results for the two modes individually)? > > Finally, you write: "JtR Incremental=UTF8, (equivalent to "ALL" in the > older version of JtR)". I think the equivalent to 1.7.9's "All" is > 1.8's "ASCII", not 1.8-jumbo's "UTF8". I don't know if this affected > your results significantly (and how) or not. I'd be curious to know the > answer to that: if "UTF8" performs better than "ASCII" on your test, > maybe we'd want to make it the default in jumbo. > > 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.