Login and Keys

Login is the gate. Nothing the Manager guards can be decrypted until a user authenticates, because the master key stays sealed until then. This is the most important security piece in XRUIOS, so it gets its own page.

The chain

  XRUIOS password ──Argon2id──► KEK ──AES-256-GCM unwrap──► master key
                                                              │
                                          ┌───────────────────┴───────────────────┐
                                     HKDF per worker                     HKDF for the permission store
                                     "xruios-worker:Calendar"            "xruios-permissions"

The master key is a random 32 bytes, minted once per user.
It is wrapped (AES-256-GCM) under a key an Argon2id KDF derives from the user's XRUIOS password (64 MiB, 3 passes).
Only the salt, the wrapped bytes, and the KDF parameters are stored - never the master key or the password.

The public login file

Each user has a world-readable login file (<Public>/Users/<uuid>.login.json): username, avatar path, and the password vector (salt + wrapped master key + Argon2 params). Anyone can read it, which is the point - a login screen lists the users on the device. Nobody can use it without the password, because the master key inside is wrapped.

Two ways to unlock

Warm (already logged in). While the OS session is alive, the master key is also sealed with the platform vault - DPAPI (CurrentUser) on Windows. The Manager unseals it with no password prompt. This is the "you're already logged into the OS, don't ask again" path. (Linux/macOS fall back to the password until libsecret/Keychain is wired.)

Cold (typed password). No seal, or a fresh machine: you enter the XRUIOS password, Argon2 derives the KEK, and the master key is unwrapped from the public file. A wrong password fails the GCM tag, which is indistinguishable from a corrupt file, by design.

Either way, XRUIOS.Manager login seals the key to the session; XRUIOS.Manager run unseals it and provisions the workers. No login means the Manager comes up locked - no keys, no workers, nothing decrypts.

From master to per-worker keys

Once unlocked, the master key never leaves the Manager. Every worker key comes from it by HKDF with the worker's name as the label, and the Manager hands each worker only its own key at launch (out-of-band, the same channel as the worker password). So:

The Manager can reproduce any worker's key on demand.
A worker holds one key and can decrypt one store.
A breach of the Media worker can't read the Time store - it never had the key.

OS accounts and recovery

When XRUIOS creates an OS account for a user, the OS password is autogenerated and encrypted under the XRUIOS-derived key, so the system can authenticate that account later without a human retyping it. A recovery path re-wraps the master key so a forgotten XRUIOS password isn't the end of the account. (The Identity worker already carries the OS-auth half of this - LogonUser on Windows, PAM on Linux.)