## Prompt Design a small **key–value store** that supports **user login** and ensures **values are encrypted at rest** using a **user-provided password**. You may assume this is a standalone service/library (language-agnostic) and you can use standard cryptographic primitives from a library (you do **not** need to implement AES/SHA yourself). ## Requirements 1. **Authentication / login** - Users can register and then log in with a password. - The system must not store plaintext passwords. 2. **Encrypted-at-rest values** - `put(key, value)` stores the value such that if the database/file is leaked, values are not readable without the user’s password. - `get(key)` returns the decrypted value for an authenticated user. 3. **Basic API surface (suggested)** - `Register(username, password)` - `Login(username, password) -> session/token` - `Put(session, key, value)` - `Get(session, key) -> value` - Optional: `Delete(session, key)` / `ListKeys(session)` 4. **Threat model / constraints** - Assume an attacker can obtain the underlying storage (DB/file) but not the running process memory. - Consider common pitfalls (e.g., deterministic encryption, IV reuse, password hashing vs encryption keys). ## What to provide - A high-level design (data model + flow) showing how you would store: - user credentials - encrypted values - any metadata needed for decryption - A description of cryptographic choices and why they are safe. - Key edge cases (password change, corruption, wrong password, multi-user isolation).