10. Architecture for an audit interview

10.1. The picture

Endpoint (private keys stay here / HSM)
    |  HPKE content (point-to-point)
    |  routing: destination + subject in the clear
    v
Untrusted message fabric (honest-but-curious)
    |  cannot read bodies; can see dest / subject / size
    v
Organizational DataCube
    |  append-only cube chain (prev + new + diff)
    |  private metadata, attachments, internal chain
    v
Peergos cryptree  (encrypted names, sizes, graph)
    |  chunks -> CID / hash, hashes verified
    v
IPFS  (distributed, content-addressed ciphertext)
    |
    +-- Verae timestamping
    |      fingerprint only -> receipt (time + sequence)
    |      org server linked to central Verae, or direct sync
    |
    +-- Iceberg write-once archive
           snapshot of cube CIDs, not under single-party delete

10.2. Walkthrough, in the order an examiner usually asks

Where are the keys? On the endpoint or in the customer’s HSM. Not on the storage host. Not in the public-key directory (that directory holds public keys only). Not in the NATS payload.

What does the network see? Destination, subject, size, timing. Not the body. Production algorithm is HPKE, not a lab construction.

What does the disk see? Padded encrypted chunks under random labels. Peergos verifies hashes. A restore re-fetches CIDs and re-checks them.

How do you prove when it existed? A hash is registered the first time it is seen. A receipt binds hash, time, and sequence. The organizational chain and the central Verae chain cross-verify. Verae is not given the object, only the fingerprint.

How do you stop delete? Live cubes replicate as hashed ciphertext. Committed snapshots go to an external Iceberg write-once tier that is specified to sit outside any one party’s delete control.

How do you know the software was not quietly reconfigured? Configuration is Ed25519-signed. Unsigned files are rejected. Admin-history records previous state, new state, and a diff.

How do you inspect without turning inspect into a leak? k-of-n officers. The author of a change is not an officer on that change. Log-before-reveal.

10.3. Identity planes

There are two login planes, and they must not be collapsed in an interview:

  • Drive / Peergos identity — unwraps cubes. This is the cryptographic identity.

  • Console identity — TOTP (RFC 6238), session cookie, admin actions. Google SSO, if present, does not unwrap cubes.

Mixing those planes is how “we have SSO” becomes “SSO is the master key.” It is not.

10.4. NATS remains untrusted

The reference message fabric is NATS. It is an honest-but-curious broker. Destinations in the clear are passthrough, not a bug. Bodies are ciphertext, or the message is rejected. Error responses carry codes and lookup identifiers, not payloads.

A public-edge NATS listener, if enabled, is token-gated and is not the same socket the internal services use.

10.5. What to hand the examiner

  • this document (HTML or PDF);

  • the two public Peergos reports, labeled as component evaluations;

  • a data-flow diagram of this instance;

  • the public-key listing (public keys only);

  • a restore-test ticket;

  • an admin-history excerpt for a dated change;

  • the organization’s policies, not Verae’s.

Live technical surfaces (reference instance):