diff options
Diffstat (limited to 'bip-0085.mediawiki')
| -rw-r--r-- | bip-0085.mediawiki | 18 |
1 files changed, 3 insertions, 15 deletions
diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 0627755..633210c 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -96,18 +96,6 @@ OUTPUT * Python library implementation: [https://github.com/ethankosakovsky/bip85] * JavaScript library implementation: [https://github.com/hoganri/bip85-js] -===Other Implementations=== - -* JavaScript library implementation: [https://github.com/hoganri/bip85-js] - -* Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39] - -* Ian Coleman's Mnemonic Code Converter: [https://github.com/iancoleman/bip39] and [https://iancoleman.io/bip39/] - -* AirGap Vault: [https://github.com/airgap-it/airgap-vault/commit/d64332fc2f332be622a1229acb27f621e23774d6] - -* btc_hd_wallet: [https://github.com/scgbckbone/btc-hd-wallet] - ==Applications== The Application number defines how entropy will be used post processing. Some basic examples follow: @@ -327,7 +315,7 @@ Entropy = log2(R ** L)<br> |- | 30 || 192.0 |- -| 20 || 512.0 +| 80 || 512.0 |} INPUT: @@ -364,7 +352,7 @@ The resulting RSA key can be used to create a GPG key where the creation date MU Note on GPG key capabilities on smartcard/hardware devices: -GPG capable smart-cards SHOULD be 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. +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. @@ -376,7 +364,7 @@ This specification relies on BIP32 but is agnostic to how the BIP32 root key is ==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 compromized. 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 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== |