December 2nd, 2016, 01:51 PM

Analysis of a simple username/password hash function
I've been thinking about using safeprimes to generate hashes of username/password pairs for website administration and came up with a very simple technique. Basically, the algorithm calculates the sum of two large integers (currently using ~10,000 digit numbers, but this would be scaled down once I've obtained a list of some smaller primes) each of which are (roughly) the product of two distinct prime numbers multiplied by a seed value (derived from the username and password), squared and then taken modulo a third (unique) prime. So six primes in total are being used.
My sense is that the result should be guaranteed to be irreversible due to the simple fact that it is impossible (barring bruteforce methods) to deduce the two addends of any given sum (particularly so with extremely large integers). Not to mention that the use of distinct moduli maps each subresult to a unique multiplicative group. The output also seems extremely welldistributed and bitpropagation excellent (changing a single bit of the input produces vastly different results). Finally, because the algorithm employs largeinteger math it makes it presumably unfeasible for an attacker to quickly and efficiently generate keys (since every hash utilizes both the username and password, pregeneration of keys is out of the question).
But of course, I could be overlooking something. Does the algorithm appear secure, or are their some obvious flaws in the system? I've developed a proofofconcept of the algorithm, implemented in Javascript as a plain webpage and posted to pastebin. This one requires an external biginteger library (runs slower) while that one is a standalone implementation that is both faster and runs on an offline machine as well.
Any comments would be sincerely appreciated!
December 2nd, 2016, 07:31 PM

Squaring does not add entropy, so you're only working with three primes, one "seed" generated from a known value (username), and one "seed" generated from an unknown value (password).
Doesn't this all require storing those the three primes, though? And what are you using to generate the seeds?
But here's some advice. In my opinion you'd be much better off securing your application against attacks than you are trying to invent a new algorithm, because unless your application is so important that you have nationstates interested in your data then your primary concern should be script kiddies and social engineers  and they don't give a damn about what encryption algorithm you're using.
December 2nd, 2016, 08:52 PM

Originally Posted by requinix
Squaring does not add entropy, so you're only working with three primes, one "seed" generated from a known value (username), and one "seed" generated from an unknown value (password).
Doesn't this all require storing those the three primes, though? And what are you using to generate the seeds?
But here's some advice. In my opinion you'd be much better off securing your application against attacks than you are trying to invent a new algorithm, because unless your application is so important that you have nationstates interested in your data then your primary concern should be script kiddies and social engineers  and they don't give a damn about what encryption algorithm you're using.
In this case though, squaring does indeed inject entropy into the system. The process is laid out in detail here (the method in question here is in fact based on the BlumBlumShub algorithm, actually).
The primes are not secret, just very large, although they really don't need to be nearly as big as the ones I've used here. I just don't have a comprehensive list of a broad range of SofieGermains, so for now I'm stuck with overkill. And moreover, the chosen primes aren't just public, they're reused over and over again.
So why "invent a new algorithm"? Well, perhaps because the ones in use to day are so convoluted and flawed and I just wanted to come up with something that works by using easily provable mathematical principles, is easily scalable, and of course flexible in usage.