[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/session.php on line 580: sizeof(): Parameter must be an array or an object that implements Countable
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/session.php on line 636: sizeof(): Parameter must be an array or an object that implements Countable
3.14.by forum • What hash to support next? - Page 2
Page 2 of 3

Re: What hash to support next?

Posted: Wed Dec 31, 2008 12:17 pm
by Spaztikdude
BarsMonster wrote:Can someone please explain what is exact difference between Unix MD5 and Freebsd MD5? :-)
None!

They're even stored in the same format on freebsd. (Just in a different file than other Unix distros. I think it's /etc/master.passwd on freebsd)

So just look at my earlier post.

Re: What hash to support next?

Posted: Sun Jan 04, 2009 12:56 am
by sactre
i know that this post is not for this topic, but i would like this change will be aplicated to the future versions.
more hash in md5 are compose by a keyword that we know + password. md5(keyword+pass)
can you implement the option to add the keyword please?
sorry for my bad english and thank you for the program.

Re: What hash to support next?

Posted: Sun Jan 04, 2009 9:12 am
by Spaztikdude
sactre wrote:i know that this post is not for this topic, but i would like this change will be aplicated to the future versions.
more hash in md5 are compose by a keyword that we know + password. md5(keyword+pass)
blah blah blah blah blah.
It's called a salt. And yes, it *will* be in it eventually. (Not sure, but I think it comes somewhere in the distributed phase)

Re: What hash to support next?

Posted: Mon Jan 05, 2009 4:12 am
by tronador
NTML :P

I manage some databases with passwords md5(pass), i think i'll change to md5(sha1(pass)) :lol:

Re: What hash to support next?

Posted: Mon Jan 05, 2009 8:54 am
by neinbrucke
tronador wrote:NTML :P

I manage some databases with passwords md5(pass), i think i'll change to md5(sha1(pass)) :lol:
if you are going to change it, how about using sha2-256(salt.pass) or something like that :)

Re: What hash to support next?

Posted: Mon Jan 05, 2009 9:35 am
by BarsMonster
neinbrucke wrote:
tronador wrote:NTML :P

I manage some databases with passwords md5(pass), i think i'll change to md5(sha1(pass)) :lol:
if you are going to change it, how about using sha2-256(salt.pass) or something like that :)
I would say FreeBSD MD5 rock the world :crazy:

Re: What hash to support next?

Posted: Mon Jan 05, 2009 9:52 am
by the_drag0n
then do it. its your decicion anyways :P

Re: What hash to support next?

Posted: Tue Jan 06, 2009 12:00 pm
by Break Action
I want to vote for FreeBSD MD5

Re: What hash to support next?

Posted: Sun Jan 11, 2009 10:15 pm
by inn
DES & freebsd md5
besides DES is really faster!! :D:D

Re: What hash to support next?

Posted: Tue Jan 13, 2009 7:49 pm
by tronador
you'll choose the winner of this poll??? :P

Re: What hash to support next?

Posted: Tue Jan 13, 2009 8:21 pm
by BarsMonster
tronador wrote:you'll choose the winner of this poll??? :P
That is to prioritize things.

Re: What hash to support next?

Posted: Thu Jan 15, 2009 11:38 am
by synthesis
I prefer FreeBSD MD5 because my friend John The Ripper has these results:

guesses: 0 time: 0:00:07:51 39% c/s: 6497 trying: djyoung

about 6,5k pass / sec on core 2 duo e6600 @ 2.40GHz... that's crazy slow, just impossible to bruteforce, I can only use worlists :(

Re: What hash to support next?

Posted: Sat Jan 17, 2009 11:19 am
by remo
maybe a dumb question... but will there be support for wpa1 2? or is there already:S

Re: What hash to support next?

Posted: Sat Jan 17, 2009 11:33 pm
by Alluz
NTLM!!! kick ms balls!!!

PD.
Actually I've used Elcomsoft Distributed Password Recovery to crack ntlm with my laptop, at 45M/s

Re: What hash to support next?

Posted: Sun Jan 18, 2009 1:15 am
by GZero
FreeBSD MD5 and 3DES seem the more sensible algorithms to support.

NTLM, SHA-1, Vanilla MD5 are all easily cracked using rainbow tables. 56-bit DES is too short and is already easy to crack without the need for GPU acceleration

Generating precomputed tables isn't feasable for FreeBSD MD5 or (Most) Unix 3DES as they are salted. They would benefit most from an optimized GPU driven attack.

Re: What hash to support next?

Posted: Sun Jan 18, 2009 2:14 am
by BarsMonster
Well, there is no rainbow tables for salted algos :-)

Re: What hash to support next?

Posted: Sun Jan 18, 2009 12:20 pm
by neinbrucke
"NTLM, SHA-1, Vanilla MD5 are all easily cracked using rainbow tables"

with gpu you can already cover a larger keyspace then with rainbow tables... also you can do many hashes at the same time, without multiplying calculation time that much...

Re: What hash to support next?

Posted: Mon Jan 19, 2009 8:37 am
by inn
neinbrucke wrote:"NTLM, SHA-1, Vanilla MD5 are all easily cracked using rainbow tables"
what about MySQL then?? :D

Re: What hash to support next?

Posted: Thu Jan 22, 2009 7:44 pm
by Sc00bz
inn wrote:
neinbrucke wrote:"NTLM, SHA-1, Vanilla MD5 are all easily cracked using rainbow tables"
what about MySQL then?? :D
MySQL3.23 or MySQL-SHA1? If MySQL3.23 then there is no point as you can already test over a trillion passwords/sec on a 2.4 GHz P4.

Re: What hash to support next?

Posted: Mon Jan 26, 2009 7:57 pm
by inn
yep, that was the point, very fast :D :D :D

personally i'm interested into DES & freeBSD MD5 (as i voted)
also BlowFish cause it's very slow, even slower then freeBSD MD5 :(

Re: What hash to support next?

Posted: Tue Jan 27, 2009 6:07 pm
by Bitweasil
inn wrote:yep, that was the point, very fast :D :D :D

personally i'm interested into DES & freeBSD MD5 (as i voted)
also BlowFish cause it's very slow, even slower then freeBSD MD5 :(
DES is a bit of a challenge to implement on GPUs, as it uses a lot of resources to do it quickly (bitslicing). It may have to be broken into multiple kernel executions. It's doable, though I'm not entirely sure what uses DES for hashing other than LM hashes (hash cracking is typically implementation specific).

freeBSD MD5 should be fairly easy, though. I'm working on that. Ugly algorithm, but it's there for a reason!

Re: What hash to support next?

Posted: Wed Jan 28, 2009 7:43 am
by Sc00bz
DES will probably run faster on a GPU than a CPU per FLOPS. This is because each MP has 8,192 (8000s and 9000s) or 16,384 (GTX 200s) registers vs 16 for a CPU. The best bit slicing implementation is optimized for least amount of instructions (but it might not be the must optimal) this does not assume you only have 16 registers. If you have 192 threads / block and 1 block / MP then you'll get 42 registers / thread or 85 registers / thread. Which means that it won't need to use as much cache (shared memory). But with only 1 block / MP you might not be able to hide... global memory latency? as well as with multiple blocks / MP. Ideally you'd want at least like 134 registers (56 key, 64 plain text, 14 substitution [I just looked at the first one since it had the most gates so this might use a few more but I'm to lazy to check the other seven]).

Re: What hash to support next?

Posted: Tue Feb 10, 2009 4:10 pm
by LordMike
LM?

Implement LM!

Re: What hash to support next?

Posted: Tue Feb 10, 2009 9:05 pm
by LordMike
By implementing SHA1, you'll also make it possible to actually calculate the file out of a torrent file.

A torrent is divided into pieces, each equal in size (Except the last, which is equal to the remainder of the file).
A typical piece size is 256 KB.

But what if we made a torrent, with pieces 16 KB or lower in piece size, and set a bruteforcer to calc it. We'd be able to restore a file, solely from the torrent.
Could be cool :)

Re: What hash to support next?

Posted: Tue Feb 10, 2009 9:48 pm
by Bitweasil
LordMike wrote:By implementing SHA1, you'll also make it possible to actually calculate the file out of a torrent file.

A torrent is divided into pieces, each equal in size (Except the last, which is equal to the remainder of the file).
A typical piece size is 256 KB.

But what if we made a torrent, with pieces 16 KB or lower in piece size, and set a bruteforcer to calc it. We'd be able to restore a file, solely from the torrent.
Could be cool :)
And totally and completely impossible. Understand the many to one mapping of hashes & you'll start to understand. Also, brute forcing a 16kb space is not practical. Period. The current space for hash cracking is about 2**64 and that's *pushing* it - 2**59 or so is about the current outer limit.

16kb = 16 * 1024 * 8 bits == 2**131072 possible values.