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

[akarve]

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

[jonatack]

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

Edit: per https://github.com/bitcoin/bips/pull/1967#discussion_r2411869941, 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.

[3rdIteration]

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

Yep, will do in the next week or two.

I'll throw in some test vectors while I'm at it as well :)