Support walletd encryption

[OrmEmbaar]

Walletd supports full wallet.db encryption. Fatd should support walletd encryption in order to fully cater to users that require heightened wallet security, such as exchanges.

[AdamSLevy]

I want to better understand the need for this here. To be clear, neither fatd nor fat-cli access the wallet.db directly. Instead they use the factom-walletd API to retrieve secret addresses. HTTPS can be used to query this endpoint for security. Alternatively a user can supply the raw secret address on the CLI directly but that is of course not recommended for security critical applications.

Please let me know specifically how fatd or fat-cli should support wallet.db encryption if you think this is still applicable.

I will close this in a few days if I don't here back.

[OrmEmbaar]

I think I have muddied the waters by referring to wallet.db. Really, this is just about walletd.

From a security perspective, best practice would be to use encryption both in transit and at rest. Currently, fatd only facilitates in transit encryption, not at rest.

Handling an encrypted wallet is done via the unlock-wallet method, which decrypts the wallet for x seconds to allow you to access keys. That decryption command must be sent from the client. Therefore, if a user wants to be able to use fatd with an encrypted wallet, they would currently be forced to handle unlocking themselves. However, I believe the user is ill-suited to understand when and for how long the wallet should be decrypted. It adds complexity to an already complex ecosystem.

[AdamSLevy]

Ah, this makes sense. Thank you for clarifying.

We can definitely add this to the factom API and use it in fatd and fat-cli.