Expand BIP85 to include ECC key types

[3rdIteration]

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.

[odudex]

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]

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]

Pinging @akarve and @scgbckbone for feedback, BIP85 is in use and in Final status (#1676), so no potentially breaking changes may be introduced.

[akarve]

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:

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

[3rdIteration]

This would be the neatest solution

[akarve]

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

[akarve]

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]

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]

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]

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?

{same_app_number_for_all}/
{key_type}/{key_bits}/key_index}/
{key_type}/{key_bits}/sub_key_index}/
...

[3rdIteration]

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?

{same_app_number_for_all}/
{key_type}/{key_bits}/key_index}/
{key_type}/{key_bits}/sub_key_index}/
...

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]

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)

[akarve]

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

[akarve]

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]

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

[jonatack]

Hi @3rdIteration, mind addressing the remaining feedback here?

Edit: per #1967 (comment), when in doubt might be most prudent to go with option c?

[3rdIteration]

Are there any that aren't addressed? (In terms of the other PR, I agree that option C makes the most sense)

It also gives more scope to make some changes that make this neater overall, even if it deviates from the original RSA-Only implementation.

[jonatack]

Are there any that aren't addressed? (In terms of the other PR, I agree that option C makes the most sense)

@3rdIteration the changelog update, not sure for the rest of @akarve's feedback

[jonatack]

#1967 has been merged, so this can now be rebased to master and the changelog updated.