Chunk encryption
Cotton encrypts stored file data through a streaming AES-GCM pipeline with per-file wrapped keys, per-chunk authentication tags, structured nonces, and authenticated container metadata. The point is not exotic crypto; the point is a conservative storage format that can stay on.
- Encryption happens in the normal storage path.
- Chunk authentication helps detect tampering, skipped blocks, duplicated blocks, and corruption.
- The server-side master key protects storage-level encrypted data and backup artifacts.
Boring crypto is the feature
AES-GCM is a widely deployed authenticated-encryption mode, and Cotton uses it through standard runtime cryptography instead of inventing a cipher. The Cotton-specific work is the storage packaging around it: key wrapping, file/chunk headers, nonce layout, bounded buffers, and tests that freeze the container behavior.
- 32-byte keys and 16-byte authentication tags match the AES-GCM storage design.
- 12-byte nonces are composed from a file prefix and chunk counter.
- Golden vectors and tamper tests protect the format from accidental drift.
Client-side encrypted folders
Cotton also supports selected end-to-end encrypted folders and files. When a folder policy is enabled, new uploads can be encrypted in the browser with a vault key before the server receives the file; encrypted display metadata keeps names and content types usable only after unlock.
- The encryption password is separate from the account password and is not sent to the server.
- Encrypted files use opaque server-side names and client-side display metadata.
- The current browser Blob pipeline has a 512 MB per-file guard until client-side streaming encryption replaces it.
Admin access threshold
Storage-level encryption protects every persisted chunk, while client-side encrypted folders raise the privacy boundary for selected content. The public wording stays precise: E2E applies to those client-side encrypted files, not to every byte of every feature by implication.
- Stored chunks are encrypted and content-addressed.
- The visible folder tree lives in metadata, not in plain user directories.
- Admin diagnostics call out deployment risks instead of hiding them.
Account security
Users can sign in with password flows, TOTP, platform passkeys, or external WebAuthn security keys. Profile settings expose active sessions so one suspicious device can be revoked without forcing every session out.
- Passkeys and hardware security keys are first-class account credentials.
- TOTP setup and recovery flows are part of profile security.
- Failed login and security events can become user notifications.
Database integrity
Protected database rows carry integrity signatures derived from master-key material. Security-sensitive reads can verify those signatures and surface failures instead of trusting modified metadata blindly.
- Users, credentials, tokens, settings, nodes, manifests, and chunks are covered by integrity descriptors.
- Bridge rollout mode can sign legacy rows while warning admins that rollout is not finished.
Admin security checkup
The admin security page scores concrete deployment risks: public account creation, master-key source, admin 2FA coverage, .NET diagnostics, Linux dumpability, seccomp, ptrace capability, writable root filesystem, Docker socket exposure, host PID namespace signals, core dumps, and confinement.
Storage pressure and quota
Filesystem-backed storage checks free capacity before accepting new physical chunk writes. Public and demo instances can apply default user quotas so onboarding content does not turn into an uncontrolled storage sink.
Honest crypto posture
The encryption modules are covered by golden-vector, tamper, truncation, stability, pipe, cancellation, and performance tests, but the site does not claim a third-party audit that has not happened. That honesty matters more than overclaiming. The right public claim is by-the-book streaming AES-GCM storage encryption for the storage layer plus client-side encryption for folders/files that explicitly use the E2E policy.
Demo accounts
The public demo does not depend on one shared account. The login link generates per-browser credentials and can seed default content into the new account through the same product mechanism used for onboarding.
Current limitations
We name these up front. Client-side E2E currently runs through a browser Blob pipeline capped at 512 MB per file, until a streaming pipeline lands. The published benchmarks are machine-mode baselines, not live end-to-end upload math; real throughput also depends on browser, HTTP/TLS, database, disk, and concurrency. And the storage crypto is by-the-book AES-GCM, but it has not had a third-party audit.
Security surfaces you can see
Cotton's security story is visible in product mechanics, not just policy text: server-side chunk encryption, selected client-side encrypted folders, passkeys, TOTP, session revoke, database signatures, quotas, storage pressure checks, and admin diagnostics all have user or operator surfaces.
- Stored chunks use streaming AES-GCM in the normal path.
- Client-side encrypted folders keep the vault secret out of the server login flow.
- Protected database rows can be verified against integrity signatures.
Security in the product path
Cotton is blunt here: this is security built into the file cloud, not a checkbox bolted to a shared folder UI. The product makes risky states visible so operators can fix them before they become incidents.
What not to overclaim
Cotton is not marketed as universally end-to-end encrypted. The accurate claim is storage-layer streaming AES-GCM by default plus client-side encryption for folders and files that explicitly use that policy.