After lurking on the discussions@password-hashing.net, the Password Hashing Competition's mailing list the last several months, I can say I am initially skeptical of this.
One of the primary concerns for PHC was making an algorithm which is hard to speed up on custom hardware. Bill Cox, Solar Designer, et al. went at this very hard, and I think their approach will turn out to be favored.
I'm a little bit concerned that if the algorithm is now flexible enough, to not be implemented efficiently in a more generalized circuit, then is it flexible enough to behave possibly erratically?
But I'm not even sure if this GSHA type algorithm really would be all that difficult to implement in an ASIC.
Of course, the great thing is that an algorithm promising such benefits is in high demand, Proof-of-Work algorithms, and so anything which shows merit will probably be explored and tested.
Agreed, I'm not sure it's a good idea to change the # of shifts or any other constants. They are/should be optimized so Differential and Linear properties are minimal over the whole cipher, which is certainly a non-trivial optimization.
I can't see how this help with the brute force attack: you start with a password and compute hash. The suggested scheme doesn't make it more difficult (i.e. cpu expensive) to compute the resulting hash from a given password than simply repeating the same MD5 or SHAXXX the given number of times. Moreover, the parameters for the hash functions (e.g. bit shift) are not random. They have been chosen on purpose. Using the input (password) to set these parameters will most likely result in some very weak hashes for specific passwords (including hash collisions).
The idea (I think) is that it's more difficult to build dedicated hardware for the brute force attack that's cheaper than doing it with a general-purpose CPU.
But, it only makes it unbreakable for 50% of passwords? Would it not be better to have an alternating scheme, i.e. MD5 -> SHA1 -> MD5 -> SHA1 repeated 100,000 times, rather than choosing a scheme deterministically at the start.
A curious case of rolling your own crypto and security through obscurity. Well, interesting thoughts but I'd be extremely hesitant to put any of this to use (as the author says in the last line).
* It's not the case of rolling your own crypto, as this phrase usually applies to the case of implementing your own crypto algorithms/protocols in an application. The author proposes a new crypto algorithm.
* It's not the case of security through obscurity, as there is no secrecy of the algorithm design.
(As a side note, I don't see how this algorithm prevents cheap hardware implementations of it.)
It's security through improbability. According to the author, there's 2^512 possible variants of his algorithm, all depending on the parameters fed to it. This means that specialized hardware wouldn't be impossible, but that it'd be highly improbable that your adversaries' hardware matches the variant of the algorithm you used to create the hash.
Ha, but it doesn't work like this: his algorithm is described in 150 lines of C + SHA512 implementation. I'm pretty sure it can be implemented in hardware as well.
Why does he think you need to build millions of ASIC/FPGA/GPUshaders, one per parameter? Couldn't you just build one "über"-ASIC/FPGA/GPUshader? Is there something magical about "gsha.c" that makes it impossible to implement in hardware?
Isn't the cost of an ASIC containing an MD5+SHA1 algorithm about the same as the cost of an ASIC containing only one of them?
17 comments
[ 5.1 ms ] story [ 52.8 ms ] threadOne of the primary concerns for PHC was making an algorithm which is hard to speed up on custom hardware. Bill Cox, Solar Designer, et al. went at this very hard, and I think their approach will turn out to be favored.
I'm a little bit concerned that if the algorithm is now flexible enough, to not be implemented efficiently in a more generalized circuit, then is it flexible enough to behave possibly erratically?
But I'm not even sure if this GSHA type algorithm really would be all that difficult to implement in an ASIC.
Of course, the great thing is that an algorithm promising such benefits is in high demand, Proof-of-Work algorithms, and so anything which shows merit will probably be explored and tested.
It's also assuming that the constants don't matter for the security of the hash function. They do.
* It's not the case of security through obscurity, as there is no secrecy of the algorithm design.
(As a side note, I don't see how this algorithm prevents cheap hardware implementations of it.)
Pretty sure collisions are a practical concern for password hashing... More collisions = more "valid" passwords for a given account.
Isn't the cost of an ASIC containing an MD5+SHA1 algorithm about the same as the cost of an ASIC containing only one of them?