BIP: 85
Layer: Applications
Title: Deterministic Entropy From BIP32 Keychains
Authors: Ethan Kosakovsky <ethankosakovsky@protonmail.com>
Aneesh Karve <dowsing.seaport0d@icloud.com>
Status: Deployed
Type: Informational
Assigned: 2020-03-20
License: BSD-2-Clause OR OPUBL-1.0
Version: 2.0.0
"One Seed to rule them all,
One Key to find them,
One Path to bring them all,
And in cryptography bind them."
It is not possible to maintain one single (mnemonic) seed backup for all keychains used across various wallets because there are a variety of incompatible standards. Sharing of seeds across multiple wallets is not desirable for security reasons. Physical storage of multiple seeds is difficult depending on the security and redundancy required.
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.
This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
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.
The terminology related to keychains used in the wild varies widely, for example `seed` has various different meanings. In this document we define the terms
- BIP32 root key is the root extended private key that is represented as the top root of the keychain in BIP32.
- BIP39 mnemonic is the mnemonic phrase that is calculated from the entropy used before hashing of the mnemonic in BIP39.
- BIP39 seed is the result of hashing the BIP39 mnemonic seed.
Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human-friendly serialization of the BIP32 root key (or BIP32 extended keys in general), which makes paper backups or manually restoring the key more error-prone. BIP39 was designed to solve this problem, but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed, which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic.
Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support BIP32 extended private keys, so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenario is particularly satisfactory for security reasons. For example, some wallets may be inherently less secure, like hot wallets on smartphones, JoinMarket servers, or Lightning Network nodes. Having multiple seeds is far from desirable, especially for those who rely on split key or redundancy backups in different geological locations. Adding keys is necessarily difficult and may result in users being more lazy with subsequent keys, resulting in compromised security or loss of keys.
There is an added complication with wallets that implement other standards, or no standards at all. The Bitcoin Core wallet uses a WIF as the hdseed, and yet other wallets, like Electrum, use different mnemonic schemes to derive the BIP32 root key. Other cryptocurrencies, like Monero, use an entirely different mnemonic scheme.
Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" to derive a mnemonic/seed, and then process the mnemonic into a BIP32 key, or private key. We can use BIP32 itself to derive the "initial entropy" to then recreate the same mnemonic or seed according to the specific application standard of the target wallet. We can use a BIP44-like categorization to ensure uniform derivation according to the target application type.
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)
[1].
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 RFC 4231.
INPUT:
- MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
- PATH: m/83696968'/0'/0'
- DERIVED KEY=cca20ccb0e9a90feb0912870c3323b24874b0ca3d8018c4b96d0b97c0e82ded0
- DERIVED ENTROPY=efecfbccffea313214232d29e71563d941229afb4338c21f9517c41aaa0d16f00b83d2a09ef747e7a64e8e2bd5a14869e693da66ce94ac2da570ab7ee48618f7
INPUT:
- MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
- PATH: m/83696968'/0'/1'
- DERIVED KEY=503776919131758bb7de7beb6c0ae24894f4ec042c26032890c29359216e21ba
- DERIVED ENTROPY=70c6e3e8ebee8dc4c0dbba66076819bb8c09672527c4277ca8729532ad711872218f826919f6b67218adde99018a6df9095ab2b58d803b5b93ec9802085a690e
BIP85-DRNG-SHAKE256 is a deterministic random number generator for cryptographic functions that require deterministic outputs, but where the input to that function requires more than the 64 bytes provided by BIP85's HMAC output. BIP85-DRNG-SHAKE256 uses BIP85 to seed a SHAKE256 stream (from the SHA-3 standard). The input must be exactly 64 bytes long (from the BIP85 HMAC output).
RSA key generation is an example of a function that requires orders of magnitude more than 64 bytes of random input. Further, it is not possible to precalculate the amount of random input required until the function has completed.
drng_reader = BIP85DRNG.new(bip85_entropy)
rsa_key = RSA.generate_key(4096, drng_reader.read)
INPUT: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
- MASTER BIP32 ROOT KEY: m/83696968'/0'/0'
- DERIVED KEY=cca20ccb0e9a90feb0912870c3323b24874b0ca3d8018c4b96d0b97c0e82ded0
- DERIVED ENTROPY=efecfbccffea313214232d29e71563d941229afb4338c21f9517c41aaa0d16f00b83d2a09ef747e7a64e8e2bd5a14869e693da66ce94ac2da570ab7ee48618f7
- DRNG(80 bytes)=b78b1ee6b345eae6836c2d53d33c64cdaf9a696487be81b03e822dc84b3f1cd883d7559e53d175f243e4c349e822a957bbff9224bc5dde9492ef54e8a439f6bc8c7355b87a925a37ee405a7502991111
The Application number defines how entropy will be used post processing. Some basic examples follow:
Derivation paths follow the format m/83696968'/{app_no}'/{index}', where {app_no} is the path for the application, and {index} is the index.
Application numbers should be semantic in some way, such as a BIP number or ASCII character code sequence.
Application number: 39'
Truncate trailing (least significant) bytes of the entropy to the number of bits required to map to the relevant word length: 128 bits for 12 words, 256 bits for 24 words.
The derivation path format is: m/83696968'/39'/{language}'/{words}'/{index}'
Example: a BIP39 mnemonic with 12 English words (first index) would have the path m/83696968'/39'/0'/12'/0', the next key would be m/83696968'/39'/0'/12'/1' etc.
Language Table
| Wordlist | Code |
|---|---|
| English | 0' |
| Japanese | 1' |
| Korean | 2' |
| Spanish | 3' |
| Chinese (Simplified) | 4' |
| Chinese (Traditional) | 5' |
| French | 6' |
| Italian | 7' |
| Czech | 8' |
| Portuguese | 9' |
Words Table
| Words | Entropy | Code |
|---|---|---|
| 12 words | 128 bits | 12' |
| 15 words | 160 bits | 15' |
| 18 words | 192 bits | 18' |
| 21 words | 224 bits | 21' |
| 24 words | 256 bits | 24' |
BIP39 English 12 word mnemonic seed
128 bits of entropy as input to BIP39 to derive 12 word mnemonic
INPUT:
- MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
- PATH: m/83696968'/39'/0'/12'/0'
- DERIVED ENTROPY=6250b68daf746d12a24d58b4787a714b
- DERIVED BIP39 MNEMONIC=girl mad pet galaxy egg matter matrix prison refuse sense ordinary nose
BIP39 English 18 word mnemonic seed
192 bits of entropy as input to BIP39 to derive 18 word mnemonic
INPUT:
- MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
- PATH: m/83696968'/39'/0'/18'/0'
- DERIVED ENTROPY=938033ed8b12698449d4bbca3c853c66b293ea1b1ce9d9dc
- DERIVED BIP39 MNEMONIC=near account window bike charge season chef number sketch tomorrow excuse sniff circle vital hockey outdoor supply token
Derives 24 word BIP39 mnemonic seed
256 bits of entropy as input to BIP39 to derive 24 word mnemonic
INPUT:
- MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
- PATH: m/83696968'/39'/0'/24'/0'
- DERIVED ENTROPY=ae131e2312cdc61331542efe0d1077bac5ea803adf24b313a4f0e48e9c51f37f
- DERIVED BIP39 MNEMONIC=puppy ocean match cereal symbol another shed magic wrap hammer bulb intact gadget divorce twin tonight reason outdoor destroy simple truth cigar social volcano
Application number: 2'
Uses the most significant 256 bits[2] of entropy as the secret exponent to derive a private key and encode as a compressed WIF that will be used as the hdseed for Bitcoin Core wallets.
Path format is m/83696968'/2'/{index}'
INPUT:
- MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
- PATH: m/83696968'/2'/0'
- DERIVED ENTROPY=7040bb53104f27367f317558e78a994ada7296c6fde36a364e5baf206e502bb1
- DERIVED WIF=Kzyv4uF39d4Jrw2W7UryTHwZr1zQVNk4dAFyqE6BuMrMh1Za7uhp
Application number: 32'
Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and the second 32 bytes[2] are the private key for the BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
Warning: The above order reverses the order of BIP32, which takes the first 32 bytes as the private key, and the second 32 bytes as the chain code.
Applications may support Testnet by emitting TPRV keys if and only if the input root key is a Testnet key.
Path format is m/83696968'/32'/{index}'
INPUT:
- MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
- PATH: m/83696968'/32'/0'
- DERIVED ENTROPY=ead0b33988a616cf6a497f1c169d9e92562604e38305ccd3fc96f2252c177682
- DERIVED XPRV=xprv9s21ZrQH143K2srSbCSg4m4kLvPMzcWydgmKEnMmoZUurYuBuYG46c6P71UGXMzmriLzCCBvKQWBUv3vPB3m1SATMhp3uEjXHJ42jFg7myX
Application number: 128169'
The derivation path format is: m/83696968'/128169'/{num_bytes}'/{index}'
`16 <= num_bytes <= 64`
Truncate trailing (least significant) bytes of the entropy after `num_bytes`.
INPUT:
- MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
- PATH: m/83696968'/128169'/64'/0'
- DERIVED ENTROPY=492db4698cf3b73a5a24998aa3e9d7fa96275d85724a91e71aa2d645442f878555d078fd1f1f67e368976f04137b1f7a0d19232136ca50c44614af72b5582a5c
Application number: 707764'
The derivation path format is: m/83696968'/707764'/{pwd_len}'/{index}'
`20 <= pwd_len <= 86`
Base64 encode all 64 bytes of entropy. Remove any spaces or new lines inserted by Base64 encoding process. Slice Base64 result string on index 0 to `pwd_len`. This slice is the password. As `pwd_len` is limited to 86, passwords will not contain padding.
Entropy calculation:
R = 64 (Base64 - do not count padding)
L = pwd_len
Entropy = log2(R ** L)
| pwd_length | (cca) entropy |
|---|---|
| 20 | 120.0 |
| 24 | 144.0 |
| 32 | 192.0 |
| 64 | 384.0 |
| 86 | 516.0 |
INPUT:
- MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
- PATH: m/83696968'/707764'/21'/0'
- DERIVED ENTROPY=74a2e87a9ba0cdd549bdd2f9ea880d554c6c355b08ed25088cfa88f3f1c4f74632b652fd4a8f5fda43074c6f6964a3753b08bb5210c8f5e75c07a4c2a20bf6e9
- DERIVED PWD=dKLoepugzdVJvdL56ogNV
Application number: 707785'
The derivation path format is: m/83696968'/707785'/{pwd_len}'/{index}'
`10 <= pwd_len <= 80`
Base85 encode all 64 bytes of entropy. Remove any spaces or new lines inserted by Base85 encoding process. Slice Base85 result string on index 0 to `pwd_len`. This slice is the password. `pwd_len` is limited to 80 characters.
Entropy calculation:
R = 85
L = pwd_len
Entropy = log2(R ** L)
| pwd_length | (cca) entropy |
|---|---|
| 10 | 64.0 |
| 15 | 96.0 |
| 20 | 128.0 |
| 30 | 192.0 |
| 80 | 512.0 |
INPUT:
- MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
- PATH: m/83696968'/707785'/12'/0'
- DERIVED ENTROPY=f7cfe56f63dca2490f65fcbf9ee63dcd85d18f751b6b5e1c1b8733af6459c904a75e82b4a22efff9b9e69de2144b293aa8714319a054b6cb55826a8e51425209
- DERIVED PWD=_s`{TW89)i4`
Application number: 828365'
The derivation path format is: m/83696968'/828365'/{key_type}'/{key_bits}'/{key_index}'
All path components are hardened (denoted by '). The key_type values are plain integers:
| OpenPGP Key Type | key_type |
|---|---|
| RSA | 0 |
| ECC(Curve25519) | 1 |
| ECC(secp256k1) | 2 |
| ECC(NIST) | 3 |
| ECC(Brainpool) | 4 |
The valid key_bits values and corresponding algorithms for each key_type are:
| key_type | key_bits | OpenPGP Algorithm / Curve |
|---|---|---|
| 0 (RSA) | 1024, 2048, 4096 | RSA |
| 1 (Curve25519) | 256 | Ed25519 (certify/sign/auth), X25519 (encrypt) |
| 2 (secp256k1) | 256 | secp256k1 |
| 3 (NIST) | 256, 384, 521 | NIST P-256, P-384, P-521 respectively |
| 4 (Brainpool) | 256, 384, 512 | brainpoolP256r1, brainpoolP384r1, brainpoolP512r1 respectively |
For key_types with a fixed curve (1 and 2), key_bits MUST be 256. Any other value is invalid.
BIP85-DRNG MUST be used as the input RNG function when key generation requires more than 64 bytes of random input. This applies to all RSA key sizes and to NIST P-521 (key_bits=521). All other supported ECC key types use the 64-byte HMAC output directly.
ECC Scalar Derivation for Curves Exceeding 64 Bytes
For elliptic curves whose base length (⌈log₂(order) / 8⌉) exceeds the 64-byte HMAC-SHA512 entropy output — currently only NIST P-521 (base length 66 bytes) — the private scalar MUST be derived using the BIP85-DRNG (SHAKE256) as follows:
1. Read `baselen` bytes from the DRNG (66 bytes for P-521).
2. Interpret the bytes as a big-endian unsigned integer.
3. Mask the integer to `order.bit_length()` bits:
`scalar = raw_int & ((1 << bit_length) - 1)`
4. If `scalar == 0` or `scalar >= order`, apply the fallback:
`scalar = (scalar % (order - 1)) + 1`
Implementations MUST use bit masking (step 3) rather than direct modular reduction (`raw_int % order`). The two methods produce different scalars when the raw integer has more bits than the curve order, because bit masking discards the top bits while modular reduction folds them in.
For curves with base length ≤ 64 bytes (all others in this spec), the scalar is derived directly from the first `baselen` bytes of the 64-byte HMAC-SHA512 entropy, reduced modulo the curve order with the same fallback.
RSA Key Generation Algorithm
RSA key generation from the BIP85-DRNG MUST use the FIPS 186-4 (§B.3.1, §C.3.1) algorithm for probable prime generation. Specifically, the Miller-Rabin primality test MUST use random bases drawn from the same DRNG (randfunc) that generates prime candidates — NOT fixed or deterministic witnesses.
The reference algorithm is PyCryptodome's `RSA.generate(key_bits, randfunc=drng.read)`, which implements FIPS 186-4 with random Miller-Rabin witnesses drawn from the provided `randfunc`.
Implementations that use fixed Miller-Rabin witnesses (e.g., small primes 2, 3, 5, …) will consume DRNG bytes at a different rate than the reference algorithm, producing different primes and therefore different RSA keys from the same entropy. Such implementations are NOT compliant with this specification.
The use of random witnesses is also cryptographically stronger, as fixed small-prime witnesses cannot detect Carmichael numbers that are strong pseudoprimes to all tested bases.
Primary Keys and Subkeys
In OpenPGP, a key consists of a primary key used for certification and one or more subkeys for encryption, signing, and authentication. This structure separates long-term identity (the primary key) from operational keys (subkeys), allowing subkeys to expire or be revoked independently without affecting the primary key identity.
Keys allocated for GPG purposes use the following scheme:
- Primary key:
m/83696968'/828365'/{key_type}'/{key_bits}'/{key_index}' - Sub keys:
m/83696968'/828365'/{key_type}'/{key_bits}'/{key_index}'/{sub_key}'- key_index is the parent key for CERTIFY capability
- sub_key
0'is used as the ENCRYPTION key - sub_key
1'is used as the AUTHENTICATION key - sub_key
2'is usually used as SIGNATURE key
For key_type 1 (Curve25519), the OpenPGP algorithm used depends on the key capability, because Curve25519 takes different forms for signing versus encryption in the OpenPGP standard:
- CERTIFY, SIGN, and AUTHENTICATE capabilities use Ed25519 (EdDSA)
- ENCRYPT capability uses X25519 (ECDH)
Note on timestamps:
The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to UNIX Epoch timestamp 1231006505 (the Bitcoin genesis block time '2009-01-03 18:15:05' UTC)[3] because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of faketime).
All keys derived under this application MUST use a fixed creation date of unix Epoch timestamp 1231006505 (the Bitcoin genesis block time '2009-01-03 18:05:05' UTC) when constructing the OpenPGP key packet, because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of faketime).
Note on GPG key capabilities on smartcard/hardware devices:
GPG capable smart-cards SHOULD be loaded as follows: The encryption slot SHOULD be loaded with the ENCRYPTION capable key; the authentication slot SHOULD be loaded with the AUTHENTICATION capable key. The signature capable slot SHOULD be loaded with the SIGNATURE capable key.
However, depending on available slots on the smart-card, and preferred policy, the CERTIFY capable key MAY be flagged with CERTIFY and SIGNATURE capabilities and loaded into the SIGNATURE capable slot (for example where the smart-card has only three slots and the CERTIFY capability is required on the same card). In this case, the SIGNATURE capable sub-key would be disregarded because the CERTIFY capable key serves a dual purpose.
INPUT:
- MASTER BIP32 ROOT KEY:
xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
| Key Bits | Path | Entropy (hex) | Fingerprint |
|---|---|---|---|
| 1024 |
m/83696968'/828365'/0'/1024'/0'
|
2b9380df43421f46b5c38e13ea80612ff53488bc5d272e86d493ee1eecf738bb7b50e4978b7352f95772f1211483b0e6bba86c544a946b10d76ed493b8c2e01f
|
874A 3964 4ED0 255D EEC1 8E0E 1E63 8864 9672 CF70
|
| 2048 |
m/83696968'/828365'/0'/2048'/0'
|
98c4fb6d76f203e8828bdfd28416edca7a83a9b203901f7ad31f056cda8b3c25b19e5fd2aa642ca0abb9ed8bebf3d141af6c76b28a19eba624bdc6f8a76ce138
|
9987 9DF6 D21E 34C8 A086 A4BD 8B44 8E5B C298 294A
|
| 4096 |
m/83696968'/828365'/0'/4096'/0'
|
2d2ef3335dc51e7a0642bfe86fba0bb4e8401b703d8d679bb1a31d75f8a81f1fd52b20b2eae50ef6e0378b8755f4f0426c68b54f11edc0c848e017e81bb2ad87
|
24C2 5A48 383E 1175 4687 1767 D9A0 5CA6 4F2F 6A85
|
Key Type 1 — Curve25519
| Key Bits | Path | Entropy (hex) | Fingerprint |
|---|---|---|---|
| 256 |
m/83696968'/828365'/1'/256'/0'
|
0e90b553528cd97a033c282f54cf72c1020adaec205d5c0e57e9f2556d06fea683618e4be8f91e7e059647f9d6373eb8b5f535e7ba4097cfb3e93c4957843614
|
E81D F237 1408 2AD2 747E 732B 9A24 C95B D8C2 A55E
|
Key Type 2 — secp256k1
| Key Bits | Path | Entropy (hex) | Fingerprint |
|---|---|---|---|
| 256 |
m/83696968'/828365'/2'/256'/0'
|
f3bb8b3d6b81fbd202c34b59ce7e97c83969e9b5733b936de16c51119c7a48239ddf66729ef5e4df97ea39471f05a89f070869b3f9d72d69f3ae8bd7ee4fb6b3
|
6D99 D348 74C6 E88F F30C 758A 46F7 E1AF 05FC 3414
|
Key Type 3 — NIST (P-256, P-384, P-521)
| Key Bits | Path | Entropy (hex) | Fingerprint |
|---|---|---|---|
| 256 |
m/83696968'/828365'/3'/256'/0'
|
f52586f58521916b9f28b0058be86effcde82e571eabada9e3f63c6f67752ff12a4d3bf2fffe0f147164945691605a58f28f6bded869c38b3db9f0e577d83728
|
2FE6 D862 FF2A BF1C 1FAA 2753 B681 BEF5 B5D5 74C4
|
| 384 |
m/83696968'/828365'/3'/384'/0'
|
830005ea400f7a03c27aa06a9728fe311c9a48dc31bd417f07b96c69edc73d25baa00d04b9dbbe6f42539b06d9ef1ba62ed73d4a3a992302aae09e17e0d9f42f
|
5668 7C3C 9072 19B2 9FCE 39CF 95F0 16F9 B150 B8A1
|
| 521 |
m/83696968'/828365'/3'/521'/0'
|
3524b3cbe60eb78a156dae44674702f69381afe5292d6d15d7801b7e530f2a0616b7b876c0ba85d6e675587fdc0ce2242ad00252493ec9c3a024217d1e2aa954
|
AAAA 594C 6DB9 5F6B B622 5DCA 10CC E597 28A4 7DBC
|
Key Type 4 — Brainpool (P-256, P-384, P-512)
| Key Bits | Path | Entropy (hex) | Fingerprint |
|---|---|---|---|
| 256 |
m/83696968'/828365'/4'/256'/0'
|
97ee4490d89bf257e9a038e2af12824fba47fec721970ca1fc1c094650d2716d75491402530776ba31d215fac6c2de0cb6661f1d380b682e20246bf962cdf385
|
6161 7C06 F6F2 AC32 3D67 782F 11CB 4B79 FEFD 4369
|
| 384 |
m/83696968'/828365'/4'/384'/0'
|
3fa833db4195fbd7a9c4e3f6fdb65ffb8951c5c65ca0cce441a4410e11aa96fcb094ed8c1fb5317448ae098ca9cae2c351b513e47d1b74e4c80c1facdf7b0a5a
|
3278 6624 D0CA 7D7F 0133 0940 397F 2F1F A2BE 47CB
|
| 512 |
m/83696968'/828365'/4'/512'/0'
|
985f0131503109fc7fb2ab15e6a86846888e4b9a9f4f11f0d7b30dba4570cf8cc728a4c8ce9bbeb9b9819fbe924bb2d6d71a9c8332635cfb5db5008364f3a43a
|
99D7 BDC9 37AC 6E9B CC17 D093 6643 E050 1D03 C680
|
Application number: 89101'
The derivation path format is: m/83696968'/89101'/{sides}'/{rolls}'/{index}'
2 <= sides <= 2^32 - 1
1 <= rolls <= 2^32 - 1
Use this application to generate PIN numbers, numeric secrets, and secrets over custom alphabets. For example, applications could generate alphanumeric passwords from a 62-sided die (26 + 26 + 10).
Roll values are zero-indexed, such that an N-sided die produces values in the range
[0, N-1], inclusive. Applications should separate printed rolls by a comma or similar.
Create a BIP85 DRNG whose seed is the derived entropy.
Calculate the following integers:
bits_per_roll = ceil(log_2(sides))
bytes_per_roll = ceil(bits_per_roll / 8)
Read bytes_per_roll bytes from the DRNG.
Trim any bits in excess of bits_per_roll (retain the most
significant bits). The resulting integer represents a single roll or trial.
If the trial is greater than or equal to the number of sides, skip it and
move on to the next one. Repeat as needed until all rolls are complete.
INPUT:
- MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
- PATH: m/83696968'/89101'/6'/10'/0'
- DERIVED ENTROPY=5e41f8f5d5d9ac09a20b8a5797a3172b28c806aead00d27e36609e2dd116a59176a738804236586f668da8a51b90c708a4226d7f92259c69f64c51124b6f6cd2
- DERIVED ROLLS=1,0,0,2,0,1,5,5,2,4
This specification is not backwards compatible with any other existing specification.
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.
BIP32, BIP39
- 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
- ECC GPG key types for OpenPGP under application 828365': Curve25519/key_type=1, secp256k1/key_type=2, NIST/key_type=3, Brainpool/key_type=4
- RSA application 828365' (introduced in 1.1.0) extended with a
key_typepath component (key_type=0 for RSA) to unify all OpenPGP key types under a single application number; RSA derivation path changed fromm/83696968'/828365'/{key_bits}'/{key_index}'tom/83696968'/828365'/0'/{key_bits}'/{key_index}'(breaking change for existing RSA implementations)
- Fixed the human-readable datetime string for BIP85 GPG Keys that was incorrectly stated as '2009-01-03 18:05:05' rather than '2009-01-03 18:15:05'. Implementations that relied on the previously incorrect datetime string instead of UNIX Epoch timestamp 1231006505 will produce different key fingerprints.
- Dice application 89101'
- Czech language code to application 39'
- TPRV guidance for application 32'
- Warning on application 32' key and chain code ordering
- Base64 application 707764'
- Base85 application 707785'
- BIP85-DRNG-SHAKE256
- RSA application 828365'
- Initial version
- ^ 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 hardened 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.
- a b
There is a very small chance that you'll make an invalid
key that is zero or larger than the order of the curve. If this occurs, software
should hard fail (forcing users to iterate to the next index). From BIP32:
In case parse256(IL) ≥ n or ki = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2127.)
- ^ The human-readable datetime string was incorrectly noted as '2009-01-03 18:05:05' prior to v2.0.0 of this BIP, so implementations that relied on it rather than UNIX Epoch timestamp 1231006505 will produce different key fingerprints.
Many thanks to Peter Gray and Christopher Allen for their input, and to Peter for suggesting extra application use cases.