Expand BIP85 to include ECC key types #1968

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.

Could this change break anything?

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.

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.

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}/
...

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')

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)

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}

This would be the neatest solution

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

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.

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.

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

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

there's a pretty simple app protocol in the ref. implementation now: https://github.com/akarve/bipsea/blob/main/src/bipsea/apps/README.md

I have actually got a working implementation of the draft spec (as per the last edit) here: https://github.com/3rdIteration/bipsea

The derivation path format already hardens the key_type component ("{key_type}'"), but the table also defines key_type values with a trailing apostrophe (e.g., "0'", "1'"). This is ambiguous and can lead to double-hardening / inconsistent interpretation across implementations. Define key_type as a plain integer (0..4) and state that the path component is always hardened, or remove the apostrophe from the path placeholder.

@copilot code review[agent] Can you add a note for the ECC key_types that mentions which key_bits lengths are valid

The spec introduces ECC key types but does not define how {key_bits} selects a specific curve/algorithm for each key_type (e.g., which NIST curve corresponds to which key_bits, and similarly for Brainpool). For fixed-size curves like Curve25519 and secp256k1, it’s also unclear what {key_bits} is expected to be (and whether other values are invalid). Please add explicit, deterministic mappings/constraints so independent implementations derive identical keys for the same path.

For Curve25519, OpenPGP typically uses different algorithms for different capabilities (e.g., Ed25519 for certify/sign/auth vs X25519/Curve25519 ECDH for encryption). The current text says all subkeys SHOULD use the same key_type, but doesn’t specify the required per-capability algorithm mapping within that key_type. Please clarify the exact OpenPGP public-key algorithm/curve used for primary vs encryption/auth/sign subkeys under key_type=Curve25519 to avoid incompatible key material generation.

All subkeys SHOULD use the same key_type (i.e. the same underlying curve family) as the primary key. Mixed key types across primary and subkeys are out of scope for this specification. For <code>key_type = Curve25519</code>, implementations MUST generate OpenPGP keys as follows: the primary CERTIFY key and any SIGNATURE or AUTHENTICATION subkeys MUST use Ed25519 (OpenPGP EdDSA with curve Ed25519), while ENCRYPTION subkeys MUST use X25519/Curve25519 ECDH (OpenPGP ECDH with curve Curve25519). Additional subkeys may be added following the same role pattern, incrementing the sub_key index.

The guidance on when to use BIP85-DRNG for ECC ("over 256 bits") doesn’t align with the earlier definition of BIP85-DRNG being needed when more than 64 bytes of random input are required. Consider specifying DRNG usage based on the keygen’s required randomness/bytes (or explicitly justify why >256-bit ECC needs DRNG), otherwise implementers may diverge on whether to use DRNG for common curves like P-384.

The RSA key generator should use BIP85-DRNG as the input RNG function. Likewise, any ECC key types whose key generation requires more than 64 bytes of random input should use BIP85-DRNG.

This section now covers multiple GPG key types, but the timestamp note still refers specifically to "The resulting RSA key". Either generalize the statement to apply to all OpenPGP keys derived here (including ECC), or explicitly scope the timestamp requirement to RSA-only if ECC behavior differs.

Changing the GPG derivation path from the previously-specified RSA format (which did not include {key_type}) will change the derived material for existing paths and break interoperability with any current implementations/vectors. If backward compatibility is a goal, consider keeping the legacy RSA path intact and allocating new application numbers for ECC (or otherwise defining a legacy/compat mode) rather than inserting a new path level under the same application number.

this is a major issue. given that this BIP is widely implemented we have to preserve backward compatibility. we either need to extend and not break the existing paths (including what was sub_key) or we can do this in a clean GPG application.

This was my original suggestion, basically just add additional application numbers for ECC (Or perhaps a separate application for ECC and child derivation as per this current draft), but folk seemed to want to go with a 3.0 change that wasn't backwards compatible earlier in the discussion thread.

The 2.0.0 changelog entry says the GPG section now uses a single application number with key_type, "replacing separate per-type application numbers", which doesn’t match the earlier changelog/history in this document (it previously introduced an RSA application at 828365'). Also, this conflicts with the PR description’s stated approach of using different application IDs per key type. Please reconcile the changelog text (and/or the spec approach) so the intended compatibility strategy is clear.

Changelog entries below include dates (e.g., "1.3.0 (2024-10-22)"), but the new "2.0.0" entry has no date. Add a date (or follow whatever versioning/date convention the document uses) to keep the changelog consistent.

===2.0.0 (2024-11-01)===

minor: aim for ~80 wide for terminal readability:

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.

i think this can be one big table and will read better; there's already a common join key and both are small

we need to be very careful with that timestamp, it was just corrected: https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki#fixed

Yes

Can we try a "same for all" algorithm that also has less chance for bias? For example:

1. Initialize BIP85-DRNG with the 64-byte HMAC entropy
2. L = ceil((ceil(log2(n)) + 128) / 8)
3. Read L bytes from DRNG
4. scalar = (int.from_bytes(buf, 'big') % (n - 1)) + 1

As I understand it without a safety margin we risk bias e.g. when curve order is high and close to the entropy size. See e.g. https://www.rfc-editor.org/rfc/rfc9380.html#name-hashing-to-a-finite-field

Even better if you can refer us to a standard procedure for this step let's just use that.

There isn't really a standard procedure other than "Generate at least X bits of entropy and use that", so the question is how to throw away the excess. (Mod or mask)

The other thing to avoid was something that happened with Putty a few years back where they just used 512bits and padded with 9 bits, making the keys easier to recover.

Should we even support RSA-1024, it's deprecated right?

It's deprecated so I wouldn't imagine any current implementations would use it