bond key encryption

[buck54321]

trafficstars

We need to encrypt the db.Bond.PrivKey.

https://github.com/decred/dcrdex/blob/8d99975b34e4ed372953ee39f5fbc659b2302918/client/db/types.go#L100

With #2036 introducing automatic bond rotation, encryption of the private key becomes difficult, since we don't want to keep the application Crypter in memory. But we certainly don't want to store the private key in plaintext either. I could see a couple of approaches.

1. Create a derivative Crypter on login that we do keep in memory. It is only used for bond private keys. Pros: no plaintext keys in memory. Cons: encryption key in memory
2. On login, decrypt existing bond private keys, and create a generous set of keys for future use. Pros: No encryption key in memory. Cons: plaintext keys in memory

There may be other approaches too, but if I had to choose between the 2, I'd pick option 1 since it adds a layer of obfuscation. It seems to me that without requiring user input for every bond, we must keep sensitive information in memory. Which I guess brings up one more option.

3. Require user input for every bond broadcast. If I had to consider this, it would be a pop-up modal dialog for GUI. RPC and Go consumers could have a method exposed to trigger a rotation with a password.

Obviously the last option has some drawbacks for UX.

[chappjc]

In the bond rotation PR, those keys are derived from the extended key Core.bondKey, so I think we can just replace the db.Bond.PrivKey field with a child index. Unless you're thinking there's an issue with that approach in that PR. I think this is fine personally. The dcrwallet ticket buyer / mixing process does something similar. If we really want to, we can keep a secondary (randomly generated) crypter paired with an "encBondKey" to add that bit of obfuscation, but I think that's not necessary. (Maybe I should be more worried about memory scraping attacks?)

3. Require user input for every bond broadcast. If I had to consider this, it would be a pop-up modal dialog for GUI. RPC and Go consumers could have a method exposed to trigger a rotation with a password.

Obviously the last option has some drawbacks for UX.

That's putting it mildly IMO. I think dex would be almost unusable.

[buck54321]

so I think we can just replace the db.Bond.PrivKey field with a child index

That sounds great.