Prerequisites
Before implementing SSE-C, ensure you have:- Access to Object Storage with appropriate permissions.
- An S3-compatible client or library that supports SSE-C.
- A method to generate and store encryption keys securely.
- Understanding of basic S3 operations (upload, download, and copy).
If you lose your encryption key, you can’t recover your encrypted data. CoreWeave doesn’t store your encryption keys, and can’t decrypt your data without them. See the Key management section for best practices on storing and managing your encryption keys securely.
Understanding key verification
Object Storage uses your provided key to encrypt or decrypt your data as required, but doesn’t store that key itself. Instead, CoreWeave stores only a base64-encoded MD5 digest of your encryption key. This hash is stored only for verification: when you later access the object, you must supply the same key and hash you used originally. CoreWeave checks the hash of the supplied key against the stored hash to verify that the correct key is provided before attempting decryption.Why only the hash?The hash of the key serves as a checksum: it can verify that the key is correct, but it can’t be used to reconstruct the key. By storing only the hash and not the key itself, CoreWeave ensures that only someone who possesses the original encryption key can access the corresponding encrypted data. If you lose your key, neither you nor CoreWeave can recover your data. The hash makes it computationally infeasible to recover the original key due to the one-way nature of cryptographic hashes.
Basic operations
In these examples,$BASE64_KEY represents your base64-encoded encryption key. Replace this with your generated key in all examples.
Generate encryption keys
SSE-C requires 256-bit (32-byte) encryption keys. Generate these keys using cryptographically secure methods and encode them in base64 format:- OpenSSL
- Python
- Shell
Upload objects with SSE-C
When uploading objects with SSE-C, include the encryption key in your request headers:- AWS CLI
- Boto3
- curl
Replace
[LOCAL-FILE-PATH] with the path to the local file you want to upload. Replace [BUCKET-NAME] with the name of the destination bucket.Download objects with SSE-C
When downloading objects that were encrypted with SSE-C, provide the same encryption key:- AWS CLI
- Boto3
- curl
Copy objects with SSE-C
When copying objects that use SSE-C, specify the encryption parameters for both source and destination:- AWS CLI
- Boto3
- curl
Replace
[SOURCE-BUCKET-NAME] and [SOURCE-OBJECT-KEY] with the source bucket name and object key. Replace [DEST-BUCKET-NAME] and [DEST-OBJECT-KEY] with the destination bucket name and object key.Verify encryption
After uploading objects with SSE-C, confirm that encryption was applied so you know your data is protected. Verify that your objects are encrypted by checking the response headers or object metadata:Check upload response
- Boto3
- AWS CLI
- curl
Set environment variables for your CoreWeave credentials and encryption key:Replace
[BUCKET-NAME] with the bucket name and [OBJECT-KEY] with the object key.List objects with encryption info
- Boto3
- AWS CLI
- curl
Set environment variables for your CoreWeave credentials and encryption key:Replace
[BUCKET-NAME] with the bucket name and [PREFIX] with the object prefix to search for.Error handling
When you use SSE-C, you may encounter specific errors:
Implement error handling in your applications. For example:
Key management
Because CoreWeave doesn’t store your encryption keys, how you generate, store, and rotate those keys determines whether your data stays accessible and secure. The following sections cover the practices to follow when managing SSE-C keys in production.Store keys securely
Never store encryption keys in plain text or in your application code. Use secure key management solutions:- Environment variables: Store keys in environment variables (not in code).
- Secret management systems: Use tools like HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets.
- Hardware Security Modules (HSMs): For high-security requirements, use HSMs to generate and store keys.
Centralize key management
Create a centralized key management system in your application:Validate encryption keys
Validate encryption keys before use:Advanced topics
The following sections cover advanced SSE-C use cases, including presigned URLs, bucket policy enforcement, and production best practices.SSE-C with presigned URLs
When using SSE-C with presigned URLs, you must include the encryption parameters when generating the URL and when accessing it. The encryption key is required both during URL generation and when you use the URL.Generate presigned URLs with SSE-C
- Boto3
- AWS CLI
Set environment variables for your CoreWeave credentials and encryption key:Replace
[BUCKET-NAME] with the bucket name and [OBJECT-KEY] with the key of the object to generate a presigned URL for.Use presigned URLs with SSE-C
When you access a presigned URL that was generated with SSE-C, you must include the same encryption headers in the request. Use the presigned URL generated by Boto3 or the AWS CLI, then pass it to curl with the SSE-C headers:SSE-C with bucket policies
You can configure bucket policies to enforce SSE-C usage for specific operations. This ensures that objects are always encrypted with customer-provided keys.Enforce SSE-C for uploads
Create a bucket policy that requires SSE-C for all upload operations:- AWS CLI
- Boto3
- curl
Set an environment variable for the bucket name:Apply the policy:
To have environment variables like
$BUCKET_NAME evaluated within a heredoc, use << EOF (unquoted) instead of << 'EOF' (single-quoted). Single quotes prevent variable expansion.Enforce SSE-C for specific prefixes
You can also enforce SSE-C only for specific object prefixes. For example, the following policy denies uploads to any object under thesensitive/ prefix unless the request uses SSE-C with the AES256 algorithm. This ensures that only objects stored under [BUCKET-NAME]/sensitive/ require customer-provided encryption keys, while other objects in the bucket aren’t affected by this policy.
Replace [BUCKET-NAME] with the name of your bucket.
Allow specific encryption keys
For tighter security, you can restrict uploads to specific encryption keys by checking the key hash. Replace[BUCKET-NAME] with the name of your bucket and [KEY-MD5-HASH] with the base64-encoded MD5 hash of the allowed encryption key.
Best practices
The following sections describe practices to follow when running SSE-C in production.Rotate encryption keys
Rotate your SSE-C encryption keys on a regular schedule to reduce risk from key compromise. To rotate a key, download objects encrypted with the old key and re-upload them with a new key. Use a secret management system such as HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets to track key versions and expiry dates. Establish a rotation schedule that aligns with your organization’s security policies.Cache encryption headers
Avoid recalculating the base64-encoded MD5 hash of your encryption key for every request. Compute the key hash once and store it in an environment variable or application configuration for reuse across operations. This reduces computational overhead, especially in high-throughput workloads.Monitor key operations
Log all SSE-C upload, download, and copy operations to maintain an audit trail. Track which keys are used for which objects, and record key rotation events. Integrate with your existing logging and monitoring infrastructure to detect unauthorized access attempts or missing key errors.Validate keys before use
Before you use an encryption key in an SSE-C operation, verify that it’s valid base64 and decodes to exactly 32 bytes (256 bits). Validating keys upfront prevents cryptic errors during upload or download operations.Additional resources
- Review the SSE-C concept guide to learn more about how SSE-C works.
- Check the S3 API reference for detailed SSE-C headers and parameters.
- Explore key management best practices for production deployments.
- For more information about SSE-C implementation, see the AWS documentation on using server-side encryption with customer-provided keys.