Add interface for client-side encryption

What would you like to have changed?

Provide a mechanism for client-side encryption.

Why is this feature a useful, necessary, and/or important addition to this project?

Several storage implementations already support some form of client-side encryption, but each using a slightly different encryption mechanism:

• Caddy TLS consul, Caddy TLS Redis allow specifying a AES Key in the config.
• certmagic-generic-s3 allow specifying a Secretbox key.

Adding a mechanism for client-side envelope encryption to cert-magic would :

• Improve security: Client-side encryption adds another layer of security on top of encryption that might happen server-side (for example with s3 or gcs). Encryption would occur before data is sent to the Storage backend. A potential attacker would need to compromise both the storage backend and acquire the encryption key to be able to use the data.
• provide more flexibility to the users. Some users might want to use chose the encryption mechanism: SecretBox or AES, or maybe a KMS service. If implemented within cert-magic, encryption would become available to every storage backend currently not supporting it.

Here are some initial thoughts:

• A naive first pass implementation could be to extend the Storage interface with Encrypt/Decrypt optional functions. For example:

    Encrypt func(ctx context.Context, data []byte) ([]byte, error)
    Decrypt func(ctx context.Context, data []byte) ([]byte, error)

This would delegate the responsibility to the caller to provide the encryption mechanisms.

• Ideally, encryption should only happen when data is written to the store. After enabling encryption, only newly created or updated data should be encrypted when stored. Existing unencrypted data should still be readable. This is a bit harder to implement but it would allow users to transition from un-encrypted to encrypted data 💪 . One way to do this would be to store the encryption provider as metadata alongside with the data. This is similar to how kubernetes encrypts secrets in ETCD (see docs) and allows moving from one encryption to another seamlessly.

I would love to get the community's opinion this before doing a first pass implementation.

Start by reviewing the Storage interface and the existing storage implementations linked in the issue, then read the Kubernetes encrypted-secrets documentation for the metadata approach. The issue needs an agreed encryption-provider interface, key and format behavior, and a compatibility plan for existing unencrypted data before implementation can be considered done.