From 3728f8e12f63b4f7d8aef8fc2aaf63d5c5a54a42 Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Mon, 15 Sep 2025 15:16:18 -0400 Subject: [PATCH 01/10] Expand BIP85 to include ECC key types --- bip-0085.mediawiki | 42 ++++++++++++++++++++++++++++++++---------- 1 file changed, 32 insertions(+), 10 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 174ba816b2..a51a1c36e9 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -360,36 +360,58 @@ OUTPUT * DERIVED ENTROPY=f7cfe56f63dca2490f65fcbf9ee63dcd85d18f751b6b5e1c1b8733af6459c904a75e82b4a22efff9b9e69de2144b293aa8714319a054b6cb55826a8e51425209 * DERIVED PWD=_s`{TW89)i4` -===RSA=== +===GPG Keys=== -Application number: 828365' +Application number is dependant on the key type. -The derivation path format is: m/83696968'/828365'/{key_bits}'/{key_index}' +{| +!OpenGPG Key Type +!Application Number +|- +| RSA +| 828365' +|- +| ECC(Curve25519) +| 828366' +|- +| ECC(secp256k1) +| 828367' +|- +| ECC(NIST) +| 828368' +|- +| ECC(Brainpool) +| 828369' +|- +|} -The RSA key generator should use BIP85-DRNG as the input RNG function. +The RSA key generator should use BIP85-DRNG as the input RNG function. Likewise, any ECC key types over 256bit should use BIP85-DRNG. -===RSA GPG=== +====Primary Keys and Subkeys==== -Keys allocated for RSA-GPG purposes use the following scheme: +Keys allocated for 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}' + - Primary key m/83696968'/{key_type}'/{key_bits}'/{key_index}' + - Sub keys: m/83696968'/{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 -Note on timestamps: +Additional subkeys can be added to a primary key, including keys of a different key type, following the role pattern defined above, but the key_index MUST be incremented with each subkey. + +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: +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. + ===DICE=== Application number: 89101' From 56a8de8209722f30c66fe8a3f3668321cc016894 Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Mon, 6 Oct 2025 14:28:24 -0400 Subject: [PATCH 02/10] Update bip-0085.mediawiki Co-authored-by: Jon Atack --- bip-0085.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index a51a1c36e9..5b2e343614 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -385,7 +385,7 @@ Application number is dependant on the key type. |- |} -The RSA key generator should use BIP85-DRNG as the input RNG function. Likewise, any ECC key types over 256bit should use BIP85-DRNG. +The RSA key generator should use BIP85-DRNG as the input RNG function. Likewise, any ECC key types over 256 bits should use BIP85-DRNG. ====Primary Keys and Subkeys==== From 31eea92063a7d6a1ea8054d8d9a29263ee218c2d Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Mon, 6 Oct 2025 14:39:10 -0400 Subject: [PATCH 03/10] Update bip-0085.mediawiki Co-authored-by: Aneesh Karve --- bip-0085.mediawiki | 1 - 1 file changed, 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 5b2e343614..914d8a2c68 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -411,7 +411,6 @@ GPG capable smart-cards SHOULD be loaded as follows: The encryption slot SHOULD 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. - ===DICE=== Application number: 89101' From 94796129c7ffafae2fe9c461a8764502fca12ab7 Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Fri, 27 Feb 2026 22:24:16 -0500 Subject: [PATCH 04/10] Update bip-0085.mediawiki --- bip-0085.mediawiki | 47 ++++++++++++++++++++++++++++++---------------- 1 file changed, 31 insertions(+), 16 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 914d8a2c68..3a1fb7570d 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -362,26 +362,30 @@ OUTPUT ===GPG Keys=== -Application number is dependant on the key type. +Application number: 828365' + +The derivation path format is: m/83696968'/828365'/{key_type}'/{key_bits}'/{key_index}' + +The key_type values are defined as follows: {| -!OpenGPG Key Type -!Application Number +!OpenPGP Key Type +!key_type value |- | RSA -| 828365' +| 0' |- | ECC(Curve25519) -| 828366' +| 1' |- | ECC(secp256k1) -| 828367' +| 2' |- | ECC(NIST) -| 828368' +| 3' |- | ECC(Brainpool) -| 828369' +| 4' |- |} @@ -389,17 +393,18 @@ The RSA key generator should use BIP85-DRNG as the input RNG function. Likewise, ====Primary Keys and Subkeys==== -Keys allocated for GPG purposes use the following scheme: +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. - - Primary key m/83696968'/{key_type}'/{key_bits}'/{key_index}' - - Sub keys: m/83696968'/{key_type}'/{key_bits}'/{key_index}'/{sub_key}' +Keys allocated for GPG purposes use the following scheme: - - 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 +* 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 -Additional subkeys can be added to a primary key, including keys of a different key type, following the role pattern defined above, but the key_index MUST be incremented with each subkey. +All subkeys SHOULD use the same key_type as the primary key. Mixed key types across primary and subkeys are out of scope for this specification. Additional subkeys may be added following the same role pattern, incrementing the sub_key index. Note on timestamps: @@ -464,6 +469,16 @@ BIP32, BIP39 ==Changelog== +===2.0.0=== + +====Added==== + +* ECC GPG key types for OpenPGP: Curve25519 (key_type 1'), secp256k1 (key_type 2'), NIST (key_type 3'), Brainpool (key_type 4') + +====Changed==== + +* GPG key section restructured to use a single application number (828365') with key_type as a path level component, replacing separate per-type application numbers + ===1.3.0 (2024-10-22)=== ====Added==== From 729f412f1d1920a0557ddca6852fa061a29ea466 Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Fri, 27 Feb 2026 22:28:23 -0500 Subject: [PATCH 05/10] Update bip-0085.mediawiki --- bip-0085.mediawiki | 1 + 1 file changed, 1 insertion(+) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 3a1fb7570d..113bdd2313 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -478,6 +478,7 @@ BIP32, BIP39 ====Changed==== * GPG key section restructured to use a single application number (828365') with key_type as a path level component, replacing separate per-type application numbers +* RSA GPG derivation path changed from m/83696968'/828365'/{key_bits}'/{key_index}' to m/83696968'/828365'/0'/{key_bits}'/{key_index}' (breaking change) ===1.3.0 (2024-10-22)=== From 86a64f1fddc1e723750d5df44671c73a799b0964 Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Fri, 27 Feb 2026 22:40:15 -0500 Subject: [PATCH 06/10] incorporate improment suggestions --- bip-0085.mediawiki | 62 ++++++++++++++++++++++++++++++++++++---------- 1 file changed, 49 insertions(+), 13 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 113bdd2313..f72cca0324 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -366,30 +366,61 @@ Application number: 828365' The derivation path format is: m/83696968'/828365'/{key_type}'/{key_bits}'/{key_index}' -The key_type values are defined as follows: +All path components are hardened (denoted by '). The key_type values are plain integers: {| !OpenPGP Key Type -!key_type value +!key_type |- | RSA -| 0' +| 0 |- | ECC(Curve25519) -| 1' +| 1 |- | ECC(secp256k1) -| 2' +| 2 |- | ECC(NIST) -| 3' +| 3 |- | ECC(Brainpool) -| 4' +| 4 |- |} -The RSA key generator should use BIP85-DRNG as the input RNG function. Likewise, any ECC key types over 256 bits should use BIP85-DRNG. +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. ====Primary Keys and Subkeys==== @@ -406,9 +437,15 @@ Keys allocated for GPG purposes use the following scheme: All subkeys SHOULD use the same key_type as the primary key. Mixed key types across primary and subkeys are out of scope for this specification. Additional subkeys may be added following the same role pattern, incrementing the sub_key index. +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) + +This means the primary key and sub_keys 1 (auth) and 2 (sign) under key_type 1 produce Ed25519 keys, while sub_key 0 (encrypt) produces an X25519 key. The same derived entropy bytes are interpreted according to the required algorithm. + 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). +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: @@ -469,16 +506,15 @@ BIP32, BIP39 ==Changelog== -===2.0.0=== +===2.0.0 (2026-02-27)=== ====Added==== -* ECC GPG key types for OpenPGP: Curve25519 (key_type 1'), secp256k1 (key_type 2'), NIST (key_type 3'), Brainpool (key_type 4') +* 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 ====Changed==== -* GPG key section restructured to use a single application number (828365') with key_type as a path level component, replacing separate per-type application numbers -* RSA GPG derivation path changed from m/83696968'/828365'/{key_bits}'/{key_index}' to m/83696968'/828365'/0'/{key_bits}'/{key_index}' (breaking change) +* RSA application 828365' (introduced in 1.1.0) extended with a key_type path component (key_type=0 for RSA) to unify all OpenPGP key types under a single application number; RSA derivation path changed from m/83696968'/828365'/{key_bits}'/{key_index}' to m/83696968'/828365'/0'/{key_bits}'/{key_index}' (breaking change for existing RSA implementations) ===1.3.0 (2024-10-22)=== From 04995e6150e5f20622a6829d191e7b7dd30879d8 Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Sat, 28 Feb 2026 16:05:50 -0500 Subject: [PATCH 07/10] Fix typos --- bip-0085.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index f72cca0324..f5c370179d 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -202,7 +202,7 @@ OUTPUT: ====18 English words==== BIP39 English 18 word mnemonic seed -196 bits of entropy as input to BIP39 to derive 18 word mnemonic +192 bits of entropy as input to BIP39 to derive 18 word mnemonic INPUT: * MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb @@ -506,7 +506,7 @@ BIP32, BIP39 ==Changelog== -===2.0.0 (2026-02-27)=== +===3.0.0 (2026-02-27)=== ====Added==== From 00a7583b1582e65e8eca6d84b9b86cf006a19216 Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Sat, 7 Mar 2026 23:11:36 -0500 Subject: [PATCH 08/10] Enhance ECC and RSA key generation guidelines Expanded the section on ECC scalar derivation and RSA key generation, detailing the use of BIP85-DRNG and compliance requirements. --- bip-0085.mediawiki | 52 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 51 insertions(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index f5c370179d..d4e0264291 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -422,7 +422,57 @@ For key_types with a fixed curve (1 and 2), key_bits MUST be 256. Any other valu 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. -====Primary Keys and Subkeys==== +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. From b7756c99758ff9488ca3c59fa697b96b806e4f42 Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Mon, 9 Mar 2026 09:37:04 -0400 Subject: [PATCH 09/10] Add test vectors for key types in bip-0085 Added test vectors for various key types including RSA, Curve25519, secp256k1, NIST, and Brainpool. --- bip-0085.mediawiki | 105 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index d4e0264291..69038d4bee 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -503,6 +503,111 @@ GPG capable smart-cards SHOULD be loaded as follows: The encryption slot SHOULD 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. +===Test vectors=== + +INPUT: +* MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb + +'''Key Type 0 — RSA''' + +{| class="wikitable" +! 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''' + +{| class="wikitable" +! 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''' + +{| class="wikitable" +! 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)''' + +{| class="wikitable" +! 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)''' + +{| class="wikitable" +! 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 +|} + ===DICE=== Application number: 89101' From c44de4611b06858c50c2afda99629f5a4b6abb6b Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Mon, 9 Mar 2026 09:38:12 -0400 Subject: [PATCH 10/10] Fix heading format for Test vectors section --- bip-0085.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 69038d4bee..a824759265 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -503,7 +503,7 @@ GPG capable smart-cards SHOULD be loaded as follows: The encryption slot SHOULD 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. -===Test vectors=== +====Test vectors==== INPUT: * MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb