UseAI's cryptographic design, authentication model, and vulnerability reporting process.
Every session record is part of a hash chain that provides tamper evidence. If any record is modified, deleted, or reordered, the hash chain breaks and verification fails.
Each record (session_start, heartbeat, session_end, session_seal) is serialized to JSON.
SHA-256(record_json + prev_hash) produces the record's hash, linking it to the previous record.
The hash is signed with your Ed25519 private key: Ed25519_sign(hash, private_key).
The record's hash becomes the prev_hash for the next record, forming an append-only chain.
When a session ends, a session_seal record captures summary data and two chain anchors:
The seal provides a compact, verifiable summary of the session without requiring the full chain.
On first use, UseAI generates an Ed25519 key pair. The private key is encrypted with AES-256-GCM using machine-specific entropy and stored in ~/.useai/keystore.json.
You can register your public key with the server. This allows the server to verify that synced sessions were signed by your key, enabling the verified badge on your profile.
The user has registered a public key with the server. Ed25519 signatures are valid and the hash chain is intact.
No public key registered. Signatures cannot be validated server-side. Could be from an older version or an unsigned session.
UseAI uses OTP (one-time password) authentication:
User requests a one-time password via email at useai.dev
User enters the OTP in the CLI (useai login)
Server returns a JWT token stored locally in ~/.useai/config.json
If you discover a security vulnerability in UseAI, please report it responsibly. Do not file public issues for security vulnerabilities.
We aim to acknowledge reports within 48 hours and provide a fix timeline within 7 days.