Hello guys. In my free time i created a new (i hope)
PBKDF called
NonHashpass (
/NonHashpass][Suspicious link removed]/NonHashpass), which based on PRNG and 14 hash-functions.
To complicate brute-forcing password can be passed through N iterations of one (or various) hash-functions, so attacker would need generate N hashes for one "crack-attempt" or fully brute-force hashfunc (which is truly nonsense even for md5). But this way algorithm come to problems with ASIC devices because of static chain of hash-functions.
With algorithm i propose, order of hashfuncs dynamically changes for any change of password.
So question is simple: is it ASIC-resistant? And if, can it be used in cryptocurrencies?
Note: main 14 hash-functions is:
sha3_256, blake2b, sha3_512, shake_256,
sha1, shake_128, sha384, sha512, sha224,
blake2s, sha3_224, sha256, md5, sha3_384
NonHashpass is
very simple:
It takes
3 arguments:
passphrase (a.k.a
master key / can be BIP39),
unique_word (for creating different keys) and
iterations count.
In
1st step: function concatenates arguments you passed and creates sha512 (
the initkey) from this data:
nonhashpass("phrase", "unique", 1000) -> sha512("phraseunique1000") -> 76f2f60da0cb2867ccb46e44bf3dd228a... <- initkeyIn
2nd step: function initializes PRNG with initkey, which shuffle order of hash_functions:
prng = PRNG(76f2f60da0cb2867ccb46e44bf3dd228a...)
prng.shuffle(hash_functions)
In
3rd: initkey goes through the cycled shuffled hash_funcs
iteration times:
for _ in range(1000: iterations):
hashfunc = next(hash_functions)
initkey = hashfunc(initkey)
In the
end, initkey hashes with shake_256, which can produce
endless amount of bytes (as much as needed for key):
return shake_256(initkey)
As i see for now, the worst case in this algorithm will be exit-hash of 20bytes length or totally
2^160 variations of shake_256 (with unknown length), but there is
85% probability of another exit-hash, with much more byte length.
For PoW we can reduce amount to "only-32bytes-exit-hash-:)".
Any thoughts? Thanks.
