Page 1 of 1

New Hashing Method (trust-worthy?)

Posted: Sun Dec 19, 2010 10:51 pm
by toryglory
So, I was looking up some new hashing methods for my database, because I understand that MD5 and SHA have been around for a while and have dictionaries, rainbow tables, and some (limited) security risks. I came across one at hackforums.net, and am wondering if any of you could verify if it is a legitimate hashing algorithm. It appears so, after alot of testing. But I don't want to just throw anything into my database that would potentially leave it vulnerable.

the post was here:

Quote from site ::
Introduction
Hello everyone, I've been developing a hashing algorithm (similiar to MD5, and SHA) for the last year with my dorm-mates. I've wanted to release for ages... However, my friends have kept me from releasing it and instead I kept it in invitation-only beta. Now that we have finished doing the math, and programming it in PHP; I want to release it to the PHP community. I am proud to present Binary Hashing Method -- which really has nothing to do with binary after we scrapped the first idea.

After reading you can download the php file class here.
Also, you can see and example of BHM here.

It's new
I'm not going to go too much into this one, Binary Hashing Method is a new digest, meaning there are virtually no rainbow tables or hash-dictionaries. As well as an absence of any known birthday attack or inherent flaw. With all the speed of todays hashing (and more); BHM gives a new sense of security. A breath of fresh air, after years of using the same algorithms.

It's easy to Implement
Including BHM into one of your projects is easy. Simply use the following syntax :

Code: Select all

inlcude("path/to/file/bhm.php");
$handler = new bhm();    // create handler object
$handler->length = 127;    // (optional) set hash length
$handler->bhm("string","salt"); // hash/digest text
echo $handler->hash;    // retrieve hash from object
All BHM(v.1) versions will be backwards and forwards compatible. Meaning regardless of your project and the version you had previously, you will be able to update frictionlessly.

Also, you can use BHM's "smart file hashing" system in the following way:

Code: Select all

inlcude("path/to/file/bhm.php");
$handler = new bhm();    // create handler object
$handler->bhm1File('test.php');  //defaults to 127 for conformity abroad
echo $handler->hash;    // retrieve hash from object
The Next Hashing Algorithm
BHM as said previously, is a hashing algorithm. One that me and a few other friends at DaemonF Studios. We are only college students going for their PH.D's in Mathematics(2 years in) and Bachelor's in Computer Science(1 year in). However, we believe that our hashing algorithm is one of the most secure out there by default. I'll explain why later on my post. Also, please tell me if there are any sections that you have a question/comment on. I will now explain why BHM is secure.

Hash-Length Flexibility
Most of you will probably be confused by what I mean without explanation, so let me explain. Most programmers and database managers are forced to deal with the inherent flaws of MD5, SHA1, and other hashing methods... Such as well developed dictionary attacks, rainbow tables, birthday attacks, collisions, and so much more. With BHM however, you'll have far less to worry about. With the ability to change the hash length (at the same time changing the hash) you'll have full control over what dictionary set, and rainbow table the attacker uses. They divide, you conquer.

Avalanche Efffect
BHM boasts a powerful and diverse avalanche effect. For example please take a look at the following hashes :

(using 32 character length hashes)

As you can see, the avalanche effect of both hashes are comparable. Our hash's avalanche effect is well developed through its dependency on each part of the plain-text for the hash, as well as its diversity through the length of the hash. This effects the looping process and this creates both diverse hashes, and a pretty well distributed character count.

Fast Hashing
BHM is faster than MD5, 7% faster when hashing plaintext and 299% faster when doing file hashing (through the use of our smart hashing capabilities). Some people believe that this is a negative, as it encourages brute-forcing, it however, in the functions nature, to start slowing down over X (about a million) number of hashes in very minuscule amounts, but it adds up for someone attempting to brute-force.

Defense Against Collisons
MD5 is strong within itself against collisions, boasting an impressive 36 character set with a length of 32. Lets do the math for how many possibilities there are, assuming there is an even distribution.

Code: Select all

Thank you for the important correction Cida it's appreciated.
MD5 Character Set : a,b,c,d,e,f,0,1,2,3,4,5,6,7,8,9 : 16 
MD5 Length : 32 characters
Total Combinations : 16^32 : 10,633,823,966,279,326,983,230,456,482,242,756,608
There you have it, the odds of finding a collision for an MD5 hash on a pure bruteforce routine is 1 in 63,340,286,662,973,277,706,162...etc you get the point. Now, I understand that this is an already insane number, I put it here to compare it with BHM, which uses almost the entire ASCII set. Minus quotes and "<" ">" symbols. For those of you who would wish to print these out on a website or into a database without having to filter the hash itself out.

Code: Select all

BHM Character Set :126-34 : 92
BHM Length : 127 (default) characters
Total Combinations : 92^127 : 9,938,811,786,544,134,782,975,395,067,916,806,572,161,831,572,522,242,964,154,407,812,002,041,000,993,825,666,052,871,002,480,108,126,653,561,222,116,070,384,228,003,968,696,849,851,577,636,812,476,748,035,882,828,873,691,728,356,666,522,323,955,524,156,974,490,738,245,866,708,988,465,282,867,714,131,964,290,335,776,640,169,952,757
So there you have it BHM has 340,282,366,920,938,463,463,374,607,431,768,211,456 times as many possible outcomes (in it's in default) than MD5. This goes a long way to protect against collisions, as well as scaring off the less brave hackers. You can go ahead and double check my calculations, all my calculations for these horrifically huge numbers comes from http://world.std.com/~reinhold/BigNumCalc.html.

HF User Endorsements
Finally, If you look in my signature, you'll see a link to the thread that this all was originally tested from. I found quite a few candidates who were willing to test out the hash and write a review based on what they thought. Also, in the same thread, I've defended my hash mathematically against people who were genuinely skeptical and weren't being morons about it. Just in case I ever change my signature, the link is here.

Reviews from HF members
Qkyrie wrote: review on the BHM-message digest algorithm ~By Qkyrie

First of all, I'd like to thank Champloo11 for the opportunity to test this Java-implementation of his own-written hashing algorithm. While testing, I could obviously see what dedication was needed for this to succeed.

Collisions / Randomness

Of course, the first thing I did, was test on collisions and the randomness of the output depending on the input. After some combinatorics I realised that a chance of a collision was small enough to be ignored. This was the first point into making me think Champloo11 was actually pulling this off.
The randomness was tested with various inputs, which weren't a lot of difference (f.ex: aaa, aaaa, aaab etc...). All of the inputs leaded to very different outputs. Champloo already posted his findings on this. Mine were very alike, therefore I don't think it's necessary to post mine.

speed

When testing the speed of this hashing algorithm, I compared it with a fast native Java implementation of MD5 and SHA1. The SHA1 and MD5 implementations were very alike when it came to speed, therefore, afterwards, I only tested against the MD5 implementation.

speed vs file hashing

One of the things I did, was test the file-hashing algorithm implemented by Champloo11. He told me this was something he was very proud of, and therefore I just had to test it.
The results were indeed astonishing. BHM was indeed fast, it was at some times a lot faster than MD5, with a ratio of 2-1. Since file hashing speed is actually the most important speed to be measured, I think that BHM really is a good hashing technique to be used.

speed vs plaintext hashing

Of course, since the file hashing was a lot faster, I expected the plaintext hasher to have about the same ratios. Unfortunately, this was not the case.
When testing 1000 randomly generated plaintext words and comparing them to the speed of the same amount of plaintexts generated by MD5, I realised that BHM was a bit slower. The difference wasn't that big, but there's still a difference, which increases a bit if the password generator had to create more.
We shouldn't forget that this hash hash a length of 127. Therefore, it's normal that it's slower. When lowering the length, speeds increased a lot.
This of course got me thinking if it was positive or not. Which gave me the next conclusion.
Extremely fast password hashing speeds are only a good thing if you are trying to bruteforce something. Champloo11 is a person that is interested in Encryption and Security. Therefore, the hash being a bit slower is only a good thing.
A server will almost never have to generate more than 1000 hashes at a second, given that 1000 people login at the same time, or registrate, or the hash gets used for another purpose. At 1000 hashes speed is still extremely fast, so I'm not complaining.

conclusion

In my opinion, Champloo did a great job creating this versatile hashing algorithm. After thinking a bit, I'm raising my score from 9 to 9.5.
The speed isn't actually that big of a problem, and I'm pretty sure, that if your OOP in Java was created with Generics instead of overloaded methods that things would get even a bit faster.
yipyIP wrote:The other day I was able to test the BHM python module for a few hours. In my previous post, before I saw the code, I was skeptical of the hashes defense against dictionary/brute force attacks. I am no cryptography expert, but I ran a few tests and I was very impressed. Brute forcing a bhm hash is several times slower than md5 and rainbow tables would be quite a pain, leaving an 'on-the-fly' dictionary attack as the only really formidable attack. That is to say, if there are no flaws in the hashing algorithm itself; I don't know enough to properly test that. I tested this algorithm by writing a brute forcing algorithm identical to one I made for md5 hashes not long ago, and then comparing speeds between the two. Using two identical algorithms, bhm hash generated approx 200,000 hashes in a minute, where md5 generated several million. It does indeed seem that brute-forcing and hash tables for bhm would be very impractical. Another security feature I liked is the huge charset; hashes will have quotes, slashes, and all types of special characters. You'd have to be careful when setting up a service that uses it though for this reason. All in all, as far as my crypto knowledge goes, this hashing method looks promising and deserves attention, and could potentially become very popular.
bourd wrote: Ok I have tested this script.

When I was using the script on my local server is was extremal fast. Have not yet tested it on a web server.
I tested it with several strings that I randomly thought up. Each time it can out with the required result. (As Expected)
The hash would be very secure as it has a huge range of characters that it is using. I am quite sure that the information would take day to brute force.
The script only takes a few lines of code and output you has along with the char string with at first scared me! =P
The script allows for you to change the length of the encryption which will also make for great security as the person will have to have a list with length^length.
If this script ever makes it as a PHP extension I will know exactly what I would use. ( This one for those that don't know )

I am looking forward to further developments with this hash algorithm.

Regards,
Bourd
F.A.Q
Q : Doesn't a faster digest algorithm make it easier to bruteforce?
A : Long Response: Here (3rd down)

Q : How do you limit the values between X and Y?
A : Some pretty wicked mathematical functions, that work in cohesion with the trigonometric functions "sine" and "log"

Q : Are you going to try and make this apart of the PHP module?
A : Yes, i'm currently trying to get in contact with the PHP devs

Q : Is it decrypt-able? Or is it like MD5?
A : No, it is not decrypt-able it's a hash/digest system. I worded myself carefull.
If you have any comments, queries, or suggestions please post them here (i've reached the post limit)

Re: New Hashing Method (trust-worthy?)

Posted: Mon Dec 20, 2010 1:03 am
by Weirdan
I wouldn't rely on opinions of people saying something like this:
Another security feature I liked is the huge charset; hashes will have quotes, slashes, and all types of special characters.
MD5/SHA1 is a number, its encoding could be whatever you like. Encode it in base64 (instead of default hexadecimal encoding) and whoah, you've got bigger "charset". Don't encode it at all - and you get even bigger. Like it's making it any stronger...

Re: New Hashing Method (trust-worthy?)

Posted: Mon Dec 20, 2010 3:05 am
by Darhazer
toryglory instead of using unproved methods, switch to hmac md5 / sha1
this makes dictionary and rainbow attacks useless

Re: New Hashing Method (trust-worthy?)

Posted: Sun Jan 09, 2011 11:25 am
by Mordred
Hello everyone, I've been developing a hashing algorithm (similiar to MD5, and SHA) for the last year with my dorm-mates.
... aaaand game over. This is the point where you should realize that you can't trust this.

Salted hashing (like the aforementioned HMAC scheme) is the way to defeat rainbow tables. Salt-and-pepper is the way to defeat/mitigate the risk of dictionary attacks.