AES-256-GCM does two jobs at once
It encrypts your data so nobody without the key can read it, and it produces a short authentication tag that proves the data wasn't altered. Flip a single bit of the ciphertext — a corrupted disk, a man-in-the-middle, a malicious storage operator — and decryption doesn't quietly hand back garbage. It fails. That distinction is the whole point, and most "encrypted cloud" pitches skip it.
The name unpacks cleanly. AES is the Advanced Encryption Standard, the block cipher the world settled on after a public NIST competition that ended in 2001. 256 is the key length in bits. GCM is Galois/Counter Mode — the part that turns a raw block cipher into something safe to use on a real file, and that catches tampering.
AES-256: the lock
AES on its own is a block cipher. It takes a 128-bit chunk of data and a key, then scrambles the chunk through rounds of substitution and permutation — 14 of them for a 256-bit key. Without the key, reversing those rounds isn't a matter of being clever. The search space for a 256-bit key is 2²⁵⁶, a number with 78 digits. No known practical attack does meaningfully better than trying every key, and trying every key is not happening this side of the heat death of the sun.
So why does everyone say 256 when 128 is already far beyond brute force? Margin. A 128-bit key is secure today; 256 buys headroom against future cryptanalysis and large-scale quantum search. Grover's algorithm roughly halves the effective bits, so 256 degrades to a still-comfortable 128. It's cheap insurance — on modern CPUs, 256-bit AES is only marginally slower than 128.
GCM: the tamper-check
A block cipher alone has a gap. It tells you nothing about whether the ciphertext you received is the ciphertext that was written. An attacker who can't read your data can still try to change it. GCM closes that gap.
Mechanically, the "counter" half (CTR mode) turns AES into a stream cipher: it encrypts a running counter and XORs the result with your data, so you can encrypt any length, not just neat 128-bit blocks. The "Galois" half runs the ciphertext through a fast field operation — multiplication in a Galois field — to produce a 128-bit authentication tag. On decryption, the receiver recomputes the tag and compares. Match, and you get your plaintext. Mismatch, and the operation returns an error. No plaintext, not even a best-effort guess.
This is authenticated encryption, and it's why GCM won out over older modes like CBC, where you bolted on a separate integrity check and got the order wrong at your peril. With GCM, confidentiality and integrity come from one primitive, standardized by NIST in SP 800-38D.
What this means for your files
At Beebeeb, every file you upload is encrypted client-side with AES-256-GCM before it leaves your device. Large files are split into 1 MB chunks, and each chunk is sealed independently. The on-disk format for a chunk is three parts laid end to end:
nonce— 12 random bytes (96 bits), fresh for every chunkciphertext— your encrypted datatag— 16 bytes (128 bits), the authentication tag
The practical upshot: our servers in Falkenstein, Germany hold nothing but those opaque blobs. The decryption key is derived on your device and never transmitted. We can store your data, replicate it, and serve it back — and we still cannot read it, because we don't have the key. That isn't a policy promise. It's what the math allows us to do, and nothing more.
The tamper-check earns its keep here too. If a storage bug, a hardware fault, or a hostile actor altered one byte of one chunk, the GCM tag would not verify and the download would fail loudly instead of silently returning a corrupted file. You'd know. Integrity isn't a feature we layer on top; it falls out of the cipher itself.
The honest caveat: nonces
AES-256-GCM has one sharp edge, and pretending it doesn't exist would be exactly the marketing we're against. GCM's security depends on never reusing a nonce with the same key. Reuse one and you don't get slightly weaker security — you get a complete collapse. Two messages under the same key and nonce leak the XOR of their plaintexts, and a known technique (the "forbidden attack," documented during GCM's standardization) can recover the authentication key and forge valid tags.
This is real, it has bitten production systems, and it's the single thing an implementation has to get right. The defense is simple: a fresh random nonce for every encryption. A 96-bit random nonce gives a vanishingly small collision probability across any realistic number of chunks, and Beebeeb derives a distinct key per file on top of that, so the same nonce in two different files isn't even under the same key. We don't reuse nonces. The wire format above carries a unique one per chunk for exactly that reason.
Why not "military-grade"?
You'll see AES-256 sold as "military-grade" and "bank-grade." We don't use those words. They mean nothing technically — there's no grade certificate, and the cipher protecting a classified document is the same cipher protecting your HTTPS connection to your bank. AES-256-GCM is good because it's a well-studied, hardware-accelerated, authenticated cipher with a quarter-century of public cryptanalysis behind it. That's a real reason. "Military-grade" is a vibe.
The cipher is also fast. Every modern CPU ships dedicated AES instructions (Intel and AMD call it AES-NI), which drop the cost of AES from roughly 28 CPU cycles per byte to about 3.5 — close to an order of magnitude. Client-side encryption used to mean a noticeable wait. On current hardware it's effectively free, which is why we do it on every byte by default instead of as an opt-in.
AES-256-GCM is one link in a longer chain. It sits underneath the key derivation, sharing, and recovery that make the whole thing usable. For how keys are derived and where they live, our security page walks through the hierarchy, and the features page shows what client-side encryption actually buys you day to day.