Expand BIP85 to include ECC key types

3rdIteration commented at 7:28 pm on September 15, 2025: none

So I’m doing some work on extending BIP85 functionality on SeedSigner to include GPG key generation, file verification, encrypted messaging, etc, but the resource limitation on low power devices like the Raspberry Pi really makes RSA keys quite painful to use at any useful bit length. (RSA3072 takes 15-20 minutes for a primary key + 3 subs)

Basically I’m suggesting an expansion of the current functionality to add support for some common ECC curves and provide a bit of a process for future curves to be added in a way that doesn’t break existing implementations. (The simplest solution is to just use ECC with key length on the existing RSA derivation, but that doesn’t seem very consistent with how BIP85 works for other similar use cases where the derivation path should tell you everything you need to know about the output data/entropy/usage)

While it would have been nice to have a separate derivation level for key_type, that ship has probably sailed, so rather than add that, I am just suggesting a different applicationID for each key type. (Similar to how variations are handled with the existing password application type)

While I’m at it, I’m also suggesting some information about how additional and mixed key types should be handled.

Anyway, just keen to get some input on a way forward, can add some additional test vectors and stuff once others have provided some input about a preferred way forward.

Expand BIP85 to include ECC key types 3728f8e12f

odudex commented at 8:00 pm on September 15, 2025: none

The inclusion of GPG ECC key specifications also interests me. I’m developing tools to derive secp256k1 GPG key material on Krux My implementation differs slightly, as it relies on a PC-based coordinator app to handle metadata and prepare files for GPG signing.

Although the approach is different from @3rdIteration’s, he confirmed that the results are compatible, currently using the RSA derivation path in preliminary tests.

My long-term goal is to also support the creation of encryption subkeys.

Having two independent projects producing different, yet compatible implementations creates an excellent opportunity to include ECC keys in the BIP85 specifications.

3rdIteration commented at 8:06 pm on September 15, 2025: none

I didn’t include it in the body of the wiki, but I would suggest that basically this approach would mean that the 8283 prefix for applications types is reserved for GPG related keys

jonatack added the label Proposed BIP modification on Sep 17, 2025

jonatack added the label Pending acceptance on Sep 17, 2025

in bip-0085.mediawiki:388 in 3728f8e12f

387+| 828369'
388+|-
389+|}
390 
391-The RSA key generator should use BIP85-DRNG as the input RNG function.
392+The RSA key generator should use BIP85-DRNG as the input RNG function. Likewise, any ECC key types over 256bit should use BIP85-DRNG.

jonatack commented at 3:56 pm on September 17, 2025:

0The RSA key generator should use BIP85-DRNG as the input RNG function. Likewise, any ECC key types over 256 bits should use BIP85-DRNG.

in bip-0085.mediawiki:402 in 3728f8e12f outdated

406     - sub_key <code>0'</code> is used as the ENCRYPTION key
407     - sub_key <code>1'</code> is used as the AUTHENTICATION key
408     - sub_key <code>2'</code> is usually used as SIGNATURE key
409 
410-Note on timestamps:
411+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.

jonatack commented at 4:01 pm on September 17, 2025:

Could this change break anything?

3rdIteration commented at 5:23 pm on September 17, 2025:

Could this change break anything?

It doesn’t break the existing RSA implementations, but does add the possibility of having something like an RSA primary key and non-RSA subkeys. (Though the overall RSA fingerprint would remain the same) There is actually already ambiguity in BIP85 as to whether the subkeys should/must have the same key bits as the primary key. (Even if it is a general convention that they align)

The use-case to consider here is basically that someone might want to revoke a subkey(s) (or have some expire) and create some additional subkeys that they can continue using while preserving the original primary key. (Which is normal in the context of GPG)

The question of whether mixing key types should be allowed is a separate matter, but the use-case for this is basically scenarios where someone may want a strong and long-lived primary key that for their identity, but use different keys for the actual signing and stuff. (Whether due to limitations on smartcards, etc) For example, someone may have an ED25119 primary key and have subkeys use something like P256 or RSA subkeys for compatibility reasons.

akarve commented at 1:51 am on October 6, 2025:

As for mixing types I would discourage that unless there’s a really good reason. For one thing are we nesting derivation paths at that point? A worked example of mixed subkeys would help.

akarve commented at 2:20 am on October 6, 2025:

the use-case for this is basically scenarios where someone may want a strong and long-lived primary key that for their identity, but use different keys for the actual signing and stuff. (Whether due to limitations on smartcards, etc) For example, someone may have an ED25119 primary key and have subkeys use something like P256 or RSA subkeys for compatibility reasons.

reasonable enough. at that point why not turtles all the way down, e.g. the following or something like it?

0{same_app_number_for_all}/
1{key_type}/{key_bits}/key_index}/
2{key_type}/{key_bits}/sub_key_index}/
3...

3rdIteration commented at 6:32 pm on October 6, 2025:

the use-case for this is basically scenarios where someone may want a strong and long-lived primary key that for their identity, but use different keys for the actual signing and stuff. (Whether due to limitations on smartcards, etc) For example, someone may have an ED25119 primary key and have subkeys use something like P256 or RSA subkeys for compatibility reasons.

reasonable enough. at that point why not turtles all the way down, e.g. the following or something like it?
0{same_app_number_for_all}/
1{key_type}/{key_bits}/key_index}/
2{key_type}/{key_bits}/sub_key_index}/
3...

I think that would be a better approach overall, to have an app number to signify GPG keys generally and then an additional level of derivation for key type, but this would break compatibility with existing RSA implementations. (Even though it doesn’t seem to me that there are any in the wild) The reality is that new key types will likely continue to be added to GPG, so the ability to add more in a neat way would be better long term. (With the rational for different applications for each key type being related to respecting the status of this BIP as ‘Final’)

3rdIteration commented at 6:38 pm on October 6, 2025:

As for mixing types I would discourage that unless there’s a really good reason. For one thing are we nesting derivation paths at that point? A worked example of mixed subkeys would help.

Even with that example, it’s not really an issue to just assert that mixed key types are beyond the scope of the spec. (As most people will just use the same key type for everything)

jonatack commented at 4:05 pm on September 17, 2025: member

Pinging @akarve and @scgbckbone for feedback, BIP85 is in use and in Final status (https://github.com/bitcoin/bips/pull/1676), so no potentially breaking changes may be introduced.

in bip-0085.mediawiki:365 in 3728f8e12f outdated

359@@ -360,36 +360,58 @@ OUTPUT
360 * DERIVED ENTROPY=f7cfe56f63dca2490f65fcbf9ee63dcd85d18f751b6b5e1c1b8733af6459c904a75e82b4a22efff9b9e69de2144b293aa8714319a054b6cb55826a8e51425209
361 * DERIVED PWD=_s`{TW89)i4`
362 
363-===RSA===
364+===GPG Keys===
365 
366-Application number: 828365'
367+Application number is dependant on the key type.

akarve commented at 1:47 am on October 6, 2025:

I would recommend a single application number and then extend the path for different key types. That’s more consistent with the rest of BIP85:

0{same_app_number_for_all}/{key_type}/{key_bits}/{key_index}

3rdIteration commented at 6:36 pm on October 6, 2025:

This would be the neatest solution

in bip-0085.mediawiki:394 in 3728f8e12f outdated

397-Keys allocated for RSA-GPG purposes use the following scheme:
398+Keys allocated for GPG purposes use the following scheme:
399 
400- - Main key <code>m/83696968'/828365'/{key_bits}'/{key_index}'</code>
401- - Sub keys:  <code>m/83696968'/828365'/{key_bits}'/{key_index}'/{sub_key}'</code>
402+ - Primary key <code>m/83696968'/{key_type}'/{key_bits}'/{key_index}'</code>

akarve commented at 1:48 am on October 6, 2025:

Here and elsewhere these list nested code blocks don’t render as expected (… > View file)

akarve commented at 1:50 am on October 6, 2025:

In the description please motivate the need and intent of sub keys. It’s not immediately obvious why this is needed above and beyond the standard key index.

3rdIteration commented at 6:36 pm on October 6, 2025:

It’s mostly about trying to follow the process elsewhere in BIP85 where a given derivation path will always map to a certain use case 1:1.

One solution to all of this is to basically just have BIP85 use the same derivation path for both primary keys and subkeys, regardless of the key algo being used.

akarve commented at 1:53 am on October 6, 2025: contributor

@3rdIteration howdy, feedback provided. please also do a patch entry to the changelog.

in bip-0085.mediawiki:363 in 3728f8e12f outdated

359@@ -360,36 +360,58 @@ OUTPUT
360 * DERIVED ENTROPY=f7cfe56f63dca2490f65fcbf9ee63dcd85d18f751b6b5e1c1b8733af6459c904a75e82b4a22efff9b9e69de2144b293aa8714319a054b6cb55826a8e51425209
361 * DERIVED PWD=_s`{TW89)i4`
362 
363-===RSA===
364+===GPG Keys===

akarve commented at 1:57 am on October 6, 2025:

Definitely need test vectors and expected outputs for all applications and sub applications. I can also add it to the reference implementation but won’t be able to get to that right away. PRs welcome. https://github.com/akarve/bipsea

3rdIteration commented at 6:40 pm on October 6, 2025:

I’m happy to work up some test vectors and a reference implementation once there is some agreement on a general direction :)

Update bip-0085.mediawiki

Co-authored-by: Jon Atack <jon@atack.com>

56a8de8209

Update bip-0085.mediawiki

Co-authored-by: Aneesh Karve <akarve@users.noreply.github.com>

31eea92063

Expand BIP85 to include ECC key types #1968