Encryption of private key used for proofs

If proving is an RPC call, it leaves an issue to be addressed about the threat model being addressed w.r.t. secret key material.

In the case of a wallet, we obviously encrypt the secret "at rest", in something like a wallet file. It's unlocked in memory and used only within-process.

The architectural problem here, however, is non-trivial. Consider that, the most plausible usage scenario for the app would be:

a wallet application exists, call it W.

W wants to support this as a feature for its user.

W calls AUTCT with a proving request; it needs to provide the private key to AUTCT to allow the proving request to work.

This means that AUTCT has to be kind of "owned" by A from a security point of view (it could run it as a subprocess or similar), and trust giving to AUTCT either a raw private key or a password to decrypt a wallet file. The latter might seem more normal, but AUTCT would need to "speak the language" of the decrypted wallet file of W (and be able to decrypt it), which doesn't seem to make sense.

But the alternative, that W passes to AUTCT the raw private key as part of the RPC call, also seems dangerous. A well known example of this insecure pattern is: imagine that W called AUTCT as a subprocess with a flag -i <privkey> - this would result in the private key being visible in the OS process list.

If the RPC prove call is via an encrypted/secure channel (TLS), then this problem is addressed, so long as that channel is actually authenticated and encrypted properly, preferably with forward secrecy. I think this option is a little annoying in terms of extra baggage (self signed certs will be required), but probably correct.

Opinions welcome, hence the label.

AdamISZ / aut-ct

Encryption of private key used for proofs #18