From 3728f8e12f63b4f7d8aef8fc2aaf63d5c5a54a42 Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Mon, 15 Sep 2025 15:16:18 -0400 Subject: [PATCH 01/13] 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/13] 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/13] 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/13] 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/13] 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/13] 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/13] 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/13] 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/13] 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/13] 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 From 34e8931978096e943bb2258f081a1f64614221d0 Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Sat, 4 Apr 2026 18:55:43 -0400 Subject: [PATCH 11/13] Apply suggestion from @akarve Co-authored-by: Aneesh Karve --- bip-0085.mediawiki | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index ae5ec6981f..3fdbb37068 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -418,7 +418,9 @@ The valid key_bits values and corresponding algorithms for each key_type are: 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. +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 From 9dd0eee916487fb954cf886f14e99bc3c175b904 Mon Sep 17 00:00:00 2001 From: 3rd Iteration Date: Wed, 17 Jun 2026 11:20:20 -0400 Subject: [PATCH 12/13] Split GPG into RSA (828365') + ECC (828366') apps; preserve backward-compatible RSA paths (#2) Co-authored-by: 3rdIteration --- bip-0085.mediawiki | 268 ++++++++++++++++++--------------------------- 1 file changed, 108 insertions(+), 160 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 3fdbb37068..7baa24bfcb 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -358,134 +358,115 @@ OUTPUT * DERIVED ENTROPY=f7cfe56f63dca2490f65fcbf9ee63dcd85d18f751b6b5e1c1b8733af6459c904a75e82b4a22efff9b9e69de2144b293aa8714319a054b6cb55826a8e51425209 * DERIVED PWD=_s`{TW89)i4` -===GPG Keys=== +===RSA=== Application number: 828365' -The derivation path format is: m/83696968'/828365'/{key_type}'/{key_bits}'/{key_index}' +The derivation path format is: m/83696968'/828365'/{key_bits}'/{key_index}' -All path components are hardened (denoted by '). The key_type values are plain integers: +The RSA key generator should use BIP85-DRNG as the input RNG function. -{| -!OpenPGP Key Type -!key_type -|- -| RSA -| 0 -|- -| ECC(Curve25519) -| 1 -|- -| ECC(secp256k1) -| 2 +===RSA GPG=== + +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)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. 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. + +====Test vectors==== + +INPUT: +* MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb + +{| class="wikitable" +! Key Bits +! Path +! Entropy (hex) +! Fingerprint |- -| ECC(NIST) -| 3 +| 2048 +| m/83696968'/828365'/2048'/0' +| e3ff02b1f0b934357cc0952225bb0e90081005b0cc992c5ed22f6fb8e9c628a3a0f138f9324e33ed4ba7250e43dd66d725a4e4c683dcf5a3b4015b82bcf71934 +| 08E6 99DF 4693 0585 D4AB 8A16 BF0C 839D 2367 6360 |- -| ECC(Brainpool) -| 4 +| 3072 +| m/83696968'/828365'/3072'/0' +| 9bd8cb61fea01892ffd981b4da7aae22f32c9641e49c48104682e249a98f7911ed55035a52e085938291d64e34537e9cc0b730f42ae9183b5ddaac33a55764ea +| B242 63BC 646F 34EE 10CC F75A 962E 123B 8CB8 654C |- +| 4096 +| m/83696968'/828365'/4096'/0' +| 12a499947a142ee3ede9c0960061383f2564b5cc569327d0dd22f7887094676f2e5d5785cd4eb683990d12209ebf6f39a5c1b5e217ea66710260e99fbe4b2be3 +| 9148 089D 2080 DF38 4C05 726E A26B B714 0A1B 13FF |} -The valid key_bits values and corresponding algorithms for each key_type are: +===ECC GPG Keys=== -{| -!key_type -!key_bits -!OpenPGP Algorithm / Curve +Application number: 828366' + +The derivation path format is: m/83696968'/828366'/{key_type}'/{key_bits}'/{key_index}' + +All path components are hardened (denoted by '). The key_type values and their corresponding curves are: + +{| class="wikitable" +! key_type +! OpenPGP Key Type +! key_bits +! Algorithm / Curve |- -| 0 (RSA) -| 1024, 2048, 4096 -| RSA +| 0 +| ECC(Brainpool) +| 256, 384, 512 +| brainpoolP256r1, brainpoolP384r1, brainpoolP512r1 respectively |- -| 1 (Curve25519) +| 1 +| ECC(Curve25519) | 256 | Ed25519 (certify/sign/auth), X25519 (encrypt) |- -| 2 (secp256k1) +| 2 +| ECC(secp256k1) | 256 | secp256k1 |- -| 3 (NIST) +| 3 +| ECC(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)` +BIP85-DRNG MUST be used as the input RNG function when key generation requires more than 64 bytes of random input. This applies to NIST P-521 (key_type=3, key_bits=521). All other supported ECC key types use the 64-byte HMAC output directly. -4. If `scalar == 0` or `scalar >= order`, apply the fallback: - `scalar = (scalar % (order - 1)) + 1` +ECC Scalar Derivation -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 except NIST P-521), the private scalar is derived from the first baselen bytes of the 64-byte HMAC-SHA512 entropy output, interpreted as a big-endian unsigned integer. If the resulting scalar is zero or greater than the curve order, apply the fallback: scalar = (scalar % (order - 1)) + 1. -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. +For NIST P-521 (base length 66 bytes), read 66 bytes from BIP85-DRNG-SHAKE256 seeded with the 64-byte HMAC output. Interpret as a big-endian unsigned integer and apply the same fallback if the scalar is zero or greater than the curve order. 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: +The primary/subkey scheme follows the same structure as [[#RSA GPG|RSA GPG]], using this application's derivation path: -* 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 - -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. +* Primary key: m/83696968'/828366'/{key_type}'/{key_bits}'/{key_index}' +* Sub keys: m/83696968'/828366'/{key_type}'/{key_bits}'/{key_index}'/{sub_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) @@ -494,22 +475,17 @@ For key_type 1 (Curve25519), the OpenPGP algorithm used depends on the key capab 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:15:05' UTC)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. 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). +See [[#RSA GPG|RSA GPG]] for the fixed creation date requirement and faketime guidance. 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. +See [[#RSA GPG|RSA GPG]] for smart-card slot loading guidance. ====Test vectors==== INPUT: * MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb -'''Key Type 0 — RSA''' +'''Key Type 0 — Brainpool (P-256, P-384, P-512)''' {| class="wikitable" ! Key Bits @@ -517,20 +493,20 @@ INPUT: ! Entropy (hex) ! Fingerprint |- -| 1024 -| m/83696968'/828365'/0'/1024'/0' -| 2b9380df43421f46b5c38e13ea80612ff53488bc5d272e86d493ee1eecf738bb7b50e4978b7352f95772f1211483b0e6bba86c544a946b10d76ed493b8c2e01f -| 874A 3964 4ED0 255D EEC1 8E0E 1E63 8864 9672 CF70 +| 256 +| m/83696968'/828366'/0'/256'/0' +| 99f74d7072aac4946462a3ab99fd6b55f509ab321321f27813dee383a98aa541bd4cc82136d56b4d67eefe32919243b077eed26874218f5df567ac07568756bf +| 1B33 A17E F8CE 55BC 767D 6373 A10D B6B0 4953 6F87 |- -| 2048 -| m/83696968'/828365'/0'/2048'/0' -| 98c4fb6d76f203e8828bdfd28416edca7a83a9b203901f7ad31f056cda8b3c25b19e5fd2aa642ca0abb9ed8bebf3d141af6c76b28a19eba624bdc6f8a76ce138 -| 9987 9DF6 D21E 34C8 A086 A4BD 8B44 8E5B C298 294A +| 384 +| m/83696968'/828366'/0'/384'/0' +| 6ef5e7ea71ca14fe1a89f741fbaa4bedf8f59584c6fa9372e1b0c2e4516d7949e61a2311e9bfc9dd5372221d7192f8a2957c1571f96be2f774cc5fee8adcd911 +| 38D5 8529 39EE 735F 8B79 CB6B 2173 A1CB D667 7AA6 |- -| 4096 -| m/83696968'/828365'/0'/4096'/0' -| 2d2ef3335dc51e7a0642bfe86fba0bb4e8401b703d8d679bb1a31d75f8a81f1fd52b20b2eae50ef6e0378b8755f4f0426c68b54f11edc0c848e017e81bb2ad87 -| 24C2 5A48 383E 1175 4687 1767 D9A0 5CA6 4F2F 6A85 +| 512 +| m/83696968'/828366'/0'/512'/0' +| af5ef50a4f3277f4f57e714cba3caae61ca19bc2a4bfeba4b6726ef319a67427f317d91ed72948abc6f96a77008acad7ee6b3585e6b0beaef76a2ab9f52f75f1 +| 37F6 3BBF 5C00 A340 E1AD D2E9 A09B DE42 3DB9 D62C |} '''Key Type 1 — Curve25519''' @@ -542,9 +518,9 @@ INPUT: ! Fingerprint |- | 256 -| m/83696968'/828365'/1'/256'/0' -| 0e90b553528cd97a033c282f54cf72c1020adaec205d5c0e57e9f2556d06fea683618e4be8f91e7e059647f9d6373eb8b5f535e7ba4097cfb3e93c4957843614 -| E81D F237 1408 2AD2 747E 732B 9A24 C95B D8C2 A55E +| m/83696968'/828366'/1'/256'/0' +| 0321683e4d481bb6b5bac0585dbb06689827b9d6db3c530b5f6c31e20c52e4447059dbf3076cbd982cb90e2054f098a5cad5496528a5a7542b09b5b3e5394dbb +| 6D2B 602A A788 9B97 FDCF 116B 926E 9A8C AA2D 1BEA |} '''Key Type 2 — secp256k1''' @@ -556,9 +532,9 @@ INPUT: ! Fingerprint |- | 256 -| m/83696968'/828365'/2'/256'/0' -| f3bb8b3d6b81fbd202c34b59ce7e97c83969e9b5733b936de16c51119c7a48239ddf66729ef5e4df97ea39471f05a89f070869b3f9d72d69f3ae8bd7ee4fb6b3 -| 6D99 D348 74C6 E88F F30C 758A 46F7 E1AF 05FC 3414 +| m/83696968'/828366'/2'/256'/0' +| 9ba495532c0251a4a8bd0986c0bff07a413a9204881603ace0df8474f3af7e19e622cf1b4da077d26ecfc972f2b84069b50a4c11680fecc4afb2af8b74c68913 +| 308A 8CB4 B297 8856 50EA 2E91 0E47 B58F F734 3035 |} '''Key Type 3 — NIST (P-256, P-384, P-521)''' @@ -570,43 +546,19 @@ INPUT: ! Fingerprint |- | 256 -| m/83696968'/828365'/3'/256'/0' -| f52586f58521916b9f28b0058be86effcde82e571eabada9e3f63c6f67752ff12a4d3bf2fffe0f147164945691605a58f28f6bded869c38b3db9f0e577d83728 -| 2FE6 D862 FF2A BF1C 1FAA 2753 B681 BEF5 B5D5 74C4 +| m/83696968'/828366'/3'/256'/0' +| 60e76b9f4a447d4aa4f025c488b598c773b6e0b668e2f7b71bdafb62a0fb7303950b05c2834a8d62d155239e9f78ef26c36e23ab4f4ea894aaa685ef41b89d38 +| 451D 829B 1EAD 7DB4 5048 C874 73E1 813D ACE6 70D6 |- | 384 -| m/83696968'/828365'/3'/384'/0' -| 830005ea400f7a03c27aa06a9728fe311c9a48dc31bd417f07b96c69edc73d25baa00d04b9dbbe6f42539b06d9ef1ba62ed73d4a3a992302aae09e17e0d9f42f -| 5668 7C3C 9072 19B2 9FCE 39CF 95F0 16F9 B150 B8A1 +| m/83696968'/828366'/3'/384'/0' +| 0ca78fc4de4da1969056cb3b2f84006b05b14af0728e80c6b64c0f377b0fe5bbbc948fc22c4e4159cef87bafa9941933ce7c06b0fd57a144ae03fd704f403fa6 +| A28C 41C5 66A6 D4D8 C489 FA15 DEB0 0F3E 48AD 2B3D |- | 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 +| m/83696968'/828366'/3'/521'/0' +| ae8a24dfe0384325ab79ed862516c7cb364b1380743fe0ee68fad8e2d56619964166197f2a412121976b24a1d8ad8fcf6168fcb1addb882e7ca84e93b47dec43 +| 696B 9061 E301 A9CD 542E 6B95 4F3B D64B 23FA 94DA |} ===DICE=== @@ -662,15 +614,11 @@ BIP32, BIP39 ==Changelog== -===3.0.0 (2026-02-27)=== +===2.1.0 (TBD)=== ====Added==== -* 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==== - -* 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) +* ECC GPG Keys application 828366' for deterministic derivation of OpenPGP ECC keys: Curve25519/Ed25519/X25519, secp256k1, NIST P-256/P-384/P-521, Brainpool P-256/P-384/P-512 ===2.0.0 (2025-09-19)=== ====Fixed==== From 2668c65eced41d97aa9a5e68fb96402ac7e0782a Mon Sep 17 00:00:00 2001 From: 3rdIteration Date: Wed, 17 Jun 2026 15:30:18 +0000 Subject: [PATCH 13/13] Fix timestamp in Note on timestamps section (unix -> UNIX, 18:05:05 -> 18:15:05) --- bip-0085.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 7baa24bfcb..f5913adc60 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -380,7 +380,7 @@ Keys allocated for RSA-GPG purposes use the following scheme: 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)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. 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). +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)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. 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: