Security model

Paired devices are the authority for vault state. Infrastructure services are optional and untrusted for confidentiality and correctness.

Trust model

• Vault access is granted by signed membership documents created through invite and join.
• Discovery alone grants no access.
• A peer synchronizes content only after proving that its device key belongs to the same vault membership epoch.
• Optional services hold no vault keys. They cannot read vault contents and cannot change canonical state.

Transport and protocol

• Sync traffic is encrypted and peer-authenticated with libp2p Noise over TCP or TLS 1.3 over QUIC.
• The protocol sends decrypted logical vault items only to mutually trusted peers for that vault.
• The application handshake derives a transcript-bound session ID, key-confirmation keys, and direction-separated request and response MAC keys from the membership epoch secret with HKDF-SHA256.
• Authorized requests use an exact nonzero sequence and HMAC-SHA256 tag. Replays, gaps, tampering, stale epochs, and failed key confirmation invalidate the session before vault data is served.

Data at rest

• Sync state and local resource envelopes are encrypted from the complete local KDBX credential set. Credentials that include a key file use a domain-separated composite secret.
• Stored resource chunks use versioned XChaCha20-Poly1305 envelopes derived from the current membership epoch secret. Each envelope authenticates the vault ID, epoch, resource and chunk hashes, chunk index, and length.
• Older epoch secrets are local-only and are never included in join, recovery, or replacement packages. They are removed only after causal coverage and local evidence prove they are no longer needed.
• Config, identity, heartbeat, and encrypted sync state live under per-user config, data, and runtime directories.

Local interface

• Local IPC and status output never include vault passwords, KDBX paths, or decrypted entry fields.
• Administrative mutations are serialized by the running daemon over same-user local IPC.
• On Linux the credential-cache master key stays in the daemon process keyring. On macOS it stays in the login Keychain across agent restarts.

What optional services see

The pairing rendezvous stores only encrypted, opaque pairing envelopes. It never receives the pairing capability, vault plaintext, or envelope keys. Rendezvous registrations use opaque namespaces derived from the current vault epoch; vault names and IDs are never registered. Mailbox and object storage hold encrypted data under capability-scoped access.

Known limitations

• A malicious local network can attempt availability attacks against the network stack. The current focus is confidentiality and fail-closed data preservation, not full metadata hiding.
• KDBX key files are local credentials. Lattice never synchronizes them; provision the same key material separately on each device.
• Complete device loss cannot be proven cryptographically. Secondary recovery authority is a trusted emergency override.
• Lattice PM is not a replacement for backups or for KeePass credential hygiene.