Originally Posted by
laserlight
Ah. From what I understand though, this idea of a "rounds" or "cost" or "work factor" parameter goes back to the key stretching idea applied to make using the old cryptographic hashes stronger when applied for password hashing. So while it works, why I mentioned argon2 and scrypt is because they go beyond this to the idea of memory-hard algorithms, i.e., not only do we force attackers to have to say, buy an array of FPGAs to succeed against CPU-hardness due to the configurable number of rounds, but now they have to contend with the configurable memory requirements, and of course pay for all that electricity. Does Finabel have this property too, or can it be adapted for that?
Thanks for the input, laserlight. I've created a set of "sandbox files" containing a memory-hard version of Finabel.
Example usage:
node sandbox-cli foo bar 5 64 50000
Usage: ~/test/finabel/sandbox-cli [PASSWORD] [SALT] [ROUNDS] [DIGITS] [EXPENSE]
104b8df5a7ec6e35a907d4d49dbf293fc38b4052cfcd9f87ac a1db8cfd4235f0
It was a simple modification actually, just increase the number of concatenations until a certain number of digits is reached (the so-called "expense" parameter). Although I am a little unsure exactly what the default setting should be. The larger the value, the less rounds would be practical, so those too would have to be adjusted accordingly. Any suggestions?
I've also changed the interface somewhat in order to make invocation of the function a little less error prone. So instead of something like
Code:
finabel("foo", "bar", 5, 64, 50000)
it'd be
Code:
finabel({ password: "foo", salt: "bar", rounds: 5, digits: 64, expense: 50000 })
.
Permalink to the repo: here.