User:Bluefoxicy/Salting

Here is an experimental Salting algorithm I've worked out. This is just a sort of theory; it's not a full algorithm that can be implemented, unless you bring the hash and other mathematical equations with you.

Hashing

Hashing is in most basic terms crunching a bunch of numbers together until they're a certain size. The output is directly related to the input; but there are an infinite number of inputs for every one output.

Salting

Salting is a process of adding random data to a hash. Many hashes have weaknesses, and can be reversed to any set of inputs which produce the hash. Also, any hash can be attacked via a lookup table; any entry in the lookup table corrosponding to the hash value can be used to generate the hash.

New salting technique

I have thought out a new salting technique which involves using a second hash to determine offsets of salts in the hash. Using this technique, the hash should theoretically be protected from reversal; and it should be protected from brute force techniques for substantially longer. The obvious trade-off is that hashing takes longer.

The basic theory behind this technique is that an attacker to successfully reverse a hash must intuit certain data from the hash. This data is normally simply a possible input; in our case, it is also the offsets of the salts, which in turn are intuited from a second hash. Because the salts' positions come from the second hash, the only data important for the attacker to recover is that hash.

The two hashes used must not map to one another consistently; varied lengths of inputs should produce various mappings between the outputs. In this way, to successfully correlate a guess at where the salts are-- and thus, what the original hash is-- to a guess at the secondary hash, an attacker needs to know the length of the hashed data and probably the data itself. Accomplishing this should be fairly easy.

Step 1. A hash is generated from an input iPut. This is called iHash. This can be any standard hash (md5, sha1, whatever).

Step 2. A second hash must be generated from iPut. This is called sHash, for "Salting Hash." This hash can also be any hash.

Step 3. sHash is run through an algorithm which selects offsets for N salts to be inserted. These offsets are not sorted.

Step 4. At the positions specified, iHash is shifted over to allow salts to be inserted. Each salt is inserted one at a time in the order they were generated, and so the effect is compound; for example, with hhhh and 3 salts at positions 0(1) 0(2) and 4(3), the result is 21hh3hh.

Step 5. Random values are filled in at the salts.

Step 6. iPut and sHash are both destroyed.

As long as the algorithms for sHash and iHash do not have overlapping collisions--that is, values at which data other than iPut produces the same value for iHash and sHash both as iPut--the attacker theoretically must fully brute force the password. Also, because sHash is destroyed, it does not need to be a secure hash; iHash, however, should be difficult or impossible to reverse.