Security

Assume servers are compromised

MindooDB is designed so that storage and sync infrastructure can be untrusted. Clients encrypt before sync and prove authorship with signatures.

Zero-trust security architecture: keys stay on devices, encrypted data flows to servers that cannot decrypt

Admin key signs directory; directory defines trusted users; users sign changes. — Admin key signs the directory. The directory defines trusted users. Users sign changes. Servers can validate without reading business data.

Confidentiality

Client-side encryption

Changes and attachments are encrypted before leaving the device (AES-256-GCM).

Integrity

Signed changes

Every change is signed (Ed25519) to prove authorship and prevent tampering.

Auditability

Append-only history

Entries are append-only and chained, supporting audit trails and time travel.

Access control

Default key vs named keys

Documents are encrypted with a default tenant key unless you choose a named key for fine-grained access. Named keys can be shared only with specific users.

$publicinfos key

Servers can validate which signing keys are trusted without decrypting business documents, using a minimal-access tier.

Compliance

Regulatory compliance capabilities

MindooDB's append-only architecture, end-to-end encryption, and cryptographic integrity make it suitable for meeting regulatory compliance requirements across industries.

HIPAA (Healthcare)

End-to-end encryption ensures patient data is never visible to servers
Complete audit trails document who accessed what and when
Access controls with fine-grained permissions for different roles
Data retention policies supported through archival strategies

See healthcare use cases →

SOX (Financial)

Immutable records through append-only architecture
Cryptographic integrity proves records haven't been altered
Complete transaction history for audit requirements
Time travel to reconstruct any historical state

See financial services use cases →

GDPR (Data Protection)

Right to be forgotten via purgeDocHistory() method
Data portability through export capabilities
Access logging for complete audit trails
Data protection by design through end-to-end encryption

See compliance patterns →

PCI-DSS (Payments)

Payment card data protection through document-level encryption
Access controls with named keys for restricted access
Audit trails for all access and changes
Encryption of sensitive payment data

See compliance patterns →

Compliance checklist

Audit & integrity

✅ Complete change history (append-only)
✅ Cryptographic signatures (authorship proof)
✅ Tamperproof records (hash-chained)
✅ Time travel (reconstruct any state)

Access & privacy

✅ End-to-end encryption (server can't decrypt)
✅ Fine-grained access control (named keys)
✅ Access logging (who accessed what)
✅ Data retention policies (archival support)

View detailed compliance documentation →

Threat model

Security guarantees

Cryptographic algorithms

Signing: Ed25519 (elliptic curve, 128-bit security)
Transport encryption: RSA-OAEP with SHA-256 (3072-bit keys)
Payload encryption: AES-256-GCM (256-bit security)
Token signing: HMAC-SHA256

Security guarantees

Authenticity: Ed25519 signatures prove authorship
Integrity: Hash chaining prevents tampering
Confidentiality: AES-256-GCM encryption protects content
Non-repudiation: Cryptographic signatures are unforgeable

Read the detailed security audit documentation for comprehensive threat analysis and security considerations.