0

Since I do not have 50 Rep points I had to post my question this way!

This is an answer by "https://bitcoin.stackexchange.com/users/56917/rstack" to the question "How do Ledger Backups get stored?"

"Using words to back up wallets is a process described in BIP 39.

Basically, the mnemonic is converted into a seed. This seed is then used as the seed to a Heirarchical Deterministic (HD) wallet, as laid out in BIP 32. The seed is used to generate a Master Extended Private Key, from which all other private keys can be generated. The child key generation follows the standard of BIP 44 so it is compatible with other wallets too.

Thus, by backing up your mnemonic words, any time you enter them in a wallet, it can recreate the seed, then the master private key, then all your other keys, so your wallet is back."


When I start my Ledger for the first time I get a generated 24 word seed. At this point my Ledger has the default wallets (BTC, ETH, LTC) if any. From Rstack's answer I get how this works or could work so far, BUT how does my 24 word seed know the future when I add or remove wallets? The 24 word seed does not change after I add or remove wallets. Randomly generated public and private keys that are created in the future can no way have ties to a previously generated 24 word seed. Does not make sense!

Unless this can be explained I am going to have to assume that my public and private keys are stored somewhere and retrieved by the 24 word seed.

Can anyone shed light on this? Thanks in advance and cheers everyone.

1

I don't know about Ledger specifically, but for HD wallets in general, private and public keys are not generated randomly. Rather, they are generated by a deterministic algorithm from the seed (in this case, the 24 words). So they are absolutely "tied" to the seed.

When you add a wallet for another coin, keys for that wallet would presumably be generated from the same seed (using different parameters so that you don't end up with the same keys in all your wallets). The seed itself stays the same and doesn't have to change to reflect the creation of the new wallet.

Should you ever need to restore, I assume you would need to tell the device which coins you had wallets for. It will then regenerate all the keys for those wallets from the master seed, using the same algorithm as it used originally, and you'll have all the same keys you had before. (If you try to restore some wallets that you weren't using or had removed, all that will happen is you'll find no coins in that wallet.)

Your public and private keys are not stored anywhere except within the device itself.

  • Yes, this makes total sense now! I always thought the seed is generated for the ledger and not to create keys. Cool, thanks Nate. – Briez Jan 27 '18 at 16:35
0

Entropy-to-Mnemonic

The process for a BIP39-compliant 12-word mnemonic, for example, is that first a random binary number 128 bits long is (ideally) generated with a cryptographically-secure process, then a deterministic checksum is computed by taking the first 4-bits of a SHA256 hash digest of the 128 bits formatted as a byte-array.

Then we have 132 bits which are split into 12 groups, with each group pointing to a word on an index of 2^11 words (2048 total).

Mnemonic-to-seed:

Those 12 words represent the root seed, which is then fed into an HMAC-SHA512 hash function (with 2048 rounds) and left-most 256 bits of the 512-bit hash digest is the Master Private Key, whereas the right-most 256 bits of the 512-bit hash digest is the Master Chain Code, as per BIP32 for Hierarchical Deterministic (HD) Wallets.

Extended keys (xPub/xPrv):

The Master Private key is used as an elliptic curve private key to compute the Master Public Key which is 264 bits.

The chaincode, together with an index value starting at 0, is what lets you iterate on the derivation process to produce (and thus extend) a different child private-public key pair each time, as the index value changes, while the chaincode is constant (as entropy).

Derived child private-public keys:

The way this process works, is the parent public key is concatenated with the parent chaincode along with the index value, and again fed into the HMAC-SHA512 function, where the 512-bit output represents the concatenation of child private key, and child chain code (where the private key is used to compute the child public key).

HMAC-SHA512(xPub+Chaincode+index0) = (512bits= child_privatekey_0 || childchaincode0)

childprivatekey_0 * Secp256k1 Generator point = childpublickey_0

HMAC-SHA512(xPub+Chaincode+index2) = (512bits= child_privatekey_1 || childchaincode1)

childprivatekey_1 * Secp256k1 Generator point = childpublickey_1

This process can be repeated to derive nearly 2 billion child keys form the extended private key (in terms of the maximum possible index value).

Thus, mnemonics are incredibly convenient, compared to having to store so many different private keys, as the mnemonic allows you to recreate all derived keys, and can even support multiple cryptocurrencies with the use of BIP44. I like to refer to mnemonics as Cryptovaults, and not wallets, as they house multiple wallets and potentially for multiple accounts (cryptocurrencies). The security tradeoff though is that all your assets can be tied to one potential point of failure if the mnemonic is not secured/derived properly. Thus it is common for users to have several mnemonics, such as for hot wallets and others for cold storage.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.