Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speed Hashing

codinghorror.com

Post reply on HN
Print view View original

71–80 of 133 posts

Re: Speed Hashing

#71

Post by albertsun »

nooop wrote: post #43
mistercow wrote: post #34

>A given hash uniquely represents a file, or any arbitrary collection of data. At least in theory. It really bothers me when people misuse "in theory" like that. "In theory" means "we have a model that makes good predictions in some circumstances, but there are cases where it may fall short". But a model in which hashes uniquely represent arbitrary collections of data is a model which allows for infinite compressibil…

It does not allow infinite string compression, because you obviously have to store the original data. For hashes of good length and quality, the theory stands. I would even use MD5 and say the theory stands for non-critical every day uses given there is no attacker.

If the theory doesn't stand in all cases, then it doesn't stand. It should be "in practice".

Re: Speed Hashing

#72

Post by IsTom »

mistercow wrote: post #51
nooop wrote: post #43

Earlier quoted context omitted.

It does not allow infinite string compression, because you obviously have to store the original data. For hashes of good length and quality, the theory stands. I would even use MD5 and say the theory stands for non-critical every day uses given there is no attacker.

> It does not allow infinite string compression, because you obviously have to store the original data. Nope. Say you have a hash function `h` which guarantees a unique, 128-bit output for any input. Then `h` is a function which compress any string into 128-bits: If `y = h(x)` then it is trivial for me to write a program that will reconstruct `x` from `y`. I will simply iterate `x` through the possible input strings…

That's false. Nobody is ever saying that h(x) is unique, only probability that h(x) = y for any y should be about 1/size of y choice space.

Re: Speed Hashing

#73

Post by IsTom »

donpark wrote: post #62
judofyr wrote: post #59

Earlier quoted context omitted.

> What's the point of salt if salt is in plain sight? If you by "plain sight" mean "the same place as the hash" you're misunderstanding what the salt is for. If you want to access X servers in order to verify a password, you don't need a salt; you just split the hash in X parts and store each on different servers. Salts are for preventing rainbow tables.

It doesn't matter if the hash is split into X parts and stored on X servers. We are not talking about Humpty Dumpty here and salt-specific rainbow tables can be built on-demand as long as the reward justifies the time and expense.

Salt should be user-specific, requiring construction of many rainbow tables turning this kind of attack ineffective.

Re: Speed Hashing

#74

Post by ajross »

cperciva wrote: post #36

Using "hash" to mean "strongly collision-free function" is a valid terminological choice; in a wide-readership piece like this it should ideally be pointed out in order to avoid confusion, but there are many fields where that definition would be assumed without statement. Getting confused between hash functions and password-based key derivation functions , on the other hand, is absolutely inexcusable; that very confu…

Not to quip, but surely some of the blame for that confusion has to lie on the cryptography experts who insist on using lung-spasm-inducing hairballs like "PBDKF" (edit: typo there was, I swear, unintentional!) to represent concepts better explained in English as "expensive to compute".

Re: Speed Hashing

#75

Post by mistercow »

IsTom wrote: post #72
mistercow wrote: post #51

Earlier quoted context omitted.

> It does not allow infinite string compression, because you obviously have to store the original data. Nope. Say you have a hash function `h` which guarantees a unique, 128-bit output for any input. Then `h` is a function which compress any string into 128-bits: If `y = h(x)` then it is trivial for me to write a program that will reconstruct `x` from `y`. I will simply iterate `x` through the possible input strings…

That's false. Nobody is ever saying that h(x) is unique, only probability that h(x) = y for any y should be about 1/size of y choice space.

"A given hash uniquely represents a file, or any arbitrary collection of data. At least in theory."

Re: Speed Hashing

#76

Post by dpark »

donpark wrote: post #53

Where to store the salt is that's where the real problem is. It doesn't really matter how much encryption and hashing we throw at anything if everything is stored on the same server. What's the point of salt if salt is in plain sight? What's the point of asking users to verify hash of downloadable files when hash is stored along side the file itself? What's the point of cryptography when code points straight to all t…

> What's the point of salt if salt is in plain sight?

To prevent rainbow tables and to increase attack complexity. And to prevent someone who sees a hash from being able to drop it into a search engine and get the password (works for unsalted common passwords).

The point of salt has never been secrecy.

> What's the point of asking users to verify hash of downloadable files when hash is stored along side the file itself?

To verify data integrity. It isn't an question of security, or they would be signed properly.

> What's the point of cryptography when code points straight to all that's necessary to dispell the protection?

I have no idea what you're talking about.

> Ultimate shame is that we still lack the necessary infrastructure for minimum level of security despite all the cloud-related hype, leaving each server to stand-alone which is no security at all.

Still no idea what you're talking about.

Re: Speed Hashing

#77

Post by IsTom »

eruquen wrote: post #49

Nobody mentioned pepper yet. Not the "static salt" variant which you might find while googling. That is just more security by obscurity. I'm talking about adding a random string of fixed length characters to the (salted) password that is not saved anywhere. At login, it requires a bit of brute-forcing on the server to check the hash since we have to go trough all possible pepper strings. This adds a few ms (e.g. with…

I haven't heard of this before, so I might be wrong, but I don't think it makes finding collisions any harder. It introduces expotentially many collisions in length of pepper. For example let's take xyzw and abcd such that h(xyzw) = h(abcd), now if you take peppered hash with length of pepper one you get hp(yzw) = hp(bcd).

Re: Speed Hashing

#78

Post by [deleted] »

judofyr wrote: post #61
mojuba wrote: post #38

And to slightly improve salting: $pw_hash = sprintf('%s|%s|%s|%s|%s', SALT1, $user_name, SALT2, $pw, SALT3); In fact, my salts usually include non-printables, including the NULL char, plus they are very long.

How does this improve salting? The point of salting is to avoid rainbow tables; as long as the salt is random you should be safe.

[deleted]

Re: Speed Hashing

#79

Post by tptacek »

eruquen wrote: post #49

Nobody mentioned pepper yet. Not the "static salt" variant which you might find while googling. That is just more security by obscurity. I'm talking about adding a random string of fixed length characters to the (salted) password that is not saved anywhere. At login, it requires a bit of brute-forcing on the server to check the hash since we have to go trough all possible pepper strings. This adds a few ms (e.g. with…

That's because it's a silly idea which is inferior to cryptographic adaptive hashing, as is done by bcrypt, scrypt, and PBKDF2. If you want to provide a work factor, use a real one.

Re: Speed Hashing

#80

Post by tptacek »

ajross wrote: post #74
cperciva wrote: post #36

Using "hash" to mean "strongly collision-free function" is a valid terminological choice; in a wide-readership piece like this it should ideally be pointed out in order to avoid confusion, but there are many fields where that definition would be assumed without statement. Getting confused between hash functions and password-based key derivation functions , on the other hand, is absolutely inexcusable; that very confu…

Not to quip, but surely some of the blame for that confusion has to lie on the cryptography experts who insist on using lung-spasm-inducing hairballs like "PBDKF" ( edit: typo there was, I swear, unintentional! ) to represent concepts better explained in English as "expensive to compute".

"Password based key derivation function".

The problem here isn't that cryptographers are inflicting a terrible name at you, it's that security people have repurposed a function intended for one purpose (generating crypto keys) for another (storing passwords).

Also: don't blame us, blame the PKCS standards group.

Post reply on HN