Alex V. Breger | 1 Jun 22:32 2008
Picon

CUDA the Ripper

Hello

Are there any attempts to use GPU computing for John the Ripper?
There are some examples, which get 70 millions per second of raw MD5
calculations on Geforce 8800 GS (cuda md5 project) and 34 millions per
second of raw SHA1 (without downloading and uploading data to graphic
card)
I'm doing some experiments, but only get 25 million/sec for raw MD5
and 7 million/sec for raw SHA1.

There was some problems with bench.c and incremental cracker.
Benchmark can't get a full speed, which measured by real hash
cracking after a some time. How does john calculate a speed of hash
generation? I've noticed some inertness - speed is slowly growing with
time.

How fast is incremental cracker? What a maximum rate of password
generation can it get?

For CUDA I use a big sets of password (from tens of hundreds to
several millions) to transfer
to GPU for processing.
I think, that bottleneck for now is incremental cracker or my
_set_key() function. Transferring data to GPU also can be a bottleneck.

Thanks you for JtR

--

-- 
WBR, Alex V Breger

(Continue reading)

Larry Bonner | 2 Jun 02:32 2008
Picon

Re: CUDA the Ripper

Hi Alex

don't know of attempts to run JTR on GPU.. but JTR would probably need
complete re-write for this.

i tested an md5 cracker yesterday on new 8800GT, the speed was ~232
million k/s but this was written by someone else and don't have source
code for it.

an SSE2 cracker for MD5, multi-threaded on 2.4Ghz Q6600 reached ~85
million k/s with SHA-1 at ~52 million k/s

all of these reaults were using "dumb" brute force mode.

btw, elcomsoft have a patent pending on password cracking using the GPU.

--

-- 
To unsubscribe, e-mail
john-users-unsubscribe@... and reply
to the automated confirmation request that will be sent to you.

Solar Designer | 2 Jun 06:37 2008

Re: CUDA the Ripper

On Mon, Jun 02, 2008 at 12:32:45AM +0400, Alex V. Breger wrote:
> Are there any attempts to use GPU computing for John the Ripper?

I was not aware of such attempts (specific to JtR) until you mentioned yours.

> There was some problems with bench.c and incremental cracker.
> Benchmark can't get a full speed, which measured by real hash
> cracking after a some time.

I'm not sure what you mean here.  Are you saying that "--test" does not
report "full speed" as measured by something else (by what?) or that
"incremental mode" does not achieve "full speed" as reported by "--test"?

> How does john calculate a speed of hash generation?

It's somewhat different for "--test" and actual cracking, although with
"--test" JtR does try to simulate real-world scenarios (including for one
vs. many salts, when applicable).  I may be able to give a more specific
answer if you make your question more specific. ;-)

> I've noticed some inertness - speed is slowly growing with time.

You're probably talking of "incremental mode" here.  If so, this is
addressed in the FAQ:

Q: I just noticed that the c/s rate reported while using "incremental"
mode is a lot lower than it is with other cracking modes.  Why?
A: You're probably running John for a few seconds only.  The current
"incremental" mode implementation uses large character sets which need
to be expanded into even larger data structures in memory each time John
(Continue reading)

Solar Designer | 2 Jun 06:44 2008

Re: CUDA the Ripper

On Mon, Jun 02, 2008 at 01:32:29AM +0100, Larry Bonner wrote:
> don't know of attempts to run JTR on GPU.. but JTR would probably need
> complete re-write for this.

Why?  I disagree.  Most of the high-level code can stay intact.  In
fact, for slow and/or salted hashes (when there are many salts), all of
it can stay intact.

> i tested an md5 cracker yesterday on new 8800GT, the speed was ~232
> million k/s but this was written by someone else and don't have source
> code for it.

FWIW, this has some source code by an ElcomSoft developer:

http://www.troopers08.org/content/e6/e496/BELENKO_Andrej.zip

Alexander

--

-- 
To unsubscribe, e-mail
john-users-unsubscribe@... and reply
to the automated confirmation request that will be sent to you.

Larry Bonner | 2 Jun 18:36 2008
Picon

Re: CUDA the Ripper

> Why?  I disagree.  Most of the high-level code can stay intact.  In
> fact, for slow and/or salted hashes (when there are many salts), all of
> it can stay intact.
>
what i meant to say is, anyone who wants to load JTR onto the NVidia
cards is going to have to ADD alot of code using the CUDA api.

i was referring to Elcomsofts free md5 cracker in previous post, the
open source PoC is much slower than the closed source.

For example, PoC example, using 1 kernel

8600GT - ~30M k/s
8800GT - ~90M k/s

version 0.2, using 8 kernels

8600GT - ~64M k/s
8800GT - ~232M k/s

these results were all using "dumb" brute force.

using a dictionary or hybrid attack would degrade performance, since
you'd have to transfer more data between the host CPU and GPU.

--

-- 
To unsubscribe, e-mail
john-users-unsubscribe@... and reply
to the automated confirmation request that will be sent to you.

(Continue reading)

Matt Durden | 2 Jun 20:42 2008
Picon

FileVault?

Has anyone ever used JTR for FileVault? I've not had any luck finding any
info on it.
Junty Mesmon | 2 Jun 23:20 2008
Picon

Re: FileVault?

> Has anyone ever used JTR for FileVault? I've not had any luck finding any
> info on it.

Assuming you have access to the hashed login of the particular user
who's FileVault encrypted files you wish to decrypt,
JtR can crack said hash, and the following pdf has information about
the encryption mechanism and key generation (based on password).

http://crypto.nsa.org/vilefault/23C3-VileFault.pdf

On page 9:
>>Login password used to derive key for
>>unwrapping
>>– PBKDF2 (PKCS#5 v2.0), 1000 iterations

---
and after writing that, it seems the person responsible for the pdf
also wrote software to crack it anyhow.
http://crypto.nsa.org/vilefault/
the tar.gz link on that site.

--

-- 
To unsubscribe, e-mail
john-users-unsubscribe@... and reply
to the automated confirmation request that will be sent to you.

Larry Bonner | 2 Jun 23:59 2008
Picon

Re: FileVault?

it would be possible to write a module for filevault, as the hash
algorithm is based on PBKDF2 - not sure if one exist already..but
possibly WPA PSK module is available which you could modify to attack
FileVault passwords.

On Mon, Jun 2, 2008 at 7:42 PM, Matt Durden <durdenmatt@...> wrote:
> Has anyone ever used JTR for FileVault? I've not had any luck finding any
> info on it.
>

--

-- 
To unsubscribe, e-mail
john-users-unsubscribe@... and reply
to the automated confirmation request that will be sent to you.

rolf tester | 8 Jun 13:34 2008
Picon

How to chose computer for John?

Hello,

I am about to buy a new computer, which I also would like to use for password-recovery.

My questions:

* How important is RAM?

* What would be better: Intel-Pentium Dual-Core(For instance E2160), or AMD Sempron64
3000+ or AMD Athlon 64 4000?

* For John the Ripper, what is better in general, Pentium or AMD?(I read some
improvements only concern AMD, and which AMD?)

Generally I use Linux but sometimes also Windows. Is it recommended to use the new
Windows Vista?

Finally, what would be the improvement to my current AMD Duron 800??? ;-)

Benchmarking: Traditional DES [64/64 BS MMX]... DONE
Many salts:&nbsp;&nbsp;&nbsp;&nbsp; 236611 c/s
Only one salt:&nbsp; 216775 c/s

Benchmarking: BSDI DES (x725) [64/64 BS MMX]... DONE
Many salts:&nbsp;&nbsp;&nbsp;&nbsp; 7972 c/s
Only one salt:&nbsp; 7628 c/s

Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw:&nbsp;&nbsp;&nbsp; 1854 c/s

(Continue reading)

Solar Designer | 8 Jun 14:42 2008

Re: How to chose computer for John?

On Sun, Jun 08, 2008 at 11:34:11AM +0000, rolf tester wrote:
> I am about to buy a new computer, which I also would like to use for password-recovery.

OK.  My answers below are specific to current versions of JtR.  For
other password recovery and password security auditing programs things
could be different.

> My questions:
> 
> * How important is RAM?

RAM is completely unimportant.  Any size and speed will do equally well.
This means that you can also go for a lower FSB frequency (cheaper CPU)
with almost no performance loss for JtR.

> * What would be better: Intel-Pentium Dual-Core

This is not specific enough.  It could refer to completely different CPUs.

> (For instance E2160),

That's a good choice.

> or AMD Sempron64 3000+ or AMD Athlon 64 4000?

These are a lot slower, especially at DES-based hashes supported by JtR
natively (that is, not with contributed patches).

All of these are low-end, though.  If you can afford a more expensive
CPU and don't mind higher power consumption, and you really intend to be
(Continue reading)


Gmane