Hello, please care to share why without an iteration dependent salt it is less secure? I guess what you mean is:
x = SHA1(password|salt)
for i from 0 to N do {
x = SHA1(x|i)
}
But in our specific context how this helps?
In other words, how the attacker is able to compute N-times-nested-SHA1 faster than performing all the iterations?
You protect yourself against any future weakness in the hash where it would be possible to simplify composed calls.
You say
So it is quite natural that the schema I proposed of computing SHA1(SHA1(SHA1(..))) will just do that, adding rounds to SHA1. So for the fundamental properties of SHA1 it should be computationally unfeasible to write a function SHA1000 that is equivalent to 1000 times SHA1 nested but that can be computed easily.
This is logic, but puts too much faith in SHA-1.
Crypto is hard because you assemble black boxes which never fully satisfy the advertized properties.
Nevertheless I think the best is to make it easy to change the algorithm as you will always find someone to tell you it's not secure enough.
I tend to be of the opinion that strength of hashes s overrated, other security measures should jump in and this whole discussion should be cooled down.
That said, but nesting sha1 calls you are reducing the size of the output set at each step. You will end up with a reasonably smaller possible hashes. I don't know why everybody seems to ignore this.
Does password hashing qualifies as chryptography? I don't think so.
"That said, but nesting sha1 calls you are reducing the size of the output set at each step"
I don't think so otherwise finding collisions would be trivial. What you do when using nested SHA1 is just to run a cryptographically secure PRNG with a 160 bit internal state.
The in-depth security means you design your system so that it doesn't fall apart if only one of the pieces fall.
As for your comment on the PRNG, it's actually not a very good design. You would rather use a cipher in stream mode which is indeed fed from a hash, because the cipher will have a better and more predictable behaviour over time.
I however don't understand why people were repeating bcrypt as a mantra on your git pull.
Comments
Hello, please care to share why without an iteration dependent salt it is less secure? I guess what you mean is:
But in our specific context how this helps? In other words, how the attacker is able to compute N-times-nested-SHA1 faster than performing all the iterations?Note: this is not a pre-image attack. Thanks.
You protect yourself against any future weakness in the hash where it would be possible to simplify composed calls.
You say
So it is quite natural that the schema I proposed of computing SHA1(SHA1(SHA1(..))) will just do that, adding rounds to SHA1. So for the fundamental properties of SHA1 it should be computationally unfeasible to write a function SHA1000 that is equivalent to 1000 times SHA1 nested but that can be computed easily.
This is logic, but puts too much faith in SHA-1.
Crypto is hard because you assemble black boxes which never fully satisfy the advertized properties.
Nevertheless I think the best is to make it easy to change the algorithm as you will always find someone to tell you it's not secure enough.
I tend to be of the opinion that strength of hashes s overrated, other security measures should jump in and this whole discussion should be cooled down.
That said, but nesting sha1 calls you are reducing the size of the output set at each step. You will end up with a reasonably smaller possible hashes. I don't know why everybody seems to ignore this.
Does password hashing qualifies as chryptography? I don't think so.
"That said, but nesting sha1 calls you are reducing the size of the output set at each step"
I don't think so otherwise finding collisions would be trivial. What you do when using nested SHA1 is just to run a cryptographically secure PRNG with a 160 bit internal state.
The in-depth security means you design your system so that it doesn't fall apart if only one of the pieces fall.
As for your comment on the PRNG, it's actually not a very good design. You would rather use a cipher in stream mode which is indeed fed from a hash, because the cipher will have a better and more predictable behaviour over time.
I however don't understand why people were repeating bcrypt as a mantra on your git pull.