How KeepCloud Keeps Your Cloud Credentials Safe: AES-256-GCM Encryption

April 04, 2026

KeepCloud Engineering · Security · KeepCloud

9 min read

Hero image for: How KeepCloud Keeps Your Cloud Credentials Safe: AES-256-GCM Encryption
Security · KeepCloud Engineering
Every OAuth credential KeepCloud stores is encrypted using AES-256-GCM — an authenticated encryption algorithm that ensures both confidentiality (credentials can't be read without the key) and integrity (any tampering with stored data is immediately detectable).

When you connect your Google Drive, OneDrive, or Dropbox to KeepCloud, the OAuth authorization flow produces a short-lived access credential and a longer-lived refresh credential. These credentials are effectively keys to your cloud storage — and storing them insecurely would be a critical failure. KeepCloud encrypts them using AES-256-GCM before they ever touch storage.

What is AES-256-GCM?

AES stands for Advanced Encryption Standard — the symmetric encryption algorithm used in TLS, full-disk encryption (BitLocker, FileVault), Signal, WhatsApp, and virtually every secure communication system in existence. The "256" refers to the key size: 256 bits, or 32 bytes of cryptographic key material. At this key size, a brute-force attack is computationally infeasible with any technology that exists or is expected to exist in the foreseeable future.

GCM stands for Galois/Counter Mode — a mode of operation for AES that provides two properties simultaneously: confidentiality (the ciphertext reveals nothing about the plaintext to anyone without the key) and integrity authentication (any modification of the stored ciphertext — even a single bit — is detectable and causes decryption to fail immediately).

This second property is crucial. An attacker with write access to KeepCloud's credential store cannot meaningfully modify an encrypted credential to produce a different valid decryption. The GCM authentication tag mathematically binds the ciphertext to the encryption — tamper with either, and the decryption attempt throws an error immediately.

"AES-256-GCM doesn't just hide your credential from an attacker — it makes it detectable if anyone has touched it. Even one changed bit fails the authentication check."

The nonce: why encrypting the same credential twice produces different ciphertext

A critical design detail in KeepCloud's encryption is the use of a unique random nonce (number used once) for every single encryption operation. Each time a credential is encrypted, a fresh 12-byte random value is generated and used as input to the encryption algorithm alongside the key and the plaintext.

This means that if you disconnect and reconnect the same Google Drive account twice, the two stored encrypted values will be completely different — even though they wrap the same underlying credential. This property prevents an attacker from learning anything useful by comparing stored values across multiple encryption operations.

The nonce is not secret — it's stored alongside the ciphertext and is needed for decryption. What makes this safe is that its uniqueness, not its secrecy, is what matters. As long as the same nonce is never reused with the same key, the cryptographic security of GCM mode is preserved.

What is stored, exactly

In KeepCloud's credential store, each connected cloud account record contains only the encrypted payload (the nonce + ciphertext combination, base64-encoded) and the associated account metadata (provider name, your KeepCloud user ID, and the provider account's public email address). The plaintext credential is never written anywhere. The encryption key itself is stored separately from the credential store — it lives in KeepCloud's secure server environment configuration, not in the database.

When credentials are decrypted

Credentials are decrypted in memory only at the moment they are needed — to make an API call to Google Drive, OneDrive, or Dropbox. The decryption happens, the API call is made, and the plaintext is immediately released from memory. It is never logged, never written to disk, and never transmitted to any other system. If the decryption fails (because the authentication tag doesn't match — indicating possible tampering), the request is rejected immediately with an error.

Credential refresh and re-encryption

OAuth access credentials are short-lived — typically they expire after an hour. When a credential expires, KeepCloud uses the longer-lived refresh credential to automatically obtain a new access credential from the provider. The new access credential is then encrypted with a fresh nonce and the old value in the credential store is replaced atomically. You never need to re-connect your cloud accounts because of credential expiry — KeepCloud handles the refresh cycle silently and continuously.

What happens if KeepCloud's database is compromised

In the extremely unlikely event that KeepCloud's credential store were accessed by an unauthorized party, what they would find is a set of base64-encoded encrypted payloads — meaningless without the separately-held encryption key. The encryption key is not stored in the database and is not co-located with the credential records. Without the key, the AES-256 ciphertext is computationally unbreakable with any known technology.

This is defense-in-depth: even if one layer of security fails, the cryptographic layer remains intact.

Credential encryption flow
Figure 1 — Your cloud credential travels from provider to encrypted storage without ever existing in plaintext on disk.