How AIOZ Storage Encryption Works: Zero-Knowledge Keys
AIOZ Storage encryption is built around a passphrase that only you control, one AIOZ's own documentation says the company never stores. Every bucket gets its own passphrase, and that passphrase, not an account password, is what actually protects your data. Whether that also means AIOZ can never see your data at all depends on which of its two encryption modes you use, a distinction other S3-compatible storage explainers tend to skip. This article covers the exact key derivation chain, both encryption modes and how they differ, and where the documented gaps in AIOZ's own security model sit.
TL;DR:
- AIOZ Storage encrypts objects with AES-GCM under a key chain rooted in a BIP39 passphrase.
- AIOZ never stores that passphrase, under either encryption mode.
- Server-side encryption is the default; true end-to-end encryption means running AIOZ's self-hosted gateway yourself.
What "AIOZ Never Stores Your Passphrase" Actually 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. Whether AIOZ's infrastructure ever touches your plaintext depends on which encryption mode you use, covered later in this article: end-to-end mode is architected so the server never receives it; server-side mode, the default, has the server decrypting data on your behalf when it serves a request. AIOZ's docs describe the passphrase-non-retention guarantee clearly. They do not spell out with the same clarity how that guarantee interacts with the server-side path, so this article treats that specific mechanism as undocumented rather than assuming the strongest possible reading.
A passphrase you lose is not recoverable by a support ticket regardless of mode. 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.
Inside the Key Derivation Chain
AIOZ Storage's documentation names AES-GCM 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. A key derived further down the chain can decrypt what came before it, but that ability does not run in reverse. 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. AIOZ's docs describe the property; they do not spell out this specific use case, so read it as a structural implication rather than a named feature. AIOZ's docs do not disclose a key length for the AES-GCM implementation, so treat that detail as undocumented rather than assuming a specific bit strength.
Server-Side vs End-to-End Encryption
AIOZ Storage supports two distinct encryption modes, and by default you are using the first one. 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 directly whether AIOZ Storage uses server-side or end-to-end encryption, the answer is server-side, with end-to-end available if you build a self-hosted gateway.
In end-to-end encryption, both steps happen on your side instead. Encryption occurs before data ever leaves your machine, and decryption happens only after it arrives back, which means AIOZ's servers only ever see ciphertext. The credential that makes this possible is the access grant, the same artifact that carries your read, write, list, and delete permissions, encrypted at rest using your S3 Access ID so that only your own client can unlock it.
The tradeoff is direct: server-side is the default because it requires no extra setup on your end. End-to-end removes AIOZ's servers from the decryption path entirely, at the cost of running additional infrastructure yourself. AIOZ's docs describe the two modes by where encryption and decryption physically happen (server versus client) without spelling out exactly how the bucket passphrase interacts with the server-side path, so treat that specific mechanism as undocumented rather than assuming it works the same way as the end-to-end flow.
Running a Self-Hosted Gateway for True End-to-End Encryption
To get end-to-end encryption, AIOZ's docs point you to two separate paths: use the AIOZ Storage CLI directly, or deploy AIOZ's self-hosted gateway (source published on GitHub as w3s-gateway), so encryption and decryption happen inside your own environment before anything touches the network. Setting up the gateway is three commands: gw setup to initialize it, gw server to run it, and gw add [access grant] to connect it to an access grant generated from your AIOZ Storage account.
This is aimed at teams with real end-to-end encryption requirements, not casual users. AIOZ's documentation does not publish a Docker image, port list, or config file schema for the gateway, so plan on reading the w3s-gateway source on GitHub if you need operational detail beyond the three-command quickstart. What the gateway buys you is control: your organization holds the only environment where plaintext data and decryption keys ever meet.
What AIOZ Storage's Docs Do Not Tell You
Being direct about the gaps matters more here than in most feature explainers, since encryption claims are exactly the kind of thing worth verifying rather than taking on faith. AIOZ Storage's documentation does not publish an AES key length, so do not assume AES-256 just because it is common elsewhere. It does not publish a replication factor, node count, or geographic distribution for how encrypted data is spread across the network, only that AIOZ DePIN "inherently supports replication by default." And access grant revocation is currently all-or-nothing: revoking a primary access grant kills every child grant derived from it, with no way yet to revoke a single child individually. AIOZ's own docs list granular revocation as a planned future release, not a shipped capability, so do not treat it as available today.
None of these gaps contradict the passphrase-non-retention guarantee described above, but they are the honest boundary of what AIOZ currently documents. If your use case depends on a specific key length, a specific replication guarantee, or fine-grained revocation, verify directly against AIOZ's current docs before you build on an assumption.
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, with end-to-end encryption available only if you deploy the self-hosted gateway.
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.
How do I get end-to-end encryption on AIOZ Storage instead of server-side?
Use the AIOZ Storage CLI directly, or deploy AIOZ's self-hosted gateway (w3s-gateway). The gateway's three setup commands are gw setup, gw server, and gw add [access grant].
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.
Does AIOZ Storage publish a replication factor for encrypted data?
No. The docs state that AIOZ DePIN supports replication by default but do not publish a specific replication factor, node count, or geographic distribution.
Related Reading
- AIOZ Storage Explained: S3-Compatible Decentralized Storage - what AIOZ Storage is overall, how S3-compatible it really is, and its official pricing.
- Zero-Knowledge Encryption: AIOZ Storage Can't See Your Data - a deeper look at the passphrase model this article introduces, including how to actually manage and back it up.
- 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.
References
Related Content
Generating Presigned URLs on AIOZ Storage with Python
AIOZ storage presigned url python code needs one boto3 method, generate_presigned_url, plus the same endpoint config every other AIOZ Storage script uses.
How AIOZ Storage Pricing Works: Storage and Delivery Costs
AIOZ Storage costs $17 per TB for storage and $5 per TB for delivery, billed hourly with no free tier. Here is exactly how billing and penalties work.
How AIOZ Storage Uses AIOZ DePIN for Replication
AIOZ storage depin replication runs on the same network as AIOZ Stream. Here is exactly what AIOZ's docs confirm about redundancy, and what they don't.
Migrate from Amazon S3 to AIOZ Storage with rclone
Migrating from Amazon S3 to AIOZ Storage is a config change, not a rewrite. Here is the exact rclone setup, sync command, and the one documented gotcha.
AIOZ Storage vs Storj: Two DePIN Platforms Compared
AIOZ storage vs Storj is the closest architecture match in decentralized object storage. Both use macaroon access grants. Here is where they actually differ.
AIOZ Storage vs the Alternatives: A Full Comparison
AIOZ storage vs alternatives means five real competitors, not one. Here is honest pricing and architecture for AWS, R2, B2, Wasabi, and Storj against AIOZ.