Proof isn't always possible

Yesterday I piloted the idea of using vector matrices to defeat salting. I noted that the salt need not be in a small range; this might still fall to investigations of multiple instances. Whatever variety of possibilities, the step from one to the next in a series will be constant. If we defeat salting, we might defeat the effective benefit of hashing altogether. I advance a possible solution from the memory of an embarrassing mistake. If my salt has become compromised, I can seek a remedy by introducing variations between steps. This is not what we expect from a deterministic hash, so what am I suggesting?  In the algorithm, the stepping is by one pass of the hash algorithm. Although it is inefficient, I can vary the stepping by taking two hexadecimal numerals from a fixed offset within my hash, converting them to an integer, and choosing to step by a number of hash passes equal to that integer. Because the hash is deterministic, the resulting list would always be the same, bu...

To envision a potential attack on OpenDRM, we modify a dictionary attack against the salt. We see dictionary attacks on passwords, and rainbow table projects against hashes. In OpenDRM, we salt the progress from md5 hash to md5 hash by iteration.  In the algorithm, we specify “object code looking stuff.” This category does not lend itself to any dictionary attack, and while you could possibly rule out large swaths of pronounceable instances, you would still be left with a lot of entries that iterate randomly.  Part two, securing the extant article against my new attack, is that the LENGTH of the salt is NOT specified, leaving no structure to construct a dictionary against it. Attack: Hitherto, Red Team has attacked salts by calculating creatively chosen instances, and seeking matches in rainbow tables. My idea is to contrive some idea of a generalized vector pointing from hash0 to hash1. The improvement of this strategy is that creatively modifying the vector might res...