Crypto algorithm varying based on password itself? - hash

Question

I've tried searching and found nothing (don't know what these would be called if they were things already, so searching is kind of hard), so forgive me if this is dumb or already answered somewhere. For the sake of argument lets says I'm using bcrypt or something of that reputation/quality when I say I'm hashing something.
First, is there are reason that your hashing algorithm cannot vary with the password or it's intermediate hashes?
public static byte[] myHash(byte[] input, byte[] saltA, byte[] saltB) {
return input[0] % 2 == 0
? bcrypt(bcrypt(input, saltA), saltB)
: bcrypt(bcrypt(input, saltB), saltA);
}
I feel like this doesn't use much CPU - it's just two iterations of bcrypt, and I've suggestions for 10+ iterations in other security discussions - but let's say bcrypt has discovered to be fully reversible if you knew the salt and the hash, one unhashing would now necessitate unhashing it twice - once with saltA, then with saltB and once vice versa, giving you two candidate passwords, one of which is a decoy with a 50% false positive rate (that is, it rehashes to the correct hash because it's first bit is correctly even or odd), requiring heuristics or human eyes to correctly identify the real one, so you've at least doubled the computing resources needed and possibly required human intervention. But we can do better:
public static byte[] myBetterHash(byte[] input, byte[] saltA, byte[] saltB) {
byte[] curr = input;
for (int i = 0; i < 5; i++) {
switch(input[i] % 3) {
case 0: curr = bcrypt(bcrypt(bcrypt(curr, input), saltA), saltB); break;
case 1: curr = bcrypt(bcrypt(bcrypt(curr, saltB), input), saltA); break;
case 2: curr = bcrypt(bcrypt(bcrypt(curr, saltA), saltB), input); break;
}
}
return input;
}
Now there are 3 unhashes per iteration over the 5 iterations, yielding 243 candidate passwords, and probably dozens of false positives to eliminate, but even if not, then had to do 243 times the unhashing work they would have if you had just done it. Also, the inclusion of the input again as a salt in subsequent hashes makes it impossible to actually do the unhashing, plus it requires the attacker to hold onto a little extra memory. That said, my last idea is as follows:
public static byte[] myBestHash(byte[] input, byte[] saltA, byte[] saltB) {
byte[] curr = input;
byte[][] arr = new byte[16][]
for (int i = 0; i < 16; i++) {
arr[i] = curr;
switch(curr[0] % 4) {
case 0: curr = bcrypt(curr, saltA); break;
case 1: curr = bcrypt(curr, saltB); break;
case 2: curr = bcrypt(curr, arr[input[i] % i]); break;
case 3: curr = bcrypt(bcrypt(curr, saltA), saltB); break;
}
}
return input;
}
Now the attacker has to deal with an immense number of potential unhashings (3^16 = over 4 million), each of which has to be verified with the above memory intensive (it holds onto 16 intermediate hashes and there's no way to optimize that out).
Second, I feel like the memory intensiveness of that final example paired with the branching salts and maybe even the fact that one of the branches calls bcrypt twice instead of once might, in some combination, make things harder to brute force with graphics cards by making the tack at hand ill-suited to them or making the process waste more I/O than normal. If nothing else, extending this approach beyond 16 iterations will continue to bloat the RAM usage, making it harder to parallelize. Imagine if 256 iterations were used and space for 1024 intermediate hashes had to be held onto for every hash that got leaked in an attack - if the intermediate hashes themselves are, say 1024 bits (= 128 bytes), that's 32kB of wasted memory for every iteration of the brute force attack, which isn't much, but it will definitely add up to at least slightly slower iterations for a brute force attacker and fewer iterations in parallel (due to the extra memory - though 32kB isn't much against a modern password cracking rig, that's 32GB written to memory for a million guesses, and if nothing else that should slow things down a little extra).
So, am I onto something, or is this completely stupid?

Answer 1

This more properly belongs on crypto, but here's my $0.02:
Your calculations are slightly off and depend on some assumptions you make but which don't necessarily hold.
Now the idea of extra iterations isn't new - PBKDF2 uses iterations in a very similar way and bcrypt uses iterations internally already.
The "multi salt" idea gains you little in reality, since the salt is usually stored alongside the plaintext password in plaintext anyways.
This is one of those things where you think "well, if 1 function call and 1 salt are good, then 50 iterations and 2 salts are better. This couldn't possibly hurt!" But this isn't how cryptography works and this sort of thing could hurt although it doesn't in this case; it just wastes resources.
Please don't do this sort of thing blindly. If you want to increase resistance to brute force dictionary attacks against hashes, adjust the bcrypt difficulty factor. Similarly, choose a long and unique salt and let bcrypt do it's thing.

Answer 2

A) The adversary is obviously prepared to compute bcrypt() as most often used, for very low cost. B) Maybe also prepared to run N simple iterations, with some cheat, cheaper than we would expect. C) Very likely not able to reverse the hash function.
In any case the "outer" procedure using bcrypt() should be extremely stupidly written to lower the strength. Branching makes it harder for the adversary to use it's standard crack-rigs: certainly for A) and B), and maybe also for C) - but in case of C) there are big problems anyway.
Combine different types of cryptographic hashing functions, apply branching and unless something trivial mistake is applied it won't be weaker; but most likely harder for the adversary to apply the standard crack-rigs. If the base hash you're building on is fundamentally flawed (many assumes if it was the case they would know it: but that's just naive) the branching might not solve it. But likely make it harder to crack than easier. Wasting resources is good in this case: branching and different procedure than the "stupidly just apply it multiple times" will waste more adversary resources than honest resources: so good.