exesteam wrote:i am using hashing for passwords
That one sentence means that we are discussing password hashing here. At least this is the way I think, I try to stick with the OP's questions.
Mordred wrote:For example,
kaisellgren said:
SHA-2 among with other *newer* and stronger hash families are enough to prevent any attacks. There is zero need to complicate hashing by altering it or running it through series of string and data manipulations.
Within the context of password hashing it is more or less true, although not entirely.
Within the contaxt of general, cryptographic usage of hashes, it is not true, the hashes from MD5 and SHA families suffer from length-extension attacks, meaning they can't be used as MACs and similar usages.
It was purely meant for password hashing. It is true that what I said is not entirely "true". I doubt that these algorithms (SHA-2 family among other newer) offer a good solution for the long term. Ultimately the key benefit they offer is a longer hash value. They may be vulnerable to the same kinds of attacks that may eventually make SHA-1 obsolete. People often think that a longer output yields in a stronger hash, but that is not always the case here. We have to keep in mind that cryptanalysts have not yet been dealing with these potential successors nearly as much as with SHA-1 and when that starts to change, new weaknesses may be discovered.
No hash is secure. That is the fact. The word "safe" can be used, but the word "secure" can not be used.
Mordred wrote:
md5(m).sha(m) is also valid - the concatenated hash is as strong as the strongest of the two hashes, which means that if finding collisions in one of the hashes becomes trivial, the attaker still has to fnd collisions on the other hash. It is fun to note that the strength of the concatenated hash is not stronger than the strongest of the two hashes, but just as strong.
hash(hash(m)) is also valid - it prevents length-extension attacks, although HMAC should be better (at least the experts say so)
I already explained why concatenating like that is not good,
in terms of password hashing:
do not ever try to join other hashes. Use only one hash function and never touch the final output (the hash value). In the above situation, this is no better than the strongest hash in the set - at least not with the typical hash construction. Suppose M and M’ collide in SHA-1. Then, M . Q and M’ . Q will collide since their hash states collide after M (M’ respectively). This way an attacker would only have to find a pair Ms and M’s and move forward to attack the second hash. It's feasible that two properly constructed hashes offer more security as a pair however with the common MD style hash this is not believed to be the case.
There are many ways to do mathematical attacks or cut down the time needed to run the compressor, etc and someone reading this topic may now think that creating his "own hash function" is a good idea. Hash functions have been
designed to prevent many kind of mathematical, cryptographical, etc attacks. Leave hash function creation to the experts - do not make your own implementations (this is a suggestion to everyone who has no or little expertise in this area). Many people will read this topic, so I want to make it clear that hash value manipulation is not a clever idea in general when it comes to password hashing.
Playing around with hashes is the same as playing around with fire and 99% of people will put their home in fire.
Mordred wrote:Apollo wrote:Mordred wrote:
Offline attacks do not aim for generating collisions as well. Collisions matter when you use hashes for MAC/signatures.
Hashes are commonly used for password verification. By creating a collision, you can get a password that (regardless of whether the password is really correct) gives you unauthorized access. What's that got to do with (H)MAC/signatures?
Finding collisions in hashed salted passwords gives you nothing, unless the "collision" you find is in fact the preimage (i.e. the original password + salt). Good luck with that

With passwords, I think that "bruteforce resistance" is more important than collision-resistance. This is where password strengthening (as
Hannes pointed out) and proper salting come in play.
Many applications have weak salting, finding collisions is not that hard in case they are not using SHA-256, for instance. But in general, yes, finding collisions is very hard. The note about "brute force resistance" vs "collision resistance" is good, because ultimately hashes are what are supposed to prevent collisions - not our scripts.
Mordred wrote:
kaisellgren wrote:No there are no valid reasons to double hash your passwords (or to concat, wtvr). Zero. If you need more "secure" hashes, use a more secure hash.
Here's one such instance of context mismatch. I am talking in general, not about hashes. Arguments - above.
I noticed. I have been thinking about the topic starter's post.
Mordred wrote:
kaisellgren wrote:Funny thing is, that your arguments are in contraposition. You want everybody to double hash passwords, because otherwise they are easier to break - but still you claim that no one can break hashes, because they would require much firepower. So, in which side are you?
Putting words in the mouth of the other person isn't a conversation, it's a monologue

I never said either - just said doublehashing is valid technique sometimes, and that finding collisions requires much firepower. I still insist both statements are true, and am open for discussion on them (but not on extrapolated versions of them).
Yea, the same thing again, I was referring to password hashing. I think my word choice of "valid" was a bit vague. It is hard to define what is "valid". I claim that double hashing passwords is not the best approach to take, but it is not a "bad" approach either.
Mordred wrote:
Yea maybe not. Maybe he wants to say that double hashing is a good approach in certain situations, but in password hashing it is not so great approach really.
Ah, I see that in the last posts it became clear that this is another case of context mismatch. Yes, I was talking about generic hashing, but you still misunderestimate key strengthening.
The key, which I use to refer to the content you pass into the hash function, or the preimage, used among cryptologists, has to be strong. Double hashing is not the only way to strengthen a key, and that is why I do not recommend it. For instance, let us assume we have random binary data of 64 bytes where each byte has full 8-bits of entropy and that we are concatenating your password "hello" into the end of it - isn't the key quite strong, don't you think? Is there really a need to start double hashing it? Also in terms of performance, using W cipher numerous times is expensive. Whirlpool is a great alternative to SHA family. (Like I earlier stated that SHA-2 family may not be that good choice).
There is no right answer, just good or quite good approaches which depend on the context like you said.
There is, however, one thing that almost no one ever thinks about. The ultimate solution to perfect hashing is to build a system that accepts dynamical hash switching. I can use, for instance, HAVAL-256 with some passes to hash my passwords safely, because when it becomes clear that HAVAL is not that safe anymore, I just switch my hash algorithm. That's it. I do know that it (the approach of switching hash algorithms) might be very hard to achieve in practise.
Mordred wrote:
Apollo wrote:I have no idea, and I think neither do you - one reason being that h(s1) and h(s2) have fixed length and probably only contain 0-9a-f.
I'm with you on the first part - I have no idea really, just read other people's ideas about it.
For the second part - you're wrong. You're thinking about the textual representation of the hash value, which, while containing less possible characters, has double length than the binary representation. Since the output of the hash is usually the same size as the input block, it may be constructed in such a way that there are no collisions. Whether this is the case with MD5 and SHA*, I simply don't know. That's why I said the loss of entropy is probably only a fraction of a bit.
You are right. Two weeks ago I was in a university of Tampere with a cryptologist talking about these kind of stuff. We tried to measure the amount of entropy lost in these kind of cases - and I can tell you that is nearly impossible to measure because there are so many factors in the game, and after all, the amount of entropy loss is
very insignificant. If and when I double hash, I do not care about losing entropy, I care about losing performance, because it is what you are about to lose more of the two.
Still, though, we are discussing security - and any additional strength or entropy is welcome.
And Mordred, apologizing for long posts is irrelevant, because you are allowed to post up to X bytes. If you post a longer post, then you get an irritating message saying that you have to shorten your message
