0085 - Final - Informational - March 20, 2020 (6 years, 4 months ago)
20
2020
BIP: 85
Layer: Applications
Title: Deterministic Entropy From BIP 32 Keychains
Author: Ethan Kosakovsky <[email protected]>
Aneesh Karve <[email protected]>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP 85
Status: Final
Type: Informational
Created: 2020-03-20
License: BSD-2-Clause
OPL
"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
When in doubt, assume big endian byte serialization, such that the leftmost byte is the most significant.
Most wallets implement BIP 32 which defines how a BIP 32 root key can be used to derive keychains. As a consequence, a backup of just the BIP 32 root key is sufficient to include all keys derived from it. BIP 32 does not have a human-friendly serialization of the BIP 32 root key (or BIP 32 extended keys in general), which makes paper backups or manually restoring the key more error-prone. BIP 39 was designed to solve this problem, but rather than serialize the BIP 32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP 39 seed, which can be turned into the BIP 32 root key. Saving the BIP 39 mnemonic is enough to reconstruct the entire BIP 32 keychain, but a BIP 32 root key cannot be reversed back to the BIP 39 mnemonic.
Most wallets implement BIP 39, so on initialization or restoration, the user must interact with a BIP 39 mnemonic. Most wallets do not support BIP 32 extended private keys, so each wallet must either share the same BIP 39 mnemonic, or have a separate BIP 39 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 BIP 32 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 BIP 32 key, or private key. We can use BIP 32 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 BIP 44-like categorization to ensure uniform derivation according to the target application type.
We assume a single BIP 32 master root key. This specification is not concerned with how this was derived (e.g. directly or via a mnemonic scheme such as BIP 39).
For each application that requires its own wallet, a unique private
key is derived from the BIP 32 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:
OUTPUT:
INPUT:
OUTPUT
BIP 85-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 BIP 85's HMAC output. BIP 85-DRNG-SHAKE256 uses BIP 85 to seed a SHAKE256 stream (from the SHA-3 standard). The input must be exactly 64 bytes long (from the BIP 85 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
OUTPUT
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 BIP 39 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' |
BIP 39 English 12 word mnemonic seed
128 bits of entropy as input to BIP 39 to derive 12 word mnemonic
INPUT:
OUTPUT:
BIP 39 English 18 word mnemonic seed
196 bits of entropy as input to BIP 39 to derive 18 word mnemonic
INPUT:
OUTPUT:
Derives 24 word BIP 39 mnemonic seed
256 bits of entropy as input to BIP 39 to derive 24 word mnemonic
INPUT:
OUTPUT:
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:
OUTPUT
Application number: 32'
Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and the second 32 bytes 3 are the private key for the BIP 32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
Warning : The above order reverses the order of BIP 32, 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:
OUTPUT
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:
OUTPUT
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:
OUTPUT
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 Base64 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:
OUTPUT
Application number: 828365'
The derivation path format is:
m/83696968'/828365'/{key_bits}'/{key_index}'
The RSA key generator should use BIP 85-DRNG as the input RNG function.
Keys allocated for RSA-GPG purposes use the following scheme:
- Main key
m/83696968'/828365'/{key_bits}'/{key_index}'
- Sub keys:
m/83696968'/828365'/{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
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:05:05'
UTC)
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.
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 BIP 85 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:
OUTPUT
This specification is not backwards compatible with any other existing specification.
This specification relies on BIP 32 but is agnostic to how the BIP 32 root key is derived. As such, this standard is able to derive wallets with initialization schemes like BIP 39 or Electrum wallet style mnemonics.
BIP 32, BIP 39
Many thanks to Peter Gray and Christopher Allen for their input, and to Peter for suggesting extra application use cases.
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 BIP 32:
↩︎In case parse 256 (I L ) ≥ n or k i = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2 127 .)