This page says what CipherNest protects, what it does not, and exactly how. Every claim on it is a claim about code you can read.
What CipherNest protects
The contents of your files, their names and types, your folder and album structure, and the identity of what you share. Your cloud provider, anyone who obtains your cloud account, and I, see only ciphertext.
What it does not protect
That you use CipherNest. How many files you store, their sizes, and when they change. Anything on a device that is already compromised: if malware reads your screen or memory while the app is unlocked, encryption at rest does not help. Anyone you give a share link to, and anyone they give it to.
How it works, specifically
- Files are encrypted with AES-256-GCM in 512 KiB chunks under a random per-file key. Each chunk’s authentication tag binds it to a random content id, its index, and the total chunk count, so a reordered, truncated, duplicated or spliced file fails to decrypt instead of opening silently.
- The per-file key is sealed to your vault’s X25519 public key with HPKE (RFC 9180), using the suite DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM, the one with the RFC’s published test vectors. Sealing needs only the public key, which is how the app can encrypt and upload in the background while the vault is locked, with no secret in memory.
- Your recovery phrase is a twelve-word BIP-39 mnemonic generated on your device. It yields a 64-byte seed, and HKDF-SHA256 with fixed, domain-separated labels derives the vault’s X25519 keypair from that seed. The phrase is never transmitted. On the device, the seed is wrapped under your password with Argon2id (64 MB, two passes) and AES-256-GCM, and optionally under a hardware-backed key for biometric unlock.
- Filenames and file types are sealed to your public key with HPKE inside the cloud’s file metadata, so the provider stores an opaque blob where the name would be. Folders and albums live in the vault’s encrypted index, not in the cloud’s folder tree.
- Scope: the app requests only Google’s
drive.filescope and the OneDrive equivalent, so it can see nothing you did not put there. - Share links carry the file key in the URL fragment, which browsers do not send to servers. The viewer decrypts in your browser; the proxy relays encrypted bytes only.
- The code, with test vectors, is public under GPL-3.0.
Assumptions
Your device is trusted while unlocked. Your cloud provider is honest but curious: it follows the protocol but may look at everything it stores. Google Play delivers the build I signed.
Audit status
Self-assessed against the OWASP Mobile Application Security Verification Standard; the report is published with the source. Not yet independently audited; an application for a funded audit is in progress. I will not describe CipherNest as audited until it is.
Reporting a vulnerability
Mail security@ciphernest.io. I acknowledge within 72 hours and aim to fix confirmed issues within 90 days, sooner for anything that exposes plaintext. Please give me that window before publishing. I will credit you here unless you prefer not to be named. Good-faith research within these rules will not be met with legal action.
Machine-readable version: /.well-known/security.txt.