Topic: Double hashing: less entropy? - page 2. (Read 4038 times)
The way I understand it is that adding more rounds makes it harder to find a short cut/weakness.
The fixed length for the second sha256 stage also removes one type of "attack" often used against such algorithms.
Sure, I get that double hashing was intended to slow down mining, as well as vexing brute force. But perhaps sha256(sha256(input)+input) would have been better.
for example if it does something like X=A+B (with + being a binary addition modulo 2³²) it "drops bits" in the sense that either a 1-bit in A or in B would result in a 1-bit in X.
Similarly for X=(A<>m) etc, albeit for different bits.
)
(not familiar with scrypt, perhaps you mean something similar, I think bcrypt would have been a very good, flexible, future-proof choice for Bitcoin)
First, do we actually *know* that sha-256 is *not* a one to one mapping on the 256 bit space ?
If it turns out to be, then you've got nothing. I don't know the answer, I'm not a professional cryptographer,
but looking at the code for SHA-256, there doesn't seem to be an obvious dropping of bits within
the transform step itself, but then I am too lazy to analyze it in-depth.
Can't tell for sure, but obviously sha256 is designed to be irreversible (besides the mathematical fact that for inputs larger than 256 bit it's bound to lose information).If it turns out to be, then you've got nothing. I don't know the answer, I'm not a professional cryptographer,
but looking at the code for SHA-256, there doesn't seem to be an obvious dropping of bits within
the transform step itself, but then I am too lazy to analyze it in-depth.
for example if it does something like X=A+B (with + being a binary addition modulo 2³²) it "drops bits" in the sense that either a 1-bit in A or in B would result in a 1-bit in X.
Similarly for X=(A<
Quote
Second, if SHA-256 does indeed somehow drop information for a 256-bit input, IMO, if there's a reduction
in entropy, it's likely to be negligible when compared to the additional work needed to untangle the complexity
added by the second round.
Could be, or not, I really don't see why or why not that would be negligible. I hope someone with in-depth knowledge about hashing can confirm or deny this? (hopefully confirm in entropy, it's likely to be negligible when compared to the additional work needed to untangle the complexity
added by the second round.
)Quote
Finally, what someone said: the likely intent of the team who designed bitcoin was to slow mining down, not to
add a layer of security there. Arguably, they failed because they didn't foresee the length at which people would
go to mine coins (first GPUs, then FPGAs, then dedicated ASICs).
Had they realized, they would have added an scrypt-like round to the hash step.
You mean bcrypt? add a layer of security there. Arguably, they failed because they didn't foresee the length at which people would
go to mine coins (first GPUs, then FPGAs, then dedicated ASICs).
Had they realized, they would have added an scrypt-like round to the hash step.
(not familiar with scrypt, perhaps you mean something similar, I think bcrypt would have been a very good, flexible, future-proof choice for Bitcoin)
If I understood correctly, in most situations where hashing occurs, the Bitcoin protocol applies double hashing: sha256(sha256(input)) rather than sha26(input).
Why is this, doesn't this actually reduce entropy?
As far as I know, we cannot guarantee that there aren't many different inputs x and y which have different hashes, but the same double hashes. That is, sha256 is not a one-to-one mapping on the 256 bit space, right?
Why is this, doesn't this actually reduce entropy?
As far as I know, we cannot guarantee that there aren't many different inputs x and y which have different hashes, but the same double hashes. That is, sha256 is not a one-to-one mapping on the 256 bit space, right?
First, do we actually *know* that sha-256 is *not* a one to one mapping on the 256 bit space ?
If it turns out to be, then you've got nothing. I don't know the answer, I'm not a professional cryptographer,
but looking at the code for SHA-256, there doesn't seem to be an obvious dropping of bits within
the transform step itself, but then I am too lazy to analyze it in-depth.
Would love for someone more knowledgeable than I to comment.
Second, if SHA-256 does indeed somehow drop information for a 256-bit input, IMO, if there's a reduction
in entropy, it's likely to be negligible when compared to the additional work needed to untangle the complexity
added by the second round.
Finally, what someone said: the likely intent of the team who designed bitcoin was to slow mining down, not to
add a layer of security there. Arguably, they failed because they didn't foresee the length at which people would
go to mine coins (first GPUs, then FPGAs, then dedicated ASICs).
Had they realized, they would have added an scrypt-like round to the hash step.
that is correct, but the design decision about double sha256, is i think to slow mining down. and using double-sha256 all-around is just for consistency.
it won't be a problem, as long as you don't search the whole 256 bit space for a collision(which you don't want to do).
DISCLAIMER: im not a cryptographer.
it won't be a problem, as long as you don't search the whole 256 bit space for a collision(which you don't want to do).
DISCLAIMER: im not a cryptographer.
If I understood correctly, in most situations where hashing occurs, the Bitcoin protocol applies double hashing: sha256(sha256(input)) rather than sha26(input).
Why is this, doesn't this actually reduce entropy?
As far as I know, we cannot guarantee that there aren't many different inputs x and y which have different hashes, but the same double hashes. That is, sha256 is not a one-to-one mapping on the 256 bit space, right?
Why is this, doesn't this actually reduce entropy?
As far as I know, we cannot guarantee that there aren't many different inputs x and y which have different hashes, but the same double hashes. That is, sha256 is not a one-to-one mapping on the 256 bit space, right?
Jump to: