Bring your own signing key

[jozefizso]

Hi,
this is an idea to solve the issue with Sparkle's Ed25519 keys which use a format that cannot be used by other libraries (CryptoKit, OpenSSL, BoringSSL) or services (Azure Key Vault) to do signing.

As noted on https://github.com/orlp/ed25519 their implementation will generate Ed25519 seed value and generate derived private key and a public key. The seed value is thrown away and Sparkle will use the derived private key to do signing.

Other libraries tend to use the seed as input material for signing (and internally they generate the derived private key). While the seed can be used to create derived private key, there is no way to retrieve original seed from derived private key.

Proposed Solution

Some customers may have special needs for the Ed25519 keys. Either for security or compliance reasons they must keep the original seed value.

To make Sparkle compatible with user generated Ed25519 keys, the generate_keys tool should support importing a DER encoded Ed25519 key and store it in Sparkle's format.

DER format is chosen because it is efficient (it's binary), it describes the key material and it is used by other tools (eg. NodeJS crypto library uses DER to work with private keys). DER header stores information about algorithm - the OID value for EdDSA25519 (which is 1.3.101.112).

Sample header for EdDSA25519 encoded file:

302e020100300506032b657004220420

Sample DER file for Ed25519 key a1111aaacfc876914535947e2a06b838c97cef72fee7e24515caf94ad596ecf0 (the file is encoded in binary as is shown in hex here):

302e020100300506032b657004220420a1111aaacfc876914535947e2a06b838c97cef72fee7e24515caf94ad596ecf0

This allows the generate_keys to identify data in imported file and in case of DER encoded key to import the seed value and generate Sparkle key-pair using the ed25519_create_keypair() function. The fallback would be to read the file as Base64 as import the Sparkle key-pair as it does now.

Use Cases

Being able to use own Ed25519 key (having access to the seed value) enables customers to:

• sign updates in the Azure Key Vault
• sign updates on Linux machines
• use other tools to generate signatures
• write integration tests which do signatures and verifies compatibility with Sparkle tools
• write integration tests for rotating keys

References

• https://crypto.stackexchange.com/questions/81023/oid-for-ed25519
• https://crypto.stackexchange.com/questions/39343/what-is-the-best-practices-for-storing-ed25519-private-keys-which-is-used-by-nod
• https://www.tbray.org/ongoing/When/202x/2021/04/19/PKI-Detective

[zorgiepoo]

The main practical problem (that has come across a couple times) is that people want to use non-Sparkle tools for signing their updates.

It may be a good idea to (with compatibility implications considered):

1. Don't throw away the seed when generating new keys with generate_keys and store it
2. Offer exporting a key to a "standard" format that can be plugged into other libraries with minimal hassle
3. Offer importing a key with the same format as 2.

Of these, I actually consider importing the least important.

I am not sure if DER format is the 'right' choice. What are the bytes after the header? Is it seed || publicKey as described in jedisct1/libsodium#1213 ? Are you suggesting we just hardcode the header?

Consider the scenario that someone generated keys with Sparkle and wants to export the keys to use in a tool where they use libsodium, CryptoKit, a golang library, or whatever else. Is the format we land on make it easy/feasible for them to do that?

Note that I don't want to pull in other dependencies. It makes sense the library we use throws away the seed as apparently reading through the issues it predates other libraries and the RFC.

[jozefizso]

Yes, generate_keys should store the seed value - perhaps in a second Keychain item. I have a small prototype for this but I am not sure how to pull this correctly, therefore I considered only importing existing seed for now.

I would choose DER format because of the header which identifies the key material. Only the seed value (without public key) is stored in DER format.

Consider the scenario that someone generated keys with Sparkle and wants to export the keys to use in a tool where they use libsodium, CryptoKit, a golang library, or whatever else. Is the format we land on make it easy/feasible for them to do that?

Yes, DER would be usable by these tools.

Note that I don't want to pull in other dependencies. It makes sense the library we use throws away the seed as apparently reading through the issues it predates other libraries and the RFC.

Sparkle can still use the ed25519 code it uses - it would just not throw the generated seed away.

[zorgiepoo]

Yes, generate_keys should store the seed value - perhaps in a second Keychain item. I have a small prototype for this but I am not sure how to pull this correctly, therefore I considered only importing existing seed for now.

I would like to not use another keychain item if possible. Maybe the new format can only contain the seed and public key in the keychain. One concern I have is if users run old tools that don't understand the new stored format and not leaking private keys there accidentally.. If we don't store the 64-byte private key, maybe that can be handled well enough.

I would choose DER format because of the header which identifies the key material. Only the seed value (without public key) is stored in DER format.

To me this sounds problematic / not ideal. If I'm using another library I want the binary encoded public key. If I export a private key using generate_keys in a new format that contains the seed, I should be able to import it on another machine, without using additional files/arguments, and it should have the public key stored as well for later lookup.

[zorgiepoo]

Moved to #2470

[jozefizso]

If I export a private key using generate_keys in a new format that contains the seed, I should be able to import it on another machine, without using additional files/arguments, and it should have the public key stored as well for later lookup.

Do you mean exporting private key for use by other tools, or specifically for reimport using generate_keys?

[zorgiepoo]

Both. We need to export/import the public key too. See above issue for continued discussion.