[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Nov 2011 03:16:00 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: 2ch/4ch-style tripcodes?
On Mon, Nov 14, 2011 at 09:53:20PM +0000, Jordan Bradley wrote:
> I'm actually working on exactly the same thing,
Are you using JtR or writing your own code? In the latter case, are you
writing it for/using JtR or as a standalone program?
In case you didn't notice, DES-based tripcodes are readily supported in
recent -jumbo.
> however I can only get ~192K trips per second per thread.
This suggests that you're not using bitslicing. The proof-of-concept
implementation currently in -jumbo doesn't, either. Here's what it
achieves on one core in E5420 (2.5 GHz):
Benchmarking: Tripcode DES [48/64 4K]... DONE
Raw: 266624 c/s real, 266624 c/s virtual
Switching to the bitslice implementation should result in 10x better
speed per-core, and it will also allow for OpenMP parallelization to
work. I thought that Corbin would give this a try, but maybe I'll end
up doing it myself.
> If you don't mind my asking, what method do you use
> for generating passwords?
I can't speak for others, but as currently implemented in -jumbo the
stream of candidate passwords is generated by one of the same cracking
modes that JtR uses normally. The tripcode "format" is entirely
separate from that.
For bitslicing, some extra buffering and grouping will need to be
implemented (inside the "format" definition) in order to try passwords
in large enough same-crypt(3)-salt groups.
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.
