Add encrypted configs to pcli

[cronokirby]

In real-world custody setups, in can be useful to store the pcli config file—which contains the shares of the spend key—encrypted at rest. However, given the complexity of setting up an actual threshold custody, the additional barrier of also setting up a correct encrypted backup is an additional paper cut which we might want to avoid.

We could natively support an encrypted configuration in pcli.
We would have an encrypted configuration option in pcli, which would store an encrypted blob instead of the usual config, and then require a password to decrypt the configuration.
We could implement this by:

• adding a --encrypted flag to pcli init,
• adding a method to convert a normal config into an encrypted one.

[hdevalence]

I think we should try to figure out a way to have only subfields of the config data be encrypted. This would allow the FVK to sit in the toml file and for pcli to be used for viewing operations without prompting for a password.

It would be useful to support encryption for single spend keys as well as threshold data, where it's even more important.

Is there a way that we could have the SoftKms custody implementation prompt for a passphrase only when it gets a request? That way we could avoid doing large changes to the structure of the pcli code.

[cronokirby]

Another approach instead of encrypting the config itself, is to just encrypt the custody portion of the config. We could do this with a new custody backend which would wrap another backend. This would touch the relevant items for SoftKms and Threshold custody.

[hdevalence]

Hmm, so the idea is something like

• there's a new EncryptedCustody struct (name tbd) with its own config type that has an encrypted blob;
• the EncryptedCustody has internal state that's an enum of the encrypted blob and optionally a boxed service;
• when a request comes in:
  • if the boxed service is None, it prompts for a password on stdin, decrypts, parses the config, instantiates the inner service, boxes it and sets it, then sends the request in
  • if it's Some, just pass through the request

?

[cronokirby]

Yeah, that's basically the idea; we might want to shift the decryption to initialization, but otherwise the wrapping is what I'd envisioned.