From e0cc4f0e3d3657b025af318de009f6028d673211 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Fri, 25 Oct 2024 12:03:06 -0700 Subject: [PATCH 1/4] BIP-85: Rename to 'changelog' and move above Reference implementation(s) --- bip-0085.mediawiki | 60 +++++++++++++++++++++++----------------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 18c45d57..345f45cf 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -95,7 +95,36 @@ OUTPUT * DRNG(80 bytes)=b78b1ee6b345eae6836c2d53d33c64cdaf9a696487be81b03e822dc84b3f1cd883d7559e53d175f243e4c349e822a957bbff9224bc5dde9492ef54e8a439f6bc8c7355b87a925a37ee405a7502991111 -==Reference Implementation== +==Changelog== + +===1.3.0 (2024-10-22)=== + +====Added==== + +* Dice application 89101' +* Czech language code to application 39' +* TPRV guidance for application 32' +* Warning on application 32' key and chain code ordering + +===1.2.0 (2022-12-04)=== + +====Added==== + +* Base64 application 707764' +* Base85 application 707785' + +===1.1.0 (2020-11-19)=== + +====Added==== + +* BIP85-DRNG-SHAKE256 +* RSA application 828365' + +===1.0.0 (2020-06-11)=== + +* Initial version + +==Reference Implementations== * 1.3.0 Python 3.x library implementation: [https://github.com/akarve/bipsea] * 1.1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] @@ -429,35 +458,6 @@ The reason for running the derived key through HMAC-SHA512 and truncating the re Many thanks to Peter Gray and Christopher Allen for their input, and to Peter for suggesting extra application use cases. -==Change Log== - -===1.0.0 (2020-06-11)=== - -* Initial version - -===1.1.0 (2020-11-19)=== - -====Added==== - -* BIP85-DRNG-SHAKE256 -* RSA application 828365' - -===1.2.0 (2022-12-04)=== - -====Added==== - -* Base64 application 707764' -* Base85 application 707785' - -===1.3.0 (2024-10-22)=== - -====Added==== - -* Dice application 89101' -* Czech language code to application 39' -* TPRV guidance for application 32' -* Warning on application 32' key and chain code ordering - ==References== BIP32, BIP39 From 9133ab2451c4d78631eb10bbd73ec23fd8b31a83 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Fri, 25 Oct 2024 12:05:56 -0700 Subject: [PATCH 2/4] BIP-85: Add 15 and 21 word entries to application 39' table --- bip-0085.mediawiki | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 345f45cf..657dcf3d 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -196,10 +196,18 @@ Words Table | 128 bits | 12' |- +| 15 words +| 160 bits +| 15' +|- | 18 words | 192 bits | 18' |- +| 21 words +| 224 bits +| 21' +|- | 24 words | 256 bits | 24' From 88f4fc0ecefb6164685dcafa9b8ee97a0b2bc289 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Sat, 9 Nov 2024 14:24:50 -0700 Subject: [PATCH 3/4] BIP-85: Reorder sections to be more standard, convert HMAC discussion to footnote --- bip-0085.mediawiki | 89 +++++++++++++++++++++++----------------------- 1 file changed, 44 insertions(+), 45 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 657dcf3d..949736c3 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -24,6 +24,10 @@ It is not possible to maintain one single (mnemonic) seed backup for all keychai As HD keychains are essentially derived from initial entropy, this proposal provides a way to derive entropy from the keychain which can be fed into whatever method a wallet uses to derive the initial mnemonic seed or root key. +==Copyright== + +This BIP is dual-licensed under the Open Publication License and BSD 2-clause license. + ==Definitions== The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. @@ -52,6 +56,9 @@ Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" t We assume a single BIP32 master root key. This specification is not concerned with how this was derived (e.g. directly or via a mnemonic scheme such as BIP39). For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: HMAC-SHA512(key="bip-entropy-from-k", msg=k). The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation, and truncate the rest. + +The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromised. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur. + The HMAC-SHA512 function is specified in [https://tools.ietf.org/html/rfc4231 RFC 4231]. @@ -95,41 +102,6 @@ OUTPUT * DRNG(80 bytes)=b78b1ee6b345eae6836c2d53d33c64cdaf9a696487be81b03e822dc84b3f1cd883d7559e53d175f243e4c349e822a957bbff9224bc5dde9492ef54e8a439f6bc8c7355b87a925a37ee405a7502991111 -==Changelog== - -===1.3.0 (2024-10-22)=== - -====Added==== - -* Dice application 89101' -* Czech language code to application 39' -* TPRV guidance for application 32' -* Warning on application 32' key and chain code ordering - -===1.2.0 (2022-12-04)=== - -====Added==== - -* Base64 application 707764' -* Base85 application 707785' - -===1.1.0 (2020-11-19)=== - -====Added==== - -* BIP85-DRNG-SHAKE256 -* RSA application 828365' - -===1.0.0 (2020-06-11)=== - -* Initial version - -==Reference Implementations== - -* 1.3.0 Python 3.x library implementation: [https://github.com/akarve/bipsea] -* 1.1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] -* 1.0.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js] - ==Applications== The Application number defines how entropy will be used post processing. Some basic examples follow: @@ -458,22 +430,49 @@ This specification is not backwards compatible with any other existing specifica This specification relies on BIP32 but is agnostic to how the BIP32 root key is derived. As such, this standard is able to derive wallets with initialization schemes like BIP39 or Electrum wallet style mnemonics. -==Discussion== - -The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromised. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur. - -==Acknowledgements== - -Many thanks to Peter Gray and Christopher Allen for their input, and to Peter for suggesting extra application use cases. - ==References== BIP32, BIP39 +==Reference Implementations== + +* 1.3.0 Python 3.x library implementation: [https://github.com/akarve/bipsea] +* 1.1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] +* 1.0.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js] + +==Changelog== + +===1.3.0 (2024-10-22)=== + +====Added==== + +* Dice application 89101' +* Czech language code to application 39' +* TPRV guidance for application 32' +* Warning on application 32' key and chain code ordering + +===1.2.0 (2022-12-04)=== + +====Added==== + +* Base64 application 707764' +* Base85 application 707785' + +===1.1.0 (2020-11-19)=== + +====Added==== + +* BIP85-DRNG-SHAKE256 +* RSA application 828365' + +===1.0.0 (2020-06-11)=== + +* Initial version + ==Footnotes== -==Copyright== +==Acknowledgements== -This BIP is dual-licensed under the Open Publication License and BSD 2-clause license. +Many thanks to Peter Gray and Christopher Allen for their input, and to Peter for suggesting extra application use cases. From b398219e9cf23b66431debda13765f6557e98239 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Sat, 9 Nov 2024 14:30:02 -0700 Subject: [PATCH 4/4] BIP-85: Move new reference to be near HMAC code --- bip-0085.mediawiki | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 949736c3..df6c9208 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -55,10 +55,11 @@ Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" t We assume a single BIP32 master root key. This specification is not concerned with how this was derived (e.g. directly or via a mnemonic scheme such as BIP39). -For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: HMAC-SHA512(key="bip-entropy-from-k", msg=k). The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation, and truncate the rest. +For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: HMAC-SHA512(key="bip-entropy-from-k", msg=k) The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromised. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur. - +. +The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation, and truncate the rest. The HMAC-SHA512 function is specified in [https://tools.ietf.org/html/rfc4231 RFC 4231].