Security model

Your email address, a scrypt fingerprint of a key derived from your password (never the password itself), your TOTP secret, a single HMAC fingerprint covering all of your factors together, a random key share, and your vault key in sealed envelopes.

No phone number is ever asked or kept. Your keys, seed, recovery key and secret answer never reach the server in any reversible form.

For each item: a random identifier, encrypted metadata (name, type, size, parent folder), a wrapped file key, the size of the encrypted blob and a storage reference. No name and no folder tree in the clear.

For each sign-in and each open session: the IP address your connection comes from and the browser it announces, kept for 90 days. They are what lets you spot a device that is not yours, and they are visible to the operator. Your own pages only ever show them partly hidden.

One private folder with a random name per vault, and binary files named by a random identifier (“<uuid>.bin”). The content is encrypted with AES-256-GCM before it leaves your browser; Gofile receives no original name, no type and no structure.

Uploads go through upload.gofile.io, which picks the nearest region on its own. The Gofile token stays on the crycrypt server.

Deleting a file or a folder deletes it from Gofile too. If Gofile does not confirm, the deletion stays queued and is retried every hour: a deleted file does not linger at the host.

When Premium ends, your files are kept one month, then the whole content of the vault is deleted — files, folders and the links to permanent copies. Permanent copies stay on Arweave, where nobody can delete them; their hash and link can be copied from the vault before the deadline.

A file can leave the vault while staying encrypted: your browser reseals it into a .crycrypt file, under a fresh key that is itself sealed by a key derived from your vault key. Nothing readable reaches the disk, and no identifier of the vault is written into it.

Only the vault it came from can open a .crycrypt. Dropped back into that vault, it returns exactly as it was — name, type, dates — under a fresh key; “Decrypt a .crycrypt file” decrypts it without storing it. A .crycrypt from another vault, or one that was altered, is refused.

Everything, but only once the vault is open: the vault key is recomputed in memory from your factors (Argon2id) and from the server share released after your codes. It is never written to disk in the clear; after a reload it only comes back during the open window — 20 minutes, one hour with Premium.

After a complete opening, your browser also remembers your three keys, sealed under a key that only your server session holds. When the vault closes on its own, reopening then takes one character of each key, with your answer and your codes as always. Locking the vault by hand, signing out or “Forget my keys” erases them.

The local database (IndexedDB) only holds the encrypted metadata, tied to a tag derived from the vault key: no email, no user identifier, no name in the clear. A file's content is only downloaded and decrypted when you open it.

Signing in and opening the vault are two different things. Your password and your TOTP code open your session; they do not open the vault. The vault takes your three 12-character keys in order, the answer to your secret question, a code from your authenticator app — always — and, depending on your settings, a code by email (on by default).

The keys and the answer are joined and run through Argon2id: the result, combined with a server share released only after your codes, decrypts the vault key. The order of the keys is therefore compared to nothing — swapped, they produce another key, and decryption fails.

The server keeps a single fingerprint of the whole set, never one per factor. Hashing each element separately would let someone who stole the database break them one by one: a 12-character key weighs only 60 bits, while the three together weigh 180, before the answer is even counted. It is also why a refusal never says which element was wrong: the server itself does not know.

Thirty characters for the key, twenty for the seed, shown only once when the vault is created. The seed only serves to recover: you never type it to open the vault. The server keeps an HMAC verifier and a second envelope of the same vault key, nothing more.

To recover: the recovery key, plus the seed, plus your secret answer. No code and no key are asked — that is precisely the path for a lost phone, mailbox, authenticator app or one of the three keys. Since the answer is required both to open and to recover, forgetting it loses the vault.

A recovery replaces one thing only, of your choice: the three keys, the email address or the authenticator app. A new address is only kept once a code proves it; a new app, once it shows a valid code. The seed and the answer never change.

Only the recovery key is renewed each time: it works once, and the old one stops working the moment the new one is written. An email tells the account that a recovery took place, and what it replaced.

Three wrong passwords in a row never block sign-in: the right password still works, and your authenticator code is still required. They send a link to the account's mailbox: valid 24 hours and once, it lets you choose a new password, with a code from your authenticator app as well. “Forgot password” sends the same link. Attempts are rate-limited per address and per IP, and the response is the same whether or not an account exists behind the address.

The vault is not involved: a password only opens the session, never the vault, and changing it touches no key.

Email serves three purposes only: verification codes, the recovery alert and that link. No other notification is sent — not when the vault opens, not after a failure, not when a setting changes.

Your browser re-wraps the file key under HKDF(vault key, random freeze share), signs the deadline and the fingerprint of the frozen key with an Ed25519 key derived from the vault key, then hands the freeze share to the server.

The server refuses to return the share before the deadline, even to an authenticated session. At the deadline, your browser checks the original signature before restoring the key: the server cannot move the date without it showing.

Premium can place a file, an image or a web page of up to 100 KB on Arweave, a decentralized network built to keep data for 50 years and more, paid once. Encrypted, Arweave receives ciphertext under a fresh file key that only your vault can unwrap; public, it receives the file itself, readable by anyone with its arweave.net link, forever.

Your browser signs the copy, then the crycrypt server relays it to Turbo, the Arweave upload service, through a proxy: Turbo never sees your address. The relay keeps nothing — an encrypted copy passes through as ciphertext, a public one in the clear. The copy's identifier is stored only inside your encrypted metadata. A public copy can never be taken down — not by you, not by us — which is why the vault asks you to confirm it in red.

Premium is paid in cryptocurrency — BTC, ETH, USDT, USDC, SOL or XMR — through Plisio, on this site, from any wallet. Plisio receives a random order number, the price and the coin: never your email address, nothing from your vault.

A payment is only credited once its state has been read back from Plisio by the crycrypt server itself: a notification that claims a payment can at most trigger that check. The server keeps each payment — the paying address and the transaction — against your account; on public blockchains those are visible to anyone, while Monero hides them.