Topic: In theory,THE most unsafe HD Wallet - [BIP32, BIP39, BIP44, BIP84] - am I close? (Read 96 times)

This is interesting. Remember a decade ago and the fuck-up with brain wallets?

People would take SHA256(secret) and use the 32-byte output as a BTC private key. Things got really interesting when someone set secret = "", i.e. an empty string. Its SHA256 is


Here is a neat tool to convert 32-byte strings to Bitcoin key pairs. For the empty string hash above, it gives us


...and the infamous 50 BTC transaction belongs to one of them.

"What on Earth does any of this have to do with HD Wallets?" is a valid question.

Well, I realized we can easily recreate the madness using a master XPRV and leave out derivation paths.

Others have described the anatomy of XPRV better before me, so allow me to concatenate the bytes according to:

(pseudocode) b"\x04\x88\xad\xe4" + a string of zeros + SHA25&(""), so that we get a 156 characters long hexadecimal string like so


To verify is as an XPRV and make it human-readable, here is a one-liner that does the trick:


Lo and behold, if we run


we get... the same private keys and public addresses!

In other words, we have resurrected the decade-old brain wallet madness and shown that the same goes for XPRV.

Bonus:

If we instead use the stupid SHA("") twice in the same string, e.g.


We get a seemingly new and unique XPRV, but it resolves to the same good old key pairs. If no derivation path is specified, none of these extra bytes matter.

This ultimately leads me to believe that we could scan using either ...01, ...02, ...03 like brainflayer or by feeding it with good old SHA256 that has been out in the wild for a long time.

Additionally, it will be interesting to see whether the derivation path can be the variable that leads us to the discovery of new (old) public keys and their private keys.

Mnemonic phrases and hierarchical deterministic (HD) wallets may be good. I mean, the intention was certainly good. But it is not so good if you can trick non-tech-savvy people into using XPRVs that are accepted by all major wallet software even if they are a cryptographic disaster.

Simplifying further with a one-liner (added "x01" to the 32-byte/64-character hexadecimal string as the least significant byte)


This leads to five public addresses, of which all(!) have had activity on the blockchain this year. Therefore, I would like to call this


the most catastrophic XPRV of them all. Agree?


And we may control them. Merry Christmas and happy scripting.

My main point is that it doesn't matter how many safety stops you have along the way, when the end product, the XPRV, is a simple base58_check string with a defined, even hard-coded, structure.

I'll try with a separate demonstration using as few libraries and imports as possible.

The proper, safe, and sound protocols are supposed to spit out a high-entropy seed of 32 bytes (64 hexadecimal characters) after intricate rounds of hashing. But nothing stops us from hardcoding it to a string of zeroes.

Demo in Python:


which gives


which is a valid XPRV - but, according to me, with catastrophic properties

Using the same code as in the OP, we can derive from it:


and (almost) infinitely many more by playing around with the derivation path.



Edit/addition: The true power of strong and secure hashing methods, such as PBKDF2-HMAC-SHA512 - "computationally slow one-way functions," becomes their weakness in intentionally bad applications. This is because discarding outputs for which the input was catastrophic is, by definition, impossible. It will always be possible to override suggested requirements such as "at least 128 bits of entropy", as demonstrated here, where it is impossible to tell from the XPRV output alone if it was generated properly or not. (I tested this last one, too, with Electrum, which accepts it if you tick the BIP39 box, and generates an array of receiving and change addresses from it.)

I'm assuming `bip32 = BIP32.from_seed(bytes.fromhex(""))` is from
https://github.com/darosior/python-bip32/blob/1492d39312f1d9630363c292f6ab8beb8ceb16dd/bip32/bip32.py#L332
In which case the library is broken because it should have rejected your input as insecure because despite what you said in the quote above the only "good practice" that you overrode was using a 0 bit entropy whereas the doc says it should be between 128 and 512 bits
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#master-key-generation

The rest can be skipped and your derived keys would still be secure as long as the entropy was secure.
Meaning you can skip passphrase in BIP39, you can even modify the algorithm and completely remove PBKDF2 and just use a single SHA512 (removes all the hashes and usage of salt), not use any derivation path, and so on and still produce 100% secure child keys.

You might also want to mention sending a lot of Bitcoins to burned addresses for no reason or maybe that single address has actually an owner with private key, I don't know, but I would like to know who has done what you said, to derive a key like that?

Ps, do an rmd160 on empty string, the address contains 72 Bitcoins.

DISCLAIMER: Consider this a theoretical exercise in producing the worst imaginable HD Wallet and its private keys and public addresses from a safety and good practice perspective. It contains overriding as many safety measures as possible - on purpose. Don't try this at home.

Brief introduction
Firstly, I will skip a proper intro and instead recommend those interested to read up on BIP32, BIP39, BIP44, and BIP84 as needed. These are intended to add safety and utility to Bitcoin, and I chose to try my best to misuse them.

I will use Python and some common crypto-related libraries, leaving out most whys and hows.

My idea is to create the worst imaginable BTC mainnet extended private key (XPRV) from a cryptographic viewpoint and derive the first of its corresponding key pairs. In other words: "Catastrophic private keys" in WIF format and the different flavors of public addresses they control - details you can import in Electrum and sweep clean in a matter of seconds.

This is hopefully somewhat entertaining and, in the best of worlds, even rewarding in one way or the other.

I hypothesize that if you learn to do every step wrong, you become better at making it right when needed. I look forward to your comments, corrections, and feedback!

Let's get going
We need a disastrous XPRV to begin with. Let's aim for the worst of them all. There are excellent online tools, such as this, this and this you can use to create high-entropy and human-readable mnemonic phrases based on standardized word lists, but they have safety measures, as they should have, against week phrases. Also, remember that creating cryptographically sound XPRVs involves many rounds of one-way hashing and the incremental use of random salts and checksums (PBKDF2-HMAC-SHA512).

Can we break it? I think we can:


See what I did there? I overrode all traces of good practice: I used an empty string ("") as the passphrase, didn't hash anything, didn't salt, used no derivation path at all ("m"), and confirmed both outputs, the master and the first derivation, equate to the same value:


Please tell me if you imagine a more unsafe and stupid method to create a master XPRV for Bitcoin! (Further, consider all this a homage to the marvelous 50 BTC transaction to the address that belongs to SHA256(*empty string*) in 2015.)

Now, let's use this master XPRV, once again without derivation paths, to find the possible private keys and all(?) corresponding public addresses, given BTC standards of 2023:


After some prettification (actual print commands omitted), the output is


Concluding remarks and questions
At least one of these public addresses has appeared on the blockchain before. I claim no fame in finding these. I just added what has been out for years together, but I sincerely wonder - can you think of an even more stupid and/or insecure way of using XPRV to set up an HD Wallet?

I haven't even bothered with playing around with derivation paths yet. It should be a simple loop in Python to spit out millions, if not billions, of "hardened" (not so hardened) children and change addresses that are derived from this single disastrous XPRV.

What say you? Can you possibly do worse?