summaryrefslogtreecommitdiff
path: root/bip-0032.mediawiki
diff options
context:
space:
mode:
authorWladimir J. van der Laan <laanwj@gmail.com>2014-10-15 10:58:22 +0200
committerWladimir J. van der Laan <laanwj@gmail.com>2014-10-15 10:58:22 +0200
commit1ce83204951c5e46f4c4b1f4734403b7f1899281 (patch)
tree2a9600d990ca77971fea1157c6939092fc1cf4b0 /bip-0032.mediawiki
parent666bbf3c4abc02a95555b63ffe4453127349f8f0 (diff)
parent5be4021fa14ba679fefd44e02cb9d25d6b6707c3 (diff)
Merge pull request #64 from harding/bip32-ancestor-risk
BIP32: Disambiguate Which Key Is Compromised When Ext. PubKey + PrivKey Are Leaked
Diffstat (limited to 'bip-0032.mediawiki')
-rw-r--r--bip-0032.mediawiki2
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index db13b06..3b70bd6 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -201,7 +201,7 @@ Private and public keys must be kept safe as usual. Leaking a private key means
Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys.
-One weakness that may not be immediately obvious, is that knowledge of the extended public key + any non-hardened private key descending from it is equivalent to knowing the extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys.
+One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys.
It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.