Cynvara
A zero-knowledge encrypted workspace for passwords, files, developer credentials, and organization secrets.
Project / cynvaraLive previewThe problem and product context.
Passwords, API keys, recovery codes, banking details, and identity documents are often scattered across browsers, notes, chats, and environment files. This increases the risk of accidental leakage, weak access control, and unnecessary trust in third parties.
Cynvara is a zero-knowledge encrypted vault. Sensitive data is encrypted on the user's device, while the server stores protected ciphertext without plaintext or decrypt-capable keys.
- Privacy-conscious individuals
- Developers handling API keys, SSH keys, and environment secrets
- Cybersecurity professionals
- Researchers and students
- Future teams and enterprises requiring controlled secret sharing, RBAC, audit logs, SSO, and SCIM
What I contributed.
Lead Developer and Product/Security Architecture Contributor
I worked across product architecture, trust boundaries, security flows, backend integration, and interface implementation rather than contributing only to the frontend.
- 01
Defined the zero-knowledge product architecture and trust boundaries.
- 02
Built React-based personal vault and organization/project workspace interfaces.
- 03
Implemented login, registration, MFA, vault unlock, and remembered-session flows.
- 04
Developed workflows for passwords, secure notes, files, developer credentials, and environment variables.
- 05
Integrated client-side key derivation, encryption, and encrypted sharing flows.
- 06
Implemented organization, membership, project, RBAC, and tenant-aware APIs.
- 07
Built step-up authentication, device/session management, and audit interfaces.
- 08
Worked on PostgreSQL migrations, Docker environments, and Vercel/serverless configuration.
- 09
Maintained security requirements, architecture decisions, threat models, and release evidence.
- 10
Implemented UX consistency, route-level code splitting, and centralized application content.
How the system is shaped.
Frontend
- React 18, TypeScript, Vite, and React Router
- Tailwind CSS
- React Hook Form and Zod
- Web Crypto API
- hash-wasm for Argon2id
Backend
- Node.js with TypeScript
- Modular-monolith service architecture
- PostgreSQL
- Prisma schema and migration tooling
- Explicit storage, security, and notification contracts
Security architecture
- Zero-knowledge custody model
- Argon2id-based master-password key derivation
- AES-256-GCM authenticated encryption with a random nonce for every operation
- Account, item, and object identity bound through additional authenticated data
- Separate authentication and vault-decryption keys
- Vault Master Key stored on the server only in wrapped form
- TOTP multi-factor authentication and HttpOnly remembered-session cookies
- Step-up authentication for sensitive operations
- Tamper-evident audit logs using hash chaining
- Tenant isolation through application authorization and PostgreSQL controls
Infrastructure and integrations
- npm workspaces monorepo with separate client, service, and reusable contract packages
- Docker Compose for PostgreSQL and production-like verification
- Vercel/serverless build configuration
- Brevo transactional email integration
- Razorpay billing integration
- Edition flags separating Personal V1 and V2 functionality
Challenges and engineering decisions.
Zero knowledge versus convenient recovery
If the platform can recover a vault, it may theoretically possess enough capability to decrypt it.
Reject operator-controlled recovery and use recovery material held by the user.
Authentication versus vault unlock
A successful account login should not automatically expose encrypted vault contents.
Let the server verify account authentication while deriving vault-unlock keys from the master password on the client.
Secure team sharing
The server cannot receive shared plaintext or a broadly usable shared decryption key.
Use per-user public keys, encrypted item keys, and sharing epochs so revocation can remove future access.
Multi-tenant isolation
Hiding organization features in the interface is not an authorization boundary.
Verify organization context, membership, roles, project ancestry, and data access server-side, supported by cross-tenant substitution tests.
Payment scripts and vault exposure
Loading a third-party checkout script while a vault is unlocked increases exposure risk.
Lock the vault before checkout and verify payment results against provider data on the server.
V1 and V2 scope management
Personal and organization-focused editions share a codebase but have different production requirements.
Keep edition boundaries explicit and disable V2 by default until its required database profile and configuration are available.
Security versus performance
Organization, billing, and administration code should not inflate the initial personal-vault load.
Use route-level lazy loading and separate chunks for advanced features.
Current outcome.
Personal V1 is feature-complete and locally verified, while the advanced organization and team-security foundation is implemented and progressing through production-readiness gates.
- Personal vault, files, developer secrets, MFA, recovery, sessions, audit history, import/export, and security settings
- Organization and project workspaces with encrypted sharing and role-based access control
- SSO, SCIM, billing, and monitoring foundations
- Passing TypeScript production build
- 34 of 34 client tests passed
- 99 of 99 service tests passed
- 133 tests passed in total with zero failures
- One PostgreSQL-backed integration suite was environment-gated in the latest local verification
- Retained Docker evidence documents 82 of 82 PostgreSQL-backed V2 integration tests passing
Cynvara should not yet be described as production-ready. External security review, provider staging, accessibility validation, backup/restore rehearsal, and final deployment gates remain outstanding.
Public evidence and links.