

Generalized Secure Hash Algorithm - zdw
http://www.tedunangst.com/flak/post/generalized-secure-hash-algorithm

======
zaroth
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.

~~~
SAI_Peregrinus
It certainly seems like he hasn't heard of a barrel shifter. That alone would
make this pretty damn easy to implement in an ASIC.

It's also assuming that the constants don't matter for the security of the
hash function. They do.

~~~
johnwhitech
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.

------
lsh123
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).

~~~
taejo
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.

~~~
beejiu
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.

------
0x0
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?

------
ancarda

        from crypto to bcrypt to scrypt
    

Hang on. I thought the consensus was to use bcrypt. Is scrypt better now?

~~~
tshadwell
The scrypt paper includes comparisons to bcrypt:
[https://www.tarsnap.com/scrypt/scrypt.pdf](https://www.tarsnap.com/scrypt/scrypt.pdf)
decide for yourself.

------
kngspook
> GSHA will almost certainly give up collisions than SHA, but collisions are
> not a practical concern for password hashing or KDF operations.

Pretty sure collisions are a practical concern for password hashing... More
collisions = more "valid" passwords for a given account.

~~~
tomp
But if the cost of finding any of the "valid" passwords increases faster than
the number of "valid" passwords (collisions), it's still worth it.

------
lucb1e
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).

~~~
dchest
* 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.)

~~~
jhgg
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.

~~~
dchest
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.

