> For the complete documentation index, see [llms.txt](https://oten.gitbook.io/drive-support/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://oten.gitbook.io/drive-support/security-model/create-a-new-vault.md).

# How your data is protected

A plain-language summary of what Oten Drive does to keep your files private. The goal is for these claims to be **verifiable in behavior**, not just asserted.

A file's full round trip — your device does all the crypto; the server only ever moves ciphertext:

```mermaid
sequenceDiagram
    participant U as Your device
    participant S as Oten Cloud
    participant V as Another device
    U->>U: Encrypt file on device
    U->>S: Upload ciphertext + opaque metadata
    Note over S: Stores blobs only — no keys, no plaintext
    S-->>V: Download ciphertext
    V->>V: Decrypt locally with your keys
```

### Everything is encrypted on your device

* File contents, file names, folder structure, and vault names are encrypted **on your device** before anything is written to disk or sent over the network.
* Plaintext exists **only in memory**, only while a file is open, and is purged when you close it or lock the vault.
* Encryption uses strong, modern, authenticated algorithms with **post-quantum-ready** (KEM-based) key handling. It's on by default and there's nothing to configure. A public **cryptography white paper** documents the design.

### Keys stay with you

* Your seeds and keys live in the operating system's **secure storage** (Keychain), protected by device hardware. They are **not** escrowed in the cloud.
* Keys are derived in a hierarchy — **User → Vault → Shadow Layer → file** — so each layer of access is independent.
* Keys reach a new device only through **your User Recovery Key**, never a cloud key backup.
* **Passwords are verified on your device**, against the encrypted data itself. They are never sent to or stored on the server — so there's nothing for the server to check, leak, or be compelled to reveal.

### The server can't read your files

* Oten Cloud is **zero-knowledge**: it stores only opaque encrypted blobs plus minimal bookkeeping, and holds **no** decryption keys.
* No one in the middle — not the network, not Oten — can read your files, even under legal compulsion. There's no plaintext to hand over.

### Deletion is real

* Permanently deleting data (Delete everything) securely wipes the keys involved, making that content **unrecoverable by anyone**.

### Integrity & resilience

* **Safe Writes** protect against corruption; **Auto-Lock** keeps files sealed even on a crash. Sync uses conflict-aware versioning so concurrent edits don't silently clobber each other.

### Under the hood (for the curious)

You don't need any of this to stay safe — it's automatic. But "encrypted on your device" is doing real work, and here's what it actually means:

* **Files are split into chunks.** A file isn't stored as one lump. It's cut into fixed-size pieces, and each piece is sealed on its own with **AES-256-GCM** — authenticated encryption that also detects tampering.
* **Every file gets its own key.** That per-file key is random and unique, so exposing one file's key tells an attacker nothing about any other file.
* **Your file keys are sealed with post-quantum crypto.** Each file key is wrapped to your vault using **ML-KEM-768**, a NIST-standardized post-quantum algorithm — so even a future quantum computer can't unwrap it.
* **Names and folders live in an encrypted index.** File names and folder structure are kept in an encrypted local database (the "manifest"), never written in the clear.
* **Sharing re-seals; it doesn't expose.** When you share, your file key is re-wrapped with ML-KEM to the recipient's public key (plus a share password). Only they can open it — the server still sees nothing.

```mermaid
flowchart LR
    F["Your file"] --> C["Split into chunks"]
    K["Per-file key"] --> E["Each chunk sealed<br/>AES-256-GCM"]
    C --> E
    K --> W["File key wrapped to your vault<br/>ML-KEM-768 (post-quantum)"]
    N["Names & folders"] --> M["Encrypted manifest"]
    E --> UP["Upload: ciphertext only"]
    W --> UP
    M --> UP
    UP --> S["Oten Cloud<br/>stores opaque blobs only"]
```

The upshot is the same claim as above, now visible in the mechanics: what leaves your device is ciphertext plus keys that are themselves sealed to keys only you hold. The full design — key hierarchy, decoy slots, signatures — is documented in the public **cryptography white paper**.

### The trade-off

Because only you hold the keys, **Oten cannot recover your data for you.** If you lose your passwords *and* your recovery keys, the data is gone. That limitation is what makes the privacy trustworthy.

> See also: What the server can see · What Shadow Layers do not protect against