How MemoryClaw Encrypts Your Data (And Why We Can't Read It)

“Why should I send my AI data to someone else's server?”

Fair question. Your OpenClaw assistant has deep context on your codebase, your workflow habits, your project-specific rules. Sending that to a third-party server feels wrong — and honestly, with most cloud backup services, it is wrong. They hold the encryption keys. They can read your data. You're trusting their security team, their employees, their compliance posture.

MemoryClaw takes a different approach: we never see your data unencrypted. Not at rest, not in transit, not during processing. The encryption key is derived from a passphrase that only exists on your machine. Our servers store ciphertext that is, to us, indistinguishable from random noise.

This post explains exactly how that works. No hand-waving, no marketing language. Just the implementation.

Zero-knowledge architecture

“Zero-knowledge” in our context means the server has zero knowledge of the plaintext contents of your backups. The encryption and decryption happen entirely on your machine, inside the MemoryClaw CLI. The server is a dumb storage layer that accepts and returns encrypted blobs.

Here is the actual data flow when you run memoryclaw push:

  YOUR MACHINE                              MEMORYCLAW SERVER
  ────────────                              ─────────────────

  ~/.openclaw/
       │
       ▼
  ┌──────────┐
  │  1. ZIP   │  Compress all files (zlib level 9)
  └────┬─────┘
       │
       ▼
  ┌───────────────────────────────────────┐
  │  2. DERIVE KEY                        │
  │  passphrase ──► scrypt(N=16384) ──► key│
  │  (32-byte random salt each time)      │
  └────┬──────────────────────────────────┘
       │
       ▼
  ┌───────────────────────────────────────┐
  │  3. ENCRYPT                           │
  │  AES-256-GCM(key, random 16-byte IV) │
  │  Output: salt ∥ iv ∥ authTag ∥ cipher │
  └────┬──────────────────────────────────┘
       │
       ▼
  ┌──────────┐        HTTPS (TLS 1.3)       ┌──────────────┐
  │ .enc blob├──────────────────────────────►│ Encrypted    │
  └──────────┘                               │ blob storage │
                                             └──────────────┘

  Server receives: opaque bytes. No key. No passphrase.
  Server stores: salt ∥ iv ∥ authTag ∥ ciphertext.
  Server can decrypt: nothing.

The restore path (memoryclaw pull) is the exact reverse: download the encrypted blob, derive the same key from your passphrase and the embedded salt, decrypt, unzip. If you provide the wrong passphrase, GCM authentication fails and you get nothing — not garbled data, just an error.

The encryption: AES-256-GCM + scrypt

Let's break down the two cryptographic primitives and why we chose them.

AES-256-GCM — authenticated encryption

AES-256-GCM is an authenticated encryption with associated data (AEAD) cipher. It provides two guarantees simultaneously:

• Confidentiality — The ciphertext reveals nothing about the plaintext without the key.
• Integrity/authenticity — The 128-bit authentication tag detects any tampering. If even a single bit of the ciphertext, IV, or auth tag is modified, decryption fails. This prevents an attacker from silently corrupting your backup.

AES-256-GCM is the same cipher used by the U.S. government for TOP SECRET classified data (per CNSA Suite), by TLS 1.3 for web traffic, and by virtually every major cloud provider for data-at-rest encryption. It is fast, hardware-accelerated on modern CPUs (AES-NI), and has decades of cryptanalytic scrutiny behind it.

scrypt — passphrase to key derivation

Your passphrase is not your encryption key. It gets transformed into a 256-bit key through scrypt, a memory-hard key derivation function designed specifically to resist brute-force attacks.

Here is the actual function from our codebase:

// plugin/src/lib/crypto.ts

const ALGORITHM   = "aes-256-gcm";
const SALT_LENGTH = 32;   // 256-bit random salt
const IV_LENGTH   = 16;   // 128-bit random IV
const KEY_LENGTH  = 32;   // 256-bit derived key
const SCRYPT_COST = 16384; // N parameter (2^14)

function deriveKey(passphrase: string, salt: Buffer): Buffer {
  return scryptSync(passphrase, salt, KEY_LENGTH, {
    N: SCRYPT_COST,
  });
}

Key details:

• 32-byte random salt — Generated via crypto.randomBytes(32) for every single backup. Even if you use the same passphrase for 1,000 backups, each one produces a different encryption key. An attacker cannot precompute a rainbow table.
• N=16384 (2^14) — The scrypt cost parameter. This controls how much memory and CPU each key derivation attempt requires. At N=16384, each derivation needs ~16 MB of RAM and takes measurable wall-clock time. A brute-force attacker trying billions of passphrases cannot parallelize cheaply with GPUs because scrypt is memory-hard by design.
• 16-byte random IV — A fresh initialization vector for every encryption operation, ensuring identical plaintext never produces identical ciphertext.

The encrypted output is a single binary blob with a deterministic layout:

┌──────────┬──────────┬──────────┬─────────────────┐
│  Salt    │  IV      │ AuthTag  │  Ciphertext     │
│ 32 bytes │ 16 bytes │ 16 bytes │ variable length │
└──────────┴──────────┴──────────┴─────────────────┘

Total overhead: 64 bytes per backup (negligible).

On decryption, the CLI reads the salt, re-derives the key with your passphrase, reads the IV and auth tag, and feeds everything into AES-256-GCM. If the passphrase is wrong, the auth tag check fails and the operation aborts cleanly — no partial output, no information leakage.

What MemoryClaw stores vs. what it can see

Transparency matters. Here is a complete breakdown of what our servers store and what is visible to us:

The metadata we do see — size, timestamp, claw ID — is necessary for basic service operation: enforcing storage quotas, showing backup history in your dashboard, and routing downloads to the right blob. None of it reveals what is inside the backup.

Note that the SHA-256 checksum is computed over the encrypted blob, not the plaintext. It tells us whether the upload completed without corruption. It tells us nothing about your data.

What happens if MemoryClaw gets breached

No security discussion is complete without the breach scenario. Let's say an attacker gains full access to our servers and downloads every backup blob we store. What do they get?

• Encrypted blobs — Each one is AES-256-GCM ciphertext. To decrypt any single backup, the attacker needs the user's passphrase. There is no master key, no key escrow service, no “admin decrypt” endpoint.
• Unique salt per backup — Even if two users pick the same passphrase, their backups produce different keys (different random salts). The attacker cannot crack one and apply it to others.
• scrypt cost — At N=16384, each brute-force attempt against a single backup costs real memory and CPU time. An attacker cannot simply throw a GPU cluster at the problem the way they can with PBKDF2 or bcrypt — scrypt's memory-hardness makes parallelization expensive.
• No password reuse attack — Your encryption passphrase is separate from your MemoryClaw account password. Even if the account database is compromised, the attacker does not learn your encryption passphrase (it is never sent to our servers).

To put a number on it: AES-256 has a key space of 2^256 — roughly 1.16 x 10^77 possible keys. For reference, the estimated number of atoms in the observable universe is approximately 10^80. Brute-forcing the key directly is not a realistic attack vector with any foreseeable technology.

The practical attack would be brute-forcing the passphrase, which is why we enforce an 8-character minimum and strongly recommend a unique, high-entropy passphrase. With a strong passphrase and scrypt, even a targeted attack is computationally infeasible.

Local passphrase storage

For convenience, MemoryClaw can save your passphrase locally so that automated backups (push --auto) work without prompting. This is opt-in — we ask during your first push.

When saved, the passphrase is encrypted with AES-256-GCM using a machine-specific key derived from your home directory path and system architecture via scrypt. The resulting file is stored at ~/.config/memoryclaw/.passphrase with 0600 permissions (owner-read-write only). It is also bound to your account email — if you log in with a different account, the saved passphrase is rejected automatically to prevent cross-account data leakage.

Running memoryclaw logout clears the saved passphrase, stored credentials, and device configuration.

Verify it yourself

We believe the strongest security claim is one you can verify independently. The entire encryption implementation lives in a single file: plugin/src/lib/crypto.ts. It is 46 lines of code. There are no hidden layers, no obfuscation, no network calls.

import { randomBytes, scryptSync,
         createCipheriv, createDecipheriv } from "node:crypto";

export function encrypt(data: Buffer, passphrase: string): Buffer {
  const salt = randomBytes(32);
  const iv   = randomBytes(16);
  const key  = scryptSync(passphrase, salt, 32, { N: 16384 });

  const cipher    = createCipheriv("aes-256-gcm", key, iv);
  const encrypted = Buffer.concat([cipher.update(data), cipher.final()]);
  const authTag   = cipher.getAuthTag();

  return Buffer.concat([salt, iv, authTag, encrypted]);
}

export function decrypt(data: Buffer, passphrase: string): Buffer {
  const salt       = data.subarray(0, 32);
  const iv         = data.subarray(32, 48);
  const authTag    = data.subarray(48, 64);
  const ciphertext = data.subarray(64);

  const key = scryptSync(passphrase, salt, 32, { N: 16384 });

  const decipher = createDecipheriv("aes-256-gcm", key, iv);
  decipher.setAuthTag(authTag);

  return Buffer.concat([decipher.update(ciphertext), decipher.final()]);
}

That is the complete encryption and decryption logic. No key transmission, no server callbacks, no telemetry. Node.js's crypto module delegates to OpenSSL under the hood, giving you battle-tested, FIPS-validated cryptographic primitives.

We welcome community audits. If you are a security researcher and find an issue, reach out at info@memoryclaw.ai. We take every report seriously.

The tradeoff: no recovery without your passphrase

Zero-knowledge encryption comes with a real tradeoff: if you lose your passphrase, we cannot help you recover your data. There is no “forgot passphrase” button, no admin override, no support ticket that will unlock your backups. This is by design.

We make this tradeoff deliberately. The alternative — holding a recovery key on our side — would mean your data is only as safe as our key management. A single insider threat, a single misconfigured server, and the entire trust model collapses. We would rather give you a system that is genuinely secure than one that is convenient but compromised.

Our recommendation: choose a strong, unique passphrase and store it in a password manager. The MemoryClaw CLI can also save it locally (encrypted with a machine-specific key) for automated backups.