I know about PBKDF2, bcrypt, scrypt, etc. and while I'm not a crypt professional, I think I understand why are they better than just "hash(pass+salt)".

But a colleague of mine surprised me with the following password hash function which he claims to be good, because

It is slow on CPU (takes about 2-3 seconds in i5)

It will be slower on GPU because needs random access to a lot of memory (why? GPUs have lots of gigabytes)

It cannot be timed, any time-based attack will fail even if underlying hash-function will be vulnerable (aren't hash calculation time a constant, for SHA512 at least?).

It cannot be cracked by audio attack because of fake operations (what's that?)

So while I do not like bicycles in cryptography in general, arguments sound reasonable and I just want to know the truth fro myself, in the first place and to argue for rewriting of this code to something standard.

EDIT

So here are some specific questions, as suggested in comment by @B-Con:

Why this (needing a lot of memory) hash will be slow of GPU?

Isn't SHA512 and RIPEMD160 calculation time a constant?

Does a fake data processing in parallel of real data really help against audio attack whatever it is?

$\begingroup$Hi there. Crypto.SE discourages custom algorithm analysis, which is really the essence of this question. You may receive better information by sifting your question down to a set of specific questions about achieving certain cryptographic properties. As it stands, the question is possibly in danger of being removed.$\endgroup$
– B-ConFeb 25 '14 at 6:15

1

$\begingroup$All the properties you enumerate are supposed to be achieved by scrypt. Scrypt has a paper behind it and it is used by many people out there. Even if that's true many people would consider you an early user if you use scrypt (because it's been there for not so many years). So, do you think your colleague's algorithm is worth the risk? Has he exposed it? Is anyone else using it?$\endgroup$
– izaeraFeb 25 '14 at 7:45

$\begingroup$The technique for avoiding timing attacks doesn't work. So if the salt is known, it's just as vulnerable to side channel attacks as scrypt with known salt. At a glance this looks like a badly done variant of scrypt.$\endgroup$
– CodesInChaosFeb 25 '14 at 9:57

1 Answer
1

The threat model of password storage is that of server compromision, where the attacker gain access to the database and server code. The attacker can then run the code to test password candidates, possibly making modifications, porting to faster platform, etc.

The attacker will not bother computing the fake hash and fake salt. So this scheme is twice as slow for the real server than for the attacker.

That part is quite interesting and breaks a lot of things that the designers of one-way hash functions painstainkingly crafted into their babies.

The realData array is initialized with zeroes and if data length is less than hashLength, not all of it will be filled with actual data at the end of the loop.
Any pair of inputs that differ only in the number of trailing zeroes will hash to the same thing. (Granted, it might not be possible to input \x00 as a valid password character, but still).

Then, I think there is a one-off error, it should simply be realData[index % hashLength]. As is, realData[hashlength - 1] will never be set.

In addition, there will be collisions with longer strings, it suffice to find pairs of bytes that XOR to the same thing.
For the simplest example, a string of 2 * hashLength of the same repeated character will hash to the same thing as any other string of 2 * hashLength of another repeated character. When the index loops over, the character will be XORed with itself, yielding 0.
There are many other way to find collisions even before looking at the internal loops.