How Rochsafe protects your records

A technical overview for IT teams, auditors and legal advisers evaluating Rochsafe.

Your archive stays on your hardware

Rochsafe is a desktop application, not a cloud service. The vault lives on the computer where Rochsafe is installed, by default in %LOCALAPPDATA%\Rochsafe. Nobody outside your organisation, including Qeysten, holds a copy of your records or the keys to them.

Encryption at rest

  • The database, including its full-text search index and write-ahead log, is encrypted with AES-256 using SQLCipher.
  • Documents are split into chunks, and each chunk is sealed with AES-256-GCM. Tampering with a chunk, removing one or reordering them is detected when the document is opened.
  • The only unencrypted file in the vault is a small manifest that holds the encrypted key envelopes.

A vault folder that reveals nothing

Anyone who opens the vault folder in File Explorer, or copies it to a USB drive, gets nothing usable:

  • No readable content. Every chunk is encrypted with a key that exists only inside a signed-in Rochsafe session.
  • No readable names. File names are derived from a keyed HMAC, so knowing a document's ID doesn't reveal where its pieces are.
  • No readable structure. A document's chunks share no folder, prefix or ordering; they're scattered across thousands of directories.
  • No way to confirm a document is there. IDs are random rather than content hashes, so someone holding a copy of a deed can't check whether it's in the vault.

Keys and passwords

Each operator's password unlocks the vault through a chain of keys:

  1. Operator password

    Known only to the operator. Never stored.

  2. Key-encryption key

    Derived with Argon2id: 128 MiB of memory, 3 passes.

  3. Vault master key

    32 random bytes, unwrapped with AES-256-GCM. Not derived from any password.

  4. Database, document and file-name keys

    Separate keys derived with HKDF-SHA256, one per purpose.

Because the vault master key is random rather than derived from a password, changing a password or adding and removing operators only rewrites a small key envelope. No documents are re-encrypted.

There is no recovery path. The master password isn't stored or escrowed anywhere, and Qeysten can't reset it. That's deliberate: a recovery mechanism would also be a way in.

Access control

  • Clearance is enforced by Rochsafe's backend on every request. The interface never tells the backend what clearance it has; the backend looks it up from the signed-in session.
  • A record that doesn't exist and a record above your clearance produce the same response, so the system can't be probed to discover what it holds.
  • Sign-in takes the same time whether or not the username exists, so response times don't reveal who has an account.
  • Sessions are held in memory only, and expire after a period of inactivity and after a fixed maximum length.
  • Passwords are hashed with Argon2id.

Network behaviour

Rochsafe works fully offline. It makes no network connections at all unless your organisation turns on the optional AI answers feature, and even then:

  • Only the five most relevant passages for a question are sent, never whole documents or the archive.
  • Documents are never sent to a cloud service to be indexed. Search indexing happens on the computer.
  • The feature can be switched off with a single setting, even when it has been configured.

Intake and deletion

New scans are placed in a watched intake folder. Rochsafe announces each one, and an operator decides its classification. Nothing is filed automatically, because only a person can tell a routine transfer from a live dispute. Once a document is encrypted into the vault, the original in the intake folder is overwritten and deleted.

Deleted records go to a quarantine bin first, where they can be restored for 30 days. After that, Rochsafe overwrites their encrypted chunks and purges their records. Executive Board operators can purge a record immediately.

No software can guarantee that an overwrite reaches every physical copy on a solid-state drive, so the real protection is keeping plaintext confined to the intake folder. That's why we recommend BitLocker and excluding the intake folder from shadow copies.

Audit trail and testing

Actions in the vault are recorded in an append-only audit log; entries can't be edited or deleted after they're written.

Documents leave the vault only through a controlled export. It's limited to Executive Board operators, requires the master password to be entered again along with a written justification, stamps a watermark across every page, and records the export in the audit log.

Rochsafe's automated test suite covers the security-critical paths, including:

  • Tamper detection, missing chunks and wrong-key rejection
  • That no readable text survives anywhere on disk
  • Clearance isolation across all three levels
  • Search queries that try to inject search operators
  • Session expiry and file paths that try to escape the intake folder

Deployment checklist

We recommend every installation follows these steps:

  • Turn on BitLocker for the drive that holds the vault.
  • Exclude the intake folder from Volume Shadow Copy.
  • Store the master password offline, for example in a sealed envelope held by a trustee.
  • Give each person their own operator account at the lowest clearance they need.
  • Keep Windows up to date on every computer that holds the vault.

Questions from your IT team?

We're happy to walk your IT staff or advisers through Rochsafe's design before you commit.