3

Is it a good idea to do some kind of non destructive post processing (reordering) on hash strings before storing then? Ex:

$hash = strrev(hash($algo, $data . $salt));

Other example:

$hash = hash($algo, $data . $salt)
$hash = strrev(substr($hash, 0, (int) ($length / 2))) . strrev(substr($hash, (int) ($length / 2)));

Instead of simply:

$hash = hash($algo, $data . $salt);

In other words:

Considering the breaker will not know how the hashes were transformed, will first two examples result in less breakable hashes than third example?

I'm NOT saying I will strrev my hashes, this is just the most simple example I could think of to illustrate what "non destructive" means in this context: to post process the hash without reduce algorithm's key space.

Answers I'm NOT looking for:

  • Dude, use a salt to avoid raimbow table blah blah - Rainbow table is related though
  • Just rehash your hash like this hash(hash(hash($data))) - Question is not about rehashing
  • Please please please do not roll your own crypto - That's not what I'm talking about
  • DON'T RUN YOUR OWN CRYPTO. - This won't help either

Answer I'm actually looking for:

This is (is not) a good idea because of ...reasons... Here is some example about why you should (should not) do this: ...example... Also, read this ...paper, article, post, link to a research... that proves my point.

marcio
  • 10,002
  • 11
  • 54
  • 83
  • 3
    You should *always* assume the algorithm is known, because, you know, [Kerckhoffs’s principle](http://en.wikipedia.org/wiki/Kerckhoffs's_principle). – Gumbo May 30 '14 at 18:34
  • 1
    What is objective to do this instead of rehashing or using a crypt solution? Are you trying to improve performance, are you doing this for theoretical reasons, are you investigating a breach? What is behind this quesition? – kurast May 30 '14 at 18:48
  • Iterations, iterations, iterations... – leppie May 30 '14 at 18:49
  • @kurast consider I'm asking this for theoretical reasons – marcio May 30 '14 at 19:10
  • 1
    What do you mean by "non-destructive?" Do you mean "invertible?" – templatetypedef May 30 '14 at 19:15
  • @templatetypedef "non-destructive" means to process a hash in way the key space is not reduced, without loosing strength. Please correct me if you know a better term that could be used :) reverse the hash was just the most simple example I could think. – marcio May 30 '14 at 19:18
  • possible duplicate of [Is "double hashing" a password less secure than just hashing it once?](http://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once) – kurast May 30 '14 at 19:26
  • @kurast very different questions IMMO. I'm not not talking about rehashing (using the same algorithm a repeated number of times). Read the "Answers I'm NOT looking for" part. – marcio May 30 '14 at 19:28
  • Read the first answer to that question. – kurast May 30 '14 at 19:30
  • of course some parts will apply because the answer brings general concepts about hashing but certainly does not address the key point of this question. – marcio May 30 '14 at 19:37
  • 2
    If you can mathematically proove that your operations will not alter the probability of finding the message given the hash and that it won't increase the collision probability, it is may be not hurting. However, you are not gaining anything on the other hand as well (Kerkhoff's principle, see above). This mathematical proof for your operations on the other hand is mandatory and most times quite a complex, error-prone and time consuming operation. – Stephan May 30 '14 at 19:48

1 Answers1

1

Let's try analyzing the proposed algorithm as if the "non destructive post processing" were a secret function, taken from some space of possible functions.

In this view, the post processing is somewhat like a key, and the overall algorithm is a keyed hash (like HMAC). Here are some key points about this algorithm.

A keyed hash may be resistant to known-plaintext attacks: if an attacker knows the input values of many post processed hashes, it should still be hard to find the "key". However, if the post processing is simple, like strrev in your example, it could be very easy for an attacker to figure out the "key".

You'd have to design the space of these functions carefully.

edit: how 'bout just applying a block cipher to the hash result? At least that way, you can take advantage of the strength of a well scrutinized space of non destructive functions.

guest
  • 6,450
  • 30
  • 44