> For the complete documentation index, see [llms.txt](https://docs.neova.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.neova.io/our-product/security.md).

# Security

Files leave the browser encrypted. Keys live in a vault, separate from storage. The swarm only admits authorized nodes.

## Security

On a distributed network, a CID is enough to ask for bytes, and a gateway is there to return them. Access control on the drive matters. It is the second lock. The first lock is whether those bytes are readable at all.

NeoDrive uses three locks, and they stack.

### The file leaves encrypted

Encryption happens in the browser, with **AES-GCM**, before the upload request is sent.

For every file, the client draws a random **12-byte initialization vector** and writes it in front of the ciphertext. That is the payload NeoDrive streams to the node: IV, then ciphertext. The same document uploaded twice produces two different payloads and two different CIDs, because the IV is new each time.

Download is the same path in reverse. The gateway returns the encrypted bytes. The browser decrypts them after the session has been allowed to fetch the key. Kubo, the indexer, and the accelerator only ever handle ciphertext.

You do not pick a “secure” folder. Every upload takes this path.

Names, folders, and ownership stay in the drive index, which is what makes the product searchable and fast. The document itself is not in that index. A copy of a node’s repository is a pile of blocks that do not open.

### The key lives apart from the file

Each account has an AES-256 key, generated at random and stored in a dedicated **key vault** (HashiCorp Vault). The browser asks the vault for that key when it needs to encrypt or decrypt, over the user’s own session. The drive service is a different system. It stores ciphertext and CIDs. It does not store the key, and it does not call the vault on the upload path.

This is what makes NeoDrive openable on an ordinary Monday. You sign in. The browser retrieves the key. Your files decrypt. There is no seed phrase taped under the keyboard, because a drive for a whole team has to be recoverable by the person who owns the account.

It is also a precise claim. Copying a storage node, or copying the file table, does not reveal the documents. The vault is the place the key can be retrieved by an authorized session. Confidentiality holds against the storage layer. The account session is the thing you protect the way you protect any cloud login: password, SSO, and machines you trust.

A later tightening is already on the map: a data key per file, wrapped by the account key, so one file can be retired without treating the whole history as a single secret. Today the boundary that matters is in place. Cleartext stops at the browser.

### The network is a members-only swarm

Ciphertext still deserves a closed set of machines.

* A **swarm key** is required to complete the handshake. Nodes outside the network never become peers.
* The public DHT is off, so CIDs are not published into the global IPFS directory.
* The Private Indexer accepts announces from authorized peers and ranks those peers for the accelerator.
* **Swarm Keys v2** adds what a shared secret cannot: a name for each node, a role, an expiration, and revocation of one machine while the others stay up. That control plane is the open grant described in Open-source contribution. The swarm you use today is already closed with v1.

Isolation decides who is allowed to store and forward. Encryption decides who is allowed to read. They solve different problems, and NeoDrive runs both.

### Along the life of a file

| Moment                            | What holds                                       |
| --------------------------------- | ------------------------------------------------ |
| Before the bytes leave the laptop | AES-GCM in the browser                           |
| On a node’s disk                  | Ciphertext only                                  |
| In the drive database             | Name, folder, size, CID — the document stays out |
| When you download                 | Decryption in the browser, after your session    |
| Who may host the blocks           | Swarm membership                                 |
| Who can be removed later          | Revocation, the job of Swarm Keys v2             |

For organizations that also need a region, a role split, or their own nodes on the same swarm, continue with Enterprise.