Bitcoin Forum

Other => Meta => Topic started by: gene on September 11, 2011, 10:17:20 AM



Title: A public service announcement
Post by: gene on September 11, 2011, 10:17:20 AM
Use BCrypt, Fool! (http://yorickpeterse.com/articles/use-bcrypt-fool/)

This forum stores passwords as weak hashes derived from weak salts using fast hash functions. It is amateur hour at bitcointalk.org.

Stop using MD5 or SHA. They were never designed to store passwords and protect them from offline attacks.

For example, MTGOX foolishly stores passwords as SHA512 hashes. (http://news.ycombinator.com/item?id=2676781) It should use bcrypt(). It is amateur hour at MTGOX and probably most other exchanges. The notable exception is bitcoin-central (https://bitcoin-central.net), which does use bcrypt.

Salts should be generated using proper random number generators (http://en.wikipedia.org/wiki//dev/random).

Again, Use BCrypt, Fool! (http://yorickpeterse.com/articles/use-bcrypt-fool/)


Title: Re: A public service announcement
Post by: ShadowOfHarbringer on September 11, 2011, 11:50:29 AM
Use BCrypt, Fool! (http://yorickpeterse.com/articles/use-bcrypt-fool/)

This forum stores passwords as weak hashes derived from weak salts using fast hash functions. It is amateur hour at bitcointalk.org.

Stop using MD5 or SHA. They were never designed to store passwords and protect them from offline attacks.

For example, MTGOX foolishly stores passwords as SHA512 hashes. (http://news.ycombinator.com/item?id=2676781) It should use bcrypt(). It is amateur hour at MTGOX and probably most other exchanges. The notable exception is bitcoin-central (https://bitcoin-central.net), which does use bcrypt.

Salts should be generated using proper random number generators (http://en.wikipedia.org/wiki//dev/random).

Again, Use BCrypt, Fool! (http://yorickpeterse.com/articles/use-bcrypt-fool/)

Actually, you don't need to use bcrypt.
You can have exactly the same effect using multiple layered hashing algorithms with specified number of rounds.
You only need to increase the number of rounds once hardware gets more powerful - it will have exactly the same effect as bcrypt.

Also, i trust multiple salted hashing algorithms more than a single algorithm (blowfish), which is used in bcrypt.


Title: Re: A public service announcement
Post by: gene on September 11, 2011, 12:19:24 PM
<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.


Title: Re: A public service announcement
Post by: Raoul Duke on September 11, 2011, 01:18:28 PM
Some real programmers, please chime in.

That must mean you are not a real programmer also and are nothing more than a parrot that can only repeat stuff without even understand what he's saying, right?


Title: Re: A public service announcement
Post by: captainteemo on September 11, 2011, 01:22:51 PM
<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.
You should be using bcrypt().
Not whatever many rounds of hashing.

Hashing is meant for huge amounts of data (such as files) and is meant to run fast - which means it can be bruteforced fast.

By using bcrypt with a high work factor, logins take one second to process - and bruteforcing takes one second per hash as opposed to 10 billion hashes per second.


Title: Re: A public service announcement
Post by: gene on September 11, 2011, 01:40:15 PM
Some real programmers, please chime in.

That must mean you are not a real programmer also and are nothing more than a parrot that can only repeat stuff without even understand what he's saying, right?

I won't presume to call myself and expert in web programming, but I have experience in certain fields going back more than 10 years. At the very least, I do know how to protect a local password database.

For those who refuse to read linked texts (lazy TL;DR crowd), let me quote a portion of it:
Quote
To cut a long story short, hashing a hash N times doesn't make your passwords more secure and can actually make it less secure as a hacker can quite easily reverse the process by generating hash collisions.

[...]

It has already been mentioned before but the solution is to use an algorithm called "BCrypt". BCrypt is a hashing algorithm based on Blowfish with a small twist: it keeps up with Moore's law. The idea of BCrypt is quite simple, don't just use regular characters (and thus increasing the entropy) and make sure password X always takes the same amount of time regardless of how powerful the hardware is that's used to generate X. I'm not going to cover all the technical details but basically BCrypt requires you to specify a cost/workfactor in order to generate a password. This workfactor not only makes the entire process slower but is also used to generate the end hash. This means that if somebody were to change the workfactor the hash would also be different. In other words, hackers, you're fucked. In order for a hacker to gain the original password he must use the same workfactor and thus has to wait N times longer than when not using a workfactor.

It might be useful to avoid problems which have long ago been solved. Simple things like using proper functions and understanding programming interfaces makes life much easier and keeps us from embarassing situations like MTGOX and others repeatedly keep finding themselves in.


Title: Re: A public service announcement
Post by: ctoon6 on September 11, 2011, 02:34:01 PM
heres an idea that might sound crazy, but what if we all used secure passwords? sure hashing as some weaknesses, but it allows for you to log in fast, and if you use a good password and a salt you should be good, as i dont think any huge company handling huge volumes of traffic would use that algorithm, simply because they do not have the required amount of processing power to keep the passwords secure and a reasonable login time.


Title: Re: A public service announcement
Post by: gene on September 11, 2011, 02:43:14 PM
heres an idea that might sound crazy, but what if we all used secure passwords? sure hashing as some weaknesses, but it allows for you to log in fast, and if you use a good password and a salt you should be good, as i dont think any huge company handling huge volumes of traffic would use that algorithm, simply because they do not have the required amount of processing power to keep the passwords secure and a reasonable login time.

Wrong threat model. Read this link:
http://codahale.com/how-to-safely-store-a-password/


Title: Re: A public service announcement
Post by: ctoon6 on September 11, 2011, 02:51:25 PM
heres an idea that might sound crazy, but what if we all used secure passwords? sure hashing as some weaknesses, but it allows for you to log in fast, and if you use a good password and a salt you should be good, as i dont think any huge company handling huge volumes of traffic would use that algorithm, simply because they do not have the required amount of processing power to keep the passwords secure and a reasonable login time.

Wrong threat model. Read this link:
http://codahale.com/how-to-safely-store-a-password/

the link contains no information i didnt already know, again, a 64cha hexadecimal password will take a really long time according to https://www.grc.com/haystack.htm . assuming the hashing algorithm isnt found to be insecure or something. hell, acording to grc, "thecowsaysmoo" would take months to crack, id consider that relatively safe, sure over time it becomes more insecure, but it does not have all the drawbacks of bcrypt. its probably fine for personal use, but once you get thousands of people logging on at the same time, that's a thousand seconds worth of computing time you need.


Title: Re: A public service announcement
Post by: ShadowOfHarbringer on September 11, 2011, 02:57:32 PM
<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.

I have been a programmer for 14 years, and FYI, i have written from scratch strong cryptography algorithms myself.
So please stop talking bullshit and let's have a real discussion other than "BCRYPT FTW, IF YOU DON'T THINK SO, STFU".

<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.
You should be using bcrypt().
Not whatever many rounds of hashing.

Hashing is meant for huge amounts of data (such as files) and is meant to run fast - which means it can be bruteforced fast.

By using bcrypt with a high work factor, logins take one second to process - and bruteforcing takes one second per hash as opposed to 10 billion hashes per second.

Wait, just let me get something straight before i continue this discussion.

If i generate a password hash using bcrypt with X rounds, and then i increase it to Y rounds, will both functions generate the same hash ?

I mean is bcrypt(pwd, rounds = 10, salt) equal to bcrypt(pwd, rounds = 20, salt) ?

Am I understanding this correctly ?


Title: Re: A public service announcement
Post by: ctoon6 on September 11, 2011, 03:00:55 PM
<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.

I am a programmer from 14 years, and FYI, i have written some stron cryptography myself from scratch.
So stop talking bullshit.

<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.
You should be using bcrypt().
Not whatever many rounds of hashing.

Hashing is meant for huge amounts of data (such as files) and is meant to run fast - which means it can be bruteforced fast.

By using bcrypt with a high work factor, logins take one second to process - and bruteforcing takes one second per hash as opposed to 10 billion hashes per second.

Wait, just let me get something straight before i continue this discussion.

If i generate a password hash using bcrypt with X rounds, and then i increase it to Y rounds, will both functions generate the same hash ?

I mean is bcrypt(pwd, rounds = 10, salt) equal to bcrypt(pwd, rounds = 20, salt) ?

Am I understanding this correctly ?

id assume no, or else it would be pointless to increase round time.


Title: Re: A public service announcement
Post by: gene on September 11, 2011, 03:05:05 PM
<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.

I am a programmer from 14 years, and FYI, i have written from scratch strong cryptography algorithms myself.
So please stop talking bullshit and let's have a real discussion other than "BCRYPT FTW, IF YOU DON'T THINK SO, STFU".

Scary... but doubtful.

Quote
<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.
You should be using bcrypt().
Not whatever many rounds of hashing.

Hashing is meant for huge amounts of data (such as files) and is meant to run fast - which means it can be bruteforced fast.

By using bcrypt with a high work factor, logins take one second to process - and bruteforcing takes one second per hash as opposed to 10 billion hashes per second.

Wait, just let me get something straight before i continue this discussion.

If i generate a password hash using bcrypt with X rounds, and then i increase it to Y rounds, will both functions generate the same hash ?

I mean is bcrypt(pwd, rounds = 10, salt) equal to bcrypt(pwd, rounds = 20, salt) ?

Am I understanding this correctly ?

No. Try reading the links. Also, bcrypt doesn't use "rounds" as a means to be slow. It has a slow key schedule.


Title: Re: A public service announcement
Post by: ShadowOfHarbringer on September 11, 2011, 03:05:56 PM
<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.

I am a programmer from 14 years, and FYI, i have written some stron cryptography myself from scratch.
So stop talking bullshit.

<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.
You should be using bcrypt().
Not whatever many rounds of hashing.

Hashing is meant for huge amounts of data (such as files) and is meant to run fast - which means it can be bruteforced fast.

By using bcrypt with a high work factor, logins take one second to process - and bruteforcing takes one second per hash as opposed to 10 billion hashes per second.

Wait, just let me get something straight before i continue this discussion.

If i generate a password hash using bcrypt with X rounds, and then i increase it to Y rounds, will both functions generate the same hash ?

I mean is bcrypt(pwd, rounds = 10, salt) equal to bcrypt(pwd, rounds = 20, salt) ?

Am I understanding this correctly ?

id assume no, or else it would be pointless to increase round time.

If no is the answer, then there is completely no advantage of using bcrypt versus multi hashes with multi salt as I have already written a recurrent function which does exactly the same as bcrypt().

You simply use the_hash_function($data, salt1, salt2, salt3, rounds) and basically what it does is it recurrently repeats

Code:
hash_algo1(salt1 + hash_algo2(salt2 + hash_algo3(salt3 + data)))

for X number of rounds, each time salting everything again.

Once the hardware becomes more powerful, i can simply increase the number of rounds to Y.


Title: Re: A public service announcement
Post by: ctoon6 on September 11, 2011, 03:08:41 PM
<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.

I am a programmer from 14 years, and FYI, i have written some stron cryptography myself from scratch.
So stop talking bullshit.

<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.
You should be using bcrypt().
Not whatever many rounds of hashing.

Hashing is meant for huge amounts of data (such as files) and is meant to run fast - which means it can be bruteforced fast.

By using bcrypt with a high work factor, logins take one second to process - and bruteforcing takes one second per hash as opposed to 10 billion hashes per second.

Wait, just let me get something straight before i continue this discussion.

If i generate a password hash using bcrypt with X rounds, and then i increase it to Y rounds, will both functions generate the same hash ?

I mean is bcrypt(pwd, rounds = 10, salt) equal to bcrypt(pwd, rounds = 20, salt) ?

Am I understanding this correctly ?

id assume no, or else it would be pointless to increase round time.

If no is the answer, then there is completely no advantage of using bcrypt versus multi hashes with multi salt as I have already written a recurrent function which does exactly the same as bcrypt().

You simply use the_hash_function($data, salt1, salt2, salt3, rounds) and basically what it does is it recurrently repeats

Code:
hash_algo1(salt1 + hash_algo2(salt2 + hash_algo3(salt3 + data)))

for X number of rounds, each time salting everything again.

Once the hardware becomes more powerful, i can simply increase the number of rounds to Y.

he said it uses a slow key schedule, so i dont think this is the same thing if you are using traditional hashing.


Title: Re: A public service announcement
Post by: gene on September 11, 2011, 03:09:15 PM
<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.

I am a programmer from 14 years, and FYI, i have written some stron cryptography myself from scratch.
So stop talking bullshit.

<whole lotta' bullshit>

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.
You should be using bcrypt().
Not whatever many rounds of hashing.

Hashing is meant for huge amounts of data (such as files) and is meant to run fast - which means it can be bruteforced fast.

By using bcrypt with a high work factor, logins take one second to process - and bruteforcing takes one second per hash as opposed to 10 billion hashes per second.

Wait, just let me get something straight before i continue this discussion.

If i generate a password hash using bcrypt with X rounds, and then i increase it to Y rounds, will both functions generate the same hash ?

I mean is bcrypt(pwd, rounds = 10, salt) equal to bcrypt(pwd, rounds = 20, salt) ?

Am I understanding this correctly ?

id assume no, or else it would be pointless to increase round time.

If no is the answer, then there is completely no advantage of using bcrypt versus multi hashes with multi salt as I have already written a recurrent function which does exactly the same as bcrypt().

You simply use the_hash_function($data, salt1, salt2, salt3, rounds) and basically what it does is it recurrently repeats

Code:
hash_algo1(salt1 + hash_algo2(salt2 + hash_algo3(salt3 + data)))

for X number of rounds, each time salting everything again.

Once the hardware becomes more powerful, i can simply increase the number of rounds to Y.

Glorious. Way to miss the point of this fundamental concept.


Title: Re: A public service announcement
Post by: ctoon6 on September 11, 2011, 03:13:11 PM
i still think bcrypt is stupid because i refuse to change my ways, you will never change me, you communist.


yes its a joke.


Title: Re: A public service announcement
Post by: ShadowOfHarbringer on September 11, 2011, 03:21:06 PM
Glorious.

I am not finished.
I can also increase the entropy by using extra secret field from the database PLUS the user's registration date which is also needed to generate the final hash.

So the entropy is not low (like in the examples shown here (http://yorickpeterse.com/articles/use-bcrypt-fool/)) anywhere within the hashing process.


Title: Re: A public service announcement
Post by: ShadowOfHarbringer on September 11, 2011, 03:28:45 PM
I studied the topic a little more:

Here is the description of the crypt() function from PHP manual, which was specified in the article "Use Bcrypt Fool":

Description
string crypt ( string $str [, string $salt ] )

crypt() will return a hashed string using the standard Unix DES-based algorithm or alternative algorithms that may be available on the system.

Some operating systems support more than one type of hash. In fact, sometimes the standard DES-based algorithm is replaced by an MD5-based algorithm. The hash type is triggered by the salt argument. Prior to 5.3, PHP would determine the available algorithms at install-time based on the system's crypt(). If no salt is provided, PHP will auto-generate either a standard two character (DES) salt, or a twelve character (MD5), depending on the availability of MD5 crypt(). PHP sets a constant named CRYPT_SALT_LENGTH which indicates the longest valid salt allowed by the available hashes.

The standard DES-based crypt() returns the salt as the first two characters of the output. It also only uses the first eight characters of str, so longer strings that start with the same eight characters will generate the same result (when the same salt is used).

On systems where the crypt() function supports multiple hash types, the following constants are set to 0 or 1 depending on whether the given type is available:

    CRYPT_STD_DES - Standard DES-based hash with a two character salt from the alphabet "./0-9A-Za-z". Using invalid characters in the salt will cause crypt() to fail.
    CRYPT_EXT_DES - Extended DES-based hash. The "salt" is a 9-character string consisting of an underscore followed by 4 bytes of iteration count and 4 bytes of salt. These are encoded as printable characters, 6 bits per character, least significant character first. The values 0 to 63 are encoded as "./0-9A-Za-z". Using invalid characters in the salt will cause crypt() to fail.
    CRYPT_MD5 - MD5 hashing with a twelve character salt starting with $1$
    CRYPT_BLOWFISH - Blowfish hashing with a salt as follows: "$2a$", a two digit cost parameter, "$", and 22 digits from the alphabet "./0-9A-Za-z". Using characters outside of this range in the salt will cause crypt() to return a zero-length string. The two digit cost parameter is the base-2 logarithm of the iteration count for the underlying Blowfish-based hashing algorithmeter and must be in range 04-31, values outside this range will cause crypt() to fail.
    CRYPT_SHA256 - SHA-256 hash with a sixteen character salt prefixed with $5$. If the salt string starts with 'rounds=<N>$', the numeric value of N is used to indicate how many times the hashing loop should be executed, much like the cost parameter on Blowfish. The default number of rounds is 5000, there is a minimum of 1000 and a maximum of 999,999,999. Any selection of N outside this range will be truncated to the nearest limit.
    CRYPT_SHA512 - SHA-512 hash with a sixteen character salt prefixed with $6$. If the salt string starts with 'rounds=<N>$', the numeric value of N is used to indicate how many times the hashing loop should be executed, much like the cost parameter on Blowfish. The default number of rounds is 5000, there is a minimum of 1000 and a maximum of 999,999,999. Any selection of N outside this range will be truncated to the nearest limit.


Then basically, what crypt() function does, is multiple salted rounds of hashing.

So can somebody explain to me what is the difference between bcrypt and my algorithm ?

Code:
hash_algo1(salt1 + hash_algo2(salt2 + hash_algo3(salt3 + data))) * N recursive rounds

Because, seriously - I cannot find one.


Title: Re: A public service announcement
Post by: theymos on September 11, 2011, 06:37:47 PM
If you create a modification for SMF that uses advanced password hashing and gracefully upgrades from old hash types, I will use it.

Bcrypt is probably fine, though I tend to prefer many iterations of traditional hash algorithms. This is what hashes were designed to do. PGP does it, and it's used in many crypto standards.


Title: Re: A public service announcement
Post by: ShadowOfHarbringer on September 11, 2011, 07:13:44 PM
If you create a modification for SMF that uses advanced password hashing and gracefully upgrades from old hash types, I will use it.

Bcrypt is probably fine, though I tend to prefer many iterations of traditional hash algorithms. This is what hashes were designed to do. PGP does it, and it's used in many crypto standards.

I can supply the hashing algorithm, as I have already written it.
Give me half an hour, i need to start up the laptop and find it.


Title: Re: A public service announcement
Post by: ShadowOfHarbringer on September 11, 2011, 07:45:38 PM
Here ya go:

Code:
define('CNF_PASSWORD_SALT1', 'fvuiyt8635t394nng'); //Change this to some random stuff
define('CNF_PASSWORD_SALT2', 'sdfkofuhnA%^%^23J'); //Change this to some random stuff

define('CNF_PASSWORD_HASH0', 'sha512');
define('CNF_PASSWORD_HASH1', 'whirlpool');
define('CNF_PASSWORD_HASH2', 'sha512');

//20 rounds by default. Change to more if more security is required
define('CNF_PASSWORD_EXTRA_ROUNDS', 20);


class HashPassword {

protected static $level0PassHash = null;
protected static $level1PassHash = null;
protected static $level2PassHash = null;

protected static $defaultHashRounds = null;

protected static function _init(){
self::$level0PassHash = CNF_PASSWORD_HASH0;
self::$level1PassHash = CNF_PASSWORD_HASH1;
self::$level2PassHash = CNF_PASSWORD_HASH2;

self::$defaultHashRounds = CNF_PASSWORD_EXTRA_ROUNDS;
}

public static function Make($inputData, $extraSalt = false, $extraRounds = false) {
if (!isset(self::$level0PassHash)){
self::_init();
}

if ($extraRounds === false) {
$extraRounds = self::$defaultHashRounds;
}

if ($extraRounds > 0) {//More rounds through recursion
$halfStringPos = floor(strlen($inputData) / 2);
$inputData = substr($inputData, $halfStringPos) . substr($inputData, 0, $halfStringPos); //This shifts the string on each round -  '123456' into '456123' etc.
$inputData = self::Make($inputData, $extraSalt, $extraRounds - 1); // Recursion
}

$hashLevel0 = $extraSalt ?
hash(self::$level0PassHash, $extraSalt.$inputData.$extraSalt) :
hash(self::$level0PassHash, $inputData);

$hashLevel1 = hash(self::$level1PassHash, CNF_PASSWORD_SALT1.$inputData.CNF_PASSWORD_SALT1);

$output = hash(self::$level2PassHash, CNF_PASSWORD_SALT2.$hashLevel0.CNF_PASSWORD_SALT2);

return $output;
}

}

3 layered hashing, different salt on each layer. Level 3 salting is optional.

There are 3 smaller rounds in a single big round, so a total of 20 rounds (default) gives you 60 salted hashing rounds in total for a single password. Benchmark your scripts and change the number of rounds depending of the power of your servers. Too many rounds can clog up the server as users logging in massively will use a lot of CPU.

20 big rounds should be enough for everyone for starters.

Usage:
Code:
HashPassword::Make($data, [optional] $additionalLevel3Salt = null, [optional] $changeNumberOfRounds = 20);

If you want some serious security, put (for example) user's registration date (or anything else generated randomly on registration) into the $additionalLevel3Salt parameter. It will make rainbow tables attack unfeasible.

This is a production - grade code. It should work without any modifications.


License:
WTFPL License, http://en.wikipedia.org/wiki/WTFPL



---------------------
EDIT:
Also, there is a useful list of different hashing algorithms' speed on php.net

Performance test results on my laptop:
Results are here shorten to fit php web notes ...
This was tested with 1024000 bytes (1000 KB) of random data, md4 always gets the first place, and md2 always get the last place :)

Results: (in microseconds)
   1.  md4                           5307.912
   2.  md5                           6890.058
   3.  crc32b                        7298.946
   4.  crc32                         7561.922
   5.  sha1                          8886.098
   6.  tiger128,3                    11054.992
   7.  haval192,3                    11132.955
   8.  haval224,3                    11160.135
   9.  tiger160,3                    11162.996
  10.  haval160,3                    11242.151
  11.  haval256,3                    11327.981
  12.  tiger192,3                    11630.058
  13.  haval128,3                    11880.874
  14.  tiger192,4                    14776.945
  15.  tiger128,4                    14871.12
  16.  tiger160,4                    14946.937
  17.  haval160,4                    15661.954
  18.  haval192,4                    15717.029
  19.  haval256,4                    15759.944
  20.  adler32                       15796.184
  21.  haval128,4                    15887.022
  22.  haval224,4                    16047.954
  23.  ripemd256                     16245.126
  24.  haval160,5                    17818.927
  25.  haval128,5                    17887.115
  26.  haval224,5                    18085.002
  27.  haval192,5                    18135.07
  28.  haval256,5                    18678.903
  29.  sha256                        19020.08
  30.  ripemd128                     20671.844
  31.  ripemd160                     21853.923
  32.  ripemd320                     22425.889
  33.  sha384                        45102.119
  34.  sha512                        45655.965
  35.  gost                          57237.148
  36.  whirlpool                     64682.96
  37.  snefru                        80352.783
  38.  md2                           705397.844

Plus the lengths of hashes produced by each of the algos:

Quote
md2           32
md4           32
md5           32
sha1          40
sha256        64
sha384        96
sha512       128
ripemd128     32
ripemd160     40
ripemd256     64
ripemd320     80
whirlpool    128
tiger128,3    32
tiger160,3    40
tiger192,3    48
tiger128,4    32
tiger160,4    40
tiger192,4    48
snefru        64
gost          64
adler32        8
crc32          8
crc32b         8
haval128,3    32
haval160,3    40
haval192,3    48
haval224,3    56
haval256,3    64
haval128,4    32
haval160,4    40
haval192,4    48
haval224,4    56
haval256,4    64
haval128,5    32
haval160,5    40
haval192,5    48
haval224,5    56
haval256,5    64


Have fun.


Title: Re: A public service announcement
Post by: gene on September 11, 2011, 08:06:06 PM
This is what hashes were designed to do.

No. They are designed to quickly compute a mostly unique digest for a preimage.

Quote from: ShadowOfHarbringer


Title: Re: A public service announcement
Post by: ShadowOfHarbringer on September 11, 2011, 08:10:15 PM
This is what hashes were designed to do.

No. They are designed to quickly compute a mostly unique digest for a preimage.

Quote from: ShadowOfHarbringer
[image]

Can you please stop talking "I'm smarter than you and I know better" bullshit and show me the difference between bcrypt() and my algo ?
Because sorry - there isn't any according to PHP manual.


----
EDIT2:
Investingating the matter further, actually it seems that my function far better than crypt(), as it uses different salt for each layer of hashing, where crypt() only uses single salt for all layers.

----
EDIT:
OK, i have had enough of this.
Only a fool uses the argument of power instead of power of arguments.

So you either show me the logical evidence that you are correct, or I will officially view you as a fool. I dare you.


Title: Re: A public service announcement
Post by: gene on September 12, 2011, 06:27:20 AM
Can you please stop talking "I'm smarter than you and I know better" bullshit and show me the difference between bcrypt() and my algo ?
Because sorry - there isn't any according to PHP manual.

Try harder. Maybe read primary references.

Quote
EDIT2:
Investingating the matter further, actually it seems that my function far better than crypt(), as it uses different salt for each layer of hashing, where crypt() only uses single salt for all layers.

Cool. Now go write a paper and submit it, because you have just discovered something that dozens of security specialists over several decades couldn't. Or... maybe you missed something rather important and are letting your ego get the better of you. Sorry, but you're no Niels Provos.

Quote
EDIT:
OK, i have had enough of this.
Only a fool uses the argument of power instead of power of arguments.

So you either show me the logical evidence that you are correct, or I will officially view you as a fool. I dare you.

Try reading and understanding what bcrypt actually does instead of assuming that you have trivially solved one of the most well-studied problems in computer security.


Title: Re: A public service announcement
Post by: Alex Zee on September 12, 2011, 06:52:24 AM
[SYSTEM MESSAGE]: Arrogance indicator overflowing!


Title: Re: A public service announcement
Post by: ShadowOfHarbringer on September 12, 2011, 07:26:02 AM
Can you please stop talking "I'm smarter than you and I know better" bullshit and show me the difference between bcrypt() and my algo ?
Because sorry - there isn't any according to PHP manual.

Try harder. Maybe read primary references.

Quote
EDIT2:
Investingating the matter further, actually it seems that my function far better than crypt(), as it uses different salt for each layer of hashing, where crypt() only uses single salt for all layers.

Cool. Now go write a paper and submit it, because you have just discovered something that dozens of security specialists over several decades couldn't. Or... maybe you missed something rather important and are letting your ego get the better of you. Sorry, but you're no Niels Provos.

Quote
EDIT:
OK, i have had enough of this.
Only a fool uses the argument of power instead of power of arguments.

So you either show me the logical evidence that you are correct, or I will officially view you as a fool. I dare you.

Try reading and understanding what bcrypt actually does instead of assuming that you have trivially solved one of the most well-studied problems in computer security.


OK.... so here you go.
You have no arguments whatsoever and you are simply saying "hey, I am right because the guy in the article said so". You also have completely no idea how the bcrypt() itself works, as you cannot explain the differences between it and my algorithm in detail.

I am sorry, but you are no cryptography specialist or even an experienced programmer. I find it a waste of time to continue discussing with trolls.

EOT.


Title: Re: A public service announcement
Post by: FalconFour on September 12, 2011, 09:05:30 AM
[SYSTEM MESSAGE]: Arrogance indicator overflowing!
This.

Children, can we stop fighting?

I just did a quick search for bcrypt and saw how pointlessly irrelevant it is:
http://duckduckgo.com/?q=bcrypt
It's a file hashing algorithm FFS. First demonstrated on a Pentium-II, I'm sure, to much fanfare after it took a full second to crunch out. In 1999.

(and to think, prior to scrolling up and reading Shadow's full-blown WTFPL-licensed smack-code, followed by gene's totally worthless off-topic reply, I was almost siding with gene here - then I searched it.)

Here's what we need: an algorithm that's designed for passwords, not files. Run an MD5 through a SHA-1 and a Blowfish and a fuck-why-not-throw-the-rest-in-there-too set of hashes, then store THAT fucking hash in the database. Someone types in a password, run it through the same gauntlet of hashes, compare the result. Match? Good, sexy, let 'em in. Mash two together in a run or something. Obscurity? You bet your fucking ass, but without reading the source code, you'd have no idea how to break the values apart to reverse them, it'd be impossible.

Or just find an API to KeePass or some shit, store everything in there. I dunno, it's probably been done.
(and I can guarantee nobody will have a gripey bitch about how secure KeePass is.)

Or here's a better idea: don't let your fucking forum SQL database get compromised in the first place.


Title: Re: A public service announcement
Post by: Pieter Wuille on September 12, 2011, 09:41:16 AM
Bcrypt means two things: a hashing algorithm and a file encryption utility, both of which are based on the blowfish algorithm.

To encrypt passwords and want to prevent a stolen database from being hacked easily, you need a slowdown. If checking one password for correctness takes N times longer, it takes N times longer to crack as well. The intent is to make a single check as slow as you can bear.

Schemes like iterated sha512 or pbkdf2 achieve this slowdown by hashing multiple times, bcrypt achieves it through a slow key scheduling step.

Given that no preimage attack against the used hash function (sha1 on this forum and in pbkdf2, sha512 on mtgox) exist, I'd say they are equally safe if their verification step takes the same time. There exist attacks against sha1, but only collision attacks (which won't help you here) and theoretical preimage attacks (which don't really help much)

The main advantage of bcrypt is that is slower to implement on hardware, but not so much anymore on modern hardware. A more recent password hashing system called scrypt was designed to overcome this, but is not very much used. Given that the bitcoin community has massive amounts of computation hardware, that may be the best choice.

Sources:
  • http://stackoverflow.com/questions/2772014/is-sha-1-secure-for-password-storage (http://stackoverflow.com/questions/2772014/is-sha-1-secure-for-password-storage)
  • http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415 (http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415)


Title: Re: A public service announcement
Post by: gene on September 12, 2011, 09:47:59 AM
I'm not the one claiming to have written a superior technique here. The burden of proof rests with the person making claims about his superior his method is compared to established methods. Also, the functions are already written in basically every language that matters.


Look at how easy this is:
Code:
$hash = bcrypt_hash({
                        key_nul => 1,
                        cost => 8,
                        salt => $salt,
                }, $password);
Done. That particular problem is now solved, and you can go on to other issues.

No need for algorithms of dubious efficacy written by anonymous authors.

Also, don't take my word for it:
https://bitcointalk.org/index.php?topic=17004.msg228724#msg228724

Bcrypt effectively eliminates offline attacks. Iterative hashing does not. Again, I'm not the one who proved that. This has been well understood for many years. Time to use the right tools.

Also worth noting explicitly, as this has come up: the question of obtaining the database is of course important, but it is a separate issue.


Title: Re: A public service announcement
Post by: ShadowOfHarbringer on September 12, 2011, 06:08:50 PM
@gene

When you are done trolling and making a fool of yourself and you actually **understand** what bcrypt() does, then we can talk.
For now, I find discussion with you a complete waste of time.


Title: Re: A public service announcement
Post by: ctoon6 on September 12, 2011, 08:05:47 PM
is this by chance what keepass uses to make breaking your password DB more difficult?


Title: Re: A public service announcement
Post by: theymos on September 12, 2011, 08:36:45 PM
is this by chance what keepass uses to make breaking your password DB more difficult?

KeePass uses SHA-256.


Title: Re: A public service announcement
Post by: ctoon6 on September 12, 2011, 08:58:33 PM
is this by chance what keepass uses to make breaking your password DB more difficult?

KeePass uses SHA-256.

what is this number for exactly? it makes saving the DB slower so i assumed it did a similar thing.

http://img651.imageshack.us/img651/1307/keepass.png


Title: Re: A public service announcement
Post by: gene on September 12, 2011, 09:10:35 PM
The funniest thing about this discussion (besides ShadowOfHarbringer, or course, who makes me cringe with each post (https://bitcointalk.org/index.php?topic=16457.msg222943#msg222943)) is that in a forum dedicated to software which depends on hashing the shit out of SHA256 -- where people buy cheap video cards which are capable of generating literally hundreds of millions of SHA256 hashes per second on a single video card -- people still think that sha256 is a great way to slow down offline password cracking.

Pathetic. And the hits will keep on coming. More stolen password databases from poorly secured websites. More stolen emails and more stolen passwords. An endless comedy of errors and bad PR.

Also, nice ponzi scheme signature, theymos... inspires a lot of confidence in those who are first learning about bitcoin to see that a "Administrator/Hero Member" peddles a fucking ponzi scheme. I'm sure that won't reinforce the suspicions that people already have... What happened to your previous ponzi scheme website? Wasn't there some security problem there too?

BTW. Keypass uses SHA256 to truncate or expand a user's password to 256 bits. It has nothing to do with adding computational cost to cracking.

Quote
what is this number for exactly? it makes saving the DB slower so i assumed it did a similar thing.

Who knows? The authors apparently don't go out of their way to make it clear, but then again, I don't use keepass... smells a bit too much like snakeoil (http://www.schneier.com/crypto-gram-9902.html#snakeoil).


Title: Re: A public service announcement
Post by: ctoon6 on September 12, 2011, 09:14:32 PM
The funniest thing about this discussion (besides ShadowOfHarbringer, or course, who makes me cringe with each post) is that in a forum dedicated to software which depends on hashing the shit out of SHA256 -- where people buy cheap video cards which are capable of generating literally hundreds of millions of SHA256 hashes per second on a single video card -- people still think that sha256 is a great way to slow down offline password cracking.

Pathetic. And the hits will keep on coming. More stolen password databases from poorly secured websites. More stolen emails and more stolen passwords. An endless comedy of errors and bad PR.

Also, nice ponzi scheme signature, theymos... inspires a lot of confidence in those who are first learning about bitcoin to see that a "Global Moderator" peddles a fucking ponzi scheme. I'm sure that won't reinforce the suspicions that people already have...

BTW. Keypass uses SHA256 to truncate or expand a user's password to 256 bits. It has nothing to do with adding computational cost to cracking.

Quote
what is this number for exactly? it makes saving the DB slower so i assumed it did a similar thing.

Who knows? The authors apparently don't go out of their way to make it clear, but then again, I don't use keepass... smells a bit too much like snakeoil (http://www.schneier.com/crypto-gram-9902.html#snakeoil).

yet you trust the very keys that have claim over your coins, and what else would you recommend to store passwords in? lastpass?, don't get me started.


Title: Re: A public service announcement
Post by: gene on September 12, 2011, 09:18:55 PM
yet you trust the very keys that have claim over your coins

Wrong. I trust that I can keep my private key secure. You're conflating separate issues.

Quote
and what else would you recommend to store passwords in? lastpass?
GnuPG (http://www.gnupg.org).


Title: Re: A public service announcement
Post by: FalconFour on September 12, 2011, 09:29:15 PM
The funniest thing about this discussion (besides ShadowOfHarbringer, or course, who makes me cringe with each post (https://bitcointalk.org/index.php?topic=16457.msg222943#msg222943))
Oh god, I seriously wanted to reply a big fat "WTF?!" to that post. Biggest crock of bullshit I'd ever read. Why the fuck install an entire virtualized operating system inside a multi-encrypted disk image... that shit doesn't even make any sense; just use the same outer encryption library to create another disk image inside the first layer, which itself is, despite the encryption layer residing on the outside, still encrypting data within a subsequent layer in the same way. Shit just makes me cringe thinking the guy wanted to install multiple OS copies inside multiple layers to produce an illusion of security... it's still protected by a f***ing password. /headdesk
Quote
what is this number for exactly? it makes saving the DB slower so i assumed it did a similar thing.

Who knows? The authors apparently don't go out of their way to make it clear, but then again, I don't use keepass... smells a bit too much like snakeoil (http://www.schneier.com/crypto-gram-9902.html#snakeoil).
KeePass user here. Works damn fucking well IMO. Here's how the key transformation thing works, to my understanding:
your master composite key (whatever method you use to authenticate - a password, a file, etc) -> key to encrypt data stored in each data row of login data <-><-> buttfuck using some encryption algorithm -> repeat 100,000+ times to generate completely incomprehensible data.
That happens whenever the DB is changed and saved. And when it's opened, it goes through the reverse mechanism: take a row, un-buttfuck it 100,000 times, and see if it's valid data. If not, bad composite key, try again. If so, buzzah, there's your key. Except that there's no way to break down any one of those 99,999 intermediate steps to see if you got it right without going through each one of the 100,000 iterations for every attempt. So let's amplify your brute-force method by 100,000 times and see how long it takes to crack the fuckin' database, shall we? ;)

I'd say it's pretty effective.
(that's also why it takes about 20 seconds for my phone to load the database (a 55KB database from SD) that takes only about 1 second for my computer to load. 600MHz processor sucks ass.)


Title: Re: A public service announcement
Post by: trentzb on September 12, 2011, 09:54:52 PM
I've been watching http://en.wikipedia.org/wiki/NIST_hash_function_competition and particularly Skein (http://www.skein-hash.info/). Seems interesting.


Title: Re: A public service announcement
Post by: ShadowOfHarbringer on September 13, 2011, 07:48:22 AM
The funniest thing about this discussion (besides ShadowOfHarbringer, or course, who makes me cringe with each post (https://bitcointalk.org/index.php?topic=16457.msg222943#msg222943))

This has nothing to do with the current topic.

I am not listening to you, until you explain what is the difference between bcrypt() and my func. Because i keep stating you have no fuckin idea what you are talking about. You are deliberately making offtopic to mask your total lack of knowledge, but this trick does not work with me.

I dare you. Explain that to me. Still waiting.

Also, about earlier post:
Quote from: gene
Look at how easy this is:
Code:
$hash = bcrypt_hash({
                        key_nul => 1,
                        cost => 8,
                        salt => $salt,
                }, $password);

Look how easy this is:
Code:
$hashedPassword = HashPassword::Make($password, 'LEVEL3 SALT', 2048); //Total of 6144 rounds

This will provide stronger hashing than bcrypt() with 12 rounds , as each round in bcrypt() is actually a power of 2 rounds (bcrypt(data, 12) gives you actually total 4096 small rounds if I am not mistaken) .



Oh god, I seriously wanted to reply a big fat "WTF?!" to that post. Biggest crock of bullshit I'd ever read. Why the fuck install an entire virtualized operating system inside a multi-encrypted disk image... that shit doesn't even make any sense; just use the same outer encryption library to create another disk image inside the first layer, which itself is, despite the encryption layer residing on the outside, still encrypting data within a subsequent layer in the same way. Shit just makes me cringe thinking the guy wanted to install multiple OS copies inside multiple layers to produce an illusion of security... it's still protected by a f***ing password. /headdesk

This is just one bad idea, **which I admitted is not the best sollution** in the same topic. But still gives you higher level of security than no virtual machine at all (the attacker has to crack all the layers, which will take time. Also, he has to figure out that there is VM within VM, which he may accidentally not do).

But what is important, this has completely nothing to do with the current discussion.


Title: Re: A public service announcement
Post by: Pieter Wuille on September 13, 2011, 08:58:12 AM
The funniest thing about this discussion (besides ShadowOfHarbringer, or course, who makes me cringe with each post (https://bitcointalk.org/index.php?topic=16457.msg222943#msg222943))

This has nothing to do with the current topic.

I am not listening to you, until you explain what is the difference between bcrypt() and my func. Because i keep stating you have no fuckin idea what you are talking about.

I dare you. Explain that to me. Still waiting.

Also, about earlier post:
Quote from: gene
Look at how easy this is:
Code:
$hash = bcrypt_hash({
                        key_nul => 1,
                        cost => 8,
                        salt => $salt,
                }, $password);

Look how easy this is:
Code:
$hashedPassword = HashPassword::Make($password, 'LEVEL3 SALT', 2048); //Total of 6144 rounds

This will provide stronger hashing than bcrypt() with 12 rounds , as each round in bcrypt() is actually a power of 2 rounds (bcrypt(data, 12) gives you actually total 4096 small rounds if I am not mistaken) .

The "strength" of the hashing is irrelevant (even an 80-bit hash function - used properly - cannot be bruteforced by the current bitcoin network in any reasonable time). The only thing that matters is how long it takes to try one key for an attacker. bcrypt and whatever iterated hashing you're using achieve this in a very different way, and it is hard to compare.

It is true by the way that iterated hashing increases the chances for collisions, but only slightly. As explained in an earlier linked post, NIST recommends PBKDF2 for storing passwords, which is in fact based on salted iterated hashing.

So please stop throwing insults to eachother. Yes, bcrypt() is a very good way for storing passwords, but so it a (well implemented) iterated hashing scheme. Iterated hashing schemes are better researched and used, but bcrypt() is somewhat slower to implement in hardware. If you really want maximal resistance to hardware-assisted attacks, scrypt() may be an even better choice, yet even more recent.


Title: Re: A public service announcement
Post by: gene on September 13, 2011, 09:00:46 AM
It's not my job to hand-feed you. I provided some initial references, and now it is up to you to explain why your method is superior. You have not.

The reasons why eksblowfish is several orders of magnitude harder (http://news.ycombinator.org/item?id=1091445) to bruteforce that other algos (like SHA, or N interations of hash-x) have little to do with iterations. It is because hashes were never designed to encrypt passwords, despite what theymos may think. They are, in part, designed to be fast. This is the opposite of what you want when protecting from password cracking (slow).

from http://www.skein-hash.info/about :
Quote
The Skein Hash Function Family
Fast, Secure, Simple, Flexible, Efficient. And it rhymes with "rain."

[...]

Skein is fast. Skein-512—our primary proposal—hashes data at 6.1 clock cycles per byte on a 64-bit CPU. This means that on a 3.1 GHz x64 Core 2 Duo CPU, Skein hashes data at 500 MBytes/second per core—almost twice as fast as SHA-512 and three times faster than SHA-256. An optional hash-tree mode speeds up parallelizable implementations even more. Skein is fast for short messages, too; Skein-512 hashes short messages in about 1000 clock cycles.

The references explain why eksblowfish is so good at being slow. But go ahead... keep "daring" me to explain (the references that I posted in this thread do an ample job, for those who are interested). I will admit that your taunts amuse me, however.

The post of yours that I linked is salient because it demonstrates your level of understanding of security issues (https://bitcointalk.org/index.php?topic=16457.msg222943#msg222943). You seem to think that just by nesting questionable mechanisms N times, that you have achieved some sort of a secure cascade effect. This is demonstrably untrue in your "methods," as FalconFour described. It may help others decide wether or not to trust your scheme if they know what other schemes you have proposed on these very fora.

Also, the burden of proof rests on the person who presents new methods. You.

Bcrypt is the best tool to protect password databases against offline attacks.


Title: Re: A public service announcement
Post by: gene on September 13, 2011, 10:47:30 AM
The "strength" of the hashing is irrelevant (even an 80-bit hash function - used properly - cannot be bruteforced by the current bitcoin network in any reasonable time). The only thing that matters is how long it takes to try one key for an attacker. bcrypt and whatever iterated hashing you're using achieve this in a very different way, and it is hard to compare.

It is true by the way that iterated hashing increases the chances for collisions, but only slightly. As explained in an earlier linked post, NIST recommends PBKDF2 for storing passwords, which is in fact based on salted iterated hashing.

So please stop throwing insults to eachother. Yes, bcrypt() is a very good way for storing passwords, but so it a (well implemented) iterated hashing scheme. Iterated hashing schemes are better researched and used, but bcrypt() is somewhat slower to implement in hardware. If you really want maximal resistance to hardware-assisted attacks, scrypt() may be an even better choice, yet even more recent.

Scrypt looks good, and if I were a bit less conservative with these issues, I would use it. The only thing is that it hasn't been around for as long, so maybe not quite as much peer review and bcrypt. I'm not sure if I trust the implementations out there yet. The CYA types love PBKDF2 because it meets all "industry standards," and that is ok, I suppose. After all, everything out of RSA® (The Security Division of EMC Corp.) has been bulletproof, right?  ;)


Title: Re: A public service announcement
Post by: ShadowOfHarbringer on September 13, 2011, 06:07:30 PM
The reasons why eksblowfish is several orders of magnitude harder (http://news.ycombinator.org/item?id=1091445) to bruteforce that other algos (like SHA, or N interations of hash-x) have little to do with iterations.

Let me quote something for you:

Provos and Mazières took advantage of this, and actually took it further. They developed a new key setup algorithm for Blowfish, dubbing the resulting cipher "Eksblowfish" ("expensive key schedule Blowfish"). The key setup begins with a modified form of the standard Blowfish key setup, in which both the salt and password are used to set all subkeys. Then there are a number of rounds in which the standard Blowfish keying algorithm is applied, using alternately the salt and the password as the key, each round starting with the subkey state from the previous round. This is not cryptographically significantly stronger than the standard Blowfish key schedule, but the number of rekeying rounds is configurable; the hashing process can therefore be made arbitrarily slow, which helps deter brute-force attacks upon the hash or salt.

As you are an insolent fool, which doesn't understand a thing about hashing algorithms and you failed to explain how bcrypt actually works, let me explain you in my own words what this description means.

Roughly the eksblowfish is all about creating multiple keys, of which each is mixed with salt, and then each of the keys is applied in each of multiple rounds of the algorithm. Each next (n+1) round begins in mixing the key with salt and applying it to the previous (n) round through encryption. In other words, bcrypt() is simply a recurrent hashing algorithm, where each consecutive round of hashing begins with adding the salt to the result of previous round.

Exactly as the algorithm which I have written.

The references explain why eksblowfish is so good at being slow. But go ahead... keep "daring" me to explain (the references that I posted in this thread do an ample job, for those who are interested). I will admit that your taunts amuse me, however.

You are still a fool, and you have explained nothing. What you have done is a copypasta work from other sites. You haven't actually described in your own words how the algorithms work.

The post of yours that I linked is salient because it demonstrates your level of understanding of security issues (https://bitcointalk.org/index.php?topic=16457.msg222943#msg222943). You seem to think that just by nesting questionable mechanisms N times, that you have achieved some sort of a secure cascade effect

1. Learn to read first, before you start talking to me. I have never ever in any post said anything about any "cascade effect".
2. STOP MANIPULATING!. STOP making offtopic so it makes you look smarter than you actually are. You are weak, and you are using cheap tricks of the weak. This will not work with me.

It's not my job to hand-feed you.

It is your job to provide valid logical arguments since you started this stupid discussion. You have failed to do so.

Bcrypt is the best tool to protect password databases against offline attacks.

Actually, i personally think about incorporating bcrypt() into my algo for greater performance, but i will be continuing this discussion just to prove how stupid, impudent and manipulative you are.