Architecture for an audit interview
===================================

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

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.

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.

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.

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.

.. only:: html

   Live technical surfaces (reference instance):

   * https://pfc.georgelambert.org/health
   * https://pfc.georgelambert.org/v1/npe/keys
   * https://docs.pfc.georgelambert.org/controls.html

.. only:: latex

   Companion PDFs, same folder as this file (relative PDF
   hrefs, not Markdown):

   .. raw:: latex

      \begin{itemize}
      \item \href{peergos-for-compliance.pdf}{peergos-for-compliance.pdf}
      \item \href{nats-service-endpoints.pdf}{nats-service-endpoints.pdf}
      \item \href{secure-messaging.pdf}{secure-messaging.pdf}
      \end{itemize}