joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-27 09:46:12 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Make Clearer The Benefits Of Hardened Keys And The Absence Of A Master PubKey

Browse source 
As suggested by @gmaxwell (thanks!), I tried to make clearer the benefit
of hardened keys:

* Described hardened keys as a solution in the first sentence of the
  Hardened Keys subsection.

* Reordered the text so that the problem is described before the
  solution, making the presence of a solution clearer.

* Added a prefatory sentence to the description of the two key
  derivation formulas again describing the hardened formula as a
  solution.

As suggested by @vbuterin (thanks!), I added a paragraph describing that
HD wallets don't use normal derivation on the master key so they don't
have an effective master public key. (See end of the diff.)

This is a fairly large diff because of the reordering, but no new
clauses were added besides those described above.
This commit is contained in:
David A. Harding 2014-05-20 10:15:23 -04:00
parent e21d527523
commit cb5b2206b1
No known key found for this signature in database
GPG key ID: 4B29C30FF29EC4B7
3 changed files with 31 additions and 25 deletions
Download patch file Download diff file Expand all files Collapse all files

53
_includes/guide_wallets.md
View file

@ -215,27 +215,9 @@ which makes them special.
{% autocrossref %}
Deriving [child extended keys][child extended key]{:#term-child-extended-key}{:.term} from parent extended keys is more nuanced
than described earlier due to the presence of two extended private key
derivation formulas. The normal formula, described above, combines
together the index number, the parent chain code, and the parent public key to create the
child chain code and the integer value which is combined with the parent
private key to create the child private key.
![Creating Child Public Keys From An Extended Private Key](/img/dev/en-hd-private-parent-to-private-child.svg)
The hardened formula, illustrated above, combines together the index
number, the parent chain code, and the parent private key to create
the data used to generate the child chain code and child private key.
This formula makes it impossible to create child public keys without
knowing the parent private key. In other words, parent extended public
keys can't create hardened child public keys.
Because of that, a [hardened extended private
key][]{:#term-hardened-extended-private-key}{:.term} is much less
useful than a normal extended private key---however, it's more secure
against multi-level key compromise. If an attacker gets a normal parent
chain code and parent public key, he can brute-force find all 2<sup>31</sup> normal chain
Hardened extended keys fix a potential problem with normal extended keys.
If an attacker gets a normal parent
chain code and parent public key, he can brute-force find all chain
codes deriving from it. If the attacker also obtains a child, grandchild, or
further-descended private key, he can use the chain code to generate all
of the extended private keys descending from that private key, as
@ -256,7 +238,27 @@ better secured than standard public keys and users should be advised
against exporting even non-extended private keys to
possibly-untrustworthy environments.
Hardened extended private keys create a firewall through which
This can be fixed, with some tradeoffs, by replacing the the normal
key derivation formula with a hardened key derivation formula.
The normal key derivation formula, described in the section above, combines
together the index number, the parent chain code, and the parent public key to create the
child chain code and the integer value which is combined with the parent
private key to create the child private key.
![Creating Child Public Keys From An Extended Private Key](/img/dev/en-hd-private-parent-to-private-child.svg)
The hardened formula, illustrated above, combines together the index
number, the parent chain code, and the parent private key to create
the data used to generate the child chain code and child private key.
This formula makes it impossible to create child public keys without
knowing the parent private key. In other words, parent extended public
keys can't create hardened child public keys.
Because of that, a [hardened extended private
key][]{:#term-hardened-extended-private-key}{:.term} is much less
useful than a normal extended private key---however,
hardened extended private keys create a firewall through which
multi-level key derivation compromises cannot happen. Because hardened
child extended public keys cannot generate grandchild chain codes on
their own, the compromise of a parent extended public key cannot be
@ -284,6 +286,13 @@ firewalls.
![Example HD Wallet Tree Using Prime Notation](/img/dev/en-hd-tree.svg)
Wallets following the BIP32 HD protocol only create hardened children of
the master private key (*m*) to prevent a compromised child key from
compromising the master key. As there are no normal children for the
master keys, the master public key is not used in HD wallets. All other
keys can have normal children, so the corresponding extended public keys
may be used instead.
The HD protocol also describes a serialization format for extended
public keys and extended private keys. For details, please see the
[wallet section in the developer reference][devref wallets] or BIP32