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.

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, 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. 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, 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 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. Revocation on an access grant is currently all-or-nothing: revoking a primary grant kills every child grant derived from it, with no way yet to revoke a single child individually, AIOZ's own docs list per-child revocation as a planned future release, not a shipped capability, worth planning around if you're issuing scoped grants to a team.

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 detailing exactly how the bucket passphrase interacts with the server-side path specifically.

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.

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.

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.
• Setting Up a Self-Hosted S3 Gateway for AIOZ Storage - the full step-by-step walkthrough for the gateway this article introduces as one of the two end-to-end encryption paths.
• 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 own two-mode model sits alongside.

References

• AIOZ Storage Documentation: Encryption Concepts
• AIOZ Storage Documentation: Server-Side vs End-to-End Encryption
• BIP39: Mnemonic Code for Generating Deterministic Keys
• NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation (GCM and GMAC)