Encryption at rest diagram
Concept

Encryption at rest

Encrypted by default, post-quantum, transparent to your tools — and no KMS to deploy.

On by default

A plain KerPlace install encrypts every object as it is written — no flag, no setup, no KMS to deploy. Encryption at rest is the default posture, not an add-on.

With the default key provider, this is post-quantum: each object’s data key is wrapped with ML-KEM-1024 (NIST FIPS 203) and the bytes are sealed with AES-256-GCM. Data written today stays sealed when quantum computers arrive.

Transparent to your tools

Encryption is server-side and transparent — the SSE-S3 model. You upload normally and read normally; the cryptography happens underneath. mc, aws s3, rclone, s3fs and S3 SDKs work unchanged — copy, list, sync, multipart and range reads all behave as usual. There are no keys for your clients to manage.

Layered control

Encryption applies if any layer asks for it — and by default the global layer always does:

LayerSet with
Whole serveron by default
Per bucketmc encrypt set sse-s3 alias/bucket
Per objectthe standard S3 server-side-encryption request header

The familiar S3 tooling all works; with the default on, it simply confirms what is already happening.

Key custody is yours

By default the keys live on the host — protecting against a stolen disk or a leaked backup. When you need stronger separation, KerPlace can keep the keys in an external service you control, so the storage host holds only ciphertext and access is revocable at any moment. See Off-host key custody.