4. Secure communications — data in transit

4.1. 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.

4.2. 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.

4.3. 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.

4.4. 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.

4.5. 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.

4.6. 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.