3 ms·

I enjoyed the paper but Satoshi definitely is a cryptographer. Who else can decide to use the double-SHA for not letting to use Blockchain as a source for findi

I enjoyed the paper but Satoshi definitely is a cryptographer. Who else can decide to use the double-SHA for not letting to use Blockchain as a source for finding collisions in the SHA.

makeworld 3y ago
Pretty sure the accepted justification for double-SHA is to prevent length-extension attacks.
- eimrine 3y ago
  How is it possible if a length of input data going to SHA-256 is one of the required inputs for SHA-256?
  - makeworld 3y ago
    That is not one the required inputs for SHA-256. It is vulnerable to length extension attacks.
    - eimrine 3y ago
      My bad, i thought kt or wt parameters are about length.
- adastra22 3y ago
  You are correct in general, but all bitcoin data structures are self-synchronized, so length extension is not possible.
  - eimrine 3y ago
    Are you sure he is correct in general? I suppose he supposed the length extension attack not on Bitcoin (because all Bitcoin data are self-synchronized) but on anything else using blockchain as a rainbow-table.
    - adastra22 3y ago
      Yes, in general anything being hashed that is subject to length extension ought to be double hashed. And most things are subject to length extension, often in surprising ways. So a good rule of thumb is to always double hash. But in this case, after 15 years of analysis, we can say with confidence that the double hashing bitcoin does is redundant.
TheBlight 3y ago
I don't think they were a cryptographer exactly but someone very familiar with cryptography tools. One of the most interesting aspects of the original code to me is how they lifted the sha256 algorithm from the CryptoPP library when the project already had an OpenSSL dependency.
- mortallywounded 3y ago
  Was it lifted prior to the dependency on OpenSSL? Perhaps, and never retro-fixed?
  - TheBlight 3y ago
    I suspect the inclusion of just the sha2 file from CryptoPP was the fix. Although I've never benchmarked them, my suspicion is the CryptoPP code outperformed OpenSSL at the time. Having the most optimal implementation would have been critical.

I enjoyed the paper but Satoshi definitely is a cryptographer. Who else can decide to use the double-SHA for not letting to use Blockchain as a source for finding collisions in the SHA.

makeworld 3y ago

Pretty sure the accepted justification for double-SHA is to prevent length-extension attacks.

eimrine 3y ago
How is it possible if a length of input data going to SHA-256 is one of the required inputs for SHA-256?
- makeworld 3y ago
  That is not one the required inputs for SHA-256. It is vulnerable to length extension attacks.
  - eimrine 3y ago
    My bad, i thought kt or wt parameters are about length.
adastra22 3y ago
You are correct in general, but all bitcoin data structures are self-synchronized, so length extension is not possible.
- eimrine 3y ago
  Are you sure he is correct in general? I suppose he supposed the length extension attack not on Bitcoin (because all Bitcoin data are self-synchronized) but on anything else using blockchain as a rainbow-table.
  - adastra22 3y ago
    Yes, in general anything being hashed that is subject to length extension ought to be double hashed. And most things are subject to length extension, often in surprising ways. So a good rule of thumb is to always double hash. But in this case, after 15 years of analysis, we can say with confidence that the double hashing bitcoin does is redundant.

TheBlight 3y ago

I don't think they were a cryptographer exactly but someone very familiar with cryptography tools. One of the most interesting aspects of the original code to me is how they lifted the sha256 algorithm from the CryptoPP library when the project already had an OpenSSL dependency.

mortallywounded 3y ago
Was it lifted prior to the dependency on OpenSSL? Perhaps, and never retro-fixed?
- TheBlight 3y ago
  I suspect the inclusion of just the sha2 file from CryptoPP was the fix. Although I've never benchmarked them, my suspicion is the CryptoPP code outperformed OpenSSL at the time. Having the most optimal implementation would have been critical.