KEY EXCHANGE…000
Skip to content

Security

Security, in plain sight.

How QuorVault works under the hood, what it protects against, what it doesn't, and how we test it. No marketing fog.

01Architecture

How the keys fit together.

Three layers, each protecting the next. The password never touches your data; your data never meets a key in the clear.

Vault passwordArgon2idSealed private keysX25519 + ML-KEM-768Hybrid KEMX25519 ‖ ML-KEM → HKDFData keyAES-256, wrappedField tokensAES-256-GCM, bound to row

02Building blocks

Every primitive, named.

ML-KEM-768NIST FIPS 203Post-quantum key encapsulation
X25519IETF RFC 7748Classical key agreement
HKDF-SHA256IETF RFC 5869Combines both secrets into one key
AES-256-GCMNIST FIPS 197 · SP 800-38DAuthenticated encryption of values
Argon2idIETF RFC 9106Derives the vault key from the password

Implementation: OpenSSL 3.5, the most widely deployed open-source cryptography library, built into Node.js.

03Threat model

What it protects. What it doesn't.

Protects against

  • A stolen database dump or leaked backup: attackers only get ciphertext.
  • "Harvest now, decrypt later": stored data stays locked even once classical key exchange is broken.
  • Anyone with raw SQL access (DBA, contractor, attacker) reading sensitive columns.
  • Values swapped or copied between rows: decryption fails.
  • Any modified byte of a ciphertext: authentication fails.

Does not protect against

  • A compromised application server: it holds the vault and its password, so it can decrypt, like any application-side encryption.
  • A weak, reused or leaked vault password.
  • Data in transit between your app and your users: that is TLS's job.
  • Sorting, prefix or range searches on encrypted columns: only exact lookups stay possible, through a keyed fingerprint.
  • Malicious people with legitimate access to the application itself.

04Verification

Tested like it matters.

190+
automated tests, all passing
2
official test-vector suites (RFC 5869, RFC 7748)
1
independent implementation cross-checked (ML-KEM & X25519)
4
real database servers tested: PostgreSQL 14 & 18, MySQL 8.0 & 8.4

Every single byte of a ciphertext is flipped in our tests to prove tampering is always caught. Migrations run on real PostgreSQL and MySQL servers and on SQLite, including crashes mid-way, full reverts, and an application writing to the table during the migration. 50,000 rows are encrypted and indexed in about 4 seconds.

Not yet independently audited. An external audit is planned as the company grows; we'd rather tell you than let you assume.

05Responsible disclosure

Found a vulnerability?

Write to contact@quorvault.com with the subject "Security report". We acknowledge within 72 hours, keep you informed, and credit you if you wish. Please don't access data that isn't yours or disrupt the service.

06Roadmap

What's next.

01

Key separation

Private keys held by a KMS or HSM, away from the data they protect.

02

SQL Server & Oracle

After PostgreSQL, MySQL, MariaDB and SQLite.

03

Independent audit

An external cryptography review of the engine.

04

Composite keys

Tables whose primary key spans several columns.

Questions about your setup?

Let's go through it together.

Every environment is different. We'll look at yours and tell you honestly what QuorVault would and wouldn't change.

Get a quote →

or write to contact@quorvault.com · read the FAQ