Prevent encryption operations to use swap files

[xxsanzxx]

I believe many of the encryption operations that are being done in memory could reach the disk if any wallet/node uses any encryption function whilst having a full memory. This would result in passphrases and private keys reaching swap files on disk, making it possible to access them.

Some of the affected functions include: generateNew , xPrvChangePass in Wallet.hs and encryptedKey,encryptedCreate,encryptedCreateDirectWithTweak,encryptedChangePass,encryptedSign in Encrypted.hs

In summary ensuring that encryption functions are done in memory will avoid the posibility of passphrases/keys being leaked into the disk and therefore susceptible to be stolen. A possible solution would be using mlock in unix and VirtualLock in Win32, which locks some memory space and ensures that some operations will always be executed in memory.

[vincenthz]

What you're asking to do here is not currently doable with the haskell memory model (as used), and 'raw-memory-dump' is actually not part of the threat model (since the passphrases are in clear pretty much all over memory). The only non invasive way right now to solve this problem is to use hardware key; all the counter measure above would just be snake oil without a complete re-architecturing of the secret managements.

[dcoutts]

We will review with the product managers if we want to address this, and if so with what priority.

This will be more relevant with KES since although we may start with the encrypted KES_0 and passphrase, we will need to keep in memory (at different times) KES_1..KES_n, and not leak these to disk, so an ability to use mlock'ed memory for the private keys could be important.

[vincenthz]

This repository doesn't implement KES, and is not tracking meta tasks either. so I fail to see the point to track this here, considering this is about redefining the threat model of the application.