🔐 NcryptVault

NcryptVault is an open-source SDK + reference server for storing sensitive keys (like nsecs) safely and with familiar authentication flows for highly secure, decentralized applications.

• Client-side encryption only — servers never see your raw keys or passwords.
• Modern authentication — OPAQUE password-auth, passkeys (WebAuthn), recovery codes.
• Multi-wrap DEK/KEK design — encrypt once, unlock with multiple factors.
• Pluggable storage — SQL (Postgres, SQLite), object storage (S3), decentralized options (Nostr).

Think of ncryptVault as a “passwordless, multi-factor, storage-agnostic key vault” — designed for apps that want strong security but also need accessible user flows.

🤨 What is NcryptVault?

Most applications need to handle sensitive secrets — encryption keys, credentials, tokens. In most systems today, secrets are stored like this:

1. User creates an account with a password.
2. The password is hashed (bcrypt/argon2) for login checks.
3. When the app needs to store a secret, it encrypts it on the server.
4. The decryption key for that encryption lives somewhere on the server — in an .env file, memory, or a cloud KMS token.

The problem is that this always leaves a key on the server.

A leak or compromise means attackers (or even operators) can still decrypt all secrets. Hashing helps for verifying passwords, but it doesn’t protect recoverable secrets.

ncryptVault changes this by moving all cryptography to the client. The server only ever stores ciphertexts, salts, and nonces — never raw keys or plaintext secrets. To unlock, the client re-derives a KEK from a factor and unwraps the DEK locally.

This way there is no usable decryption key on the server, operators cannot silently decrypt user data, and you can add or revoke factors without re-encrypting the secret itself.

Traditional model: “Server keeps the keys, user must trust the server.”
ncryptVault model: “Server only stores ciphertext — the user chooses how to decrypt it locally.”

🔑 Features

• TypeScript SDK (client + server)
  Import one library to handle key wrapping, unwrapping, and storage; providing high-level functions such as createVault(), vault.register({ username, password, secret, label }), vault.login({ username, password}) and vault.get({ label }).

• Client-side encryption
  Encryption and decryption never happen on the server. The server only stores ciphertext, nonces, and salts. Clients can individually configure how they want to encrypt secrets.

• Flexible DEK/KEK model
  A secret is encrypted once with a Data Encryption Key (DEK), which can be wrapped by multiple Key Encryption Keys (KEKs) derived from chosen user factors (password, passkey, recovery code).

• Vault backends are pluggable
  Point the SDK to any vault: self-hosted Postgres, cloud object storage, or even decentralized systems like Nostr – and of course, BYOA (Bring Your Own Adapter)!

• Open infrastructure
  100% FOSS, modular, and auditable. Built to be extended with new auth methods, adapters, and language ports.

*Future extensions may include WebAuthn passkeys, transparency logs for stronger accountability, and SDKs in additional languages to broaden adoption (Rust, Go, Python, ...).

🛠 Roadmap

• Core cryptographic engine (TypeScript SDK, DEK/KEK, OPAQUE PoC)
• Minimal reference server (REST)
• Storage adapters: SQLite, Postgres, S3, Nostr
• Auth factors: OPAQUE, WebAuthn, recovery codes
• Integration demos (web, mobile, CLI)
• Independent security audit

🤝 Funding & Support

NcryptVault is public infrastructure. Development will be supported through:

• Grants (NLnet/NGI, OpenSats, others)
• Sponsorships (GitHub Sponsors, OpenCollective, partnerships)
• Crowdfunding (crypto contributions)

📣 Sponsors will be credited in documentation and transparency logs.

🚀 Contributing

We welcome contributions of all kinds:

• Storage adapters
• Language ports
• Documentation improvements
• Demo integrations

👉 Open an issue or PR to get started.

📜 License

MIT — free to use, fork, and extend.