Security model.

The useful version of this page is the part describing what is still exposed, so that is here too.

The honest guarantee#

Slifer does not claim your upstream credential never exists in cleartext. It cannot: something has to put a real key on the wire for the provider to accept the call. What it narrows is where the key exists, for how long, and what has to be true first.

Anything claiming a key is mathematically incapable of leaking is selling you something. The boundary here is that the key does not live in client applications, source control, routine logs, or agent context.

Two unlock factors#

Unlocking combines a passphrase you remember with a 256-bit Vault Secret Key that was generated for you and is not stored in the vault file. Both are stretched and combined before anything is decrypted. A stolen vault file alone cannot be attacked by guessing the passphrase, because the attacker is also missing 256 bits of generated entropy.

The Vault Secret Key is encoded in Crockford Base32, which drops the characters that get confused when read aloud or copied by hand, and carries a checksum bound to the vault identity so a mistyped key fails cleanly instead of producing garbage.

The key hierarchy#

The root key is never used directly as an encryption or authentication key. Every use is derived through a distinct domain, so a weakness in one role cannot be pivoted into another:

passphrase + Vault Secret Key
  -> unlock key           (Argon2id, then HKDF combiner)
  -> vault root key
     -> key-encryption keys   (wrap the per-secret keys)
        -> data-encryption keys   (one per secret, per version)
     -> token verifier key    (separate HKDF domain)

Every stored secret version gets its own data key, wrapped under the root with associated data binding it to the vault, alias, and version.

Because the associated data binds each wrapped key to its alias and version, a ciphertext lifted from one entry cannot be replayed into another.

Parameters, and why these#

Passphrase stretching uses Argon2id at 64 MiB of memory, three passes, and four lanes. That is exactly the second recommended option in RFC 9106. The memory floor is not tradeable against iteration count: configurations below it are refused at construction rather than accepted with a warning, because memory hardness is what makes GPU attacks expensive and trading it away quietly defeats the point.

For context, this is heavier than the OWASP Password Storage Cheat Sheet minimum, which goes as low as 7 MiB. Slifer exceeds that floor rather than merely meeting it.

Token verification uses a much cheaper profile deliberately. The input there is a 256-bit random token, not a human-chosen password, so there is no dictionary to slow down and spending 64 MiB per API request would only be a denial-of-service surface.

Algorithms#

Full citations, including the primary papers, are on the references page.

Primitives in use, and what each one is for.
Primitive	Used for
Argon2id	Stretching the passphrase before it is combined with the Vault Secret Key.
HKDF-SHA256	Combining the two unlock factors, and separating every derived key by domain.
XChaCha20-Poly1305	Encrypting secret bodies and wrapping keys, with a random 192-bit nonce and associated data on every operation.
HMAC-SHA256	Verifying a Locker token, and binding an authorization decision to its policy.
TLS 1.3	The broker-to-provider hop only, with operating-system trust roots.

The random 192-bit nonce is why the extended-nonce variant was chosen: at that size, generating nonces randomly is safe without tracking a counter across restarts, which removes an entire category of implementation mistake.

The redaction contract#

Secret values are held in a type that cannot be serialized, cannot be implicitly copied, zeroes itself when dropped, prints as a redaction marker through both debug and display formatting, and compares in constant time. The workspace forbids unsafe code outright.

The activity log records the event, when, who, which alias, which version, and the stated reason. It never records a value, and break-glass output is dropped before the response is even assembled.

What the locked file still reveals#

The current vault format encrypts secret values but leaves aliases, provider labels, and timestamps readable in the locked file. Someone who takes a copy learns that you have an OpenAI key and when you last rotated it, though not what it is. Encrypting that metadata is designed and not yet implemented.

Residual risk#

An unlocked vault on a compromised machine is an unlocked vault. Slifer defends the credential at rest and in transit to the provider, not against an attacker who already has your user session.
locker run puts a value into a child's environment, where it sits in ordinary process memory. That memory is not Slifer's to zeroize.
Authenticated encryption gives integrity, not freshness. It detects tampering with a stored value; it is not a rollback defence.
The pre-release code has not had an external audit.

What is not claimed#

No FIPS validation. No claim that keys never exist in cleartext. No throughput numbers. No claim of rollback prevention. No audit certification. If a page here ever reads stronger than this one, this one is correct.

Reporting something#

Mail the address in the site footer, or the contact in the security.txt file at the well-known path. No released version is supported today, and nothing here should be holding a production secret in the first place.