Key material storage

[str4d]

In zcashd, spending key material (and the HD seed it was derived from where relevant) were stored in the same BDB database as the rest of the wallet data.

zcash_client_sqlite (which Zallet uses as its backend) is designed to never store spending key material, due to its history as the backing library for the mobile SDKs. On mobile devices, platform-level keystores exist which are ideal for storing seed phrases or key material. However, Zallet is a desktop wallet, and therefore cannot assume the presence of these kinds of affordances.

We therefore need to decide where and how to store key material in Zallet.

[str4d]

Some thoughts:

Where to store

• Do not store any key material. Require users to manage their key material separately, e.g. stored in a hardware wallet.
  • Some users may use Zallet in this way, but it is untenable as a zcashd wallet replacement given how the latter is used for "hot wallets".
• Store key material in a Zallet-specific table within the zcash_client_sqlite wallet database file.
• Store key material in a section of the zallet.toml config file.
  • This is what we currently do in zcash-devtool wallet.
• Store key material in a dedicated file.
• Don't store key material, and require the user to pass it in whenever performing spend operations.
  • This is (effectively) how the mobile SDKs, Zashi etc. work.
• Don't store key material, and require the user to create signatures using PCZTs and a standalone binary.
  • This is a use case we want to support, but probably too many moving parts for someone migrating from the zcashd wallet.

How to store

• Store the seed phrase(s) in plaintext, store the derived keys in plaintext.
  • Key material can be secured from offline compromise with Full Disk Encryption (which is commonplace nowadays).
  • This is how the zcashd wallet works, and would be the simplest migration pathway.
    • Wallet encryption was never supported due to issues with maintaining Sprout balances, and dissatisfaction with the Bitcoin Core-inherited encryption scheme.
• Store the seed phrase(s) in plaintext, derive any needed keys on-the-fly.
  • Same considerations as above.
  • This requires access to the seed phrases at spending time, which is reasonable (and no more onerous than requiring a hardware wallet).
• Encrypt the seed phrase(s) with age, derive any needed keys on-the-fly after requesting decryption of the relevant seed phrase.
  • This is how zcash-devtool wallet works.
  • Could support any or all of the following encryption methods:
    • "native identity file" (only plaintext on disk is the age identity, and that could be on a different disk)
    • "passphrase" (like zcashd's experimental wallet encryption)
      • The closest analogue to zcashd's experimental wallet encryption would be a passphrase-encrypted native identity file: need passphrase once to decrypt the age identity into memory, and then can use the identity to decrypt and access seed phrases on-the-fly.
      • An advantage over the zcashd approach is that you don't need the wallet to be decrypted in order to import or generate new seed phrases / key material (zcashd used solely symmetric crypto; native age identities use asymmetric).
      • Current downside is that because of the above, encrypted key material would be quantum-vulnerable (but ML-KEM support is in progress for the age ecosystem).
    • "plugin" (enabling key material to be encrypted in a user-specified way e.g. to a YubiKey, or a corporate KMS)
      • Might also want a hybrid approach here to allow for on-first-use decryption requests rather than every-time decryption requests. Or maybe we want to support both.
• Encrypt the seed phrase(s) or key material in some other way.
  • I'd prefer we don't do this option; I'd rather not design Yet Another Key Encryption Mechanism.

[pacu]

For the immediate/short term we need whatever was available in Zcashd. Although that can be hassle to undo once deployed.
Are there any of the viable alternatives listed above already deployed in existing full-node wallets of other chains?