Expose encrypt/decrypt to wallet rpc

[jbakosi]

This enables (optionally signed) encryption and (optionally verified) decryption of arbitrary text by a wallet.

[jbakosi]

If the size is not preserved, it should really be fixed in the encrypt/decrypt rather than being left to the user to keep an extra pad parameter.

I have thought about this too and I also don't like returning the pad arg. The problem is that wallet2::encrypt() needs a plaintext whose length must be divisible by 4. If it is not, the amount of padding needs to be trimmed after wallet2::decrypt().

I see two options besides the current solution:

1. We keep pad in wallet_rpc_server's state, but that introduces a constraint/ordering on client code having to call wallet_rpc_server::decrypt() after wallet_rpc_server::encrypt() on the same data. I don't like that at all.
2. We put the burden of dealing with pad on client code, which is also not great because it pushes the possibility of an error to a higher level, i.e., to client code.

The current one at least does not expose pad beyond wallet-rpc and can be used from a wallet/lib as a black box without having to worry about padding or ordering of multiple calls to {en,de}crypt. Maybe there is a third option, but I am not familiar with the code enough to see it.

[woodser]

@jbakosi any updates?

[jbakosi]

Other than the discussion above, no.

[jtgrassie]

@jbakosi

I see two options besides the current solution

I see a third option, don't use z85.

If you use base64 (or even base16), you won't have to deal with passing a padding variable around. If someone wants to reduce bandwidth over the wire, compression can be used. base64 and base16 are widely supported also.