5

This question already has an answer here:

I read this interesting question on why improvising your own Hash function out of existing hash functions is bad. However this is specifically focusing on 'mixing' existing hashfunctions. What if for instance, I modify the per-round shifts of the MD5 hashfunction? Example:

Shifts rounds as of now

s[ 0..15] := { 7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22 }
s[16..31] := { 5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20 }
s[32..47] := { 4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23 }
s[48..63] := { 6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21 }

My own slightly adjusted shift rounds

s[ 0..15] := { 5, 14, 19, 22,  5, 14, 19, 22,  5, 14, 19, 22,  5, 14, 19, 22 }
s[16..31] := { 6, 12, 14, 21,  6, 12, 14, 21,  6, 12, 14, 21,  6, 12, 14, 21 }
s[32..47] := { 4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23 }
s[48..63] := { 7,  9, 11, 17,  7,  9, 11, 17,  7,  9, 11, 17,  7,  9, 11, 17 }

These changes change the outcome of my 'own' hashfunction drastically. This is just one small example to change. My reasoning behind this is that it temporarily prevents Rainbow attacks. If I have some sloppy users with passwords like thisisnopassword, pandabear & 12346 they would be sligtly safer after my database would be hacked as no Rainbow tables exist for 'my' hash.

By the way, I chose the per-round shift amounts is because I couldn't find a clear rationale on why they were specifically chosen, see this question.

marked as duplicate by Philipp, Steve, Neil Smithline, Deer Hunter, D.W. Oct 12 '15 at 21:28

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 2
    Why would you do this? There are easier ways to avoid rainbow table attacks. – fNek Oct 12 '15 at 17:33
  • 3
    What's easier, re-implementing MD5 with some slight tweaks (and having no inter-operability with standard libraries), or calling a function with an extra parameter (salt)? I also see no reason this is any more secure than using a random salt. – puzzlepalace Oct 12 '15 at 17:42
  • 2
    @ThomasW One thing to keep in mind is that the chosen per round shifts, constants, etc are chosen to help maximize unique outputs. By changing them you could create a situation where collisions are more likely, and therefore a more cryptographically insecure hashing function. – RoraΖ Oct 12 '15 at 18:01
  • 1
    @ThomasW Reading the answer to that question, you ARE exposing holes because you are making the algorithm weaker by using less ideal values. – Philipp Oct 12 '15 at 18:02
  • 2
15

Changing shift rounds blindly has undefined effect on strength. E.g., you could have similar amount of collisions, you could have orders of magnitude more amounts of collisions, shift rounds defined initially have known probability of collisions, shift rounds changed randomly do not.

Listen to folks above, use salting, it's specifically used to serve your purpose. Altering the engine of the car you're driving is a funny sport with fatal outcomes.

  • 4
    "Instead of reworking the engine of the car, try using the steering wheel to get where you want." – Paul Draper Oct 12 '15 at 21:07
4

If you have the knowledge to be able to adequately test the effects of your changes on the security, or otherwise, of the result then of course you should go ahead!

The problem is that the old saying 'don't roll your own' with crypto is well founded because it seems easy to think of how you might do it yourself, but unless we are well informed, testing crypto strength is as complex, if not more so, than coming up with new algorithms.

Make your changes, publish them along with the explanation and, where possible, demonstration of improved security, have your work peer reviewed by Crypto experts, and you're done. If you can't do any or all of these steps then leave it to people who spend their lives dedicated to getting it right.

Mind you - you could say that about a lot of things in life :)

  • There's a lot to like in this answer, but this answer seems potentially a bit misleading in some respects. No one knows how to mathematically prove that MD5 is secure, or to mathematically prove that a small tweak to MD5 (such as suggested in the question) preserves its security properties. No one -- not even crypto experts. We'd love to be able to do that, but it's beyond the state of the art. Mentioning that might make the answer stronger. – D.W. Oct 12 '15 at 21:30
  • I agree - the use of the word 'proof' is misleading and I've changed to 'demonstrate' or 'explain'. It doesn't seem strong enough wording but I can't think of an alternative. – David Scholefield Oct 13 '15 at 6:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.