4. Encryption at rest — IPFS blocks and Peergos

4.1. The problem

Bytes that are no longer moving still have to live somewhere: a disk, a replica, a backup, a cold archive. The people who operate those surfaces — hosting providers, backup operators, someone with a snapshot credential — are rarely the same people who are authorized to read the records. A design that stores plaintext on those surfaces is a design that makes every disk operator a reader. A design that stores ciphertext, but lets an operator swap a block without detection, is a design that fails integrity even if it keeps confidentiality.

The Verae DataCube Server Solution stores data at rest as encrypted, content-addressed IPFS blocks, with Peergos verifying hashes on the way in and the way out.

4.2. Content-addressed blocks

IPFS names a block by a cryptographic hash of its contents (a Content Identifier, or CID). Two properties follow immediately:

  • If the bits change, the name changes. There is no such thing as “the same CID, different payload” under a collision-resistant hash.

  • A client that asked for CID X and received bytes whose hash is not X knows it was given the wrong object.

That is the definition of a tamper-evident store. It does not prevent a hostile replica from refusing to serve a block (availability). It does prevent a hostile replica from silently serving a substitute and hoping nobody notices (integrity).

4.3. Peergos on top of IPFS

Peergos is not “IPFS with a folder UI.” It is an encrypted filesystem — a cryptree — whose nodes and file chunks are stored as IPFS blocks. The properties that matter for an audit-ready DataCube are:

  • Client-side encryption. Symmetric keys for chunks live with the customer, not on the storage host. A host with disk access sees padded, encrypted chunks and random labels, not filenames, not sibling names, not a social graph.

  • Hash verification. Peergos verifies the hash of every block it reads from or writes to IPFS. A restored cube is not “whatever was on the tape.” It is a set of CIDs re-fetched and re-checked.

  • Signed writes. Updates are signed. An unsigned rewrite is not a valid Peergos write.

  • Independent chunk keys. Chunks (up to 5 MiB, padded) are encrypted with random 256-bit keys (Salsa20-Poly1305 in the published design), not with convergent encryption that would leak equality of plaintext across users.

  • CHAMP places encrypted cryptree nodes under random 32-byte labels, so the storage host cannot walk the directory tree by name.

  • Sharing uses hybrid encryption (X25519 plus ML-KEM-1024 in current Peergos) so a capability can be given to another user without placing the chunk key on the server.

4.4. Tamper-evident restore

“Backup” in this architecture does not mean a second plaintext copy in a different building. It means:

  1. the CIDs that constitute a cube are known;

  2. the encrypted blocks for those CIDs exist on more than one replica;

  3. a restore re-fetches the blocks and re-verifies the hashes;

  4. the customer, holding keys, decrypts locally.

If step 3 fails, the restore fails closed. That is the opposite of a backup product that “helpfully” returns the last good plaintext it had. Helpfulness of that kind is how silent corruption and silent substitution enter an evidence set.

4.5. Append-only at the cube layer

Peergos itself uses signed updates and immutable blocks. The Verae DataCube adds an application-level chain: a JSONL history in which each record hashes the previous record. Dual hashing (for example SHA-256 plus BLAKE2b or BLAKE3) is used so that a future weakness in one function does not silently rewrite history.

These two layers must not be conflated in an audit interview:

  • IPFS / Peergos prove that the bytes retrieved are the bytes named by the CID, and that names and sizes are not in the clear on the host.

  • The cube chain proves that the organization’s own history of writes is append-only at the application layer.

Both are needed. Neither is a SOC 2 report.

4.6. What a disk operator sees

If keys never leave the client or the customer’s HSM, a disk operator, a VM snapshot operator, and an offsite replica operator see opaque hashed ciphertext. They do not see PHI, they do not see document titles, they do not see the graph of who shared what with whom.

That fact changes the Business Associate / processor conversation. It does not automatically end it. Usernames, IP addresses, billing identity, and support logs can still be personal data. Chapter 11 takes that up.

4.7. What this does, and does not, satisfy

For HIPAA encryption of ePHI at rest, for SOC 2 CC6 encryption of stored data, and for ISO 27001 Annex A cryptography and storage, this is the technical control: ciphertext on disk, keys with the customer, hash-checked restore.

It does not by itself satisfy:

  • a key-custody policy (who can unwrap, where the HSM lives, how a lost key is declared);

  • a restore-test procedure with a dated ticket proving someone actually did it last quarter;

  • retention and legal-hold rules (those require the write-once archive in Chapter 9, plus lawyers);

  • physical security of the machines, which still belongs in the organization’s ISMS or HIPAA facility controls.