Hashing algorithm choice
ocornoc opened this issue · comments
Line 109 in 9a2e9d6
Line 119 in 9a2e9d6
SHA-256 (and, by extension, double SHA-256) may be less secure than SHA-512 (already provided by the hash library) truncated to 256 bits.
A couple of guys in Austria did an analysis (Tbl 6.6, Sec 3.5, Sec 4.4, Sec 5.4)
David Strauss provides some arguments for SHA-512/256
FIPS SP 800-107 (Sec 4.1, Sec 4.2 Tbl 1)
A security analysis of SHA-512/256 and SHA-512/224
None of this is to say that SHA-256 itself is insecure, just that it may not be the optimal choice, especially when a better solution would be quite easy to drop in (from a very superficial glance, at least).
@eukreign Can you please triage?
I would suggest @jackrobison and @kaykurokawa check this one out
They are both as secure as it needs to be for the application.
Changing it would be a pointless hardfork and engineering effort.
To add some clarification to this: I think @ocornoc was specifically referring to how the wallet is encrypted on disk and not necessarily what SHA was used for the blockchain itself.
My answer is the same as Kay's though: Bitcoin and LBRY use SHA256 to secure the blockchain. If there is a valid argument that SHA256 is not secure then it seems that fixing the blockchain would be significantly higher priority than how you encrypt your wallet.
Also, torba intends to be at least somewhat backwards compatible with electrum; there are many existing wallets with encrypted seeds/keys via the old electrum wallet which now need to be decrypted with torba. Changing how encryption works would require tracking which version of the algorithm was used to encrypt the wallet and then decrypting it with the correct decrypt algorithm. For a long time, both the 256 and 512 versions would be included in the code to be able to open old wallets; this would add unnecessary technical debt.
If SHA256 is not secure then we have much bigger problems on our hands.
@eukreign is correct in the interpretation: I was specifically referring to torba's on-disk encryption.
And, eukreign, you are right (if I'm picking up on what you were saying correctly): SHA-256 is secure, and there may be reasons to keep SHA-256 in use whether or not it is optimally secure, such as backwards compatibility.
As an explanation of my original post, I had meant that SHA-256 is a secure hashing algorithm, though it may not be the most secure hashing algorithm readily available. I was attempting to provide reasons as to how truncated SHA-512 may be more secure than SHA-256, irregardless as to whether either of them were secure themselves.