[feat] Encrypt sensitive keys on disk

[JonasKruckenberg]

As far as I can see currently all allocated private key buffers are not zeroized after being freed by the go GC, this is obviously a big problem especially for lighting private keys where actual money is attached to them.

It seems like go doesn't have support for this yet, but we should implement an interim solution anyway.

[juligasa]

We do even worse. Not only we don't clear memory but also we store the lndhub credentials in the db unencrypted, I guess that should be our first concern. Related pitch can be found here

[JonasKruckenberg]

Oi, that's not great you're right. Maybe we can have a quick chat about how to encrypt those. There's a very high quality secret management engine written in Rust (created by many of the Tauri team before Tauri) that we could use to store secrets and sleep at night 😄
I don't know how we would set up the communication with go though 🤔

[burdiyan]

Let's have a separate issue for encrypting secrets. Or do we have one? There're packages to interface with OS-level key managers, like MacOS keychain, and something-something for Windows :) I don't know much about Linux.

Regarding the original topic, zeroing-out the memory from the private key after usage, I guess we could do that manually, we only really ever interact with two private keys. The one of Account, and the one of Device. The thing is that, we have to keep the device key in memory anyway, and it doesn't really get copied much, it's a pointer to the same buffer under the hood.

I don't want to dismiss the idea (and I'm not), but at the current moment we're in, that would be the least of my concern, until we have many users, or until Go implements zeroing out the memory after GC.

[juligasa]

For the record, the key manager in linux is called pass

[burdiyan]

I'm lowering the priority of this, unless we decide otherwise.

[ericvicenti]

I have renamed this issue to reflect the disk encryption feature for device keys and other sensitive keys that we keep

Remember we do not store the most sensitive key, the account ID. Although there is still a risk about it staying in memory longer than needed, so #643 is still relevant