Cryptographic Identity & State

The Zero-Trust Identity Model

In a Zero-Cloud environment, identity is synonymous with the possession of a specific private key. The vault manages access through a non-sequential, identity-based lookup table.

1. RSA-OAEP Key Wrapping

The primary 256-bit AES vault key is wrapped using RSA-OAEP (Optimal Asymmetric Encryption Padding) with a SHA-256 hash. This ensures that the system is resistant to adaptive chosen-ciphertext attacks (IND-CCA2).

Unlike older padding schemes, OAEP incorporates a feistel network with a random seed, ensuring that encrypting the same vault key with the same public key multiple times will result in different ciphertexts.

2. AEAD Security Guarantees

The payload utilizes AES-256-GCM to provide Authenticated Encryption with Associated Data (AEAD). This ensures:

• Integrity: Any alteration to the .env.vault file, even by a single bit, is detected during the authentication tag verification.
• Confidentiality: Secrets are protected against offline brute-force attacks.
• Authentication: The crypto.createDecipheriv call will throw a hard error if the Auth Tag does not match the computed ciphertext hash.

The Authorization Lifecycle

Adding or removing access to the vault does not involve re-encrypting the underlying secrets. Instead, the vault manipulates the Member Manifest.

The allow Flow

When adding a new identity via allow [path/to/key.pub]:

1. The CLI reads the provided .pub file to extract the RSA public key.
2. The current user's private key unwraps the Vault Key in-memory.
3. The Vault Key is re-wrapped using the new public key.
4. A new entry is appended to the manifest, identifying the member by their SSH fingerprint.

The run Execution Logic

When executing a command, the CLI performs a volatile decryption:

1. Resolution: The CLI iterates through the manifest to find an entry matching the local SSH fingerprint.
2. Volatile Unwrapping: The wrapped key is decrypted using crypto.privateDecrypt.
3. Stream Decryption: The payload is decrypted.
4. Memory Scrubbing: The 32-byte AES key exists only within the memory space of the active Node process and is never persisted to temporary storage.

Security Constraints