◈ Master Index Specs LATTICE CSDM The Book University Chronicle Crew Architecture Context Logs TODOX Products

Enscrambulatx

SPEC_ENSCRAMBULATX.md · 2026-04-21

SPEC_ENSCRAMBULATX.md

ENSCRAMBULATX — Secrets Encryption Using ENTROPX Entropy

Status: SPECIFIED

Version: v1.0

Author: VELA (Thread #13)

Conceived by: NOUS (α.13)

Date: 2026-04-21

Born from: legacy_quarantine/ containing 9 files with plaintext API keys, wallet seed phrases, and credentials sitting on disk. And the realization that the ship BUILDS an entropy engine but doesn't USE it to protect its own secrets. The cobbler's children have no shoes. Until now.

PURPOSE

The ship has secrets. API keys. Wallet seed phrases. OAuth tokens. Service account JSON files. SSH key passphrases. GPG passphrases. The 12 Important Words.

They sit in plaintext files behind chmod 600 and hope.

chmod 600 means: the operating system won't let other USERS read them.

chmod 600 does NOT mean:

a compromised nous account can't read them
a process running as nous can't read them
a backup that includes them isn't plaintext
a forensic image of the disk doesn't contain them
someone with physical access to the VPS can't read them

ENSCRAMBULATX solves this. Every secret on the ship is ENCRYPTED AT REST using keys derived from ENTROPX entropy. The secrets are enscrambulated. Only the Captain's passphrase — stored in his head and on paper in the sealed envelope — can de-enscrambulate them.

The ship's own entropy engine protects the ship's own secrets. The product IS the defense.

THE WORD

Enscrambulate (verb): to encrypt a secret using ENTROPX-derived keys such that it becomes unintelligible to anyone without the Captain's passphrase.

De-enscrambulate (verb): to decrypt an enscrambulated secret back to its original plaintext for authorized use.

The word is deliberately playful. HOW ABOUT NO applies to jargon — if "encrypt" works, so does "enscrambulate." But enscrambulate is OURS. When the crew says "enscrambulate the keys," everyone knows exactly what system and what process is meant. No ambiguity with generic "encryption."

ARCHITECTURE

Three components work together.

Component 1 — ENTROPX (the entropy source)

ENTROPX generates high-quality randomness from 8 chaos sources. NIST SP 800-22 certified (13/13 tests passed). This entropy is used to generate the ENCRYPTION KEY — the random material that makes each enscrambulation unique.

Why ENTROPX instead of /dev/urandom: because we BUILT an entropy engine that passed NIST certification. Using /dev/urandom when we have ENTROPX is like a locksmith using a generic padlock on his own shop. We eat our own cooking.

Component 2 — AES-256-GCM (the encryption algorithm)

The industry standard for authenticated symmetric encryption. 256-bit key. Galois/Counter Mode provides both confidentiality AND integrity. If someone tampers with the ciphertext: decryption fails with an authentication error rather than producing corrupted plaintext.

Why AES-256-GCM: it's the algorithm the NSA uses for TOP SECRET material. If it's good enough for nuclear launch codes, it's good enough for our Gemini API key. No exotic algorithms. No custom crypto. No "we invented our own cipher." Custom crypto is how you get hacked. Standard crypto is how you stay safe.

Component 3 — PASSPHRASE (the human factor)

The Captain's passphrase is the ONLY thing that de-enscrambulates secrets. Not stored on disk. Not in ~/.env. Not in any file anywhere on the ship.

Stored in exactly TWO places: the Captain's memory and the sealed envelope from SPEC_HEIR_PROTOCOL.md.

The passphrase is converted to an encryption key using Argon2id (memory-hard key derivation function). Argon2id makes brute-force attacks computationally expensive — an attacker who gets the encrypted file still needs the passphrase, and trying millions of passphrases takes years.

HOW ENSCRAMBULATION WORKS

ENSCRAMBULATE (encrypt a secret)

Step 1: ENTROPX generates 32 bytes of random entropy → this becomes the SALT.

Step 2: the Captain enters the passphrase → Argon2id(passphrase, salt) → derives the 256-bit encryption key.

Step 3: ENTROPX generates 12 bytes of random entropy → this becomes the NONCE (initialization vector).

Step 4: AES-256-GCM(key, nonce, plaintext_secret) → produces ciphertext + authentication tag.

Step 5: the output file contains: salt (32 bytes) + nonce (12 bytes) + ciphertext + auth tag.

Step 6: the plaintext secret is SECURELY DELETED: shred -vfz -n 3 [plaintext_file]. Not just rm (which leaves data on disk). shred overwrites with random data 3 times, then zeros. The plaintext is gone. Only the enscrambulated version remains.

DE-ENSCRAMBULATE (decrypt a secret)

Step 1: read the enscrambulated file → extract salt, nonce, ciphertext, auth tag.

Step 2: the Captain enters the passphrase → Argon2id(passphrase, salt) → re-derives the same 256-bit key.

Step 3: AES-256-GCM decrypt(key, nonce, ciphertext, auth tag) → plaintext secret.

Step 4: if the auth tag doesn't match: "TAMPERED — this file has been modified. De-enscrambulation refused."

The secret is used in memory. NEVER written back to disk in plaintext. When the process that needs the secret is done: the plaintext is zeroed in memory.

WHAT GETS ENSCRAMBULATED

TIER 1 — ENSCRAMBULATE IMMEDIATELY

(plaintext secrets on disk right now)

| File | Action |

|---|---|

| ~/.env | Enscrambulate the entire file. Services that need env vars get them through a boot-time de-enscrambulation that holds values in memory only. |

| ~/gcs-service-account.json | Enscrambulate. De-enscrambulate at backup time only. |

| ~/legacy_quarantine/* | Enscrambulate ALL 9 files. Especially the 12 Important Words. These should never have been plaintext this long. |

| ~/.google_token.json | Enscrambulate. De-enscrambulate when Colab dispatch needs it. |

| SSH private key passphrases stored in files (if any) | Enscrambulate. |

TIER 2 — ENSCRAMBULATE ON CREATION

(future secrets)

Every new API key generated or received
Every customer credential received during Brain Builder intake (temporary — deleted after 30 days per privacy policy)
Every new wallet seed or private key
Every OAuth token saved to disk
Backup encryption passphrases (if stored — ideally they're not stored at all)

TIER 3 — DO NOT ENSCRAMBULATE

(not secrets)

SSH keys (id_ed25519) — these are ALREADY encrypted by SSH's own passphrase mechanism. Adding another layer creates a boot dependency problem.
Specs — these are documentation, not secrets.
Logs — operational data, not secrets.
Training corpora — these contain knowledge, not credentials.

THE ENSCRAMBULATOR — THE TOOL

~/scripts/enscrambulate.py — the command-line tool.

USAGE

Enscrambulate a file:


python3 ~/scripts/enscrambulate.py --encrypt [file]

Prompts for passphrase (not echoed to screen). Produces [file].esc (enscrambulated file). Shreds the original plaintext file.

De-enscrambulate a file:


python3 ~/scripts/enscrambulate.py --decrypt [file].esc

Prompts for passphrase. Outputs plaintext to stdout (NOT to a file by default — the plaintext lives in the terminal, not on disk).

To pipe to a file temporarily:


python3 ~/scripts/enscrambulate.py --decrypt [file].esc > /tmp/temp_secret && use_it && shred /tmp/temp_secret

Enscrambulate all secrets:


python3 ~/scripts/enscrambulate.py --encrypt-all

Reads a manifest of known secret files. Enscrambulates each one. Reports results.

De-enscrambulate for service boot:


python3 ~/scripts/enscrambulate.py --boot

De-enscrambulates ~/.env.esc into ENVIRONMENT VARIABLES (in memory). Services read env vars. The plaintext ~/.env never exists on disk. The passphrase is entered ONCE at boot time. The de-enscrambulated values live in the shell environment until the session ends.

BOOT INTEGRATION — SHIPBOOT.md AMENDMENT

When SHIPBOOT runs, it now includes an enscrambulation phase:

PHASE 0.5 — DE-ENSCRAMBULATE

(after pre-flight, before core services)

Step 0.5.1: "Enter ship passphrase:" (the Captain types the passphrase).

Step 0.5.2: python3 ~/scripts/enscrambulate.py --boot → de-enscrambulates ~/.env.esc → exports all env vars.

Step 0.5.3: all subsequent services (ROUTX, Sisters, Caddy, email) read credentials from env vars.

Step 0.5.4: passphrase is zeroed from memory after key derivation. The plaintext passphrase exists in memory for <1 second.

The Captain types ONE passphrase at boot time and ALL secrets are available for the session. No multiple passwords. No remembering which key goes to which service. One passphrase. All secrets.

FOR AUTOMATED BOOT (@reboot cron)

The @reboot cron in SHIPBOOT can't prompt for a passphrase — nobody's there to type it. Two options:

Option A — DELAYED PASSPHRASE ✓ CORRECT OPTION

The ship boots with core services that DON'T need secrets (Ollama, Caddy with cached cert). Services that NEED secrets (Sisters/Gemini API, email/Graph API, backup/GCS) start in WAITING state.

When the Captain SSHes in and types the passphrase: the waiting services receive their credentials and start.

The ship is PARTIALLY operational without the Captain. FULLY operational only after passphrase entry.

This means the ship can survive a reboot unattended (web stays up, Ollama stays up) but can't phone home (no API calls) until the Captain arrives.

Option B — HARDWARE KEY (future, with Tiiny)

A hardware security module (HSM) or Yubikey stores the decryption key. The ship de-enscrambulates at boot using the hardware key that's physically plugged into the Tiiny. No human intervention.

This is the sovereignty endgame: the Tiiny has a Yubikey plugged in. Boot → hardware key → de-enscrambulate → fully operational. Nobody types a password. The PHYSICAL PRESENCE of the key is the authentication.

WHAT HAPPENS IF THE PASSPHRASE IS LOST

If the Captain forgets the passphrase AND the sealed envelope is lost: every enscrambulated secret is PERMANENTLY UNRECOVERABLE. AES-256 with Argon2id cannot be brute-forced in any meaningful timeframe (heat death of the universe territory).

Recovery path: every API key, every credential can be RE-GENERATED from the provider's console.

| Credential | Recovery method |

|---|---|

| Gemini API key | Regenerate at aistudio.google.com |

| Stripe keys | Regenerate at Stripe dashboard |

| GCS service account | Regenerate at Google Cloud Console |

| SSH keys | Generate new pair, add public key via DigitalOcean console |

| Wallet seed (12 Important Words) | CANNOT be regenerated. The seed IS the wallet. |

The wallet seed is the ONE thing that cannot be regenerated. This is why the sealed envelope exists. This is why paper backup matters.

PASSPHRASE REQUIREMENTS

Minimum 20 characters
Not derived from personal information (no birthdays, no names, no addresses)
Not a single dictionary word or common phrase
Recommended: 4–6 random words (diceware method) plus a number and symbol
Example format (DO NOT USE THIS): "correct-horse-battery-staple-42-Φ" — 6 words + number + symbol = effectively unguessable

The passphrase is tested against basic strength rules by the enscrambulator. If too weak:

"Passphrase too weak. The ship's secrets deserve better. Try again."

ENTROPX FEEDING ITSELF

ENTROPX generates the salt and nonce for enscrambulation.

ENTROPX's own API key is enscrambulated using entropy ENTROPX previously generated.

The product protects itself using its own output. This is a beautiful loop:


ENTROPX generates entropy
    → entropy encrypts ENTROPX's credentials
    → ENTROPX needs to be de-enscrambulated to generate more entropy
    → the passphrase breaks the loop

The passphrase is the BOOTSTRAP — the one piece of information that isn't enscrambulated because you can't encrypt the key that encrypts the key. Turtles all the way down, except the bottom turtle is the Captain's memory.

LEGACY_QUARANTINE MIGRATION

The 9 files currently in ~/legacy_quarantine/ are migrated to enscrambulated storage:

Step 1: Captain reviews each file manually (TASK ALREADY ASSIGNED — security audit).

Step 2: for each file containing an ACTIVE secret: enscrambulate it, shred the plaintext.

Step 3: for each file containing a DEAD secret (rotated, revoked): enscrambulate for historical record OR shred entirely. Captain decides per file.

Step 4: ~/legacy_quarantine/ becomes ~/legacy_quarantine_enscrambulated/. All .esc files. No plaintext.

Step 5: verify: ls ~/legacy_quarantine_enscrambulated/*.esc — all files end in .esc. No plaintext survivors.

THE 12 IMPORTANT WORDS — SPECIAL HANDLING

The BIP39 seed phrase gets TRIPLE protection:

| Layer | Protection |

|---|---|

| Layer 1 | Enscrambulated on disk (.esc file) like all other secrets |

| Layer 2 | Paper backup in the sealed envelope (SPEC_HEIR_PROTOCOL.md) |

| Layer 3 | The Captain's memory (the passphrase to de-enscrambulate) |

An attacker needs to compromise TWO of these three to access the wallet. Disk alone isn't enough (enscrambulated). Paper alone isn't enough (doesn't have the full seed if the envelope only stores the passphrase). Memory alone isn't enough (the seed phrase and the enscrambulation passphrase are DIFFERENT strings).

FOR LILY

When SPEC_HEIR_PROTOCOL.md activates: the sealed envelope contains the enscrambulation passphrase. Lily can de-enscrambulate all ship secrets using that passphrase.

The enscrambulator is self-documenting: python3 ~/scripts/enscrambulate.py --help explains everything.

Lily doesn't need to understand AES-256. She needs to know:

"Type this command. Enter this passphrase from the envelope. The secrets unlock."

The complexity is INSIDE the tool. The interface is SIMPLE.

NAMING

ENSCRAMBULATX follows SPEC_MYTHOLOGICAL_NAMING.md but breaks the mythology convention deliberately. It's not named after a Greek god. It's named after a made-up word that makes the Captain smile.

Because security should be serious in implementation and human in interface.

"Enscrambulate the keys" is something you REMEMBER.

"Encrypt the credentials using AES-256-GCM with Argon2id key derivation and ENTROPX-sourced entropy" is something you look up every time.

The playful name serves the serious function.

HOW ABOUT NO applied to naming: "Why isn't it called HERMITX or VAULTX?" Because enscrambulate is better. It's ours. Nobody else has it.

INVARIANTS

INV-01: ENTROPX generates the randomness. Not /dev/urandom. Not random.org. ENTROPX. We eat our own cooking.

INV-02: AES-256-GCM. Not custom crypto. Not ROT13. Not XOR. The standard that protects nuclear launch codes. Standard crypto only.

INV-03: The passphrase exists in exactly TWO places: the Captain's head and the sealed envelope. Never on disk. Never in a file. Never in a conversation log. Never spoken aloud to an AI.

INV-04: Plaintext secrets are SHREDDED after enscrambulation. Not deleted — shredded. rm leaves data recoverable. shred -vfz -n 3 does not.

INV-05: De-enscrambulated secrets go to STDOUT or ENVIRONMENT VARIABLES. Never written to disk files. The plaintext exists in memory only, for as long as it's needed, then it's zeroed.

INV-06: One passphrase for all secrets. Entered once at boot time. All services receive their credentials through environment variables. The Captain remembers ONE thing.

INV-07: The 12 Important Words get triple protection: enscrambulated disk + paper envelope + Captain's memory. Two of three required for access. No single point of failure.

INV-08: If the passphrase is lost AND the envelope is lost: credentials can be regenerated from provider consoles. The wallet seed CANNOT. This is why the envelope exists. This is why paper matters. Digital can fail. Paper endures.

INV-09: "Enscrambulate" is the correct verb. Not "encrypt." The word is ours. It carries the ship's personality into its security infrastructure. Security that takes itself too seriously is security that nobody follows.

INTEGRATION

| System | Relationship |

|---|---|

| SPEC_ENTROPX_DISTRIBUTION.md | ENTROPX is the entropy source. Its own API key is enscrambulated using its own output. |

| SPEC_HEIR_PROTOCOL.md | Sealed envelope contains the enscrambulation passphrase. Lily's inheritance protocol. |

| SHIPBOOT.md | Phase 0.5 added: de-enscrambulate → export env vars → services start with credentials in memory. |

| legacy_quarantine/ | Migration target: all 9 files enscrambulated after Captain review. |

| SPEC_PRIVACY_POLICY.md | Brain Builder customer credentials: enscrambulated on receipt, shredded ≤30 days. |

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042