Assume servers are compromised

Before an entry ever enters the store, its payload is encrypted with a symmetric key (AES-256-GCM). This encryption is part of the data model, not the transport. The server storing entries cannot read their contents — it only sees encrypted bytes.

When the server responds to a sync request, it wraps entry payloads in an additional RSA encryption layer using the requesting user's public key. Even if an attacker captures the HTTP response, they cannot decrypt without the recipient's private RSA key.

All communication happens over TLS. This protects metadata (entry IDs, timestamps, request parameters) that is not covered by the payload encryption layers. Together, the three layers ensure complete data protection at rest, in transit, and on the wire.

All documents are encrypted with the tenant's default AES-256 key unless another key is specified. Every registered user receives this key during onboarding. Use for general tenant-wide data.

For sensitive documents, create a named encryption key and share it only with authorized users. Keys are distributed offline (email the encrypted key, share the password by phone or in person). Only users with the key can decrypt.

A special key that encrypts only directory access-control entries (user registrations, revocations, groups). Servers use this to validate which signing keys are trusted — without seeing usernames or business data. Usernames are stored as SHA-256 hashes; actual names encrypted with the admin's RSA key.

Every sync session starts with a challenge-response handshake:

• Client sends its public signing key to the server
• Server looks up the key in the directory and sends a random challenge
• Client signs the challenge with its private key
• Server verifies the signature, checks revocation status, issues a short-lived JWT

No passwords or session databases on the server. A revoked user cannot even start the auth flow.

New users join through a three-step handshake where private keys never leave the device:

• Join request — New user generates keys locally, creates a request containing only public keys. Safe to share via any channel.
• Admin approval — Admin registers user in directory, encrypts symmetric keys with a one-time share password.
• Split-channel exchange — Join response sent via email/chat; share password communicated separately by phone or in person.

• Signing: Ed25519 (128-bit security, elliptic curve)
• Payload encryption: AES-256-GCM (256-bit security)
• Transport encryption: RSA-OAEP with SHA-256 (3072-bit keys)
• Key derivation: PBKDF2 with unique salts per key type
• Token signing: HMAC-SHA256
• Hashing: SHA-256 (content addressing, username privacy)

• Confidentiality: AES-256-GCM encryption — only key holders can read
• Authenticity: Ed25519 signatures — proves who created each change
• Integrity: Hash chaining — tampering breaks the chain, detectable at any point
• Non-repudiation: Signatures are unforgeable — authorship is provable
• Privacy: Usernames hashed and encrypted — server cannot identify users

• Server breach — Attacker gets ciphertext and public keys only. No plaintext, no private keys, no usernames.
• Network interception — Three encryption layers protect data even if TLS is compromised.
• Unauthorized changes — Every change is signed; unsigned or incorrectly-signed changes are rejected.
• Tampering — Hash chaining makes any modification detectable.
• Revoked user access — Revocation enforced at both challenge and token validation; blocks sync immediately.
• Relay eavesdropping — Relay nodes store and forward encrypted entries they cannot decrypt.

While payload content is always encrypted, some metadata is visible to the server by design. This is a deliberate tradeoff: the sync protocol needs metadata to reconcile entries.

• Visible: Entry timestamps, content hashes, document structure (how many entries per document), access patterns (when users sync)
• Not visible: Document content, usernames, encryption keys, attachment contents

Content hashes reveal when two entries contain identical encrypted data (for deduplication). This is an accepted tradeoff for storage efficiency.

Revoking a user blocks all future sync and rejects their future changes. However, previously synced data on their local device remains accessible — no system can guarantee deletion on a device that never reconnects. Mitigation: use named keys for sensitive documents (smaller blast radius), rotate keys when users leave.

Multiple keys per user (signing, encryption, named symmetric keys) require secure distribution. Mitigation: a single password unlocks all keys via PBKDF2 with different salts. The KeyBag provides unified key storage. The join request/response flow handles key exchange for new users.

By default, the server cannot query document content because it only sees ciphertext. All querying happens client-side through incremental indexing. However, if your use case requires server-side processing (e.g. an online booking system or a public website), you can give the server process a decryption key or share a subset of data with it. This is a conscious architectural choice per deployment — the default is confidentiality, with opt-in server access where needed.

A comprehensive security audit identified areas for hardening: rate limiting on endpoints, JWT token revocation, admin key rotation, and revocation timestamp protection. The cryptographic foundation (Ed25519, AES-256-GCM, RSA-OAEP) is solid. Operational hardening is in progress.