SSE-C encryption

lx commented

2023-07-18 22:21:09 +00:00

Owner

SSE-C is a server-side encryption method supported by AWS where the keys are provided by the client on each request. This might make sense to be implemented in Garage, as it doesn't require us to do any key management, contrarily to the other server-side encryption methods that use KMS (SSE-KMS) or S3-managed keys (SSE-S3). ref

[SSE-C](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html) is a server-side encryption method supported by AWS where the keys are provided by the client on each request. This might make sense to be implemented in Garage, as it doesn't require us to do any key management, contrarily to the other server-side encryption methods that use KMS (SSE-KMS) or S3-managed keys (SSE-S3). [ref](https://docs.aws.amazon.com/AmazonS3/latest/userguide/specifying-s3-encryption.html)

👍 2 👀 1 ❤️ 1

lx added the

S3 Compatibility

label 2023-07-18 22:21:09 +00:00

maxime commented

2023-09-22 16:23:57 +00:00

Hello !

On va utiliser Garage pour stocker des données Nextcloud, et on a vu que pour le chiffrement, Nextcloud recommendait SSE-C. On se dit qu'on aimerait bien stocker nos données de manière chiffrées, et du coup on se disait qu'on allait mettre +1 un pour l'implémentation de cette fonctionnalité.

Après je ne suis pas sûr d'avoir bien compris comment ça fonctionne. Est-ce que dans une perspective d'entre-hébergement par exemple ça veut dire que le serveur garage reçoit les clés de déchiffrement ?

Merciiii

Hello ! On va utiliser Garage pour stocker des données Nextcloud, et on a vu que pour le chiffrement, Nextcloud recommendait SSE-C. On se dit qu'on aimerait bien stocker nos données de manière chiffrées, et du coup on se disait qu'on allait mettre +1 un pour l'implémentation de cette fonctionnalité. Après je ne suis pas sûr d'avoir bien compris comment ça fonctionne. Est-ce que dans une perspective d'entre-hébergement par exemple ça veut dire que le serveur garage reçoit les clés de déchiffrement ? Merciiii

maxime commented

2023-09-22 16:24:45 +00:00

Bon visiblement on récupère une erreur 500 si on veut mettre un emoji 👍 en commentaire... (dans mon précédent message)

Bon visiblement on récupère une erreur 500 si on veut mettre un emoji :+1: en commentaire... (dans mon précédent message)

lx commented

2023-09-22 17:34:05 +00:00

Author

Owner

En effet avec SSE-C, le serveur reçoit la clef de chiffrement dans chaque requête de lecture ou d'écriture, il s'en sert sur le moment pour chiffrer ou déchiffrer le contenu de l'objet et ensuite il la jette. Mais il faut donc faire confiance au serveur :)

👍 1

maxime commented

2023-10-01 09:52:05 +00:00

En tous cas au Cloud Girofle, on souhaite mettre un 👍 pour le développement de cette fonctionnalité :).

En tous cas au Cloud Girofle, on souhaite mettre un :+1: pour le développement de cette fonctionnalité :).

lx added this to the v1.0 milestone 2023-10-16 09:39:57 +00:00

lx commented

2024-02-20 16:38:06 +00:00

Author

Owner

Findings concerning SSE-C:

The key is a 32-byte AES256 key, encoded in base64. As far as I understand, it is the responsibility of the client to send a key of the correct length. There is no key derivation on the server side.
Amazon says they use "AES256" encryption, we can probably use a variant such as AES256-GCM with streaming extensions
Amazon says they do not encrypt metadata. Encrypting the file name (object key) is probably impossible, but we could work on encrypting most of the headers (content-type, etc.)

Open question: what is the hash of an encrypted block of a file? For compression, the hash is computed before compression. For encrypted data, we will probably have to compress, then encrypt, then hash (or skip compression).

For multipart uploads, we probably want to check that the given encryption key is correct for each part upload. If we encrypt the metadata/headers given in CreateMultipartUpload, the check can be done by trying to decrypt these headers with the passed key.

Docs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html

Findings concerning SSE-C: - The key is a 32-byte AES256 key, encoded in base64. As far as I understand, it is the responsibility of the client to send a key of the correct length. There is no key derivation on the server side. - Amazon says they use "AES256" encryption, we can probably use a variant such as AES256-GCM with [streaming extensions](https://docs.rs/aead/0.5.2/aead/stream/index.html) - Amazon says they do not encrypt metadata. Encrypting the file name (object key) is probably impossible, but we could work on encrypting most of the headers (content-type, etc.) Open question: what is the hash of an encrypted block of a file? For compression, the hash is computed before compression. For encrypted data, we will probably have to compress, then encrypt, then hash (or skip compression). For multipart uploads, we probably want to check that the given encryption key is correct for each part upload. If we encrypt the metadata/headers given in CreateMultipartUpload, the check can be done by trying to decrypt these headers with the passed key. Docs: <https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html>

lx referenced a pull request that will close this issue

2024-03-07 14:53:55 +00:00

SSE-C encryption #730

lx closed this issue

2024-03-07 15:21:39 +00:00

lx referenced this issue

2024-03-27 11:28:28 +00:00

Garage v1.0 #683

SSE-C encryption #602