How AIOZ Storage Encryption Works, From Passphrase to Key

AIOZ Storage encryption works in one mode today: every object is encrypted server-side by default, under keys derived from a bucket passphrase that AIOZ's docs say the company never stores. This guide covers that key chain, what server-side mode means for your plaintext, and why end-to-end mode isn't available yet.

TL;DR:

• AIOZ Storage encrypts objects with AES-GCM under a key chain rooted in a BIP39 passphrase.
• AIOZ never stores that passphrase.
• Server-side encryption is the default and the only mode you can use today. The end-to-end mode in the docs depends on a self-hosted gateway that hasn't been released.

Updated Oct 19, 2026: the end-to-end mode is now described as announced, not available. Its self-hosted gateway has no release yet. Also corrected the direction of the key chain.

Updated Oct 22, 2026: merged our separate posts Zero-Knowledge Encryption and AIOZ Storage's Two Modes and Is the AIOZ Storage Self-Hosted Gateway Available Yet? into this guide, adding the zero-knowledge comparison, passphrase handling and what a self-hosted gateway does.

What "AIOZ Never Stores Your Passphrase" Means

It means AIOZ Storage's own documentation states plainly, on two separate pages, that the company does not have or save your bucket's encryption passphrase. Without that passphrase, the files in the bucket cannot be decrypted by anyone who doesn't hold it, AIOZ included, once the passphrase is out of AIOZ's hands. That is a real, specific, verifiable claim about the passphrase itself.

It is a narrower claim than "AIOZ can never see your data," though, and the two get conflated more often than they should. In server-side mode, the default and the only one available today, the server decrypts your data on your behalf whenever it serves a request. The docs also describe an end-to-end mode in which the server would never receive plaintext, but it depends on a gateway you can't install yet (covered below).

A passphrase you lose is not recoverable by a support ticket. A passphrase an attacker steals is the only thing standing between them and your bucket. Everything below is about how that one passphrase turns into the actual encryption keys protecting every object you upload.

Why Your Bucket Gets a Seed Phrase, Not a Password

When you upload your first object, AIOZ Storage generates a bucket passphrase from the BIP39 wordlist, the same standard word list used to generate recovery phrases for crypto wallets. You can accept the auto-generated phrase, click refresh for a new one, write your own, or download it as a text file for backup. A wordlist passphrase is also easier to write down correctly and harder to mistype than a random hex string, while still carrying enough entropy to act as a real encryption secret.

Two credentials matter here, and it is easy to conflate them since AIOZ's own docs never explicitly contrast the two. Your account password (minimum 8 characters) logs you into the dashboard. Your bucket passphrase is the separate secret that decrypts your data. Losing the first is a password reset. Losing the second, with no backup, means the bucket's contents are gone for good, since AIOZ has no copy to restore from.

How Should You Store and Share a Bucket Passphrase?

Treat it like a crypto wallet seed phrase, because losing it has the same result. When you create a bucket, the dashboard makes you tick a box that reads "I understand, AIOZ doesn't have or save encryption passphrases. Without the passphrase, your files can't be accessed," per the Upload Your First Object guide.

Download the phrase as a text file the moment you create it. Then keep it somewhere that survives a lost laptop, such as a password manager or an encrypted backup drive. Don't paste it into email or chat, where it can sit unencrypted in a message history for years.

When teammates or scripts need access, give them an access grant instead of the raw phrase. You enter the bucket passphrase once while creating the grant, and they receive an access key, secret key and endpoint with a permission and an end date. One detail is easy to miss in the Manage Buckets tutorial. A bucket you create through the S3 API takes the passphrase you entered when you created those All Buckets credentials.

Inside the Key Derivation Chain

AIOZ Storage's documentation names AES-GCM, the NIST-standardized authenticated-encryption mode, as the cipher used to encrypt object data, and describes a hierarchical, one-directional key derivation chain rooted in that bucket passphrase (called the Root Secret, S0, in the technical docs). The chain works like this: a component key K0 is derived from S0, a new secret S1 is generated by hashing S0 together with a component identifier C1, a key K1 is derived from S1, and the encryption of C1 itself (E1) is produced by encrypting C1 under K0.

The important property is direction. Each path component is encrypted with a key derived from the components above it, so a key for one level (say, a folder prefix) can encrypt and decrypt everything below that level, but not the levels above it. That direction is what makes it possible to hand out narrower decryption capability for specific objects or sub-users without exposing the Root Secret itself, the same logic behind hierarchical deterministic wallets in cryptocurrency, applied to object storage instead of coins, a structural implication of the chain rather than a feature AIOZ's docs name directly. One detail the docs don't disclose: the specific key length for the AES-GCM implementation, so don't assume AES-256 in a compliance document just because it's the common default elsewhere.

Server-Side vs End-to-End Encryption

AIOZ Storage's docs describe two encryption modes, and the default, server-side, is the one you can use today. In server-side encryption, your data is encrypted as soon as AIOZ's server receives it, and decrypted on that same server before being sent back to you. AIOZ's own FAQ confirms this is the default: asked whether AIOZ Storage uses server-side or end-to-end encryption, it answers server-side, with end-to-end available if you build a self-hosted gateway. That gateway hasn't been released yet (next section). IPFS works differently: it encrypts data in transit but not the stored content, as privacy and encryption on IPFS explains.

In end-to-end encryption, both steps would happen on your side. Data would be encrypted before it leaves your machine and decrypted only after it comes back, so AIOZ's servers would only ever see ciphertext. The server-side flow you use today runs through the access grant, the credential that carries both encryption details and your read, write, list and delete permissions. You generate it on your client, and when you use the S3 API, you send it to AIOZ's registry service, which encrypts it with your S3 Access ID and issues a set of S3 credentials.

Revocation on an access grant is currently all-or-nothing. Revoking a primary grant kills every child grant derived from it, and AIOZ's docs list per-child revocation as a planned future release. Plan around that if you issue scoped grants to a team.

If the gateway ships as described, server-side keeps the advantage of needing no setup on your end, and end-to-end would remove AIOZ's servers from the decryption path at the cost of running your own infrastructure. AIOZ's docs describe the two modes by where encryption and decryption physically happen, server versus client, without detailing exactly how the bucket passphrase interacts with the server-side path.

Is AIOZ Storage Zero-Knowledge Encryption?

Not today. Zero-knowledge encryption means the provider storing your files can never read them, because you encrypt and decrypt on your own devices and the key never reaches its servers. Tresorit, for example, describes its storage as zero-knowledge end-to-end encryption, with keys that are never sent to its servers unencrypted.

AIOZ Storage's default is server-side, so its servers handle your plaintext while they serve a request. The end-to-end mode would meet the zero-knowledge bar, but it depends on the gateway covered below, which you can't install yet.

The default still differs from provider-managed encryption in one way. Amazon S3's default, SSE-S3, encrypts each object with 256-bit AES-GCM under keys that AWS generates and rotates, per the SSE-S3 guide. SSE-KMS gives you key policies, but its keys still live in AWS Key Management Service. AIOZ Storage's docs describe no AIOZ-held master key and say AIOZ doesn't save your passphrase. That sits between the two models: no stored key on AIOZ's side, but server-side decryption while you use the bucket.

Can You Run the Self-Hosted Gateway Today?

No. The docs' gateway page tells you to download the gateway CLI from GitHub, then run gw setup, gw server and gw add [access grant]. The repo it links, AIOZNetwork/w3s-gateway, holds only a README: "W3S Gateway CLI and tutorials will be available soon." It has no releases and no binary, and its last push was on January 18, 2024 (checked again Oct 22, 2026). Those three commands describe a tool you can't install yet.

A self-hosted S3 gateway is a small server you run that speaks the S3 API. Your apps send requests to it instead of the provider, and it encrypts each object on your machine before forwarding it, so the provider only stores ciphertext. The docs say gw add would generate a set of S3 credentials for the gateway itself, so your clients would point at its address instead of s3.aiozstorage.network. The trade-off is one more service in every read and write path: if it stops, your apps lose access even though the data is safe.

The docs also name the AIOZ Storage CLI as a second end-to-end path. The CLI page, though, documents the AWS CLI pointed at https://s3.aiozstorage.network. That sends your data to the hosted endpoint, so it gets server-side encryption like any other S3 client. If a file must never reach a provider in plaintext, encrypt it on your own machine before upload and keep that key outside AIOZ.

Frequently Asked Questions

Does AIOZ Storage use server-side or end-to-end encryption by default?
Server-side encryption is the default. AIOZ's own FAQ states this directly and adds that end-to-end encryption needs a self-hosted gateway, which hasn't been released yet.

Can AIOZ recover my data if I lose my bucket passphrase?
No. AIOZ Storage's documentation states that AIOZ does not have or save your encryption passphrase, so a lost passphrase with no backup means the bucket's contents cannot be decrypted by anyone, including AIOZ.

What cipher does AIOZ Storage use to encrypt objects?
AES-GCM, according to AIOZ Storage's own encryption documentation. The specific key length is not disclosed in the public docs.

Why does my bucket passphrase look like a crypto wallet seed phrase?
Because it is generated from the BIP39 wordlist, the same standard used for wallet recovery phrases, chosen because word-based phrases are easier to write down accurately than random hex strings.

Can I get end-to-end encryption on AIOZ Storage today?
Not through an AIOZ tool. The docs point to a self-hosted gateway (w3s-gateway), but its GitHub repo holds only a README with no release (checked Oct 19, 2026). The documented CLI is the AWS CLI against the hosted endpoint, which uses server-side encryption. If you need client-side encryption now, encrypt files yourself before upload.

Can I revoke just one derived access grant without affecting the others?
Not yet. Revoking a primary access grant currently revokes every child grant derived from it. AIOZ's documentation lists per-child revocation as a planned future release.

Is AIOZ Storage zero-knowledge?
Not today. The docs FAQ says AIOZ Storage uses server-side encryption, so its servers decrypt data while serving requests. End-to-end mode would meet the zero-knowledge bar, but its self-hosted gateway hasn't been released.

Should I share my bucket passphrase with my team?
Generally no. Create an access grant for each teammate or script instead, with only the permission it needs and an end date, so the raw passphrase stays with you.

Related Reading

• AIOZ Storage Explained: S3-Compatible Decentralized Storage - what AIOZ Storage is overall, how S3-compatible it really is, and its official pricing.
• AIOZ Storage Access Control: Macaroons and Access Grants - the access grant system that shares the eKey this article's key derivation chain protects.
• Migrate from Amazon S3 to AIOZ Storage with rclone - what happens to your existing S3 data's encryption once it's moved over.
• AIOZ Storage Glossary: Bucket, Passphrase, Macaroon - quick definitions for every term this article uses, including the Root Secret/passphrase naming mismatch.
• What Is a Checksum and How S3 Verifies Data Integrity - why the ETag isn't a reliable integrity check for SSE-C or SSE-KMS encrypted objects specifically.
• SSE-S3 vs SSE-KMS vs SSE-C: S3 Encryption Types Explained - the general industry framework AIOZ Storage's server-side default sits alongside.

References

• AIOZ Storage Documentation: Encryption Concepts
• AIOZ Storage Documentation: Server-Side vs End-to-End Encryption
• AIOZ Storage Documentation: FAQ
• AIOZ Storage Documentation: Upload Your First Object
• AIOZ Storage Documentation: Manage Buckets
• AIOZ Storage Documentation: Self-Hosted Gateway
• AWS: Server-Side Encryption with Amazon S3 Managed Keys (SSE-S3)
• BIP39: Mnemonic Code for Generating Deterministic Keys
• NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation (GCM and GMAC)