How FundRM encrypts your data at rest

The promise, in one paragraph

Sensitive content lives in the database as ciphertext. The only key that can decrypt it comes from a passphrase that only the fund manager knows and that is never stored on the server — not in the database, a config file, or on disk. Because the server never holds the key, whoever operates the machine cannot read the encrypted fields. Today that means email subjects and bodies, contact notes, phone numbers and screening notes, and investor notes. Extending this to investor and contact names, email addresses, capital-activity amounts and uploaded documents is on the roadmap — see what's encrypted.

How the key works

FundRM uses two keys, not one. Each fund has a random data key that encrypts the sensitive fields; that data key is itself locked by a key derived from your passphrase (using Argon2id, a deliberately slow, memory-hard hash). The server only ever stores the locked data key plus a salt and a small verifier — useless without the passphrase.

The payoff: changing your passphrase just re-locks the same data key — instant, with no data re-encrypted — and a recovery key can lock it too (see recovery).

Day-to-day it's two steps: sign in as staff (sessions, passkeys available), then unlock with your passphrase, which releases the data key into the session in memory. Reads decrypt and writes encrypt transparently while you work. The fund re-locks on “Lock now”, session expiry, idle timeout, or server restart — at which point the fields are cryptographically unreadable, not merely hidden. Each value uses authenticated encryption (XChaCha20-Poly1305, from libsodium) bound to its exact row, so ciphertext can't be tampered with or moved between records.

What's encrypted, what's plaintext

We encrypt high-sensitivity content first and are widening coverage over time. The honest split:

Encrypted at rest today

• Email content — subjects and message bodies
• Contact phone and mobile numbers
• Contact notes and screening notes
• Investor notes

On the roadmap (plaintext today)

• Investor, contact and company names
• Email addresses and other contact identifiers
• Capital-activity amounts, allocations and NAVs
• Uploaded document files

Plaintext by design (so the app keeps working)

• Row IDs and foreign keys, timestamps, and status flags — so tables can be joined, sorted and filtered

Until the roadmap items are encrypted, treat names, email addresses and capital-activity figures as readable to anyone with database or backup access. Search still works over encrypted fields via a keyed fingerprint (a "blind index") stored beside each value, supporting exact and prefix lookups; there's no substring or full-text search inside encrypted content.

What the operator can and can't see

What the person hosting the server sees in the database or a backup:

The first four items on the right are plaintext today and on the roadmap to be encrypted; until then, an operator or stolen backup can read them. The encrypted columns are ciphertext in backups by construction — a database dump contains them exactly as stored, so restoring still requires the fund's key.

Isolation vs. confidentiality — two distinct guarantees

These are often conflated; FundRM treats them separately. Isolation gives each fund its own separate database, so data is never co-mingled in shared tables — and each fund connects with its own least-privilege database account scoped to only that database, so a cross-tenant read is refused at the database layer. Confidentiality is the column encryption above — what actually delivers “we can't read it.”

Isolation alone isn't the promise: an admin with access to a database could still read it. Encryption is what keeps the operator out of the protected fields. If you self-host, isolation is absolute the simplest way: it's your server and your database.

Key loss and recovery

Because the server never holds the key, losing the passphrase means losing the data — we cannot reset it. That impossibility is the feature: it's the same property that stops the operator reading your book. We make it safe:

• A recovery key is generated at onboarding, shown once, and kept in the fund's own vault. It can independently unlock the data key, and you re-enter it once during setup to prove you saved it.
• An optional operator escrow (off by default, contractual) can hold a further wrap of the key, for funds that prefer recoverability.

The honest caveat