Rewrite audit-ready briefing: software is not a certificate.

Open with an executive summary that HIPAA, SOC 2, and ISO 27001
are organizational programs. Verae DataCubes supply store,
communicate, timestamp, verify, and audit tools for the technical
portion only. Chapters cover transit (HPKE, visible routing), rest
(IPFS/Peergos hash-verified restore), receipts, EU Peergos
evaluations (Cure53 2019, ROS 2024), cross-blockchain timestamping,
and write-once Iceberg archive. PDF is branded with the Verae logo
top-left and Verae Inc contact in the footer; last chapters are
sourced bios for Garfinkel (FINRA CRD 5052743), Haber, and Lambert.

source/data-in-transit.rst

@@ -0,0 +1,111 @@
+Secure communications --- data in transit
+=========================================
+
+The problem
+-----------
+
+A message that leaves one machine and arrives at another crosses
+infrastructure the endpoints do not own: routers, load balancers,
+message brokers, TLS terminators, packet-capture appliances, and
+people with legitimate operational access to those devices. Any of
+those parties can copy bits. The honest design question is not
+"will anyone see the packet" --- they will --- but "**what** will
+they see, and **what** will they be able to do with it."
+
+The Verae DataCube Server Solution answers that question with
+**point-to-point encryption of content** and an explicit admission
+that **routing must be visible**.
+
+Point-to-point encryption
+-------------------------
+
+"Best in class" here is not a slogan; it names a concrete choice.
+Production content is sealed with **HPKE** (Hybrid Public Key
+Encryption, RFC 9180), in the HPKE-Base mode, using a suite such as
+X25519-HKDF-SHA256 with ChaCha20-Poly1305. Each endpoint has a
+key pair. The sender looks up the recipient's **public** key in a
+directory that is visible to every E2E service. The sender seals
+the body to that public key. Only the holder of the matching
+**private** key can open it.
+
+Consequences that matter in an audit interview:
+
+* The **sender cannot reopen** the ciphertext after it is sealed
+  unless the sender is also a recipient or has retained plaintext.
+  A lookup identifier is enough to talk about the message later
+  without retaining a second copy of the body.
+* The **broker cannot open** the body. Possession of the wire
+  image is possession of ciphertext.
+* A **lab XOR** construction, if it exists in a codebase for
+  experiments, is not a production algorithm. Production
+  configurations reject it.
+
+Visible routing
+---------------
+
+A network that cannot see a destination cannot deliver a message.
+The DataCube Server Solution therefore does **not** claim
+anonymous, metadata-free messaging. The following remain visible
+to the transport, by design:
+
+* destination (the handle or address the router needs);
+* subject or stream name (so the right service receives the
+  envelope);
+* sender handle or lookup identifier, when the protocol carries
+  them for reply and error handling;
+* approximate size and timing (any network sees these).
+
+This is the **honest-but-curious broker** model. Curiosity is
+assumed. Honesty is assumed only in the narrow sense that the
+broker forwards what it is given; it is **not** trusted with
+content, and it is **not** trusted not to log destinations.
+
+Error handling without leaking content
+--------------------------------------
+
+Failures have to be reported. A bounce that includes the original
+body would undo the encryption. The design therefore returns
+**error metadata**: an error code, a lookup identifier, a
+destination class --- not the plaintext, and not a replay of the
+ciphertext into a log aggregator that is a second, weaker store.
+
+Network Error Bundles can carry a sender-visible ciphertext and a
+system-visible ciphertext so that the right party can diagnose
+without broadcasting the payload to operators who should never see
+it.
+
+The public-key directory
+------------------------
+
+Point-to-point encryption is only as good as the lookup of public
+keys. The server solution publishes a **directory of public keys**
+so that availability of those keys is visible to all E2E services.
+Private keys do not belong in that directory. Private key files
+are mode ``0600``, held on the endpoint or in an HSM, and are
+never returned by the public listing API.
+
+An examiner can be shown the public listing. An examiner should
+never be given a private key.
+
+What this does, and does not, satisfy
+-------------------------------------
+
+For HIPAA Security Rule addressable encryption of ePHI **in
+transit**, for SOC 2 CC6 cryptographic transmission, and for
+ISO 27001 Annex A transmission security, this design is the
+**technical control**: content is encrypted to the recipient, the
+path is untrusted, keys are endpoint-held.
+
+It does **not** by itself satisfy:
+
+* a rule that requires the organization to **inventory** every
+  channel (personal devices, shadow SaaS, unapproved AI tools);
+* a rule that requires **workforce sanctions** when someone
+  bypasses the channel;
+* a rule that requires **agreements** with the broker operator
+  covering metadata that may still be personal data.
+
+Those remain policies, procedures, and contracts. The software
+makes the approved channel strong. It cannot stop a person from
+using a weak channel instead. That is an organizational control,
+not a cryptographic one.