Storage-level encryption
Cotton encrypts stored file data in the server storage pipeline. This layer is always part of the storage model and is separate from the browser-side E2E folder policy documented on its own page.
Streaming AES-GCM
By-the-book encryption that stays on.
Cotton's storage crypto is deliberately boring in the right way: standard AES-GCM, an explicit streaming container, per-file wrapped keys, per-chunk authentication, and enough throughput headroom that operators are not pushed toward unsafe shortcuts.
By-the-book container shape
The encrypted stream uses a container-style model with file-level key material and chunk-level authentication. Each chunk can be authenticated as part of the stream instead of treating a huge file as one monolithic crypto object.
- Per-file wrapped keys isolate file content.
- Per-chunk authentication tags help detect block tampering, duplication, skipping, and corruption.
- A 12-byte nonce is composed from a 4-byte file prefix and an 8-byte chunk counter.
- Authenticated additional data binds key and chunk metadata into the container rules.
Why AES-GCM
AES-GCM is a widely deployed authenticated-encryption mode: it protects confidentiality and integrity when key and nonce discipline are correct. It is also hardware-accelerated on common platforms and available through standard runtime cryptography, which makes it a pragmatic default for a cross-platform self-hosted file cloud.
No homemade cipher theater
Cotton does not ask users to trust a new encryption algorithm. The product claim is narrower and stronger: standard AES-GCM wrapped in a storage format that understands huge files, chunking, range reads, bounded memory, and the need to authenticate every piece before it is trusted.
Pipeline performance
The encryption path is built on streaming buffers and .NET primitives that keep allocation pressure low. Local benchmark baselines show the crypto layer with enough headroom that disk, network, or compression should usually become the visible limit first.
Testing posture
The crypto module is covered by golden-vector, deterministic format, tamper, truncation, duplicate-chunk, skipped-chunk, strict-length, pipe, cancellation, and performance tests. That is still not the same as an independent audit, so public marketing should say what exists and not overclaim what does not.
How this relates to E2E
Client-side encrypted folders are an additional feature. The browser encrypts selected files before upload and stores encrypted display metadata, then the server still persists the resulting payload through the normal chunked storage pipeline.
Encryption path proof
The public claim is storage-layer streaming AES-GCM with per-file wrapped keys, per-chunk authentication tags, nonce/AAD discipline, bounded buffers, and tests around the container format. It is a storage pipeline feature, not a blanket E2E claim.
Encryption stays on
Cotton can keep encryption on because encryption is in the main path and the implementation is intentionally conservative. The product does not need a separate unsafe fast lane for ordinary file work.
What storage encryption leaves visible
Storage encryption still leaves server-side processing and some metadata visible to the server. Use client-side encrypted folders when selected content must be opaque before upload.
FAQ
Direct answers
Is streaming AES-GCM the same as browser-only client-side encryption?
No. Streaming AES-GCM describes Cotton's storage encryption pipeline. Cotton's E2E surface is the separate client-side encrypted folder/file feature, where the browser vault encrypts selected uploads before they reach the server.
Is Cotton using its own encryption algorithm?
No. Cotton uses AES-GCM through standard cryptography primitives. The Cotton-specific part is the file storage container: wrapped per-file keys, chunk authentication tags, nonce layout, AAD, streaming buffers, and tests that guard format behavior.
Why not make encryption optional?
The product goal is for encryption to be the default storage posture. Performance work exists so operators are not pushed toward disabling safety for speed.
Does encryption require loading the whole file?
No. The storage path is built around streaming buffers and per-chunk work, so encryption can stay in the write path without turning large files into full-file memory events.
Does this mean Cotton has had a security audit?
No. The accurate claim is strong engineering evidence inside the project: standard AES-GCM, explicit container rules, golden vectors, tamper tests, and benchmark coverage. A third-party audit should only be claimed after one exists.