This pull-request adds a keystore implementation, that wraps a file system store, but encrypts the files at rest 🎉

Why is this useful?

In smaller setups, using a cloud KMS might become expensive, and a Vault setup that must be unlocked all the time complicated too.

How does it work?

The implementation combines existing things. It wraps the file system store, and encrypts the file content using a SecretKey. The encryption key must be provided in a dedicated file that contains exactly 32 bytes.

Is it secure?

Storing the encryption key around the file store does not make it secure, but storing the key in a remote location helps. You might mount a remote file system with the key via e.g. ssh or download the key via HTTPS to a temporary (in memory) directory.

Why not using file system encryption?

Encryption at rest has the nice benefit that backups of the file store are secure. Setting up file system encryption without manual unlocking on reboots might not easy to setup too.

How to use?

Create a new encryption key:

dd if=/dev/random of=/some-path/my-kes-master-key bs=32 count=1

Configure the encrypted file store:

...
keystore:
  encryptedfs:
    masterKeyPath: /tmpfs/private-download-path/kes-master-key
    masterKeyCipher: AES265
    path: /data/my-kes-file-store

This pull-request adds a new store, instead of modifying the existing file system store. This has the nice benefit that we can ensure the encryption key is set, and not missing by mistake. The configuration key is named encryptedfs and the implementation efs.

Fixes #392