Encryption.

Both modes use grid-aware key derivation. For the CLI commands, see CLI.

grid lock walks the grid and encrypts the body of every cell whose sensitivity is above public. The cell's address, type, written-by, written-at, and sensitivity label remain in plaintext on disk. Only the body is replaced by ciphertext.

Keys are derived per-level. The team key encrypts team-sensitivity bodies; the private key encrypts private bodies; the sealed key encrypts sealed bodies. Sharing the team key lets a reader see team-level cells without exposing private or sealed bands.

grid unlock reverses the operation using the same passphrase.

CLE is the right mode when you want the grid's structural shape to remain inspectable but the contents of sensitive cells protected at rest.

grid seal encrypts the entire file as one opaque blob. The result is a text wrapper of the form:

GLE:1:[x,y,z]:<base64 payload>

where [x,y,z] is the grid's master coordinate. After sealing, the file is no longer a binary grid; grid status cannot parse it. The coordinate prefix is the only metadata visible from the outside; an observer learns the grid's coordinate but nothing about its contents.

grid unseal decrypts the wrapper and restores the binary grid file.

GLE is the right mode for archival, transport, or any location where you do not trust the host.

To read a CLE+GLE grid: unseal first, then unlock. Both passphrases are needed.

Both CLE and GLE keys are derived as:

passphrase_key = PBKDF2-HMAC-SHA512(
    passphrase, salt, 600,000 iterations, 32-byte intermediate output
)

grid_key = SHA-512( passphrase_key || SHA-512(genesis.body) )[:32]

The 32-byte PBKDF2 result is an intermediate, not the AES key itself. The AES key is grid_key: the final SHA-512 output truncated to 32 bytes. AES-256-GCM is the actual cipher for both CLE and GLE. The hash chain above derives the 32-byte AES key; AES-GCM does the encryption itself, with a fresh random nonce per encrypt operation.

The genesis cell's body hash is mixed into the key material. Two consequences:

• Same passphrase, different grids → different keys. A leaked passphrase from one grid does not open any other grid, even if both were locked or sealed by the same operator.
• If the genesis cell is rewritten, the derivation produces a different result. The file becomes unrecoverable. Grid refuses to rewrite genesis after the first write specifically to close this failure mode.

The salt is generated randomly at lock/seal time and stored alongside the ciphertext.

~/.grid/keychain.grid is a local registry of grids you have sealed on this machine. It stores per-sealed-grid anchors as cells.

Each entry has:

The keychain is local to your machine. It is never networked. grid unseal looks up the entry by coordinate to recover the digest needed for grid-aware key derivation.

A sealed grid is recoverable if and only if you have:

1. The passphrase
2. The grid's coordinate (visible from the GLE prefix on the sealed file)
3. Either the keychain entry on this machine or an exported copy of the digest (the digest: field from a saved keychain entry)

The recovery code printed at seal time is the genesis GHA hex. Save it somewhere durable. If you lose your keychain, you cannot recover a grid-aware sealed file from the genesis GHA alone; the key derivation uses the SHA-512 of the genesis body, which is stored in the digest: field of the keychain entry. The GHA is the human-readable anchor; the digest: field is the cryptographic input.

A future revision will combine these into a single recovery code that contains both.