65 lines
3.1 KiB
Markdown
65 lines
3.1 KiB
Markdown
# Project Proposal: Zero-Knowledge Secrets Manager
|
|
|
|
## 1. Project Overview
|
|
|
|
We are building a **Zero-Knowledge Secrets Manager** based on the "Thick Client, Blind Server" philosophy. The server will act as a synchronization engine for encrypted data, ensuring that it never has access to the raw secrets. Encryption and decryption will happen exclusively on the client side.
|
|
|
|
## 2. Requirements
|
|
|
|
### Core Features
|
|
|
|
- **Zero-Knowledge Architecture:** Server stores only encrypted blobs.
|
|
- **Secure Authentication:** SRP-6a protocol for password-based authentication without sending the password to the server.
|
|
- **Data Storage:** PostgreSQL with Row-Level Security (RLS) to enforce access control.
|
|
- **API:** Node.js for auth/business logic and PostgREST for high-performance CRUD.
|
|
- **Client:** Cross-platform support (Tauri for Desktop, Flutter for Mobile). *Note: We will initially focus on the Desktop client (Tauri).*
|
|
- **Infrastructure:** Docker Compose for easy deployment of all services (Gateway, API, PostgREST, DB, Redis).
|
|
|
|
### Technology Stack
|
|
|
|
- **Backend:** Node.js v24, PostgREST
|
|
- **Database:** PostgreSQL v18+
|
|
- **Caching:** Redis Cluster v8 (official alpine image)
|
|
- **Frontend:** Tauri (Rust + Web Frontend), Flutter
|
|
- **Gateway:** Nginx/Traefik
|
|
- **Cryptography:** Argon2id, AES-256-GCM / XChaCha20-Poly1305
|
|
|
|
## 3. Implementation Plan
|
|
|
|
We propose the following step-by-step approach to build the system:
|
|
|
|
### Phase 1: Foundation & Infrastructure
|
|
|
|
1. **Repository Setup:** Initialize git and project structure.
|
|
2. **Infrastructure:** Create `docker-compose.yaml` with all required services (Postgres, Redis, Node.js, PostgREST, Nginx).
|
|
3. **Database Design:** Define SQL schema for `users`, `secrets`, and `access_policies`. Implement RLS policies.
|
|
|
|
### Phase 2: Backend Core
|
|
|
|
4. **Authentication Service:** Implement the Node.js service with SRP-6a for user registration and login.
|
|
2. **PostgREST Integration:** Configure PostgREST to work with the JWTs issued by the Auth service.
|
|
3. **API Logic:** Implement endpoints for secret rotation jobs and webhooks (if applicable at this stage).
|
|
|
|
### Phase 3: Client Development (Tauri)
|
|
|
|
7. **Client Scaffold:** Set up the Tauri project.
|
|
2. **Cryptography Layer:** Implement client-side encryption/decryption (Rust/WASM).
|
|
3. **Auth Integration:** Connect client to the SRP-6a auth flow.
|
|
4. **Secrets Management:** Implement UI for adding, viewing, and syncing secrets.
|
|
|
|
### Phase 4: Polish & Verification
|
|
|
|
11. **Testing:** Verify end-to-end flows (Auth -> Sync -> Decrypt).
|
|
2. **Documentation:** Update `docs/` and `activity.log`.
|
|
3. **Security Review:** fast audit of the implemented flows.
|
|
|
|
## 4. Questions & Clarifications
|
|
|
|
- **Frontend Preference:** Should we prioritize the Tauri desktop app or the Flutter mobile app first? (Assumed Tauri for now).
|
|
- **Domain/Network:** Do you have specific domain names or IP addresses for the extensive deployment, or is localhost sufficient for this development phase?
|
|
- **Secrets:** Do you have any specific secrets management constraints or compliance requirements not mentioned?
|
|
|
|
## 5. Next Steps
|
|
|
|
Upon approval of this proposal, we will begin with **Phase 1: Foundation & Infrastructure**.
|