Published on: 2021-03-22T12:05:13+00:00
In a recent email thread on the Bitcoin-dev mailing list, Erik Aronesty suggested using sha3-256 for generating hashes instead of sha256 due to certain attacks such as length extension. A user named Arik Sosman asked if sha256-hmac(nonce, publicKeyPoint) would be a suitable and safe alternative.The security of a hierarchical deterministic (HD) wallet scheme that can be specified in three lines cannot be assumed without specifying the security goals, according to Tim Ruffing. The main issue with using a simple incrementation method for public keys is that all those keys can be linked together easily. However, by making the offset deterministic but less predictable, it should be secure enough. Offset equals SHA256(masterPublicKey || nonce), but it is not clear how the nonce is obtained. In a deterministic scheme, either the master private key is involved in the derivation of nonce, which would make the nonce unpredictable, or it's not, which would make the nonce predictable. It may also be possible to compute a parent private key from a private key.The discussion revolves around the security of a proposed HD wallet scheme. The scheme involves using a private key to calculate a public key and incrementing it. However, all of the resulting public keys can be easily linked together, which is the only problem with this approach. To make it more secure, the suggestion is to use deterministic but less predictable offsets instead of simple incrementation. This would result in parent, first child and second child keys that cannot be linked together unless the offset is guessed by an attacker.The discussion revolves around the safety and suitability of a simple HD wallet design that uses pure ECDSA and SHA-256. The design involves generating a master public key and child public keys using SHA-256 and a nonce. The concern raised is whether this design is safe to implement in practice, given that SHA-256 suffers from certain attacks, such as length extension attacks. Erik Aronesty suggests using SHA3-256 instead, as it does not suffer from padding-related vulnerabilities.The safety of a HD wallet scheme was questioned by vjudeu in an email to bitcoin-dev. The scheme can be specified in just three lines, without even defining the security goals. In response, Tim stated that it would not be safe to assume the implementation of such a scheme is secure. His comment may come across as harsh, but it is important to prioritize safety when it comes to cryptocurrency wallets.In a discussion on the bitcoin-dev mailing list, a question was raised about the suitability and safety of using sha256-hmac(nonce, publicKeyPoint) as an alternative to sha3. Erik Aronesty recommended the use of sha3-256 instead, citing vulnerabilities in sha256 such as length extension attacks that could lead to information leaks depending on concatenation methods.In a discussion on the Bitcoin-dev mailing list, a user suggested using sha3-256 instead of sha256 for designing an HD wallet. They explained that sha256 is vulnerable to certain attacks such as length extension, which could potentially leak information depending on how things are concatenated. They suggest choosing something where padding doesn't matter.A user recently shared a link to a bitcoin forum discussing a simple and interesting HD wallet design. The user is seeking input on whether there are any flaws in the design or if it is safe for practical use. The design appears to use pure ECDSA and SHA-256, with a masterPublicKey generated from the masterPrivateKey multiplied by G. The masterChildPublicKey is derived from the masterPublicKey and a 256-bit nonce using SHA-256 and mod n. Similarly, the masterChildPrivateKey is derived from the masterPrivateKey and nonce using SHA-256 and mod n.Overall, the discussion highlights the importance of choosing secure algorithms when designing cryptographic schemes. In this case, the suggestion to use sha3-256 over sha256 may provide better protection against certain attacks. It is crucial for developers to thoroughly test and verify the security of any new implementations before use.
Updated on: 2023-08-02T03:28:21.017941+00:00