marchon/peergos-making-yourself-audit-ready-with-verae-datacubes
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

Rewrite audit-ready briefing: software is not a certificate.
Some checks are pending
ci / markdown (push) Waiting to run
Details

Browse source 
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.
This commit is contained in:
George Lambert 2026-09-16 00:55:21 -04:00
parent da60402e88
commit 4fcbb9ac95
53 changed files with 6323 additions and 814 deletions
Download patch file Download diff file Expand all files Collapse all files

99
README.md
View file

@ -1,62 +1,46 @@
# Making yourself audit-ready with Verae DataCubes
How to **prepare an organization** for HIPAA-aligned, SOC 2, or ISO 27001
work using Verae DataCubes on **Peergos** (encrypted cryptree + hashed
IPFS) and HPKE on an **untrusted NATS** broker.
**Software alone does not make an organization HIPAA certified,
SOC 2 attested, or ISO 27001 certified.**
**This repository is not a HIPAA, SOC 2, or ISO certificate.**
Peergos’s public pentests are **not** your Type II or ISO registrar
certificate. They are **component security evaluations** you can attach.
The Verae DataCube Solution gives you tools to **store**,
**communicate**, **timestamp**, **verify**, and **audit**. To
obtain those certifications and attestations, the organization
still has to write **policies**, run **procedures**, operate
**internal controls**, and sit with an **independent auditor**.
Verae provides the tools, the background, and the software
infrastructure for the **technical portion** of that work.
## What we verified about Peergos (EU)
A Verae DataCube Server Solution provides secure communications
and storage for **data in transit** and **data at rest**:
point-to-point encryption (routing remains visible), IPFS
content-addressed encryption at rest with Peergos hash
verification, global timestamped receipts, and a write-once
Iceberg archive.
Full sources: [`PEERGOS-VERIFICATION.md`](PEERGOS-VERIFICATION.md).
Peergos was independently evaluated **twice in Europe** (Cure53,
Berlin, 2019; Radically Open Security, Amsterdam, 2024). Those
reports are public component evaluations. They are **not** a
HIPAA, SOC 2, or ISO certificate.
| Fact | Verified? |
|---|---|
| Encrypted client-side filesystem (cryptree); keys not on the storage server | Yes — Peergos book + Cure53 design review |
| IPFS blocks content-addressed; Peergos verifies hashes (tamper-evident restore) | Yes — [trust-free layers](https://book.peergos.org/security/trust.html) |
| Independent **EU** security audits, reports published | **Yes — two:** Cure53 **Berlin** (2019); Radically Open Security **Amsterdam** (2024, NLnet; EU Horizon 2020 NGI-POINTER mentioned on the post) |
| “Peergos is HIPAA/SOC 2/ISO certified” | **No.** Those audits are pentest/code/design reviews, not management-system certificates |
## Document
So: Peergos **was designed as a trust-minimized encrypted filesystem**,
**evaluated in Europe** by two specialist firms, with **public reports**.
That supports the **at-rest / backup** story. It does **not** finish
*your* audit.
## Architecture (audit interview in one page)
Sphinx sources in `source/`. Each chapter starts on a new page
in the PDF. The Verae wordmark is at the top left of every page;
Verae Inc contact is in the footer. Last chapters are
biographies of James H. Garfinkel (FINRA CRD 5052743), Stuart
Haber, and George Lambert.
```
Endpoint (keys stay here / HSM)
│ HPKE content (NPE suite)
│ routing: dest + subject in the clear
▼
Untrusted NATS (cannot read bodies)
│
▼
Verae DataCube chain (append-only hashes)
│ written through Peergos client
▼
Peergos cryptree (encrypted names, sizes, graph)
│ chunks → CID / hash
▼
IPFS (distributed, hash-verified ciphertext)
make html
make latexpdf
```
- **At rest:** Peergos cryptree + IPFS. Hosts with disk/backup see
**opaque hashed ciphertext**, not PHI, if they lack keys.
- **In transit (NATS):** HPKE-Base to directory public keys. Broker is
honest-but-curious: destinations yes, bodies no.
- **Integrity:** cube JSONL chain + dual hash + IPFS CID check on
restore (re-fetch blocks, re-verify hashes — not a plaintext tape).
* HTML: `build/html/index.html`
* PDF: `build/latex/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf`
* Published: https://docs.pfc.georgelambert.org/audit-ready/
## BAAs / DPAs
Ciphertext-without-keys **narrows** who is a Business Associate or
GDPR processor for **content**. It does **not** automatically delete
contracts for VMs, usernames, or logs. See [`BAA-DPA.md`](BAA-DPA.md).
## Pack
## Pack (Markdown companions)
| File | Use |
|---|---|
@ -66,23 +50,6 @@ contracts for VMs, usernames, or logs. See [`BAA-DPA.md`](BAA-DPA.md).
| `HOWTO.md` | How to hand this to an auditor |
| `MODULE.md` | Callers / non-runtime |
Live technical surfaces (ns1): https://pfc.georgelambert.org/health ·
https://pfc.georgelambert.org/v1/npe/keys ·
https://docs.pfc.georgelambert.org/controls.html
## Related
Related: https://git.georgelambert.org/marchon/system-git-sync
## Sphinx (HTML + LaTeX PDF)
Sources live in ``source/`` (Sphinx). Build:
```
make html
make latexpdf
```
* HTML: ``build/html/index.html``
* PDF: ``build/latex/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf``
LaTeX companion links are **relative PDFs** (not Markdown). Live HTML:
https://docs.pfc.georgelambert.org/audit-ready/
https://www.verae.com · https://git.georgelambert.org/marchon/system-git-sync

BIN
build/html/_images/VeraeFullLogo.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
build/html/_static/VeraeFullLogo.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 27 KiB

17
build/html/_static/alabaster.css
View file

@ -11,7 +11,7 @@ body {
div.document {
width: 940px;
width: 980px;
margin: 30px auto 0 auto;
}
@ -21,11 +21,11 @@ div.documentwrapper {
}
div.bodywrapper {
margin: 0 0 0 220px;
margin: 0 0 0 240px;
}
div.sphinxsidebar {
width: 220px;
width: 240px;
font-size: 14px;
line-height: 1.5;
}
@ -45,7 +45,7 @@ div.body > .section {
}
div.footer {
width: 940px;
width: 980px;
margin: 20px auto 30px auto;
font-size: 14px;
color: #888;
@ -502,8 +502,12 @@ a.footnote-reference:hover {
a:hover tt, a:hover code {
background: #EEE;
}
div.sphinxsidebar {
position: fixed;
margin-left: 0;
}
@media screen and (max-width: 940px) {
@media screen and (max-width: 980px) {
body {
margin: 0;
@ -523,7 +527,8 @@ a:hover tt, a:hover code {
display: block;
float: none;
width: unset;
margin: 50px -30px -20px -30px;
margin: -20px -30px 20px -30px;
position: static;
padding: 10px 20px;
background: #333;
color: #FFF;

4
build/html/_static/documentation_options.js
View file

@ -1,11 +1,11 @@
const DOCUMENTATION_OPTIONS = {
VERSION: '',
VERSION: '2026.09',
LANGUAGE: 'en',
COLLAPSE_INDEX: false,
BUILDER: 'html',
FILE_SUFFIX: '.html',
LINK_SUFFIX: '.html',
HAS_SOURCE: true,
HAS_SOURCE: false,
SOURCELINK_SUFFIX: '.txt',
NAVIGATION_WITH_KEYS: false,
SHOW_SEARCH_SUMMARY: true,

47
build/html/_static/verae.css Normal file
View file

@ -0,0 +1,47 @@
/* Verae branded Sphinx HTML */
body {
font-family: "Source Serif 4", "Georgia", serif;
color: #111;
}
div.document {
padding-top: 0.5em;
}
div.sphinxsidebar h3, div.sphinxsidebar h4 {
color: #5B2C8B;
}
div.body h1, div.body h2, div.body h3 {
color: #5B2C8B;
}
div.related {
background: #1A0A24;
color: #fff;
}
div.related a {
color: #e8d7f5;
}
div.footer {
background: #1A0A24;
color: #e8d7f5;
padding: 1.1em 1.5em;
margin-top: 2em;
}
div.footer a {
color: #d7b8f0;
}
.verae-page-footer {
border-top: 2px solid #5B2C8B;
margin-top: 2.5em;
padding-top: 0.8em;
font-size: 0.9em;
color: #5B2C8B;
}
div.sphinxsidebarwrapper img.logo,
img.logo {
background: #1A0A24;
padding: 8px;
border-radius: 4px;
max-width: 100%;
}
.admonition.important, .admonition.warning, .admonition.note {
border-left: 4px solid #5B2C8B;
}

237
build/html/architecture.html
View file

@ -5,17 +5,19 @@
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Architecture (audit interview) &#8212; Making yourself audit-ready with Verae DataCubes</title>
<title>10. Architecture for an audit interview &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=27fed22d" />
<script src="_static/documentation_options.js?v=5929fcd5"></script>
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="BAAs and DPAs when ciphertext has no host keys" href="baa-dpa.html" />
<link rel="prev" title="Peergos verification (what was actually audited)" href="verification.html" />
<link rel="next" title="11. BAAs, DPAs, and ciphertext without host keys" href="baa-dpa.html" />
<link rel="prev" title="9. Write-once Iceberg archive" href="iceberg-archive.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
@ -24,58 +26,24 @@
</head><body>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="architecture-audit-interview">
<h1>Architecture (audit interview)<a class="headerlink" href="#architecture-audit-interview" title="Link to this heading"></a></h1>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>Endpoint (keys stay here / HSM)
│ HPKE content (NPE suite)
│ routing: dest + subject in the clear
▼
Untrusted NATS (cannot read bodies)
│
▼
Verae DataCube chain (append-only hashes)
│ written through Peergos client
▼
Peergos cryptree (encrypted names, sizes, graph)
│ chunks → CID / hash
▼
IPFS (distributed, hash-verified ciphertext)
</pre></div>
</div>
<ul class="simple">
<li><p><strong>At rest:</strong> Peergos cryptree + IPFS. Hosts with disk/backup see
<strong>opaque hashed ciphertext</strong>, not PHI, if they lack keys.</p></li>
<li><p><strong>In transit (NATS):</strong> HPKE-Base to directory public keys. Broker is
honest-but-curious: destinations yes, bodies no.</p></li>
<li><p><strong>Integrity:</strong> cube JSONL chain + dual hash + IPFS CID check on
restore (re-fetch blocks, re-verify hashes — not a plaintext tape).</p></li>
</ul>
<p>NATS remains an untrusted router. Production E2E is NPE/HPKE.
Passthrough means destination in the clear; the body is ciphertext.</p>
<p>Live: <a class="reference external" href="https://pfc.georgelambert.org/v1/npe/keys">https://pfc.georgelambert.org/v1/npe/keys</a> (public keys only).
Controls: <a class="reference external" href="https://docs.pfc.georgelambert.org/controls.html">https://docs.pfc.georgelambert.org/controls.html</a></p>
</section>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<h1 class="logo"><a href="index.html">Making yourself audit-ready with Verae DataCubes</a></h1>
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
@ -91,20 +59,40 @@ Controls: <a class="reference external" href="https://docs.pfc.georgelambert.org
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="verification.html">Peergos verification (what was actually audited)</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">Architecture (audit interview)</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">BAAs and DPAs when ciphertext has no host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">How to use this pack</a></li>
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">10. Architecture for an audit interview</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#the-picture">10.1. The picture</a></li>
<li class="toctree-l2"><a class="reference internal" href="#walkthrough-in-the-order-an-examiner-usually-asks">10.2. Walkthrough, in the order an examiner usually asks</a></li>
<li class="toctree-l2"><a class="reference internal" href="#identity-planes">10.3. Identity planes</a></li>
<li class="toctree-l2"><a class="reference internal" href="#nats-remains-untrusted">10.4. NATS remains untrusted</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-to-hand-the-examiner">10.5. What to hand the examiner</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="verification.html" title="previous chapter">Peergos verification (what was actually audited)</a></li>
<li>Next: <a href="baa-dpa.html" title="next chapter">BAAs and DPAs when ciphertext has no host keys</a></li>
<li>Previous: <a href="iceberg-archive.html" title="previous chapter"><span class="section-number">9. </span>Write-once Iceberg archive</a></li>
<li>Next: <a href="baa-dpa.html" title="next chapter"><span class="section-number">11. </span>BAAs, DPAs, and ciphertext without host keys</a></li>
</ul></li>
</ul>
</div>
@ -116,22 +104,137 @@ Controls: <a class="reference external" href="https://docs.pfc.georgelambert.org
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="architecture-for-an-audit-interview">
<h1><span class="section-number">10. </span>Architecture for an audit interview<a class="headerlink" href="#architecture-for-an-audit-interview" title="Link to this heading"></a></h1>
<section id="the-picture">
<h2><span class="section-number">10.1. </span>The picture<a class="headerlink" href="#the-picture" title="Link to this heading"></a></h2>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Endpoint</span> <span class="p">(</span><span class="n">private</span> <span class="n">keys</span> <span class="n">stay</span> <span class="n">here</span> <span class="o">/</span> <span class="n">HSM</span><span class="p">)</span>
<span class="o">|</span> <span class="n">HPKE</span> <span class="n">content</span> <span class="p">(</span><span class="n">point</span><span class="o">-</span><span class="n">to</span><span class="o">-</span><span class="n">point</span><span class="p">)</span>
<span class="o">|</span> <span class="n">routing</span><span class="p">:</span> <span class="n">destination</span> <span class="o">+</span> <span class="n">subject</span> <span class="ow">in</span> <span class="n">the</span> <span class="n">clear</span>
<span class="n">v</span>
<span class="n">Untrusted</span> <span class="n">message</span> <span class="n">fabric</span> <span class="p">(</span><span class="n">honest</span><span class="o">-</span><span class="n">but</span><span class="o">-</span><span class="n">curious</span><span class="p">)</span>
<span class="o">|</span> <span class="n">cannot</span> <span class="n">read</span> <span class="n">bodies</span><span class="p">;</span> <span class="n">can</span> <span class="n">see</span> <span class="n">dest</span> <span class="o">/</span> <span class="n">subject</span> <span class="o">/</span> <span class="n">size</span>
<span class="n">v</span>
<span class="n">Organizational</span> <span class="n">DataCube</span>
<span class="o">|</span> <span class="n">append</span><span class="o">-</span><span class="n">only</span> <span class="n">cube</span> <span class="n">chain</span> <span class="p">(</span><span class="n">prev</span> <span class="o">+</span> <span class="n">new</span> <span class="o">+</span> <span class="n">diff</span><span class="p">)</span>
<span class="o">|</span> <span class="n">private</span> <span class="n">metadata</span><span class="p">,</span> <span class="n">attachments</span><span class="p">,</span> <span class="n">internal</span> <span class="n">chain</span>
<span class="n">v</span>
<span class="n">Peergos</span> <span class="n">cryptree</span> <span class="p">(</span><span class="n">encrypted</span> <span class="n">names</span><span class="p">,</span> <span class="n">sizes</span><span class="p">,</span> <span class="n">graph</span><span class="p">)</span>
<span class="o">|</span> <span class="n">chunks</span> <span class="o">-&gt;</span> <span class="n">CID</span> <span class="o">/</span> <span class="nb">hash</span><span class="p">,</span> <span class="n">hashes</span> <span class="n">verified</span>
<span class="n">v</span>
<span class="n">IPFS</span> <span class="p">(</span><span class="n">distributed</span><span class="p">,</span> <span class="n">content</span><span class="o">-</span><span class="n">addressed</span> <span class="n">ciphertext</span><span class="p">)</span>
<span class="o">|</span>
<span class="o">+--</span> <span class="n">Verae</span> <span class="n">timestamping</span>
<span class="o">|</span> <span class="n">fingerprint</span> <span class="n">only</span> <span class="o">-&gt;</span> <span class="n">receipt</span> <span class="p">(</span><span class="n">time</span> <span class="o">+</span> <span class="n">sequence</span><span class="p">)</span>
<span class="o">|</span> <span class="n">org</span> <span class="n">server</span> <span class="n">linked</span> <span class="n">to</span> <span class="n">central</span> <span class="n">Verae</span><span class="p">,</span> <span class="ow">or</span> <span class="n">direct</span> <span class="n">sync</span>
<span class="o">|</span>
<span class="o">+--</span> <span class="n">Iceberg</span> <span class="n">write</span><span class="o">-</span><span class="n">once</span> <span class="n">archive</span>
<span class="n">snapshot</span> <span class="n">of</span> <span class="n">cube</span> <span class="n">CIDs</span><span class="p">,</span> <span class="ow">not</span> <span class="n">under</span> <span class="n">single</span><span class="o">-</span><span class="n">party</span> <span class="n">delete</span>
</pre></div>
</div>
</section>
<section id="walkthrough-in-the-order-an-examiner-usually-asks">
<h2><span class="section-number">10.2. </span>Walkthrough, in the order an examiner usually asks<a class="headerlink" href="#walkthrough-in-the-order-an-examiner-usually-asks" title="Link to this heading"></a></h2>
<p><strong>Where are the keys?</strong> 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.</p>
<p><strong>What does the network see?</strong> Destination, subject, size,
timing. Not the body. Production algorithm is HPKE, not a
lab construction.</p>
<p><strong>What does the disk see?</strong> Padded encrypted chunks under
random labels. Peergos verifies hashes. A restore re-fetches
CIDs and re-checks them.</p>
<p><strong>How do you prove when it existed?</strong> 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.</p>
<p><strong>How do you stop delete?</strong> 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.</p>
<p><strong>How do you know the software was not quietly reconfigured?</strong>
Configuration is Ed25519-signed. Unsigned files are
rejected. Admin-history records previous state, new state,
and a diff.</p>
<p><strong>How do you inspect without turning inspect into a leak?</strong>
k-of-n officers. The author of a change is not an officer
on that change. Log-before-reveal.</p>
</section>
<section id="identity-planes">
<h2><span class="section-number">10.3. </span>Identity planes<a class="headerlink" href="#identity-planes" title="Link to this heading"></a></h2>
<p>There are two login planes, and they must not be collapsed
in an interview:</p>
<ul class="simple">
<li><p><strong>Drive / Peergos identity</strong> — unwraps cubes. This is
the cryptographic identity.</p></li>
<li><p><strong>Console identity</strong> — TOTP (RFC 6238), session cookie,
admin actions. Google SSO, if present, does <strong>not</strong> unwrap
cubes.</p></li>
</ul>
<p>Mixing those planes is how “we have SSO” becomes “SSO is
the master key.” It is not.</p>
</section>
<section id="nats-remains-untrusted">
<h2><span class="section-number">10.4. </span>NATS remains untrusted<a class="headerlink" href="#nats-remains-untrusted" title="Link to this heading"></a></h2>
<p>The reference message fabric is NATS. It is an
honest-but-curious broker. Destinations in the clear are
<strong>passthrough</strong>, not a bug. Bodies are ciphertext, or the
message is rejected. Error responses carry codes and lookup
identifiers, not payloads.</p>
<p>A public-edge NATS listener, if enabled, is token-gated and
is not the same socket the internal services use.</p>
</section>
<section id="what-to-hand-the-examiner">
<h2><span class="section-number">10.5. </span>What to hand the examiner<a class="headerlink" href="#what-to-hand-the-examiner" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>this document (HTML or PDF);</p></li>
<li><p>the two public Peergos reports, labeled as component
evaluations;</p></li>
<li><p>a data-flow diagram of <em>this</em> instance;</p></li>
<li><p>the public-key listing (public keys only);</p></li>
<li><p>a restore-test ticket;</p></li>
<li><p>an admin-history excerpt for a dated change;</p></li>
<li><p>the organization’s policies, not Verae’s.</p></li>
</ul>
<p>Live technical surfaces (reference instance):</p>
<ul class="simple">
<li><p><a class="reference external" href="https://pfc.georgelambert.org/health">https://pfc.georgelambert.org/health</a></p></li>
<li><p><a class="reference external" href="https://pfc.georgelambert.org/v1/npe/keys">https://pfc.georgelambert.org/v1/npe/keys</a></p></li>
<li><p><a class="reference external" href="https://docs.pfc.georgelambert.org/controls.html">https://docs.pfc.georgelambert.org/controls.html</a></p></li>
</ul>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
&#169;2026, Verae.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 9.1.0</a>
&amp; <a href="https://alabaster.readthedocs.io">Alabaster 1.0.0</a>
|
<a href="_sources/architecture.rst.txt"
rel="nofollow">Page source</a>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>

268
build/html/baa-dpa.html
View file

@ -5,17 +5,19 @@
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>BAAs and DPAs when ciphertext has no host keys &#8212; Making yourself audit-ready with Verae DataCubes</title>
<title>11. BAAs, DPAs, and ciphertext without host keys &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=27fed22d" />
<script src="_static/documentation_options.js?v=5929fcd5"></script>
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Audit-ready checklist" href="checklist.html" />
<link rel="prev" title="Architecture (audit interview)" href="architecture.html" />
<link rel="next" title="12. Audit-ready checklist" href="checklist.html" />
<link rel="prev" title="10. Architecture for an audit interview" href="architecture.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
@ -24,93 +26,24 @@
</head><body>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="baas-and-dpas-when-ciphertext-has-no-host-keys">
<h1>BAAs and DPAs when ciphertext has no host keys<a class="headerlink" href="#baas-and-dpas-when-ciphertext-has-no-host-keys" title="Link to this heading"></a></h1>
<p>This is <strong>guidance for an evidence pack</strong>, not legal advice.</p>
<section id="the-operator-statement">
<h2>The operator statement<a class="headerlink" href="#the-operator-statement" title="Link to this heading"></a></h2>
<p>Data at rest lives in the <strong>encrypted Peergos cryptree</strong>. Restore uses
<strong>distributed, hash-verified, encrypted IPFS blocks</strong>. Hosts and backup
media see <strong>opaque blobs</strong> (and random CHAMP labels), not filenames, not
PHI, not social graph — if keys never leave the client / customer HSM.</p>
<p>That is <strong>true of the Peergos design</strong> (see <a class="reference internal" href="verification.html"><span class="doc">Peergos verification (what was actually audited)</span></a>).
It <strong>changes the BAA/DPA conversation</strong>. It does <strong>not</strong> auto-delete the
need for contracts.</p>
</section>
<section id="hipaa-us-business-associate">
<h2>HIPAA (US) — Business Associate<a class="headerlink" href="#hipaa-us-business-associate" title="Link to this heading"></a></h2>
<p>A Business Associate is a person who <strong>creates, receives, maintains, or
transmits ePHI</strong> for a covered entity.</p>
<p><strong>Technical argument you can make (and should document):</strong></p>
<ol class="arabic simple">
<li><p>ePHI is encrypted <strong>before</strong> it leaves the endpoint (Peergos client /
DataCube writer).</p></li>
<li><p>The storage node, IPFS, disk, and backup hold <strong>ciphertext + hashes</strong>.</p></li>
<li><p>Private keys <strong>do not</strong> reside on the storage host (customer HSM /
client). Hash verification detects tampering.</p></li>
<li><p>Therefore the host <strong>cannot maintain ePHI in intelligible form</strong>.</p></li>
</ol>
<p>HHS distinguishes <strong>conduits</strong> and parties that never have access to
ePHI. Many programs still <strong>sign a BAA</strong> when a vendor touches
infrastructure, because misconfiguration, support exports, or logs could
later expose plaintext. OCR looks at <strong>your</strong> risk analysis.</p>
<p><strong>Practical pack:</strong> risk analysis memo citing cryptree + IPFS hash checks
+ key custody; BAA <strong>or</strong> written determination that the vendor is
<strong>not</strong> a BA because they cannot decrypt; list every party with
disk/backup (ns1, IPFS cluster, offsite replica).</p>
</section>
<section id="gdpr-eu-uk-processor-vs-technical-measure">
<h2>GDPR (EU/UK) — processor vs technical measure<a class="headerlink" href="#gdpr-eu-uk-processor-vs-technical-measure" title="Link to this heading"></a></h2>
<p>Encrypted data can still be <strong>personal data</strong> if it is reasonably
attributable (usernames, IPs, invoice identity). GDPR <strong>Art. 32</strong> lists
encryption as a security measure.</p>
<p>Peergos is designed so the <strong>server is an adversary</strong> for content and
most metadata. EU-based <strong>independent pentests</strong> (Cure53 DE, ROS NL)
evaluated that design. Processing location for <strong>self-host</strong> is <em>your</em>
ns1 / customer region, not peergos.net’s Germany hosting, unless you use
peergos.net.</p>
<p>You may still need a <strong>DPA (Art. 28)</strong> with anyone who <strong>processes</strong>
personal data (usernames, logs, billing). Ciphertext-only storage
<strong>narrows</strong> the DPA’s technical annex.</p>
</section>
<section id="nats-operators">
<h2>NATS operators<a class="headerlink" href="#nats-operators" title="Link to this heading"></a></h2>
<p>NATS is an <strong>untrusted broker</strong>. Content is HPKE; destinations and
subjects are in the clear. A NATS operator <strong>cannot</strong> read bodies without
endpoint private keys; <strong>can</strong> see routing metadata; <strong>can</strong> drop/delay
copy <strong>ciphertext</strong>. Treat like a transit provider: DPA/BAA depends on
whether routing metadata is personal data in your jurisdiction.</p>
</section>
<section id="what-making-yourself-audit-ready-means">
<h2>What “making yourself audit-ready” means<a class="headerlink" href="#what-making-yourself-audit-ready-means" title="Link to this heading"></a></h2>
<p>You are <strong>not</strong> buying Peergos’s Cure53/ROS reports as <em>your</em> SOC 2.
You are <strong>reusing</strong> those public evaluations as <strong>vendor/component
assurance</strong>, then adding your scope, RoPA, key-custody, inspect k-of-n,
admin-history, instance evidence, and contracts that match who can
actually see plaintext.</p>
</section>
</section>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<h1 class="logo"><a href="index.html">Making yourself audit-ready with Verae DataCubes</a></h1>
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
@ -126,27 +59,41 @@ actually see plaintext.</p>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="verification.html">Peergos verification (what was actually audited)</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">Architecture (audit interview)</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">BAAs and DPAs when ciphertext has no host keys</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#the-operator-statement">The operator statement</a></li>
<li class="toctree-l2"><a class="reference internal" href="#hipaa-us-business-associate">HIPAA (US) — Business Associate</a></li>
<li class="toctree-l2"><a class="reference internal" href="#gdpr-eu-uk-processor-vs-technical-measure">GDPR (EU/UK) — processor vs technical measure</a></li>
<li class="toctree-l2"><a class="reference internal" href="#nats-operators">NATS operators</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-making-yourself-audit-ready-means">What “making yourself audit-ready” means</a></li>
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">11. BAAs, DPAs, and ciphertext without host keys</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#the-technical-fact">11.1. The technical fact</a></li>
<li class="toctree-l2"><a class="reference internal" href="#hipaa-business-associate">11.2. HIPAA — Business Associate</a></li>
<li class="toctree-l2"><a class="reference internal" href="#gdpr-processor-versus-technical-measure">11.3. GDPR — processor versus technical measure</a></li>
<li class="toctree-l2"><a class="reference internal" href="#nats-operators">11.4. NATS operators</a></li>
<li class="toctree-l2"><a class="reference internal" href="#verae-as-timestamping-service">11.5. Verae as timestamping service</a></li>
<li class="toctree-l2"><a class="reference internal" href="#component-assurance-versus-the-organization-s-report">11.6. Component assurance versus the organization’s report</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">How to use this pack</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="architecture.html" title="previous chapter">Architecture (audit interview)</a></li>
<li>Next: <a href="checklist.html" title="next chapter">Audit-ready checklist</a></li>
<li>Previous: <a href="architecture.html" title="previous chapter"><span class="section-number">10. </span>Architecture for an audit interview</a></li>
<li>Next: <a href="checklist.html" title="next chapter"><span class="section-number">12. </span>Audit-ready checklist</a></li>
</ul></li>
</ul>
</div>
@ -158,22 +105,129 @@ actually see plaintext.</p>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="baas-dpas-and-ciphertext-without-host-keys">
<h1><span class="section-number">11. </span>BAAs, DPAs, and ciphertext without host keys<a class="headerlink" href="#baas-dpas-and-ciphertext-without-host-keys" title="Link to this heading"></a></h1>
<p>This chapter is <strong>guidance for an evidence pack</strong>. It is not
legal advice. Counsel has to sign the actual determination.</p>
<section id="the-technical-fact">
<h2><span class="section-number">11.1. </span>The technical fact<a class="headerlink" href="#the-technical-fact" title="Link to this heading"></a></h2>
<p>Data at rest lives in the <strong>encrypted Peergos cryptree</strong>.
Restore uses <strong>distributed, hash-verified, encrypted IPFS
blocks</strong>. Hosts and backup media see <strong>opaque blobs</strong> (and
random CHAMP labels), not filenames, not PHI, not the share
graph — <strong>if</strong> private keys never leave the client or the
customer’s HSM.</p>
<p>That fact is true of the Peergos design and is the design
Cure53 reviewed in Berlin. It <strong>changes</strong> the Business
Associate and GDPR-processor conversation. It does <strong>not</strong>
automatically delete the need for contracts.</p>
</section>
<section id="hipaa-business-associate">
<h2><span class="section-number">11.2. </span>HIPAA — Business Associate<a class="headerlink" href="#hipaa-business-associate" title="Link to this heading"></a></h2>
<p>A Business Associate is a person who <strong>creates, receives,
maintains, or transmits ePHI</strong> for a covered entity.</p>
<p>A technical argument the organization can document:</p>
<ol class="arabic simple">
<li><p>ePHI is encrypted <strong>before</strong> it leaves the endpoint.</p></li>
<li><p>The storage node, IPFS, disk, Iceberg archive, and backup
hold <strong>ciphertext plus hashes</strong>.</p></li>
<li><p>Private keys <strong>do not</strong> reside on the storage host.
Hash verification detects substitution.</p></li>
<li><p>Therefore the host <strong>cannot maintain ePHI in intelligible
form</strong>.</p></li>
</ol>
<p>HHS has distinguished <strong>conduits</strong> and parties that never
have access to ePHI. Many programs still <strong>sign a BAA</strong>
whenever a vendor touches infrastructure, because
misconfiguration, a support export, or a log could later
expose plaintext. OCR will look at <strong>the organization’s</strong>
risk analysis, not at Verae’s architecture diagram.</p>
<p>Practical pack:</p>
<ul class="simple">
<li><p>a risk-analysis memo citing cryptree, IPFS hash checks,
key custody, and the two public Peergos evaluations;</p></li>
<li><p>a BAA <strong>or</strong> a written determination that a named vendor
is <strong>not</strong> a BA because they cannot decrypt;</p></li>
<li><p>a list of every party with disk, VM, backup, IPFS, or
Iceberg credentials.</p></li>
</ul>
</section>
<section id="gdpr-processor-versus-technical-measure">
<h2><span class="section-number">11.3. </span>GDPR — processor versus technical measure<a class="headerlink" href="#gdpr-processor-versus-technical-measure" title="Link to this heading"></a></h2>
<p>Encrypted data can still be <strong>personal data</strong> if it is
reasonably attributable (usernames, IPs, invoice identity).
GDPR Article 32 lists encryption as a security measure, not
as an exemption from Article 28.</p>
<p>Peergos is designed so the <strong>server is an adversary</strong> for
content and most metadata. EU-based independent pentests
evaluated that design. Processing location for <strong>self-host</strong>
is the customer’s region, not peergos.net’s Germany, unless
the customer uses peergos.net.</p>
<p>A DPA may still be required with anyone who <strong>processes</strong>
usernames, logs, or billing. Ciphertext-only storage
<strong>narrows</strong> the technical annex. It does not always
eliminate the DPA.</p>
</section>
<section id="nats-operators">
<h2><span class="section-number">11.4. </span>NATS operators<a class="headerlink" href="#nats-operators" title="Link to this heading"></a></h2>
<p>NATS is an untrusted broker. Content is HPKE. Destinations
and subjects are in the clear. A NATS operator <strong>cannot</strong>
read bodies without endpoint private keys. They <strong>can</strong> see
routing metadata. They <strong>can</strong> drop, delay, or copy
ciphertext. Treat them like a transit provider: whether a
DPA or BAA is needed depends on whether routing metadata is
personal data in the relevant jurisdiction.</p>
</section>
<section id="verae-as-timestamping-service">
<h2><span class="section-number">11.5. </span>Verae as timestamping service<a class="headerlink" href="#verae-as-timestamping-service" title="Link to this heading"></a></h2>
<p>If Verae receives <strong>only fingerprints</strong>, Verae’s role for
<strong>content</strong> is not “stores the records.” Verae’s role is
“registers hashes and issues receipts.” That is a narrower
processing. Counsel still has to decide whether the
fingerprint, plus whatever account data exists (company
name, billing, operator emails), requires a DPA or a BAA.
Do not let a sales sentence skip that memo.</p>
</section>
<section id="component-assurance-versus-the-organization-s-report">
<h2><span class="section-number">11.6. </span>Component assurance versus the organization’s report<a class="headerlink" href="#component-assurance-versus-the-organization-s-report" title="Link to this heading"></a></h2>
<p>Attaching Cure53 2019 and ROS 2024 is <strong>vendor / component
assurance</strong>. It is appropriate. It is <strong>not</strong> the
organization’s SOC 2, ISO 27001, or HIPAA program. Those
still require the organization’s scope, Record of
Processing, key-custody, inspect k-of-n, admin-history,
instance evidence, restore tests, and the contracts that
match who can actually see plaintext.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
&#169;2026, Verae.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 9.1.0</a>
&amp; <a href="https://alabaster.readthedocs.io">Alabaster 1.0.0</a>
|
<a href="_sources/baa-dpa.rst.txt"
rel="nofollow">Page source</a>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>

227
build/html/bio-george-lambert.html Normal file
View file

@ -0,0 +1,227 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>16. George Lambert &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="17. Verae Inc — contact" href="contact.html" />
<link rel="prev" title="15. Stuart Haber" href="bio-stuart-haber.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">16. George Lambert</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#role">16.1. Role</a></li>
<li class="toctree-l2"><a class="reference internal" href="#internet-technical-architect-from-1994">16.2. Internet technical architect, from 1994</a></li>
<li class="toctree-l2"><a class="reference internal" href="#new-hampshire-public-office">16.3. New Hampshire public office</a></li>
<li class="toctree-l2"><a class="reference internal" href="#why-this-biography-is-in-the-briefing">16.4. Why this biography is in the briefing</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="bio-stuart-haber.html" title="previous chapter"><span class="section-number">15. </span>Stuart Haber</a></li>
<li>Next: <a href="contact.html" title="next chapter"><span class="section-number">17. </span>Verae Inc — contact</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="george-lambert">
<h1><span class="section-number">16. </span>George Lambert<a class="headerlink" href="#george-lambert" title="Link to this heading"></a></h1>
<section id="role">
<h2><span class="section-number">16.1. </span>Role<a class="headerlink" href="#role" title="Link to this heading"></a></h2>
<p><strong>George Lambert</strong> is an Internet technical architect and a
New Hampshire public official. Public candidate listings
(BallotReady) identify him as <strong>CTO / Chief Architect, Verae
LLC</strong>, from <strong>2019</strong>. He is the architect of the DataCube
<strong>server</strong> side of the solution described in this briefing:
the assembly of encrypted storage, point-to-point messaging,
public-key directory, organizational timestamping link, and
write-once archive that an organization actually runs.</p>
</section>
<section id="internet-technical-architect-from-1994">
<h2><span class="section-number">16.2. </span>Internet technical architect, from 1994<a class="headerlink" href="#internet-technical-architect-from-1994" title="Link to this heading"></a></h2>
<p>Lambert’s public account of his engineering work begins in
the <strong>earliest days of the commercial Internet</strong>, when
shipping an application that could speak TCP/IP was still a
specialist task.</p>
<p>In <strong>1994–1995</strong> he was moving through senior application
engineering and sales roles (Terralogics; Serif) at the
moment Borland’s developer tools were being connected to
the public network. He then founded <strong>NetMasters LLC</strong>
(New Hampshire, formed 1996; he describes the product work
from 1995). At NetMasters he <strong>personally designed and
built FastNet Tools</strong> — the <strong>Internet integration
technology that shipped with Borland’s Delphi and C++
Builder</strong> products.</p>
<p>Those tools are the historically important fact. They
enabled a generation of Delphi and C++ Builder developers
to Internet-enable applications as a shipped part of
Borland’s commercial toolchain, not as a research demo.
Lambert’s own summary is that FastNet Tools “enabled
millions of developers to internet-enable their
applications in minutes.” That is the beginning of the
through-line that ends, in this briefing, at a DataCube
server: <strong>make the hard network problem a product that
other people can operate</strong>.</p>
<p>He continued as <strong>Vice President of Engineering</strong> at
GoldenWare / <strong>FlightLookup</strong> (from 1995, for two decades
on the public listings), building airline-information
systems, and later as founder of PodKey Solutions
(2004–2010) and as an interim/contract CTO.</p>
</section>
<section id="new-hampshire-public-office">
<h2><span class="section-number">16.3. </span>New Hampshire public office<a class="headerlink" href="#new-hampshire-public-office" title="Link to this heading"></a></h2>
<p>Lambert is a <strong>Republican</strong> from <strong>Litchfield, New
Hampshire</strong>, born <strong>4 September 1968</strong> in Sanford, Maine
(Wikipedia; Vote Smart).</p>
<ul class="simple">
<li><p><strong>Litchfield Board of Selectmen</strong>, from 2007 (Vote Smart
lists council of town selectmen, Town of Litchfield,
2007–present on the biography page then current).</p></li>
<li><p><strong>New Hampshire House of Representatives</strong>:
Hillsborough 27th district, December 2010 – December
2012; Hillsborough 44th district, December 2012 –
December 2014.</p></li>
<li><p>Subsequent campaigns for the New Hampshire Senate,
District 18 (2014, 2018, 2020, 2022 Republican primary
winner in several of those cycles).</p></li>
</ul>
<p>Vote Smart records a diploma from <strong>Pelham High School,
1986</strong>; family (wife Rhonda, children); home city
Litchfield. He has also served on the <strong>National Grange
Strategic Planning Task Force</strong> (1999–2004).</p>
<p>His public technical site, <a class="reference external" href="https://georgelambert.org/">https://georgelambert.org/</a>,
describes three decades at the intersection of technology,
governance, and sound money, and repeats the FastNet /
Borland fact as the credential for knowing what scalable
architecture looks like.</p>
</section>
<section id="why-this-biography-is-in-the-briefing">
<h2><span class="section-number">16.4. </span>Why this biography is in the briefing<a class="headerlink" href="#why-this-biography-is-in-the-briefing" title="Link to this heading"></a></h2>
<p>The DataCube Server Solution is not only a timestamping
API. It is a <strong>running system</strong>: keys, brokers, cryptree,
replicas, admin-history, Iceberg export. Lambert is the
person whose public career is the <strong>implementation</strong> of
Internet integration from the Borland era through to this
server stack, and whose public service is New Hampshire
legislative and municipal office. The biography is here so
that a reader who asks “who architected the server side,
and on what history?” has a sourced answer.</p>
<p>It is not a substitute for a pentest, a Type II, or a
restore test. Code either runs or it does not; Lambert’s
own stated ethic. This briefing is the description of what
the code is for, and of what it cannot certify by existing.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

246
build/html/bio-james-garfinkel.html Normal file
View file

@ -0,0 +1,246 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>14. James H. Garfinkel &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="15. Stuart Haber" href="bio-stuart-haber.html" />
<link rel="prev" title="13. How to use this briefing" href="howto.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">14. James H. Garfinkel</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#name-and-sources">14.1. Name and sources</a></li>
<li class="toctree-l2"><a class="reference internal" href="#role-at-verae">14.2. Role at Verae</a></li>
<li class="toctree-l2"><a class="reference internal" href="#finra-brokercheck-crd-5052743">14.3. FINRA BrokerCheck (CRD 5052743)</a></li>
<li class="toctree-l2"><a class="reference internal" href="#education-public-professional-listings">14.4. Education (public professional listings)</a></li>
<li class="toctree-l2"><a class="reference internal" href="#why-this-biography-is-in-the-briefing">14.5. Why this biography is in the briefing</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="howto.html" title="previous chapter"><span class="section-number">13. </span>How to use this briefing</a></li>
<li>Next: <a href="bio-stuart-haber.html" title="next chapter"><span class="section-number">15. </span>Stuart Haber</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="james-h-garfinkel">
<h1><span class="section-number">14. </span>James H. Garfinkel<a class="headerlink" href="#james-h-garfinkel" title="Link to this heading"></a></h1>
<section id="name-and-sources">
<h2><span class="section-number">14.1. </span>Name and sources<a class="headerlink" href="#name-and-sources" title="Link to this heading"></a></h2>
<p>This chapter summarizes <strong>James H. Garfinkel</strong> (the spelling on
the FINRA BrokerCheck individual report; also styled Garfinkle
in some informal references). Two public sources were used, as
requested:</p>
<ul class="simple">
<li><p><strong>FINRA BrokerCheck</strong>, CRD number <strong>5052743</strong>,
<a class="reference external" href="https://files.brokercheck.finra.org/individual/individual_5052743.pdf">https://files.brokercheck.finra.org/individual/individual_5052743.pdf</a></p></li>
<li><p><strong>verae.com</strong>, which names Stuart Haber as co-founder and
describes the DataCube product. As of this writing the public
marketing site does <strong>not</strong> carry a dedicated biography page
for Garfinkel. The product and company description below is
therefore taken from verae.com’s company narrative plus
Garfinkel’s own public statement of role, not from a
fabricated “about the CEO” page.</p></li>
</ul>
</section>
<section id="role-at-verae">
<h2><span class="section-number">14.2. </span>Role at Verae<a class="headerlink" href="#role-at-verae" title="Link to this heading"></a></h2>
<p>Public professional listings (including a long-standing
Facebook work listing) identify Garfinkel as <strong>CEO of Verae
LLC</strong>, from <strong>January 2020</strong>, based in <strong>New York, New York</strong>.
In that listing he describes Verae’s technology as
blockchain-authenticated containers called <strong>DataCubes</strong>,
“which conveniently and securely ensure integrity and enable
selective sharing of digital information and records of all
sorts,” and he quotes Stuart Haber on the original motivation
for timestamping digital objects.</p>
<p>That description matches the public verae.com product: records
remain in customer-controlled storage; Verae seals a
fingerprint; the scientific core is Haber-style cryptographic
timestamping, aimed at compliance and examinations rather than
at operating a public chain.</p>
</section>
<section id="finra-brokercheck-crd-5052743">
<h2><span class="section-number">14.3. </span>FINRA BrokerCheck (CRD 5052743)<a class="headerlink" href="#finra-brokercheck-crd-5052743" title="Link to this heading"></a></h2>
<p>The following facts are from the public BrokerCheck report.
They are <strong>registration history</strong>, not a Verae claim and not an
endorsement by FINRA.</p>
<ul class="simple">
<li><p><strong>Name on the report:</strong> James H. Garfinkel</p></li>
<li><p><strong>CRD:</strong> 5052743</p></li>
<li><p><strong>Current registration:</strong> this broker is <strong>not currently
registered</strong></p></li>
<li><p><strong>Disclosed events:</strong> the report summary states <strong>no</strong>
events disclosed about this broker</p></li>
<li><p><strong>Examinations recorded on the summary:</strong> 0
principal/supervisory exams; 3 general industry/product
exams; 3 state securities law exams</p></li>
<li><p><strong>Investment adviser:</strong> BrokerCheck points readers to the
SEC IAPD site for any IAR record</p></li>
</ul>
<p><strong>Prior broker registrations</strong> listed on the report:</p>
<ul class="simple">
<li><p><strong>LPL Financial LLC</strong>, CRD 6413, New York, NY,
<strong>January 2013 – March 2024</strong>, registered representative</p></li>
<li><p><strong>Hornor, Townsend &amp; Kent, Inc.</strong>, CRD 4031, New York, NY,
<strong>November 2011 – December 2012</strong></p></li>
<li><p><strong>Park Avenue Securities LLC</strong>, CRD 46173, New York, NY,
<strong>April 2008 – October 2009</strong></p></li>
</ul>
<p>Other employment lines that appear in the same public report
family include <strong>Abbott Solutions Inc.</strong> (insurance advisor,
from November 2009) and <strong>MPWM Advisory Solutions LLC</strong>
(investment adviser representative, January 2014 – November
2020). Readers should treat the PDF as the living source;
registration status changes.</p>
</section>
<section id="education-public-professional-listings">
<h2><span class="section-number">14.4. </span>Education (public professional listings)<a class="headerlink" href="#education-public-professional-listings" title="Link to this heading"></a></h2>
<p>Public professional listings state:</p>
<ul class="simple">
<li><p><strong>Hamilton College</strong>, B.A. Economics, class of <strong>1980</strong></p></li>
<li><p><strong>United Nations International School</strong>, class of <strong>1975</strong></p></li>
</ul>
<p>Other ventures listed on professional-directory sites (not
FINRA, not verae.com) have included Beryl Consulting, Intaglio
Blockchain, and earlier broker-dealer roles. Those directory
sites are secondary; they are noted here only so that a reader
who searches the name is not surprised. They are not used as
primary evidence of Verae corporate structure.</p>
</section>
<section id="why-this-biography-is-in-the-briefing">
<h2><span class="section-number">14.5. </span>Why this biography is in the briefing<a class="headerlink" href="#why-this-biography-is-in-the-briefing" title="Link to this heading"></a></h2>
<p>A compliance briefing is not a pitch deck. Garfinkel’s
biography is here because the user of this system is entitled
to know <strong>who is on the commercial and regulatory-facing side
of Verae</strong>, and because a broker-dealer or RIA CCO will
<strong>look the name up on BrokerCheck anyway</strong>. The honest
presentation is:</p>
<ul class="simple">
<li><p>CEO of Verae LLC (public listing, from 2020);</p></li>
<li><p>a long New York securities-industry registration history
ending March 2024 at LPL, <strong>not currently registered</strong>;</p></li>
<li><p><strong>no</strong> BrokerCheck disclosed events on the current report;</p></li>
<li><p><strong>not</strong> given a biography block on verae.com at the time
this document was compiled — Haber is the scientist the
site puts on the homepage.</p></li>
</ul>
<p>Do not treat a CRD number as a product certification. Do not
treat a CEO biography as a control.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

240
build/html/bio-stuart-haber.html Normal file
View file

@ -0,0 +1,240 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>15. Stuart Haber &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="16. George Lambert" href="bio-george-lambert.html" />
<link rel="prev" title="14. James H. Garfinkel" href="bio-james-garfinkel.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">15. Stuart Haber</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#role-at-verae">15.1. Role at Verae</a></li>
<li class="toctree-l2"><a class="reference internal" href="#the-scientific-work">15.2. The scientific work</a></li>
<li class="toctree-l2"><a class="reference internal" href="#surety-1994-first-commercial-blockchain">15.3. Surety, 1994: first commercial blockchain</a></li>
<li class="toctree-l2"><a class="reference internal" href="#other-cryptographic-publications">15.4. Other cryptographic publications</a></li>
<li class="toctree-l2"><a class="reference internal" href="#why-this-biography-is-in-the-briefing">15.5. Why this biography is in the briefing</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="bio-james-garfinkel.html" title="previous chapter"><span class="section-number">14. </span>James H. Garfinkel</a></li>
<li>Next: <a href="bio-george-lambert.html" title="next chapter"><span class="section-number">16. </span>George Lambert</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="stuart-haber">
<h1><span class="section-number">15. </span>Stuart Haber<a class="headerlink" href="#stuart-haber" title="Link to this heading"></a></h1>
<section id="role-at-verae">
<h2><span class="section-number">15.1. </span>Role at Verae<a class="headerlink" href="#role-at-verae" title="Link to this heading"></a></h2>
<p><strong>Stuart Haber</strong> is a <strong>co-founder of Verae</strong>. The company’s
public site introduces him as one of the creators of
blockchain and as the inventor, in 1991, of cryptographic
timestamping — “the science that lets you prove a record
hasn’t been altered, and the foundation under every
blockchain since.” The site quotes him:</p>
<blockquote>
<div><p>“I co-founded Verae to make blockchain accessible to
enterprises without having to deal with the complexity of
blockchain.”</p>
<p class="attribution">—Stuart Haber, Co-Founder of Verae; co-inventor of
blockchain timestamping, 1991</p>
</div></blockquote>
<p>Verae’s product claim is that this is the proof Haber has
been building toward: simple enough for a compliance team,
precise enough for an SEC exam, with the customer’s records
remaining in the customer’s storage and only a fingerprint
being sealed.</p>
</section>
<section id="the-scientific-work">
<h2><span class="section-number">15.2. </span>The scientific work<a class="headerlink" href="#the-scientific-work" title="Link to this heading"></a></h2>
<p>Haber is a cryptographer. He worked at <strong>Bellcore</strong> (Bell
Communications Research) in Morristown, New Jersey, in the
late 1980s and 1990s, in the research culture descended from
Bell Labs. With physicist <strong>W. Scott Stornetta</strong> he posed a
problem that looks obvious only after it is solved: digital
documents live on media that can be altered without a mark;
how do you certify <strong>when the bits existed</strong>, without
trusting the disk, and without handing the document to the
timestamping service?</p>
<p><strong>1991.</strong> Stuart Haber and W. Scott Stornetta, “How to
Time-Stamp a Digital Document,” <em>Journal of Cryptology</em>,
volume 3, number 2, pages 99–111. This is the paper that
introduces computationally practical digital timestamping
so that a user cannot back-date or forward-date a document
even with the collusion of a timestamping service, while
keeping the document itself private. Bitcoin’s white paper
cites it as reference <strong>[3]</strong>.</p>
<p><strong>1993.</strong> Dave Bayer, Stuart Haber, and W. Scott Stornetta,
“Improving the Efficiency and Reliability of Digital
Time-Stamping,” in <em>Sequences II: Methods in Communication,
Security and Computer Science</em>, pages 329–334. Merkle
trees, efficient certificates, publication of a compact
root. Bitcoin’s white paper cites it as reference <strong>[4]</strong>.</p>
<p><strong>1997.</strong> Stuart Haber and W. Scott Stornetta, “Secure names
for bit-strings,” <em>Proceedings of the 4th ACM Conference on
Computer and Communications Security</em>, pages 28–35. Bitcoin’s
white paper cites it as reference <strong>[5]</strong>.</p>
<p>Those three papers are <strong>three of the eight</strong> citations in
Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash
System” (2008). Haber has remarked that this is a .375
batting average, and that Bitcoin is an application built on
top of the early blockchain rather than the invention of the
data structure itself. That is a historical statement, not a
claim that Verae is Bitcoin.</p>
</section>
<section id="surety-1994-first-commercial-blockchain">
<h2><span class="section-number">15.3. </span>Surety, 1994: first commercial blockchain<a class="headerlink" href="#surety-1994-first-commercial-blockchain" title="Link to this heading"></a></h2>
<p>Haber and Stornetta took the research into production as
<strong>Surety</strong>. Surety hashed customer documents, linked those
hashes in a chain of certificates, and published a weekly
summary hash in the classified section of the Sunday <em>New
York Times</em>. That analog publication is widely described as
the oldest surviving public blockchain: a commitment that
does not depend on Surety’s servers remaining honest or
online, because the <em>Times</em> is independently archived. The
design idea — <strong>commit a compact fingerprint to a widely
witnessed record, without revealing the documents</strong> — is
the same idea Verae productizes for enterprise compliance.</p>
</section>
<section id="other-cryptographic-publications">
<h2><span class="section-number">15.4. </span>Other cryptographic publications<a class="headerlink" href="#other-cryptographic-publications" title="Link to this heading"></a></h2>
<p>Haber’s research record is broader than timestamping. It
includes work on minimum-knowledge interactive proofs,
symmetric public-key encryption, and secure multi-party
protocols (including “Cryptographic Computation: Secure
Fault-Tolerant Protocols and the Public-Key Model”). A
reader who wants the academic trail should start with the
three Bitcoin-cited papers and the 1991 <em>Journal of
Cryptology</em> article, then the ACM CCS 1997 paper.</p>
</section>
<section id="why-this-biography-is-in-the-briefing">
<h2><span class="section-number">15.5. </span>Why this biography is in the briefing<a class="headerlink" href="#why-this-biography-is-in-the-briefing" title="Link to this heading"></a></h2>
<p>Timestamping in this document is not a metaphor. It is a
specific scientific object — hash, time, sequence, privacy
of the document from the notary — that Haber defined in
print in 1991, commercialized in 1994, and is now building
into Verae so that a CCO can produce a receipt instead of a
vendor letter. The biography is here as <strong>provenance of the
receipt</strong>, not as a substitute for the organization’s
controls.</p>
<p>The same honesty that applies to Peergos applies here:
Haber co-invented the timestamping chain; he did not issue
the customer’s SOC 2.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

285
build/html/checklist.html
View file

@ -5,17 +5,19 @@
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Audit-ready checklist &#8212; Making yourself audit-ready with Verae DataCubes</title>
<title>12. Audit-ready checklist &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=27fed22d" />
<script src="_static/documentation_options.js?v=5929fcd5"></script>
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="How to use this pack" href="howto.html" />
<link rel="prev" title="BAAs and DPAs when ciphertext has no host keys" href="baa-dpa.html" />
<link rel="next" title="13. How to use this briefing" href="howto.html" />
<link rel="prev" title="11. BAAs, DPAs, and ciphertext without host keys" href="baa-dpa.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
@ -24,96 +26,24 @@
</head><body>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="audit-ready-checklist">
<h1>Audit-ready checklist<a class="headerlink" href="#audit-ready-checklist" title="Link to this heading"></a></h1>
<p>Use this as a working list. Check items only when <strong>evidence exists</strong>
(screenshot, log export, signed policy, ticket). This list is not a
certificate.</p>
<section id="a-scope-and-data-map">
<h2>A. Scope and data map<a class="headerlink" href="#a-scope-and-data-map" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>Named legal entity and systems in scope (console, Drive, NATS, IPFS, ns1)</p></li>
<li><p>Data-flow diagram: endpoint → HPKE/NATS → cryptree/IPFS</p></li>
<li><p>What is PHI / personal data vs ciphertext vs routing metadata</p></li>
<li><p>Peergos verification chapter attached (<a class="reference internal" href="verification.html"><span class="doc">Peergos verification (what was actually audited)</span></a>)</p></li>
</ul>
</section>
<section id="b-keys-and-encryption">
<h2>B. Keys and encryption<a class="headerlink" href="#b-keys-and-encryption" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>Customer holds Peergos/Drive keys; not on storage host</p></li>
<li><p>NPE/HPKE endpoint keys in directory; private 0600; no xor content</p></li>
<li><p>Signed Ed25519 config; unsigned rejected; admin-history prev+new+diff</p></li>
<li><p>HSM or documented lab-to-HSM path</p></li>
</ul>
</section>
<section id="c-access">
<h2>C. Access<a class="headerlink" href="#c-access" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>Console <code class="docutils literal notranslate"><span class="pre">PFC_REQUIRE_AUTH=1</span></code>, TOTP; Drive login separate</p></li>
<li><p>Inspect k-of-n; author is not an officer; log-before-reveal</p></li>
<li><p>Joiner / mover / leaver for console users</p></li>
<li><p>Google SSO does <strong>not</strong> unwrap cubes</p></li>
</ul>
</section>
<section id="d-integrity-and-backup">
<h2>D. Integrity and backup<a class="headerlink" href="#d-integrity-and-backup" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>Cube chain append-only JSONL; dual hash</p></li>
<li><p>Hash registry: first SHA-256 and receipt win</p></li>
<li><p>Peergos/IPFS: hash-verified encrypted blocks (restore = re-fetch CIDs)</p></li>
<li><p>Restore test: recover a cube from content-addressed ciphertext without
plaintext backup tapes</p></li>
</ul>
</section>
<section id="e-logging">
<h2>E. Logging<a class="headerlink" href="#e-logging" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>Inspect audit events</p></li>
<li><p>SM summaries: codes + lookup_id only (no bodies)</p></li>
<li><p>Admin-history cube for config</p></li>
</ul>
</section>
<section id="f-contracts-counsel">
<h2>F. Contracts (counsel)<a class="headerlink" href="#f-contracts-counsel" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>Written BA / not-a-BA determination for disk, VM, backup, IPFS</p></li>
<li><p>DPA Art. 28 where usernames/logs/IPs are processed</p></li>
<li><p>NATS operator: metadata vs content in the annex</p></li>
<li><p>Peergos component assurance: attach Cure53 2019 + ROS 2024 PDFs
(public; not your org’s ISO/SOC report)</p></li>
</ul>
</section>
<section id="g-independent-audit-of-you">
<h2>G. Independent audit of <em>you</em><a class="headerlink" href="#g-independent-audit-of-you" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>SOC 2 Type I/II engagement <strong>or</strong> ISO 27001 registrar <strong>or</strong> HIPAA
risk analysis + policies (pick the program you actually need)</p></li>
<li><p>Evidence window (Type II / surveillance) if applicable</p></li>
</ul>
</section>
</section>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<h1 class="logo"><a href="index.html">Making yourself audit-ready with Verae DataCubes</a></h1>
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
@ -129,29 +59,43 @@ risk analysis + policies (pick the program you actually need)</p></li>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="verification.html">Peergos verification (what was actually audited)</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">Architecture (audit interview)</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">BAAs and DPAs when ciphertext has no host keys</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">Audit-ready checklist</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#a-scope-and-data-map">A. Scope and data map</a></li>
<li class="toctree-l2"><a class="reference internal" href="#b-keys-and-encryption">B. Keys and encryption</a></li>
<li class="toctree-l2"><a class="reference internal" href="#c-access">C. Access</a></li>
<li class="toctree-l2"><a class="reference internal" href="#d-integrity-and-backup">D. Integrity and backup</a></li>
<li class="toctree-l2"><a class="reference internal" href="#e-logging">E. Logging</a></li>
<li class="toctree-l2"><a class="reference internal" href="#f-contracts-counsel">F. Contracts (counsel)</a></li>
<li class="toctree-l2"><a class="reference internal" href="#g-independent-audit-of-you">G. Independent audit of <em>you</em></a></li>
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">12. Audit-ready checklist</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#a-scope-and-honesty">12.1. A. Scope and honesty</a></li>
<li class="toctree-l2"><a class="reference internal" href="#b-data-in-transit">12.2. B. Data in transit</a></li>
<li class="toctree-l2"><a class="reference internal" href="#c-data-at-rest">12.3. C. Data at rest</a></li>
<li class="toctree-l2"><a class="reference internal" href="#d-timestamping">12.4. D. Timestamping</a></li>
<li class="toctree-l2"><a class="reference internal" href="#e-write-once-archive">12.5. E. Write-once archive</a></li>
<li class="toctree-l2"><a class="reference internal" href="#f-access-and-change">12.6. F. Access and change</a></li>
<li class="toctree-l2"><a class="reference internal" href="#g-contracts-counsel">12.7. G. Contracts (counsel)</a></li>
<li class="toctree-l2"><a class="reference internal" href="#h-independent-examination-of-this-organization">12.8. H. Independent examination of <em>this</em> organization</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">How to use this pack</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="baa-dpa.html" title="previous chapter">BAAs and DPAs when ciphertext has no host keys</a></li>
<li>Next: <a href="howto.html" title="next chapter">How to use this pack</a></li>
<li>Previous: <a href="baa-dpa.html" title="previous chapter"><span class="section-number">11. </span>BAAs, DPAs, and ciphertext without host keys</a></li>
<li>Next: <a href="howto.html" title="next chapter"><span class="section-number">13. </span>How to use this briefing</a></li>
</ul></li>
</ul>
</div>
@ -163,22 +107,139 @@ risk analysis + policies (pick the program you actually need)</p></li>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="audit-ready-checklist">
<h1><span class="section-number">12. </span>Audit-ready checklist<a class="headerlink" href="#audit-ready-checklist" title="Link to this heading"></a></h1>
<p>Use this as a working list. Check an item only when
<strong>evidence exists</strong> (screenshot, log export, signed policy,
ticket, receipt). This list is not a certificate. Software
having been installed does not tick these boxes.</p>
<section id="a-scope-and-honesty">
<h2><span class="section-number">12.1. </span>A. Scope and honesty<a class="headerlink" href="#a-scope-and-honesty" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>Named legal entity and systems in scope (console, Drive,
message fabric, IPFS, timestamping link, Iceberg archive)</p></li>
<li><p>Written sentence in the system description: <strong>software is
not our HIPAA / SOC 2 / ISO 27001 certificate</strong></p></li>
<li><p>Data-flow diagram: endpoint → HPKE → DataCube →
Peergos/IPFS → receipt → Iceberg</p></li>
<li><p>PHI / personal data vs ciphertext vs routing metadata,
named</p></li>
<li><p>Peergos evaluation chapter attached, labeled <strong>component
security evaluation</strong></p></li>
</ul>
</section>
<section id="b-data-in-transit">
<h2><span class="section-number">12.2. </span>B. Data in transit<a class="headerlink" href="#b-data-in-transit" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>Production algorithm is HPKE (or documented successor),
not a lab construction</p></li>
<li><p>Destinations and subjects documented as <strong>visible by
design</strong></p></li>
<li><p>Error paths carry codes and lookup ids, not bodies</p></li>
<li><p>Public-key directory lists public keys only; private keys
mode 0600 or HSM</p></li>
<li><p>Broker operator named; metadata vs content in the annex</p></li>
</ul>
</section>
<section id="c-data-at-rest">
<h2><span class="section-number">12.3. </span>C. Data at rest<a class="headerlink" href="#c-data-at-rest" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>Customer holds Peergos / Drive keys; not on storage host</p></li>
<li><p>Peergos hash verification on write and on read, evidenced</p></li>
<li><p>Restore test: recover a cube from content-addressed
ciphertext <strong>without</strong> a plaintext tape</p></li>
<li><p>Dual-hash cube chain; first-hash-wins registry</p></li>
</ul>
</section>
<section id="d-timestamping">
<h2><span class="section-number">12.4. </span>D. Timestamping<a class="headerlink" href="#d-timestamping" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>First-registration rule documented and tested (second
submit returns original receipt)</p></li>
<li><p>Organizational node <strong>linked</strong> to central Verae, <strong>or</strong>
direct sync, named in the diagram</p></li>
<li><p>Sample bundle: receipt + private metadata + attachment
pointer, redacted for the evidence pack</p></li>
<li><p>Verae receives fingerprints, not objects — stated in
the data map</p></li>
</ul>
</section>
<section id="e-write-once-archive">
<h2><span class="section-number">12.5. </span>E. Write-once archive<a class="headerlink" href="#e-write-once-archive" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>Iceberg (or equivalent) export job exists and has a dated
last-run</p></li>
<li><p>Object-lock / dual-control / separate account — evidence
that no <strong>single</strong> party can delete a committed snapshot</p></li>
<li><p>Retention schedule written by records/counsel, not by
engineering folklore</p></li>
<li><p>Legal-hold procedure extends retention; ticket example</p></li>
</ul>
</section>
<section id="f-access-and-change">
<h2><span class="section-number">12.6. </span>F. Access and change<a class="headerlink" href="#f-access-and-change" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>Console requires authentication (TOTP or equivalent);
Drive login is a separate plane</p></li>
<li><p>Inspect is k-of-n; author is not an officer; log-before-reveal</p></li>
<li><p>Joiner / mover / leaver for console users</p></li>
<li><p>Signed configuration; unsigned rejected; admin-history
prev + new + diff</p></li>
<li><p>HSM or a dated plan to move lab keys to HSM</p></li>
</ul>
</section>
<section id="g-contracts-counsel">
<h2><span class="section-number">12.7. </span>G. Contracts (counsel)<a class="headerlink" href="#g-contracts-counsel" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>Written BA / not-a-BA determination for disk, VM, backup,
IPFS, Iceberg</p></li>
<li><p>DPA Article 28 where usernames, logs, or IPs are processed</p></li>
<li><p>NATS operator: metadata vs content</p></li>
<li><p>Verae timestamping: fingerprint-only processing described</p></li>
<li><p>Peergos PDFs attached and labeled “not our Type II / ISO”</p></li>
</ul>
</section>
<section id="h-independent-examination-of-this-organization">
<h2><span class="section-number">12.8. </span>H. Independent examination of <em>this</em> organization<a class="headerlink" href="#h-independent-examination-of-this-organization" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p>SOC 2 Type I/II engagement, <strong>or</strong> ISO 27001 registrar,
<strong>or</strong> HIPAA risk analysis plus policies — <strong>the program
actually chosen</strong>, not all three as wallpaper</p></li>
<li><p>Evidence window (Type II / surveillance) if applicable</p></li>
<li><p>Named internal owner who will sit in the meeting and not
claim the software is the certificate</p></li>
</ul>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
&#169;2026, Verae.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 9.1.0</a>
&amp; <a href="https://alabaster.readthedocs.io">Alabaster 1.0.0</a>
|
<a href="_sources/checklist.rst.txt"
rel="nofollow">Page source</a>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>

170
build/html/contact.html Normal file
View file

@ -0,0 +1,170 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>17. Verae Inc — contact &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="prev" title="16. George Lambert" href="bio-george-lambert.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">17. Verae Inc — contact</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#closing-reminder">17.1. Closing reminder</a></li>
</ul>
</li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="bio-george-lambert.html" title="previous chapter"><span class="section-number">16. </span>George Lambert</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="verae-inc-contact">
<h1><span class="section-number">17. </span>Verae Inc — contact<a class="headerlink" href="#verae-inc-contact" title="Link to this heading"></a></h1>
<p>This page is the contact block that also appears in the
footer of every page of the PDF edition and at the bottom
of every HTML chapter.</p>
<p><strong>Verae Inc</strong></p>
<p>Website: <a class="reference external" href="https://www.verae.com">https://www.verae.com</a></p>
<p>Product / activity console: <a class="reference external" href="https://app.verae.com">https://app.verae.com</a></p>
<p>Book a conversation: use the “Book a call” path on
<a class="reference external" href="https://www.verae.com">https://www.verae.com</a> (the public site states that the
company will be in touch within one business day).</p>
<p>API (fingerprint seal, as described on the public site):
<a class="reference external" href="https://api.verae.com/v1/seal">https://api.verae.com/v1/seal</a></p>
<p>This briefing (HTML and PDF):</p>
<ul class="simple">
<li><p><a class="reference external" href="https://docs.pfc.georgelambert.org/audit-ready/">https://docs.pfc.georgelambert.org/audit-ready/</a></p></li>
<li><p><a class="reference external" href="https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes">https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes</a></p></li>
</ul>
<p>A street address and telephone number are <strong>not invented
here</strong>. If a procurement file requires them, take them from
a current Verae engagement letter, W-9, or the form on
verae.com, not from this paragraph.</p>
<section id="closing-reminder">
<h2><span class="section-number">17.1. </span>Closing reminder<a class="headerlink" href="#closing-reminder" title="Link to this heading"></a></h2>
<p>Software alone does not make an organization HIPAA
certified, SOC 2 attested, or ISO 27001 certified.</p>
<p>The Verae DataCube Solution gives you tools to store,
communicate, timestamp, verify, and audit. Your
organization still has to write the policies, run the
procedures, operate the internal controls, and sit with an
independent auditor. Verae provides the tools, the
background, and the software infrastructure for the
<strong>technical portion</strong> of that work.</p>
<p>Verae Inc — <a class="reference external" href="https://www.verae.com">https://www.verae.com</a></p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

270
build/html/data-at-rest.html Normal file
View file

@ -0,0 +1,270 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>5. Encryption at rest — IPFS blocks and Peergos &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="6. Global timestamped receipts" href="timestamped-receipts.html" />
<link rel="prev" title="4. Secure communications — data in transit" href="data-in-transit.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">5. Encryption at rest — IPFS blocks and Peergos</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#the-problem">5.1. The problem</a></li>
<li class="toctree-l2"><a class="reference internal" href="#content-addressed-blocks">5.2. Content-addressed blocks</a></li>
<li class="toctree-l2"><a class="reference internal" href="#peergos-on-top-of-ipfs">5.3. Peergos on top of IPFS</a></li>
<li class="toctree-l2"><a class="reference internal" href="#tamper-evident-restore">5.4. Tamper-evident restore</a></li>
<li class="toctree-l2"><a class="reference internal" href="#append-only-at-the-cube-layer">5.5. Append-only at the cube layer</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-a-disk-operator-sees">5.6. What a disk operator sees</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-this-does-and-does-not-satisfy">5.7. What this does, and does not, satisfy</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="data-in-transit.html" title="previous chapter"><span class="section-number">4. </span>Secure communications — data in transit</a></li>
<li>Next: <a href="timestamped-receipts.html" title="next chapter"><span class="section-number">6. </span>Global timestamped receipts</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="encryption-at-rest-ipfs-blocks-and-peergos">
<h1><span class="section-number">5. </span>Encryption at rest — IPFS blocks and Peergos<a class="headerlink" href="#encryption-at-rest-ipfs-blocks-and-peergos" title="Link to this heading"></a></h1>
<section id="the-problem">
<h2><span class="section-number">5.1. </span>The problem<a class="headerlink" href="#the-problem" title="Link to this heading"></a></h2>
<p>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.</p>
<p>The Verae DataCube Server Solution stores <strong>data at rest</strong> as
<strong>encrypted, content-addressed IPFS blocks</strong>, with <strong>Peergos</strong>
verifying hashes on the way in and the way out.</p>
</section>
<section id="content-addressed-blocks">
<h2><span class="section-number">5.2. </span>Content-addressed blocks<a class="headerlink" href="#content-addressed-blocks" title="Link to this heading"></a></h2>
<p>IPFS names a block by a cryptographic hash of its contents (a
Content Identifier, or CID). Two properties follow immediately:</p>
<ul class="simple">
<li><p>If the bits change, the name changes. There is no such thing as
“the same CID, different payload” under a collision-resistant
hash.</p></li>
<li><p>A client that asked for CID X and received bytes whose hash is
not X <strong>knows</strong> it was given the wrong object.</p></li>
</ul>
<p>That is the definition of a <strong>tamper-evident</strong> 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).</p>
</section>
<section id="peergos-on-top-of-ipfs">
<h2><span class="section-number">5.3. </span>Peergos on top of IPFS<a class="headerlink" href="#peergos-on-top-of-ipfs" title="Link to this heading"></a></h2>
<p>Peergos is not “IPFS with a folder UI.” It is an encrypted
filesystem — a <strong>cryptree</strong> — whose nodes and file chunks are
stored as IPFS blocks. The properties that matter for an
audit-ready DataCube are:</p>
<ul class="simple">
<li><p><strong>Client-side encryption.</strong> 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.</p></li>
<li><p><strong>Hash verification.</strong> Peergos <strong>verifies the hash</strong> 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.</p></li>
<li><p><strong>Signed writes.</strong> Updates are signed. An unsigned rewrite is
not a valid Peergos write.</p></li>
<li><p><strong>Independent chunk keys.</strong> 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.</p></li>
<li><p><strong>CHAMP</strong> places encrypted cryptree nodes under random 32-byte
labels, so the storage host cannot walk the directory tree by
name.</p></li>
<li><p><strong>Sharing</strong> 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.</p></li>
</ul>
</section>
<section id="tamper-evident-restore">
<h2><span class="section-number">5.4. </span>Tamper-evident restore<a class="headerlink" href="#tamper-evident-restore" title="Link to this heading"></a></h2>
<p>“Backup” in this architecture does not mean a second plaintext
copy in a different building. It means:</p>
<ol class="arabic simple">
<li><p>the CIDs that constitute a cube are known;</p></li>
<li><p>the encrypted blocks for those CIDs exist on more than one
replica;</p></li>
<li><p>a restore <strong>re-fetches</strong> the blocks and <strong>re-verifies</strong> the
hashes;</p></li>
<li><p>the customer, holding keys, decrypts locally.</p></li>
</ol>
<p>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.</p>
</section>
<section id="append-only-at-the-cube-layer">
<h2><span class="section-number">5.5. </span>Append-only at the cube layer<a class="headerlink" href="#append-only-at-the-cube-layer" title="Link to this heading"></a></h2>
<p>Peergos itself uses signed updates and immutable blocks. The
Verae DataCube adds an <strong>application-level chain</strong>: 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.</p>
<p>These two layers must not be conflated in an audit interview:</p>
<ul class="simple">
<li><p><strong>IPFS / Peergos</strong> 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.</p></li>
<li><p><strong>The cube chain</strong> proves that the organization’s own history
of writes is append-only at the application layer.</p></li>
</ul>
<p>Both are needed. Neither is a SOC 2 report.</p>
</section>
<section id="what-a-disk-operator-sees">
<h2><span class="section-number">5.6. </span>What a disk operator sees<a class="headerlink" href="#what-a-disk-operator-sees" title="Link to this heading"></a></h2>
<p>If keys never leave the client or the customer’s HSM, a disk
operator, a VM snapshot operator, and an offsite replica operator
see <strong>opaque hashed ciphertext</strong>. They do not see PHI, they do
not see document titles, they do not see the graph of who shared
what with whom.</p>
<p>That fact <strong>changes the Business Associate / processor
conversation</strong>. It does not automatically end it. Usernames, IP
addresses, billing identity, and support logs can still be
personal data. Chapter 11 takes that up.</p>
</section>
<section id="what-this-does-and-does-not-satisfy">
<h2><span class="section-number">5.7. </span>What this does, and does not, satisfy<a class="headerlink" href="#what-this-does-and-does-not-satisfy" title="Link to this heading"></a></h2>
<p>For HIPAA encryption of ePHI <strong>at rest</strong>, for SOC 2 CC6
encryption of stored data, and for ISO 27001 Annex A cryptography
and storage, this is the <strong>technical control</strong>: ciphertext on
disk, keys with the customer, hash-checked restore.</p>
<p>It does <strong>not</strong> by itself satisfy:</p>
<ul class="simple">
<li><p>a <strong>key-custody policy</strong> (who can unwrap, where the HSM lives,
how a lost key is declared);</p></li>
<li><p>a <strong>restore-test procedure</strong> with a dated ticket proving
someone actually did it last quarter;</p></li>
<li><p><strong>retention and legal-hold</strong> rules (those require the
write-once archive in Chapter 9, plus lawyers);</p></li>
<li><p><strong>physical</strong> security of the machines, which still belongs in
the organization’s ISMS or HIPAA facility controls.</p></li>
</ul>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

243
build/html/data-in-transit.html Normal file
View file

@ -0,0 +1,243 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>4. Secure communications — data in transit &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="5. Encryption at rest — IPFS blocks and Peergos" href="data-at-rest.html" />
<link rel="prev" title="3. The Verae DataCube Server Solution" href="datacube-server.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">4. Secure communications — data in transit</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#the-problem">4.1. The problem</a></li>
<li class="toctree-l2"><a class="reference internal" href="#point-to-point-encryption">4.2. Point-to-point encryption</a></li>
<li class="toctree-l2"><a class="reference internal" href="#visible-routing">4.3. Visible routing</a></li>
<li class="toctree-l2"><a class="reference internal" href="#error-handling-without-leaking-content">4.4. Error handling without leaking content</a></li>
<li class="toctree-l2"><a class="reference internal" href="#the-public-key-directory">4.5. The public-key directory</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-this-does-and-does-not-satisfy">4.6. What this does, and does not, satisfy</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="datacube-server.html" title="previous chapter"><span class="section-number">3. </span>The Verae DataCube Server Solution</a></li>
<li>Next: <a href="data-at-rest.html" title="next chapter"><span class="section-number">5. </span>Encryption at rest — IPFS blocks and Peergos</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="secure-communications-data-in-transit">
<h1><span class="section-number">4. </span>Secure communications — data in transit<a class="headerlink" href="#secure-communications-data-in-transit" title="Link to this heading"></a></h1>
<section id="the-problem">
<h2><span class="section-number">4.1. </span>The problem<a class="headerlink" href="#the-problem" title="Link to this heading"></a></h2>
<p>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 “<strong>what</strong> will
they see, and <strong>what</strong> will they be able to do with it.”</p>
<p>The Verae DataCube Server Solution answers that question with
<strong>point-to-point encryption of content</strong> and an explicit admission
that <strong>routing must be visible</strong>.</p>
</section>
<section id="point-to-point-encryption">
<h2><span class="section-number">4.2. </span>Point-to-point encryption<a class="headerlink" href="#point-to-point-encryption" title="Link to this heading"></a></h2>
<p>“Best in class” here is not a slogan; it names a concrete choice.
Production content is sealed with <strong>HPKE</strong> (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 <strong>public</strong> 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
<strong>private</strong> key can open it.</p>
<p>Consequences that matter in an audit interview:</p>
<ul class="simple">
<li><p>The <strong>sender cannot reopen</strong> 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.</p></li>
<li><p>The <strong>broker cannot open</strong> the body. Possession of the wire
image is possession of ciphertext.</p></li>
<li><p>A <strong>lab XOR</strong> construction, if it exists in a codebase for
experiments, is not a production algorithm. Production
configurations reject it.</p></li>
</ul>
</section>
<section id="visible-routing">
<h2><span class="section-number">4.3. </span>Visible routing<a class="headerlink" href="#visible-routing" title="Link to this heading"></a></h2>
<p>A network that cannot see a destination cannot deliver a message.
The DataCube Server Solution therefore does <strong>not</strong> claim
anonymous, metadata-free messaging. The following remain visible
to the transport, by design:</p>
<ul class="simple">
<li><p>destination (the handle or address the router needs);</p></li>
<li><p>subject or stream name (so the right service receives the
envelope);</p></li>
<li><p>sender handle or lookup identifier, when the protocol carries
them for reply and error handling;</p></li>
<li><p>approximate size and timing (any network sees these).</p></li>
</ul>
<p>This is the <strong>honest-but-curious broker</strong> model. Curiosity is
assumed. Honesty is assumed only in the narrow sense that the
broker forwards what it is given; it is <strong>not</strong> trusted with
content, and it is <strong>not</strong> trusted not to log destinations.</p>
</section>
<section id="error-handling-without-leaking-content">
<h2><span class="section-number">4.4. </span>Error handling without leaking content<a class="headerlink" href="#error-handling-without-leaking-content" title="Link to this heading"></a></h2>
<p>Failures have to be reported. A bounce that includes the original
body would undo the encryption. The design therefore returns
<strong>error metadata</strong>: 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.</p>
<p>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.</p>
</section>
<section id="the-public-key-directory">
<h2><span class="section-number">4.5. </span>The public-key directory<a class="headerlink" href="#the-public-key-directory" title="Link to this heading"></a></h2>
<p>Point-to-point encryption is only as good as the lookup of public
keys. The server solution publishes a <strong>directory of public keys</strong>
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 <code class="docutils literal notranslate"><span class="pre">0600</span></code>, held on the endpoint or in an HSM, and are
never returned by the public listing API.</p>
<p>An examiner can be shown the public listing. An examiner should
never be given a private key.</p>
</section>
<section id="what-this-does-and-does-not-satisfy">
<h2><span class="section-number">4.6. </span>What this does, and does not, satisfy<a class="headerlink" href="#what-this-does-and-does-not-satisfy" title="Link to this heading"></a></h2>
<p>For HIPAA Security Rule addressable encryption of ePHI <strong>in
transit</strong>, for SOC 2 CC6 cryptographic transmission, and for
ISO 27001 Annex A transmission security, this design is the
<strong>technical control</strong>: content is encrypted to the recipient, the
path is untrusted, keys are endpoint-held.</p>
<p>It does <strong>not</strong> by itself satisfy:</p>
<ul class="simple">
<li><p>a rule that requires the organization to <strong>inventory</strong> every
channel (personal devices, shadow SaaS, unapproved AI tools);</p></li>
<li><p>a rule that requires <strong>workforce sanctions</strong> when someone
bypasses the channel;</p></li>
<li><p>a rule that requires <strong>agreements</strong> with the broker operator
covering metadata that may still be personal data.</p></li>
</ul>
<p>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.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

241
build/html/datacube-server.html Normal file
View file

@ -0,0 +1,241 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>3. The Verae DataCube Server Solution &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="4. Secure communications — data in transit" href="data-in-transit.html" />
<link rel="prev" title="2. What Verae provides — and what it does not" href="what-verae-provides.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">3. The Verae DataCube Server Solution</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#purpose">3.1. Purpose</a></li>
<li class="toctree-l2"><a class="reference internal" href="#the-datacube-as-a-container">3.2. The DataCube as a container</a></li>
<li class="toctree-l2"><a class="reference internal" href="#two-information-states-one-operational-picture">3.3. Two information states, one operational picture</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-server-means-in-practice">3.4. What “server” means in practice</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-the-server-solution-is-not">3.5. What the server solution is not</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="what-verae-provides.html" title="previous chapter"><span class="section-number">2. </span>What Verae provides — and what it does not</a></li>
<li>Next: <a href="data-in-transit.html" title="next chapter"><span class="section-number">4. </span>Secure communications — data in transit</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="the-verae-datacube-server-solution">
<h1><span class="section-number">3. </span>The Verae DataCube Server Solution<a class="headerlink" href="#the-verae-datacube-server-solution" title="Link to this heading"></a></h1>
<section id="purpose">
<h2><span class="section-number">3.1. </span>Purpose<a class="headerlink" href="#purpose" title="Link to this heading"></a></h2>
<p>A Verae DataCube Server Solution is the on-premises or
customer-hosted assembly that gives an organization a place to put
sensitive digital objects, a way to move them, a way to prove when
they first existed, and a way to show an examiner that the bits
have not been silently rewritten.</p>
<p>It is a <strong>server solution</strong> in the sense that an organization runs
(or has run for it) a set of cooperating services: encrypted
storage, a message fabric, a public-key directory, a timestamping
link to Verae’s central service, and an archival export path. It is
not a single binary, and it is not a cloud folder with a padlock
icon.</p>
</section>
<section id="the-datacube-as-a-container">
<h2><span class="section-number">3.2. </span>The DataCube as a container<a class="headerlink" href="#the-datacube-as-a-container" title="Link to this heading"></a></h2>
<p>A <strong>DataCube</strong> is a customer-controlled container for digital
objects and for the metadata that makes those objects examinable.
Typical contents include:</p>
<ul class="simple">
<li><p>the object bytes (a message body, a document, an image, a log
extract, an AI prompt and completion, or any other digital
media);</p></li>
<li><p><strong>private metadata</strong> that the organization needs but does not
necessarily share (internal identifiers, matter numbers, legal-hold
flags);</p></li>
<li><p><strong>attached files</strong> that travel with the object;</p></li>
<li><p>an <strong>internal chain</strong> of hashes so that the cube itself has a
history — each new write names the previous write.</p></li>
</ul>
<p>Verae’s public product description is consistent with this split:
records stay in <strong>storage the customer controls</strong>; Verae seals a
<strong>fingerprint</strong>. The server solution is the machinery that makes
that split operational rather than rhetorical.</p>
</section>
<section id="two-information-states-one-operational-picture">
<h2><span class="section-number">3.3. </span>Two information states, one operational picture<a class="headerlink" href="#two-information-states-one-operational-picture" title="Link to this heading"></a></h2>
<p>Classical security training divides information into <strong>data in
transit</strong> and <strong>data at rest</strong>. The DataCube Server Solution is
built around that division.</p>
<p><strong>In transit</strong>, the problem is an untrusted network. Messages must
be readable at the destination and nowhere else along the path, yet
the path must still be able to deliver them. Chapter 4 treats that
problem in full: point-to-point encryption, visible routing,
honest-but-curious brokers.</p>
<p><strong>At rest</strong>, the problem is an untrusted disk, an untrusted backup
operator, and an untrusted replica. Bytes must be stored so that a
host who does not hold keys sees opaque blocks, and so that a
restore can prove it brought back the same blocks that were
written. Chapter 5 treats that problem in full: IPFS
content-addressed ciphertext, Peergos hash verification,
tamper-evident restore.</p>
<p>A third problem sits beside those two: <strong>time</strong>. Storage and transit
prove confidentiality and integrity of <em>what</em> was stored or sent.
They do not, by themselves, prove <em>when</em> it first existed, or that
a later rewrite is not being offered as the original. Timestamped
receipts (Chapter 6) and the cross-blockchain timestamping
architecture (Chapter 8) address that.</p>
</section>
<section id="what-server-means-in-practice">
<h2><span class="section-number">3.4. </span>What “server” means in practice<a class="headerlink" href="#what-server-means-in-practice" title="Link to this heading"></a></h2>
<p>In a typical deployment the organization runs, or links:</p>
<ul class="simple">
<li><p>a <strong>Peergos</strong> instance (or equivalent cryptree client) that
writes encrypted, content-addressed blocks;</p></li>
<li><p>an <strong>IPFS</strong> layer that stores and replicates those blocks by
hash;</p></li>
<li><p>a <strong>message fabric</strong> (NATS in the reference deployment) that
carries HPKE-sealed bodies with destinations in the clear;</p></li>
<li><p>a <strong>public-key directory</strong> so every endpoint can find every
other endpoint’s encryption key without a private-key leak;</p></li>
<li><p>an <strong>organizational timestamping node</strong> that either syncs with
Verae’s central timestamping server or is linked to it;</p></li>
<li><p>an <strong>admin-history</strong> cube that records configuration changes as
previous state, new state, and diff;</p></li>
<li><p>an <strong>Iceberg write-once export</strong> that takes cubes out of any
single party’s delete path (Chapter 9).</p></li>
</ul>
<p>Each of those pieces can be drawn on a whiteboard in an audit
interview. Each of them also has a failure mode that the
organization’s procedures must name: lost keys, a mis-issued
directory entry, a broker that drops messages, a replica that
serves a wrong block (detected by hash), a timestamping link that
is down, an archive job that did not run.</p>
</section>
<section id="what-the-server-solution-is-not">
<h2><span class="section-number">3.5. </span>What the server solution is not<a class="headerlink" href="#what-the-server-solution-is-not" title="Link to this heading"></a></h2>
<p>It is not a substitute for workforce training. It is not a
substitute for a Business Associate Agreement analysis. It is not a
substitute for access reviews. It is not, by itself, “the HIPAA
control set” or “the SOC 2 system.” It is the <strong>technical
substrate</strong> on which those controls can be implemented with less
faith in honest administrators and more reliance on hashes,
receipts, and keys the customer holds.</p>
<p>The following four chapters unpack the substrate: transit, rest,
receipts, and the European evaluations of the Peergos storage
layer.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

292
build/html/executive.html Normal file
View file

@ -0,0 +1,292 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>1. Executive summary &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="2. What Verae provides — and what it does not" href="what-verae-provides.html" />
<link rel="prev" title="Making yourself audit-ready with Verae DataCubes" href="index.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1 current"><a class="current reference internal" href="#">1. Executive summary</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#what-a-verae-datacube-server-solution-does">1.1. What a Verae DataCube Server Solution does</a></li>
<li class="toctree-l2"><a class="reference internal" href="#data-in-transit">1.2. Data in transit</a></li>
<li class="toctree-l2"><a class="reference internal" href="#data-at-rest">1.3. Data at rest</a></li>
<li class="toctree-l2"><a class="reference internal" href="#global-timestamped-receipts">1.4. Global timestamped receipts</a></li>
<li class="toctree-l2"><a class="reference internal" href="#peergos-evaluated-in-europe">1.5. Peergos, evaluated in Europe</a></li>
<li class="toctree-l2"><a class="reference internal" href="#verae-global-timestamping">1.6. Verae global timestamping</a></li>
<li class="toctree-l2"><a class="reference internal" href="#write-once-iceberg-archive">1.7. Write-once Iceberg archive</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-this-briefing-is-and-is-not">1.8. What this briefing is, and is not</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="index.html" title="previous chapter">Making yourself audit-ready with Verae DataCubes</a></li>
<li>Next: <a href="what-verae-provides.html" title="next chapter"><span class="section-number">2. </span>What Verae provides — and what it does not</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="executive-summary">
<h1><span class="section-number">1. </span>Executive summary<a class="headerlink" href="#executive-summary" title="Link to this heading"></a></h1>
<p>Software alone does not make an organization HIPAA certified, SOC 2
attested, or ISO 27001 certified.</p>
<p>That sentence is the point of this document. It is also the sentence
that is most often skipped when a vendor, an integrator, or an internal
champion shows encryption, hashing, or a pentest PDF and treats the
conversation as finished. It is not finished. Encryption is a control.
A pentest is an evaluation of a component. A certificate, an attestation,
or a covered-entity determination is a statement about <strong>an organization</strong>
— its legal entity, its people, its written policies, its operating
procedures, its internal controls, the evidence those controls produce,
and the independent party that examined that evidence.</p>
<p>The Verae DataCube Solution gives an organization tools to <strong>store</strong>,
<strong>communicate</strong>, <strong>timestamp</strong>, <strong>verify</strong>, and <strong>audit</strong> for compliance.
Those tools are real, they are specific, and they are described in the
chapters that follow. They are still only tools. To obtain HIPAA-aligned
status as a covered entity or business associate with a defensible
program, a SOC 2 Type I or Type II report, or an ISO 27001 certificate,
the organization must still:</p>
<ul class="simple">
<li><p>write and live by <strong>policies</strong> (what the organization says it will do);</p></li>
<li><p>operate <strong>procedures</strong> (how staff actually do it, every day);</p></li>
<li><p>design and test <strong>internal controls</strong> (the checks that catch failure);</p></li>
<li><p>retain <strong>evidence</strong> (logs, tickets, screenshots, signed approvals,
restore tests, training records);</p></li>
<li><p>engage an <strong>independent auditor</strong>, CPA firm, or ISO registrar, as the
chosen program requires.</p></li>
</ul>
<p>Verae cannot issue those certificates. Verae cannot sit in the
organization’s chair during an OCR investigation, a SOC 2 fieldwork
week, or an ISO Stage 2 audit. What Verae can do — and what this
briefing is written to make precise — is provide the <strong>tools</strong>, the
<strong>background</strong>, and the <strong>software infrastructure</strong> that make it easier
to implement the <strong>technical portion</strong> of those programs.</p>
<section id="what-a-verae-datacube-server-solution-does">
<h2><span class="section-number">1.1. </span>What a Verae DataCube Server Solution does<a class="headerlink" href="#what-a-verae-datacube-server-solution-does" title="Link to this heading"></a></h2>
<p>A Verae DataCube Server Solution provides <strong>secure communications and
storage</strong> for two classical information-security states:</p>
<ul class="simple">
<li><p><strong>Data in transit</strong> — messages, objects, and control traffic while
they move from one endpoint to another.</p></li>
<li><p><strong>Data at rest</strong> — messages, objects, metadata, and receipts while
they sit on disk, in a replica, or in an archive.</p></li>
</ul>
<p>Those two states are not the same problem, and they are not solved by
the same mechanism. This document treats them separately on purpose.</p>
</section>
<section id="data-in-transit">
<h2><span class="section-number">1.2. </span>Data in transit<a class="headerlink" href="#data-in-transit" title="Link to this heading"></a></h2>
<p>Verae uses best-in-class encryption for messaging <strong>from point to
point</strong>. The content of a message is sealed so that only the intended
endpoints can open it. Routing, however, <strong>must remain visible</strong>: a
message that cannot be addressed cannot be delivered. Subjects,
destination handles, and size or timing metadata are therefore
visible to the transport. The transport is treated as
<strong>honest-but-curious</strong>. It can drop, delay, or copy ciphertext. It
cannot read the body if it does not hold endpoint private keys.</p>
</section>
<section id="data-at-rest">
<h2><span class="section-number">1.3. </span>Data at rest<a class="headerlink" href="#data-at-rest" title="Link to this heading"></a></h2>
<p>Encryption at rest is performed through <strong>IPFS content-addressed
blocks</strong>. Each block is named by its hash. Peergos verifies those
hashes on read and on write. A restore is therefore
<strong>tamper-evident</strong>: if a block was altered, its hash no longer
matches, and the client refuses it. This is not a plaintext tape
backup. It is a re-fetch of hashed ciphertext plus a verification
that the bits are the bits that were stored.</p>
</section>
<section id="global-timestamped-receipts">
<h2><span class="section-number">1.4. </span>Global timestamped receipts<a class="headerlink" href="#global-timestamped-receipts" title="Link to this heading"></a></h2>
<p>Independently of who stores the bytes, Verae issues <strong>global
timestamped receipts</strong> based on <strong>document hashes</strong>. A receipt is
proof of the <strong>time and sequence of the first registration</strong> of a
block of digital information — a message, an image, a document, or
any other digital object that can be stored in digital media. The
receipt does not require Verae to see the object. It requires a
fingerprint of the object, registered at a time that can later be
shown to third parties.</p>
</section>
<section id="peergos-evaluated-in-europe">
<h2><span class="section-number">1.5. </span>Peergos, evaluated in Europe<a class="headerlink" href="#peergos-evaluated-in-europe" title="Link to this heading"></a></h2>
<p>The offline storage and replication system used with Peergos was
<strong>audited twice in Europe</strong>, and the protocol was designed under
work that was independently reviewed:</p>
<ul class="simple">
<li><p><strong>2019 — Cure53, Berlin, Germany.</strong> Pentest, source-code audit,
and <strong>crypto/design review</strong> (May–June 2019). No fundamental
architectural or cryptographic problems. Issues found were fixed.
Cure53 stated that the platform <strong>passed this evaluation</strong>.</p></li>
<li><p><strong>2024 — Radically Open Security B.V., Amsterdam, Netherlands.</strong>
Crystal-box pentest plus code audit of the Peergos web UI
(September–November 2024). <strong>Zero</strong> findings rated extreme, high,
or elevated; <strong>two</strong> moderate; <strong>six</strong> low. Peergos states all
were fixed. No data exposure and no integrity compromise (the
issues were mostly UI crashes).</p></li>
</ul>
<p>Both firms are <strong>EU-based</strong>. Both full reports are <strong>public</strong>. That
is a <strong>security evaluation of the Peergos protocol and
implementation</strong>. It is <strong>not</strong> a HIPAA certificate, a SOC 2 report,
or an ISO 27001 certificate for Peergos, for Verae, or for any
customer.</p>
</section>
<section id="verae-global-timestamping">
<h2><span class="section-number">1.6. </span>Verae global timestamping<a class="headerlink" href="#verae-global-timestamping" title="Link to this heading"></a></h2>
<p>The Verae Global Timestamping and receipt solution is a
<strong>cross-blockchain</strong> design. It certifies the time and date stamp of
a digital object and stores that information in a <strong>digital bundle</strong>
that can carry private metadata, attached files, and an internal
blockchain. That organizational chain is <strong>cross-verified</strong> either:</p>
<ul class="simple">
<li><p>from an organizational server <strong>linked to the central Verae
server</strong>, or</p></li>
<li><p>by <strong>directly syncing</strong> with Verae’s central timestamping server.</p></li>
</ul>
<p>The result is <strong>proof of existence</strong> of a digital object at a
specific time and date. When the organization wants the object
itself stored — not only its fingerprint — the object can live
inside an <strong>encrypted Peergos DataCube</strong>.</p>
</section>
<section id="write-once-iceberg-archive">
<h2><span class="section-number">1.7. </span>Write-once Iceberg archive<a class="headerlink" href="#write-once-iceberg-archive" title="Link to this heading"></a></h2>
<p>Those DataCubes are archived into a <strong>write-once external Iceberg
file-storage solution</strong> for compliance reasons. The archive is
designed to sit <strong>outside the deletion control of any single
party</strong>. That is a retention and legal-hold property, not a
marketing slogan: once a cube is committed to the write-once tier,
neither the customer operator, nor Verae, nor a hosting vendor
should be able to quietly erase it.</p>
</section>
<section id="what-this-briefing-is-and-is-not">
<h2><span class="section-number">1.8. </span>What this briefing is, and is not<a class="headerlink" href="#what-this-briefing-is-and-is-not" title="Link to this heading"></a></h2>
<p>This briefing describes the <strong>technical portion</strong> of a compliance
program that an organization can build with Verae DataCubes. It
indexes each of the points above as its own chapter, in enough
detail that a CISO, a CCO, outside counsel, or an auditor can
distinguish:</p>
<ul class="simple">
<li><p>what the software <strong>does</strong>;</p></li>
<li><p>what the independent <strong>Peergos evaluations</strong> actually said;</p></li>
<li><p>what <strong>Verae timestamping</strong> actually proves;</p></li>
<li><p>what the organization <strong>must still write, operate, and have
examined</strong>.</p></li>
</ul>
<p>It does not claim that installing this software finishes HIPAA,
SOC 2, or ISO 27001. Anyone who says otherwise is not describing
this product honestly.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

92
build/html/genindex.html
View file

@ -7,10 +7,12 @@
<title>Index &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=27fed22d" />
<script src="_static/documentation_options.js?v=5929fcd5"></script>
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="#" />
<link rel="search" title="Search" href="search.html" />
@ -21,33 +23,24 @@
</head><body>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<h1 id="index">Index</h1>
<div class="genindex-jumpbox">
</div>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<h1 class="logo"><a href="index.html">Making yourself audit-ready with Verae DataCubes</a></h1>
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
@ -63,12 +56,25 @@
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="verification.html">Peergos verification (what was actually audited)</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">Architecture (audit interview)</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">BAAs and DPAs when ciphertext has no host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">How to use this pack</a></li>
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
@ -86,21 +92,43 @@
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<h1 id="index">Index</h1>
<div class="genindex-jumpbox">
</div>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
&#169;2026, Verae.
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 9.1.0</a>
&amp; <a href="https://alabaster.readthedocs.io">Alabaster 1.0.0</a>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

266
build/html/global-timestamping.html Normal file
View file

@ -0,0 +1,266 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>8. Verae global timestamping — a cross-blockchain receipt &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="9. Write-once Iceberg archive" href="iceberg-archive.html" />
<link rel="prev" title="7. Peergos security evaluations in Europe" href="peergos-eu-evaluations.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">8. Verae global timestamping — a cross-blockchain receipt</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#lineage">8.1. Lineage</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-cross-blockchain-means-here">8.2. What “cross-blockchain” means here</a></li>
<li class="toctree-l2"><a class="reference internal" href="#two-deployment-patterns">8.3. Two deployment patterns</a></li>
<li class="toctree-l2"><a class="reference internal" href="#the-digital-bundle">8.4. The digital bundle</a></li>
<li class="toctree-l2"><a class="reference internal" href="#proof-of-existence-versus-proof-of-custody">8.5. Proof of existence versus proof of custody</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-this-does-and-does-not-satisfy">8.6. What this does, and does not, satisfy</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="peergos-eu-evaluations.html" title="previous chapter"><span class="section-number">7. </span>Peergos security evaluations in Europe</a></li>
<li>Next: <a href="iceberg-archive.html" title="next chapter"><span class="section-number">9. </span>Write-once Iceberg archive</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="verae-global-timestamping-a-cross-blockchain-receipt">
<h1><span class="section-number">8. </span>Verae global timestamping — a cross-blockchain receipt<a class="headerlink" href="#verae-global-timestamping-a-cross-blockchain-receipt" title="Link to this heading"></a></h1>
<section id="lineage">
<h2><span class="section-number">8.1. </span>Lineage<a class="headerlink" href="#lineage" title="Link to this heading"></a></h2>
<p>The scientific problem Verae is productizing is not new. In
1991, Stuart Haber and W. Scott Stornetta published “How to
Time-Stamp a Digital Document” in the <em>Journal of
Cryptology</em>. They asked how to certify when a digital
document was created or last changed <strong>without trusting the
medium</strong> and <strong>without giving the timestamping service the
document</strong>. In 1993, with Dave Bayer, they showed how Merkle
trees make that efficient. In 1997 they published “Secure
names for bit-strings.” Satoshi Nakamoto’s 2008 Bitcoin
white paper cites those three papers as references [3], [4],
and [5] — three of the eight citations in that document.</p>
<p>Haber co-founded <strong>Surety</strong> in 1994, widely described as the
first commercial blockchain: a hash-linked chain of document
certificates, with a weekly summary published in the Sunday
<em>New York Times</em> so that the day’s commitments sat in a
public, widely archived analog record.</p>
<p>Haber is a <strong>co-founder of Verae</strong>. Verae’s public site
states the aim directly: make that proof simple enough for a
compliance team and precise enough for an SEC exam, without
forcing the enterprise to operate a public blockchain. The
quote on verae.com is: “I co-founded Verae to make
blockchain accessible to enterprises without having to deal
with the complexity of blockchain.”</p>
</section>
<section id="what-cross-blockchain-means-here">
<h2><span class="section-number">8.2. </span>What “cross-blockchain” means here<a class="headerlink" href="#what-cross-blockchain-means-here" title="Link to this heading"></a></h2>
<p>A single private log, held only by the vendor, is a vendor
assurance letter with extra steps. A single public chain may
be operationally and commercially the wrong place to put an
enterprise’s registration traffic. Verae’s design is
<strong>cross-blockchain</strong> in the following sense:</p>
<ul class="simple">
<li><p>an <strong>organizational chain</strong> runs at the customer, inside
or beside the DataCube, recording hashes, metadata, and
sequence;</p></li>
<li><p>a <strong>central Verae chain</strong> records fingerprints and issues
receipts;</p></li>
<li><p>the two are <strong>cross-verified</strong>, so that neither side can
rewrite history without the other side’s record disagreeing;</p></li>
<li><p>when policy calls for it, commitments can be <strong>anchored
further</strong> — additional public or consortium chains — so
that proof of existence does not collapse if one operator
disappears.</p></li>
</ul>
<p>The customer does not have to become a blockchain operator
to use this. That is the product claim. The examiner does
not have to trust a single vendor’s database to verify a
receipt. That is the scientific claim, inherited from
Haber–Stornetta.</p>
</section>
<section id="two-deployment-patterns">
<h2><span class="section-number">8.3. </span>Two deployment patterns<a class="headerlink" href="#two-deployment-patterns" title="Link to this heading"></a></h2>
<p><strong>Linked organizational server.</strong> The organization runs a
timestamping node next to its DataCube server. That node is
linked to the central Verae timestamping server. Local
registrations are committed locally (low latency, private
metadata stays home) and cross-verified centrally (receipt
the rest of the world can check).</p>
<p><strong>Direct sync.</strong> An organization that does not want to run
the organizational node can sync registrations directly with
Verae’s central timestamping server. Proof of existence at a
specific date and time still issues. Private metadata and
attached files, if any, remain the organization’s problem to
store — typically in the encrypted Peergos DataCube.</p>
<p>Both patterns produce the same external artifact: a receipt
bound to a hash, a time, and a sequence. They differ in
where the organizational metadata lives and in how much
infrastructure the customer operates.</p>
</section>
<section id="the-digital-bundle">
<h2><span class="section-number">8.4. </span>The digital bundle<a class="headerlink" href="#the-digital-bundle" title="Link to this heading"></a></h2>
<p>The unit of production is a <strong>digital bundle</strong>:</p>
<ul class="simple">
<li><p>the <strong>receipt</strong> (hash, time, sequence, verification path);</p></li>
<li><p><strong>private metadata</strong> (classification, matter, hold,
internal identifiers) that need not be on a public chain;</p></li>
<li><p><strong>attached files</strong> that should be produced together;</p></li>
<li><p>a pointer or capability to the object in the encrypted
DataCube, when the organization chose to store the object
and not only its fingerprint.</p></li>
</ul>
<p>An examiner can be given the bundle, or a redacted bundle,
without being given a login to the production console and
without Verae ever having seen the object bytes.</p>
</section>
<section id="proof-of-existence-versus-proof-of-custody">
<h2><span class="section-number">8.5. </span>Proof of existence versus proof of custody<a class="headerlink" href="#proof-of-existence-versus-proof-of-custody" title="Link to this heading"></a></h2>
<p>Timestamping answers: <strong>did these bits exist by this time?</strong></p>
<p>The DataCube answers: <strong>does the organization still have
them, encrypted, hash-checkable?</strong></p>
<p>The Iceberg write-once tier answers: <strong>can anyone quietly
delete them anyway?</strong></p>
<p>A complete production to a regulator often needs all three.
Timestamping alone is not an archive. An archive without a
receipt is a pile of files with a clock on the filesystem
that the administrator can set.</p>
</section>
<section id="what-this-does-and-does-not-satisfy">
<h2><span class="section-number">8.6. </span>What this does, and does not, satisfy<a class="headerlink" href="#what-this-does-and-does-not-satisfy" title="Link to this heading"></a></h2>
<p>For SEC Rule 17a-4, FINRA books-and-records, and similar
regimes that demand records in a non-rewriteable,
non-erasable form <strong>with the ability to produce the
original</strong>, timestamped receipts plus write-once archive are
the <strong>technical portion</strong> of the answer: you can show when
the record was sealed, that the bits match, and that the
archive copy is not under ordinary delete.</p>
<p>They do not satisfy:</p>
<ul class="simple">
<li><p>the requirement to <strong>capture the channel in the first
place</strong> (if the team used an unsealed tool, there is
nothing to timestamp);</p></li>
<li><p>the requirement to have <strong>written procedures</strong> for
production, legal hold, and supervision;</p></li>
<li><p>the requirement that a <strong>named principal</strong> own the
recordkeeping obligation.</p></li>
</ul>
<p>Software seals what it is shown. The organization must still
show it the right things, on time, under a policy someone
will sign.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

165
build/html/howto.html
View file

@ -5,16 +5,19 @@
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>How to use this pack &#8212; Making yourself audit-ready with Verae DataCubes</title>
<title>13. How to use this briefing &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=27fed22d" />
<script src="_static/documentation_options.js?v=5929fcd5"></script>
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="prev" title="Audit-ready checklist" href="checklist.html" />
<link rel="next" title="14. James H. Garfinkel" href="bio-james-garfinkel.html" />
<link rel="prev" title="12. Audit-ready checklist" href="checklist.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
@ -23,51 +26,24 @@
</head><body>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="how-to-use-this-pack">
<h1>How to use this pack<a class="headerlink" href="#how-to-use-this-pack" title="Link to this heading"></a></h1>
<ol class="arabic simple">
<li><p>Read <a class="reference internal" href="verification.html"><span class="doc">Peergos verification (what was actually audited)</span></a> so you do not over-claim Peergos audits.</p></li>
<li><p>Fill <a class="reference internal" href="checklist.html"><span class="doc">Audit-ready checklist</span></a> with <strong>your</strong> instance evidence (ns1, keys, users).</p></li>
<li><p>Give <a class="reference internal" href="baa-dpa.html"><span class="doc">BAAs and DPAs when ciphertext has no host keys</span></a> to counsel with the data-flow from <a class="reference internal" href="architecture.html"><span class="doc">Architecture (audit interview)</span></a>.</p></li>
<li><p>Point auditors at live technical surfaces (do not give them private keys).</p></li>
</ol>
<ul class="simple">
<li><p><a class="reference external" href="https://pfc.georgelambert.org/health">https://pfc.georgelambert.org/health</a></p></li>
<li><p><a class="reference external" href="https://pfc.georgelambert.org/v1/npe/keys">https://pfc.georgelambert.org/v1/npe/keys</a> (public keys only)</p></li>
<li><p><a class="reference external" href="https://docs.pfc.georgelambert.org/controls.html">https://docs.pfc.georgelambert.org/controls.html</a></p></li>
<li><p><a class="reference external" href="https://docs.pfc.georgelambert.org/custody.html">https://docs.pfc.georgelambert.org/custody.html</a></p></li>
<li><p>Peergos Drive (cryptree) on your host</p></li>
<li><p><a class="reference external" href="https://git.georgelambert.org/marchon/peergos-for-compliance">https://git.georgelambert.org/marchon/peergos-for-compliance</a></p></li>
<li><p><a class="reference external" href="https://git.georgelambert.org/marchon/system-git-sync">https://git.georgelambert.org/marchon/system-git-sync</a></p></li>
<li><p><a class="reference external" href="https://git.georgelambert.org/marchon/secure-messaging">https://git.georgelambert.org/marchon/secure-messaging</a></p></li>
</ul>
<ol class="arabic simple" start="5">
<li><p>Attach the two <strong>public</strong> Peergos pentest PDFs from the Peergos
<code class="docutils literal notranslate"><span class="pre">audits/</span></code> tree as <strong>vendor security evaluations</strong>, labeled “not our
SOC 2 / ISO certificate”.</p></li>
</ol>
</section>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<h1 class="logo"><a href="index.html">Making yourself audit-ready with Verae DataCubes</a></h1>
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
@ -83,19 +59,33 @@ SOC 2 / ISO certificate”.</p></li>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="verification.html">Peergos verification (what was actually audited)</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">Architecture (audit interview)</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">BAAs and DPAs when ciphertext has no host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">Audit-ready checklist</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">How to use this pack</a></li>
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="checklist.html" title="previous chapter">Audit-ready checklist</a></li>
<li>Previous: <a href="checklist.html" title="previous chapter"><span class="section-number">12. </span>Audit-ready checklist</a></li>
<li>Next: <a href="bio-james-garfinkel.html" title="next chapter"><span class="section-number">14. </span>James H. Garfinkel</a></li>
</ul></li>
</ul>
</div>
@ -107,22 +97,81 @@ SOC 2 / ISO certificate”.</p></li>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="how-to-use-this-briefing">
<h1><span class="section-number">13. </span>How to use this briefing<a class="headerlink" href="#how-to-use-this-briefing" title="Link to this heading"></a></h1>
<ol class="arabic simple">
<li><p>Read the <strong>executive summary</strong> aloud in the first five
minutes of any vendor, board, or auditor meeting that
touches this system. If anyone says “so we are certified,”
stop and reread Chapter 1.</p></li>
<li><p>Read <strong>What Verae provides</strong> so the five verbs (store,
communicate, timestamp, verify, audit) are not confused
with an ISMS, a Type II, or a HIPAA program.</p></li>
<li><p>Read the <strong>transit</strong>, <strong>rest</strong>, <strong>receipts</strong>, <strong>Peergos
evaluations</strong>, <strong>timestamping</strong>, and <strong>Iceberg</strong> chapters
in that order. They are the technical portion, in the
order an examiner usually probes: “can the wire read it,
can the disk read it, can you prove when, who looked at
the crypto, can you produce it later.”</p></li>
<li><p>Fill the <strong>checklist</strong> with <strong>this instance’s</strong> evidence.
Empty checkboxes are not a moral failing; they are the
work remaining.</p></li>
<li><p>Give <strong>BAAs and DPAs</strong> to counsel with the architecture
diagram. Do not let engineering declare a vendor “not a
BA.”</p></li>
<li><p>Attach the two <strong>public</strong> Peergos reports as <strong>vendor
security evaluations</strong>, with a cover slip that says they
are not the organization’s SOC 2, ISO 27001, or HIPAA
certification.</p></li>
<li><p>Point auditors at <strong>live technical surfaces</strong> (health,
public-key listing, Drive). Do not give them private
keys. Do not give them a story that the pentest PDF is
the Type II.</p></li>
<li><p>Keep the <strong>biographies</strong> at the back of the PDF for
provenance — who built the timestamping science, who
is building the product, who architected the internet
integration and the DataCube server side — without
substituting biography for controls.</p></li>
</ol>
<p>Reference instance (not a certificate):</p>
<ul class="simple">
<li><p><a class="reference external" href="https://pfc.georgelambert.org/health">https://pfc.georgelambert.org/health</a></p></li>
<li><p><a class="reference external" href="https://pfc.georgelambert.org/v1/npe/keys">https://pfc.georgelambert.org/v1/npe/keys</a> (public keys only)</p></li>
<li><p><a class="reference external" href="https://docs.pfc.georgelambert.org/controls.html">https://docs.pfc.georgelambert.org/controls.html</a></p></li>
<li><p><a class="reference external" href="https://docs.pfc.georgelambert.org/custody.html">https://docs.pfc.georgelambert.org/custody.html</a></p></li>
<li><p><a class="reference external" href="https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes">https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes</a></p></li>
<li><p><a class="reference external" href="https://www.verae.com">https://www.verae.com</a></p></li>
</ul>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
&#169;2026, Verae.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 9.1.0</a>
&amp; <a href="https://alabaster.readthedocs.io">Alabaster 1.0.0</a>
|
<a href="_sources/howto.rst.txt"
rel="nofollow">Page source</a>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>

260
build/html/iceberg-archive.html Normal file
View file

@ -0,0 +1,260 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>9. Write-once Iceberg archive &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="10. Architecture for an audit interview" href="architecture.html" />
<link rel="prev" title="8. Verae global timestamping — a cross-blockchain receipt" href="global-timestamping.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">9. Write-once Iceberg archive</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#the-deletion-problem">9.1. The deletion problem</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-write-once-iceberg-means-in-this-solution">9.2. What “write-once Iceberg” means in this solution</a></li>
<li class="toctree-l2"><a class="reference internal" href="#how-cubes-move-into-the-archive">9.3. How cubes move into the archive</a></li>
<li class="toctree-l2"><a class="reference internal" href="#relation-to-classical-worm">9.4. Relation to classical WORM</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-this-does-and-does-not-satisfy">9.5. What this does, and does not, satisfy</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="global-timestamping.html" title="previous chapter"><span class="section-number">8. </span>Verae global timestamping — a cross-blockchain receipt</a></li>
<li>Next: <a href="architecture.html" title="next chapter"><span class="section-number">10. </span>Architecture for an audit interview</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="write-once-iceberg-archive">
<h1><span class="section-number">9. </span>Write-once Iceberg archive<a class="headerlink" href="#write-once-iceberg-archive" title="Link to this heading"></a></h1>
<section id="the-deletion-problem">
<h2><span class="section-number">9.1. </span>The deletion problem<a class="headerlink" href="#the-deletion-problem" title="Link to this heading"></a></h2>
<p>Encryption at rest stops a disk operator from <strong>reading</strong>.
Hash verification stops a replica from <strong>substituting</strong>.
Timestamped receipts stop a custodian from <strong>back-dating</strong>.
None of those, by themselves, stop a person with legitimate
administrative power from <strong>deleting</strong>.</p>
<p>Deletion is the failure mode that turns a recordkeeping
program into a fine. Off-channel messaging cases at
broker-dealers were, at bottom, failures to <strong>produce</strong>. A
record that existed and was then removed, “cleaned up,” or
rotated out of the only copy is, to an examiner, a record
that cannot be produced.</p>
<p>Compliance therefore needs a tier where <strong>ordinary
administrative power does not include delete</strong>.</p>
</section>
<section id="what-write-once-iceberg-means-in-this-solution">
<h2><span class="section-number">9.2. </span>What “write-once Iceberg” means in this solution<a class="headerlink" href="#what-write-once-iceberg-means-in-this-solution" title="Link to this heading"></a></h2>
<p>DataCubes — the encrypted, hash-chained containers — are
<strong>archived</strong> into an <strong>external, write-once file-storage
solution</strong> built on the <strong>Iceberg</strong> table/file model (a
layout of immutable data files plus a metadata log that
records new snapshots rather than rewriting old ones).</p>
<p>Properties the solution is specified to have:</p>
<ul class="simple">
<li><p><strong>Write once.</strong> A committed archive object is not updated
in place. A correction is a <strong>new</strong> object with a <strong>new</strong>
receipt. The original remains.</p></li>
<li><p><strong>External.</strong> The archive is not the same disk as the
live Peergos instance. Compromising the live server should
not confer delete on the archive.</p></li>
<li><p><strong>Outside any single party’s deletion control.</strong> The
customer operator, Verae, and the hosting vendor are each
insufficient, by themselves, to erase a committed archive
file. Practical implementations of that requirement use
some combination of object-lock / WORM flags, dual-control
hold, independent cloud or tape accounts, and contractual
prohibition on early delete — plus the technical fact
that Iceberg snapshots are new files, not overwrites.</p></li>
<li><p><strong>For compliance reasons.</strong> This tier exists because
retention schedules, legal holds, and examiner production
require it — not because it is a convenient backup.</p></li>
</ul>
</section>
<section id="how-cubes-move-into-the-archive">
<h2><span class="section-number">9.3. </span>How cubes move into the archive<a class="headerlink" href="#how-cubes-move-into-the-archive" title="Link to this heading"></a></h2>
<p>A live DataCube is an operational object: it receives new
writes, it is replicated as encrypted IPFS blocks, it is
readable by holders of the right capabilities. On a schedule
and on events (legal hold, period close, exam notice), the
server solution <strong>exports</strong> a cube snapshot:</p>
<ol class="arabic simple">
<li><p>freeze a CID set and cube-chain head;</p></li>
<li><p>confirm Peergos hash verification of every block in the
set;</p></li>
<li><p>register that snapshot’s hash with Verae timestamping
(first registration of <em>this</em> snapshot);</p></li>
<li><p>write the encrypted snapshot into Iceberg as a new
immutable data file (or set of files) under a snapshot
id that never reuses a previous id;</p></li>
<li><p>record, in admin-history, that the archive job ran, who
authorized it, and which receipt was issued.</p></li>
</ol>
<p>A restore from the archive is the same tamper-evident path
as a restore from IPFS: re-fetch, re-verify hashes, decrypt
only with customer keys.</p>
<p>What “outside the control of any party for deletion” is
and is not
——————————————————-</p>
<p>It is <strong>not</strong> a claim that physics forbids destruction of
every copy in a fire, a court order, or a coordinated
malicious act by every holder of every credential. No
storage system honestly claims that.</p>
<p>It <strong>is</strong> a claim that the <strong>ordinary</strong> delete path — the
button, the <code class="docutils literal notranslate"><span class="pre">rm</span></code>, the lifecycle rule, the “empty trash,”
the support ticket to “please remove that customer folder”
— is not available to any one party acting alone against a
committed archive object. Dual control, object lock, and
separation of the archive account from the live-server
account are the organizational complements to the file
format.</p>
<p>The organization’s retention policy still has to name:</p>
<ul class="simple">
<li><p>how long a class of record stays in write-once;</p></li>
<li><p>who can place a legal hold that <strong>extends</strong> that period;</p></li>
<li><p>who, under <strong>what dual control</strong>, may allow a record to
age out <strong>after</strong> the policy period, if aging out is
legally permitted at all.</p></li>
</ul>
<p>Software can refuse a delete API. It cannot write the
retention schedule. Counsel and the records officer do that.</p>
</section>
<section id="relation-to-classical-worm">
<h2><span class="section-number">9.4. </span>Relation to classical WORM<a class="headerlink" href="#relation-to-classical-worm" title="Link to this heading"></a></h2>
<p>Broker-dealer Rule 17a-4 and similar texts speak of
non-rewriteable, non-erasable media, originally meaning
optical WORM, later allowing disk with object-lock semantics
and a designated third party. Verae’s public comparison is
that conventional WORM is <strong>immutable by policy</strong> (a vendor
setting), whereas Verae <strong>seals</strong> a record with
cryptographic proof. The Iceberg write-once tier is where
those two ideas meet: the file is not overwritten <strong>and</strong>
the snapshot hash is receipted. An examiner can check the
receipt even if they do not trust the vendor’s “WORM was
on” screenshot.</p>
</section>
<section id="what-this-does-and-does-not-satisfy">
<h2><span class="section-number">9.5. </span>What this does, and does not, satisfy<a class="headerlink" href="#what-this-does-and-does-not-satisfy" title="Link to this heading"></a></h2>
<p>This is the <strong>technical portion</strong> of retention and
production: committed cubes are not under a single delete
key, they are hash-checkable, and they carry a time of
archival.</p>
<p>It does not satisfy a retention <strong>policy</strong> that was never
written, a legal hold that was never placed, or a production
request that the organization answers from a laptop copy
instead of from the archive. Those are procedures.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

311
build/html/index.html
View file

@ -8,13 +8,15 @@
<title>Making yourself audit-ready with Verae DataCubes &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=27fed22d" />
<script src="_static/documentation_options.js?v=5929fcd5"></script>
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Peergos verification (what was actually audited)" href="verification.html" />
<link rel="next" title="1. Executive summary" href="executive.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
@ -23,94 +25,24 @@
</head><body>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="making-yourself-audit-ready-with-verae-datacubes">
<h1>Making yourself audit-ready with Verae DataCubes<a class="headerlink" href="#making-yourself-audit-ready-with-verae-datacubes" title="Link to this heading"></a></h1>
<p>How to <strong>prepare an organization</strong> for HIPAA-aligned, SOC 2, or ISO 27001
work using Verae DataCubes on <strong>Peergos</strong> (encrypted cryptree + hashed
IPFS) and HPKE on an <strong>untrusted NATS</strong> broker.</p>
<p><strong>This document is not a HIPAA, SOC 2, or ISO certificate.</strong>
Peergos’s public pentests are <strong>not</strong> your Type II or ISO registrar
certificate. They are <strong>component security evaluations</strong> you can attach.</p>
<div class="toctree-wrapper compound">
<ul>
<li class="toctree-l1"><a class="reference internal" href="verification.html">Peergos verification (what was actually audited)</a><ul>
<li class="toctree-l2"><a class="reference internal" href="verification.html#claim-to-check">Claim to check</a></li>
<li class="toctree-l2"><a class="reference internal" href="verification.html#independent-security-audits-europe">Independent security audits (Europe)</a></li>
<li class="toctree-l2"><a class="reference internal" href="verification.html#eu-funding-nlnet">EU funding / NLnet</a></li>
<li class="toctree-l2"><a class="reference internal" href="verification.html#hosted-instance-location">Hosted instance location</a></li>
<li class="toctree-l2"><a class="reference internal" href="verification.html#encrypted-filesystem-hashed-ipfs-design">Encrypted filesystem + hashed IPFS (design)</a></li>
<li class="toctree-l2"><a class="reference internal" href="verification.html#not-verified-do-not-claim">Not verified / do not claim</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">Architecture (audit interview)</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">BAAs and DPAs when ciphertext has no host keys</a><ul>
<li class="toctree-l2"><a class="reference internal" href="baa-dpa.html#the-operator-statement">The operator statement</a></li>
<li class="toctree-l2"><a class="reference internal" href="baa-dpa.html#hipaa-us-business-associate">HIPAA (US) — Business Associate</a></li>
<li class="toctree-l2"><a class="reference internal" href="baa-dpa.html#gdpr-eu-uk-processor-vs-technical-measure">GDPR (EU/UK) — processor vs technical measure</a></li>
<li class="toctree-l2"><a class="reference internal" href="baa-dpa.html#nats-operators">NATS operators</a></li>
<li class="toctree-l2"><a class="reference internal" href="baa-dpa.html#what-making-yourself-audit-ready-means">What “making yourself audit-ready” means</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">Audit-ready checklist</a><ul>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#a-scope-and-data-map">A. Scope and data map</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#b-keys-and-encryption">B. Keys and encryption</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#c-access">C. Access</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#d-integrity-and-backup">D. Integrity and backup</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#e-logging">E. Logging</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#f-contracts-counsel">F. Contracts (counsel)</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#g-independent-audit-of-you">G. Independent audit of <em>you</em></a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">How to use this pack</a></li>
</ul>
</div>
<section id="what-we-verified-about-peergos-eu">
<h2>What we verified about Peergos (EU)<a class="headerlink" href="#what-we-verified-about-peergos-eu" title="Link to this heading"></a></h2>
<p>See the full sourced table in <a class="reference internal" href="verification.html"><span class="doc">Peergos verification (what was actually audited)</span></a>.</p>
<ul class="simple">
<li><p>Encrypted client-side filesystem (cryptree); keys not on the storage
server — <strong>yes</strong> (Peergos book + Cure53 design review).</p></li>
<li><p>IPFS blocks content-addressed; Peergos verifies hashes — <strong>yes</strong>.</p></li>
<li><p>Independent <strong>EU</strong> security audits, reports published — <strong>yes, two:</strong>
Cure53 Berlin (2019); Radically Open Security Amsterdam (2024).</p></li>
<li><p>“Peergos is HIPAA/SOC 2/ISO certified” — <strong>no.</strong> Those audits are
pentest/code/design reviews, not management-system certificates.</p></li>
</ul>
<p>Peergos <strong>was designed as a trust-minimized encrypted filesystem</strong>,
<strong>evaluated in Europe</strong> by two specialist firms, with <strong>public reports</strong>.
That supports the <strong>at-rest / backup</strong> story. It does <strong>not</strong> finish
<em>your</em> audit.</p>
<p>Live technical surfaces:</p>
<ul class="simple">
<li><p><a class="reference external" href="https://pfc.georgelambert.org/health">https://pfc.georgelambert.org/health</a></p></li>
<li><p><a class="reference external" href="https://pfc.georgelambert.org/v1/npe/keys">https://pfc.georgelambert.org/v1/npe/keys</a></p></li>
<li><p><a class="reference external" href="https://docs.pfc.georgelambert.org/controls.html">https://docs.pfc.georgelambert.org/controls.html</a></p></li>
<li><p><a class="reference external" href="https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes">https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes</a></p></li>
</ul>
<p>Companion system docs (HTML): <a class="reference external" href="https://docs.pfc.georgelambert.org/">https://docs.pfc.georgelambert.org/</a></p>
</section>
</section>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<h1 class="logo"><a href="#">Making yourself audit-ready with Verae DataCubes</a></h1>
<p class="logo"><a href="#">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="#">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
@ -126,19 +58,32 @@ That supports the <strong>at-rest / backup</strong> story. It does <strong>not</
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="verification.html">Peergos verification (what was actually audited)</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">Architecture (audit interview)</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">BAAs and DPAs when ciphertext has no host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">How to use this pack</a></li>
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="#">Documentation overview</a><ul>
<li>Next: <a href="verification.html" title="next chapter">Peergos verification (what was actually audited)</a></li>
<li>Next: <a href="executive.html" title="next chapter"><span class="section-number">1. </span>Executive summary</a></li>
</ul></li>
</ul>
</div>
@ -150,22 +95,188 @@ That supports the <strong>at-rest / backup</strong> story. It does <strong>not</
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="making-yourself-audit-ready-with-verae-datacubes">
<h1>Making yourself audit-ready with Verae DataCubes<a class="headerlink" href="#making-yourself-audit-ready-with-verae-datacubes" title="Link to this heading"></a></h1>
<a class="logo reference internal image-reference" href="_images/VeraeFullLogo.png"><img alt="Verae" class="logo" src="_images/VeraeFullLogo.png" style="width: 280px;" />
</a>
<p>This volume is a technical briefing. It is <strong>not</strong> a certificate.</p>
<p>The table of contents below is the document map. In the PDF edition,
each chapter starts on a new page and the contents list includes
<strong>section titles with page numbers</strong>. In HTML, each chapter is its own
page with the Verae wordmark in the sidebar and Verae Inc contact
information in the footer.</p>
<div class="toctree-wrapper compound">
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a><ul>
<li class="toctree-l2"><a class="reference internal" href="executive.html#what-a-verae-datacube-server-solution-does">1.1. What a Verae DataCube Server Solution does</a></li>
<li class="toctree-l2"><a class="reference internal" href="executive.html#data-in-transit">1.2. Data in transit</a></li>
<li class="toctree-l2"><a class="reference internal" href="executive.html#data-at-rest">1.3. Data at rest</a></li>
<li class="toctree-l2"><a class="reference internal" href="executive.html#global-timestamped-receipts">1.4. Global timestamped receipts</a></li>
<li class="toctree-l2"><a class="reference internal" href="executive.html#peergos-evaluated-in-europe">1.5. Peergos, evaluated in Europe</a></li>
<li class="toctree-l2"><a class="reference internal" href="executive.html#verae-global-timestamping">1.6. Verae global timestamping</a></li>
<li class="toctree-l2"><a class="reference internal" href="executive.html#write-once-iceberg-archive">1.7. Write-once Iceberg archive</a></li>
<li class="toctree-l2"><a class="reference internal" href="executive.html#what-this-briefing-is-and-is-not">1.8. What this briefing is, and is not</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a><ul>
<li class="toctree-l2"><a class="reference internal" href="what-verae-provides.html#the-boundary">2.1. The boundary</a></li>
<li class="toctree-l2"><a class="reference internal" href="what-verae-provides.html#the-tools">2.2. The tools</a></li>
<li class="toctree-l2"><a class="reference internal" href="what-verae-provides.html#what-the-organization-must-still-do">2.3. What the organization must still do</a></li>
<li class="toctree-l2"><a class="reference internal" href="what-verae-provides.html#why-the-distinction-matters-in-an-exam">2.4. Why the distinction matters in an exam</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a><ul>
<li class="toctree-l2"><a class="reference internal" href="datacube-server.html#purpose">3.1. Purpose</a></li>
<li class="toctree-l2"><a class="reference internal" href="datacube-server.html#the-datacube-as-a-container">3.2. The DataCube as a container</a></li>
<li class="toctree-l2"><a class="reference internal" href="datacube-server.html#two-information-states-one-operational-picture">3.3. Two information states, one operational picture</a></li>
<li class="toctree-l2"><a class="reference internal" href="datacube-server.html#what-server-means-in-practice">3.4. What “server” means in practice</a></li>
<li class="toctree-l2"><a class="reference internal" href="datacube-server.html#what-the-server-solution-is-not">3.5. What the server solution is not</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a><ul>
<li class="toctree-l2"><a class="reference internal" href="data-in-transit.html#the-problem">4.1. The problem</a></li>
<li class="toctree-l2"><a class="reference internal" href="data-in-transit.html#point-to-point-encryption">4.2. Point-to-point encryption</a></li>
<li class="toctree-l2"><a class="reference internal" href="data-in-transit.html#visible-routing">4.3. Visible routing</a></li>
<li class="toctree-l2"><a class="reference internal" href="data-in-transit.html#error-handling-without-leaking-content">4.4. Error handling without leaking content</a></li>
<li class="toctree-l2"><a class="reference internal" href="data-in-transit.html#the-public-key-directory">4.5. The public-key directory</a></li>
<li class="toctree-l2"><a class="reference internal" href="data-in-transit.html#what-this-does-and-does-not-satisfy">4.6. What this does, and does not, satisfy</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a><ul>
<li class="toctree-l2"><a class="reference internal" href="data-at-rest.html#the-problem">5.1. The problem</a></li>
<li class="toctree-l2"><a class="reference internal" href="data-at-rest.html#content-addressed-blocks">5.2. Content-addressed blocks</a></li>
<li class="toctree-l2"><a class="reference internal" href="data-at-rest.html#peergos-on-top-of-ipfs">5.3. Peergos on top of IPFS</a></li>
<li class="toctree-l2"><a class="reference internal" href="data-at-rest.html#tamper-evident-restore">5.4. Tamper-evident restore</a></li>
<li class="toctree-l2"><a class="reference internal" href="data-at-rest.html#append-only-at-the-cube-layer">5.5. Append-only at the cube layer</a></li>
<li class="toctree-l2"><a class="reference internal" href="data-at-rest.html#what-a-disk-operator-sees">5.6. What a disk operator sees</a></li>
<li class="toctree-l2"><a class="reference internal" href="data-at-rest.html#what-this-does-and-does-not-satisfy">5.7. What this does, and does not, satisfy</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a><ul>
<li class="toctree-l2"><a class="reference internal" href="timestamped-receipts.html#why-hashes-are-not-enough-by-themselves">6.1. Why hashes are not enough by themselves</a></li>
<li class="toctree-l2"><a class="reference internal" href="timestamped-receipts.html#what-a-verae-receipt-is">6.2. What a Verae receipt is</a></li>
<li class="toctree-l2"><a class="reference internal" href="timestamped-receipts.html#what-is-registered-and-what-is-not">6.3. What is registered, and what is not</a></li>
<li class="toctree-l2"><a class="reference internal" href="timestamped-receipts.html#first-registration-wins">6.4. First registration wins</a></li>
<li class="toctree-l2"><a class="reference internal" href="timestamped-receipts.html#sequence">6.5. Sequence</a></li>
<li class="toctree-l2"><a class="reference internal" href="timestamped-receipts.html#bundles">6.6. Bundles</a></li>
<li class="toctree-l2"><a class="reference internal" href="timestamped-receipts.html#what-a-receipt-does-not-prove">6.7. What a receipt does not prove</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a><ul>
<li class="toctree-l2"><a class="reference internal" href="peergos-eu-evaluations.html#what-was-evaluated">7.1. What was evaluated</a></li>
<li class="toctree-l2"><a class="reference internal" href="peergos-eu-evaluations.html#cure53-berlin-germany">7.2. 2019 — Cure53, Berlin, Germany</a></li>
<li class="toctree-l2"><a class="reference internal" href="peergos-eu-evaluations.html#radically-open-security-b-v-amsterdam">7.3. 2024 — Radically Open Security B.V., Amsterdam</a></li>
<li class="toctree-l2"><a class="reference internal" href="peergos-eu-evaluations.html#how-to-present-these-reports-to-an-auditor">7.4. How to present these reports to an auditor</a></li>
<li class="toctree-l2"><a class="reference internal" href="peergos-eu-evaluations.html#hosted-peergos-versus-self-hosted-datacubes">7.5. Hosted Peergos versus self-hosted DataCubes</a></li>
<li class="toctree-l2"><a class="reference internal" href="peergos-eu-evaluations.html#what-designed-under-funding-from-cure53-ros-is-not">7.6. What “designed under funding from Cure53 / ROS” is not</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a><ul>
<li class="toctree-l2"><a class="reference internal" href="global-timestamping.html#lineage">8.1. Lineage</a></li>
<li class="toctree-l2"><a class="reference internal" href="global-timestamping.html#what-cross-blockchain-means-here">8.2. What “cross-blockchain” means here</a></li>
<li class="toctree-l2"><a class="reference internal" href="global-timestamping.html#two-deployment-patterns">8.3. Two deployment patterns</a></li>
<li class="toctree-l2"><a class="reference internal" href="global-timestamping.html#the-digital-bundle">8.4. The digital bundle</a></li>
<li class="toctree-l2"><a class="reference internal" href="global-timestamping.html#proof-of-existence-versus-proof-of-custody">8.5. Proof of existence versus proof of custody</a></li>
<li class="toctree-l2"><a class="reference internal" href="global-timestamping.html#what-this-does-and-does-not-satisfy">8.6. What this does, and does not, satisfy</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a><ul>
<li class="toctree-l2"><a class="reference internal" href="iceberg-archive.html#the-deletion-problem">9.1. The deletion problem</a></li>
<li class="toctree-l2"><a class="reference internal" href="iceberg-archive.html#what-write-once-iceberg-means-in-this-solution">9.2. What “write-once Iceberg” means in this solution</a></li>
<li class="toctree-l2"><a class="reference internal" href="iceberg-archive.html#how-cubes-move-into-the-archive">9.3. How cubes move into the archive</a></li>
<li class="toctree-l2"><a class="reference internal" href="iceberg-archive.html#relation-to-classical-worm">9.4. Relation to classical WORM</a></li>
<li class="toctree-l2"><a class="reference internal" href="iceberg-archive.html#what-this-does-and-does-not-satisfy">9.5. What this does, and does not, satisfy</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a><ul>
<li class="toctree-l2"><a class="reference internal" href="architecture.html#the-picture">10.1. The picture</a></li>
<li class="toctree-l2"><a class="reference internal" href="architecture.html#walkthrough-in-the-order-an-examiner-usually-asks">10.2. Walkthrough, in the order an examiner usually asks</a></li>
<li class="toctree-l2"><a class="reference internal" href="architecture.html#identity-planes">10.3. Identity planes</a></li>
<li class="toctree-l2"><a class="reference internal" href="architecture.html#nats-remains-untrusted">10.4. NATS remains untrusted</a></li>
<li class="toctree-l2"><a class="reference internal" href="architecture.html#what-to-hand-the-examiner">10.5. What to hand the examiner</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a><ul>
<li class="toctree-l2"><a class="reference internal" href="baa-dpa.html#the-technical-fact">11.1. The technical fact</a></li>
<li class="toctree-l2"><a class="reference internal" href="baa-dpa.html#hipaa-business-associate">11.2. HIPAA — Business Associate</a></li>
<li class="toctree-l2"><a class="reference internal" href="baa-dpa.html#gdpr-processor-versus-technical-measure">11.3. GDPR — processor versus technical measure</a></li>
<li class="toctree-l2"><a class="reference internal" href="baa-dpa.html#nats-operators">11.4. NATS operators</a></li>
<li class="toctree-l2"><a class="reference internal" href="baa-dpa.html#verae-as-timestamping-service">11.5. Verae as timestamping service</a></li>
<li class="toctree-l2"><a class="reference internal" href="baa-dpa.html#component-assurance-versus-the-organization-s-report">11.6. Component assurance versus the organization’s report</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a><ul>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#a-scope-and-honesty">12.1. A. Scope and honesty</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#b-data-in-transit">12.2. B. Data in transit</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#c-data-at-rest">12.3. C. Data at rest</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#d-timestamping">12.4. D. Timestamping</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#e-write-once-archive">12.5. E. Write-once archive</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#f-access-and-change">12.6. F. Access and change</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#g-contracts-counsel">12.7. G. Contracts (counsel)</a></li>
<li class="toctree-l2"><a class="reference internal" href="checklist.html#h-independent-examination-of-this-organization">12.8. H. Independent examination of <em>this</em> organization</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a><ul>
<li class="toctree-l2"><a class="reference internal" href="bio-james-garfinkel.html#name-and-sources">14.1. Name and sources</a></li>
<li class="toctree-l2"><a class="reference internal" href="bio-james-garfinkel.html#role-at-verae">14.2. Role at Verae</a></li>
<li class="toctree-l2"><a class="reference internal" href="bio-james-garfinkel.html#finra-brokercheck-crd-5052743">14.3. FINRA BrokerCheck (CRD 5052743)</a></li>
<li class="toctree-l2"><a class="reference internal" href="bio-james-garfinkel.html#education-public-professional-listings">14.4. Education (public professional listings)</a></li>
<li class="toctree-l2"><a class="reference internal" href="bio-james-garfinkel.html#why-this-biography-is-in-the-briefing">14.5. Why this biography is in the briefing</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a><ul>
<li class="toctree-l2"><a class="reference internal" href="bio-stuart-haber.html#role-at-verae">15.1. Role at Verae</a></li>
<li class="toctree-l2"><a class="reference internal" href="bio-stuart-haber.html#the-scientific-work">15.2. The scientific work</a></li>
<li class="toctree-l2"><a class="reference internal" href="bio-stuart-haber.html#surety-1994-first-commercial-blockchain">15.3. Surety, 1994: first commercial blockchain</a></li>
<li class="toctree-l2"><a class="reference internal" href="bio-stuart-haber.html#other-cryptographic-publications">15.4. Other cryptographic publications</a></li>
<li class="toctree-l2"><a class="reference internal" href="bio-stuart-haber.html#why-this-biography-is-in-the-briefing">15.5. Why this biography is in the briefing</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a><ul>
<li class="toctree-l2"><a class="reference internal" href="bio-george-lambert.html#role">16.1. Role</a></li>
<li class="toctree-l2"><a class="reference internal" href="bio-george-lambert.html#internet-technical-architect-from-1994">16.2. Internet technical architect, from 1994</a></li>
<li class="toctree-l2"><a class="reference internal" href="bio-george-lambert.html#new-hampshire-public-office">16.3. New Hampshire public office</a></li>
<li class="toctree-l2"><a class="reference internal" href="bio-george-lambert.html#why-this-biography-is-in-the-briefing">16.4. Why this biography is in the briefing</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a><ul>
<li class="toctree-l2"><a class="reference internal" href="contact.html#closing-reminder">17.1. Closing reminder</a></li>
</ul>
</li>
</ul>
</div>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
&#169;2026, Verae.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 9.1.0</a>
&amp; <a href="https://alabaster.readthedocs.io">Alabaster 1.0.0</a>
|
<a href="_sources/index.rst.txt"
rel="nofollow">Page source</a>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>

BIN
build/html/objects.inv
View file

Binary file not shown.

274
build/html/peergos-eu-evaluations.html Normal file
View file

@ -0,0 +1,274 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>7. Peergos security evaluations in Europe &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="8. Verae global timestamping — a cross-blockchain receipt" href="global-timestamping.html" />
<link rel="prev" title="6. Global timestamped receipts" href="timestamped-receipts.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">7. Peergos security evaluations in Europe</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#what-was-evaluated">7.1. What was evaluated</a></li>
<li class="toctree-l2"><a class="reference internal" href="#cure53-berlin-germany">7.2. 2019 — Cure53, Berlin, Germany</a></li>
<li class="toctree-l2"><a class="reference internal" href="#radically-open-security-b-v-amsterdam">7.3. 2024 — Radically Open Security B.V., Amsterdam</a></li>
<li class="toctree-l2"><a class="reference internal" href="#how-to-present-these-reports-to-an-auditor">7.4. How to present these reports to an auditor</a></li>
<li class="toctree-l2"><a class="reference internal" href="#hosted-peergos-versus-self-hosted-datacubes">7.5. Hosted Peergos versus self-hosted DataCubes</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-designed-under-funding-from-cure53-ros-is-not">7.6. What “designed under funding from Cure53 / ROS” is not</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="timestamped-receipts.html" title="previous chapter"><span class="section-number">6. </span>Global timestamped receipts</a></li>
<li>Next: <a href="global-timestamping.html" title="next chapter"><span class="section-number">8. </span>Verae global timestamping — a cross-blockchain receipt</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="peergos-security-evaluations-in-europe">
<h1><span class="section-number">7. </span>Peergos security evaluations in Europe<a class="headerlink" href="#peergos-security-evaluations-in-europe" title="Link to this heading"></a></h1>
<section id="what-was-evaluated">
<h2><span class="section-number">7.1. </span>What was evaluated<a class="headerlink" href="#what-was-evaluated" title="Link to this heading"></a></h2>
<p>The offline storage and replication system used with Verae
DataCubes is <strong>Peergos</strong>: an encrypted, peer-to-peer filesystem
whose blocks live on IPFS. Peergos was designed as a
trust-minimized store — the server is treated as an adversary
for content and for most metadata — and that design was
submitted to independent European security firms <strong>twice</strong>.</p>
<p>Those engagements are <strong>security evaluations of the Peergos
protocol and implementation</strong>. They are pentests, source-code
audits, and (in 2019) a cryptographic and design review. They
are <strong>not</strong>:</p>
<ul class="simple">
<li><p>a HIPAA certification of Peergos, Verae, or any customer;</p></li>
<li><p>a SOC 2 Type I or Type II report;</p></li>
<li><p>an ISO 27001 certificate of an ISMS;</p></li>
<li><p>a government “certified filesystem” designation.</p></li>
</ul>
<p>Both firms are <strong>EU-based</strong>. Both full reports are <strong>public</strong>.
That combination — independent, European, public, repeat —
is unusual and is worth attaching to a vendor-assurance file,
<strong>labeled correctly</strong>.</p>
</section>
<section id="cure53-berlin-germany">
<h2><span class="section-number">7.2. </span>2019 — Cure53, Berlin, Germany<a class="headerlink" href="#cure53-berlin-germany" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p><strong>Firm:</strong> Cure53</p></li>
<li><p><strong>Location:</strong> Berlin, Germany</p></li>
<li><p><strong>When:</strong> May–June 2019</p></li>
<li><p><strong>Scope:</strong> pentest, source-code audit, and
<strong>crypto / design review</strong></p></li>
<li><p><strong>Outcome:</strong> no fundamental architectural or cryptographic
problems were identified. Issues that were identified were
fixed. Cure53 stated that the platform <strong>passed this
evaluation</strong>.</p></li>
</ul>
<p>A crypto/design review is a stronger statement than a
black-box pentest of a web form. It is an expert reading of
whether the cryptree, the chunk encryption, the identity
model, and the threat model hang together. “Passed” in
Cure53’s language is not an ISO mark. It is a specialist
firm saying: we looked at the cryptography and the
architecture, we did not find a fatal flaw, and the issues we
did find were addressed.</p>
<p>Primary sources (public):</p>
<ul class="simple">
<li><p><a class="reference external" href="https://peergos.org/posts/security-audit">https://peergos.org/posts/security-audit</a></p></li>
<li><p><a class="reference external" href="https://cure53.de/pentest-report_peergos.pdf">https://cure53.de/pentest-report_peergos.pdf</a></p></li>
<li><p><a class="reference external" href="https://github.com/Peergos/Peergos/tree/master/audits">https://github.com/Peergos/Peergos/tree/master/audits</a></p></li>
</ul>
</section>
<section id="radically-open-security-b-v-amsterdam">
<h2><span class="section-number">7.3. </span>2024 — Radically Open Security B.V., Amsterdam<a class="headerlink" href="#radically-open-security-b-v-amsterdam" title="Link to this heading"></a></h2>
<ul class="simple">
<li><p><strong>Firm:</strong> Radically Open Security B.V.</p></li>
<li><p><strong>Location:</strong> Amsterdam, Netherlands</p></li>
<li><p><strong>When:</strong> September–November 2024</p></li>
<li><p><strong>Scope:</strong> crystal-box pentest plus code audit of the
Peergos <strong>web UI</strong></p></li>
<li><p><strong>Funding context:</strong> the 2024 audit post states support
from <strong>NLnet</strong> (Netherlands) and refers to European Union
Horizon 2020 <strong>NGI-POINTER</strong>, grant <strong>871528</strong>.</p></li>
<li><p><strong>Outcome:</strong> <strong>0</strong> findings rated extreme, high, or
elevated; <strong>2</strong> moderate; <strong>6</strong> low. Peergos states that
all were fixed. There was <strong>no data exposure</strong> and <strong>no
integrity compromise</strong>. The issues were described as
mostly UI crashes.</p></li>
</ul>
<p>A crystal-box (clear-box) engagement means the testers had
source. A web-UI scope is narrower than the 2019
crypto/design review: it is evidence about the interface
that humans actually click, which is where many “encrypted
backend” products fail in practice. Zero high-severity
findings, no data exposure, no integrity compromise, and a
public report are the facts. They are good facts. They are
still not a customer’s Type II.</p>
<p>Primary sources (public):</p>
<ul class="simple">
<li><p><a class="reference external" href="https://peergos.org/posts/security-audit-2024">https://peergos.org/posts/security-audit-2024</a></p></li>
<li><p><a class="reference external" href="https://github.com/Peergos/Peergos/tree/master/audits">https://github.com/Peergos/Peergos/tree/master/audits</a></p></li>
</ul>
</section>
<section id="how-to-present-these-reports-to-an-auditor">
<h2><span class="section-number">7.4. </span>How to present these reports to an auditor<a class="headerlink" href="#how-to-present-these-reports-to-an-auditor" title="Link to this heading"></a></h2>
<p>Correct:</p>
<blockquote>
<div><p>“Our at-rest layer is Peergos. Peergos was independently
evaluated in Berlin in 2019 (crypto and design) and in
Amsterdam in 2024 (web UI, crystal box). Both reports are
public. We attach them as <strong>component security
evaluations</strong>. They are not our SOC 2, not our ISO 27001,
and not a HIPAA certification. Our own controls, our own
period of examination, and our own auditor are separate.”</p>
</div></blockquote>
<p>Incorrect:</p>
<blockquote>
<div><p>“We are HIPAA certified because Peergos was audited in
Europe.”</p>
<p>“Peergos is ISO 27001.”</p>
<p>“The EU certified this filesystem.”</p>
</div></blockquote>
<p>EU funding is not a certification. NGI-POINTER grant 871528
is a research-and-innovation funding fact. It is worth
listing under “provenance.” It is not a registrar’s mark.</p>
</section>
<section id="hosted-peergos-versus-self-hosted-datacubes">
<h2><span class="section-number">7.5. </span>Hosted Peergos versus self-hosted DataCubes<a class="headerlink" href="#hosted-peergos-versus-self-hosted-datacubes" title="Link to this heading"></a></h2>
<p>Peergos’s hosted privacy notice has stated that peergos.net
uses servers in <strong>Germany</strong>. A <strong>self-hosted</strong> organizational
DataCube is a <strong>different processing location</strong>. The
customer’s Record of Processing, BAA pack, and ISO scope
must name <em>that</em> location — the customer’s ns1, region, or
chosen host — not peergos.net’s Germany, unless the
customer actually uses peergos.net.</p>
<p>The evaluations still apply to the <strong>protocol and
implementation</strong>. Location of processing is an
organizational fact on top.</p>
</section>
<section id="what-designed-under-funding-from-cure53-ros-is-not">
<h2><span class="section-number">7.6. </span>What “designed under funding from Cure53 / ROS” is not<a class="headerlink" href="#what-designed-under-funding-from-cure53-ros-is-not" title="Link to this heading"></a></h2>
<p>The 2019 Cure53 work and the 2024 ROS work are <strong>evaluations</strong>
of a system that was designed by the Peergos authors. They
are not a claim that Cure53 or Radically Open Security
designed Peergos. The accurate statement is: the storage and
replication system was <strong>independently audited twice in
Europe</strong>, by Cure53 in Berlin (2019) and by Radically Open
Security in Amsterdam (2024), with public reports, and the
2019 work included a cryptographic and design review of the
architecture that Verae DataCubes rely on for data at rest.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

BIN
build/html/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf
View file

Binary file not shown.

120
build/html/search.html
View file

@ -7,13 +7,15 @@
<title>Search &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=27fed22d" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=5929fcd5"></script>
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<script src="_static/searchtools.js"></script>
<script src="_static/language_data.js"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="#" />
<script src="searchindex.js" defer="defer"></script>
@ -28,9 +30,68 @@
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
@ -67,58 +128,25 @@
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<h1 class="logo"><a href="index.html">Making yourself audit-ready with Verae DataCubes</a></h1>
<h3>Navigation</h3>
<ul>
<li class="toctree-l1"><a class="reference internal" href="verification.html">Peergos verification (what was actually audited)</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">Architecture (audit interview)</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">BAAs and DPAs when ciphertext has no host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">How to use this pack</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
&#169;2026, Verae.
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 9.1.0</a>
&amp; <a href="https://alabaster.readthedocs.io">Alabaster 1.0.0</a>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

2
build/html/searchindex.js
View file

File diff suppressed because one or more lines are too long

243
build/html/timestamped-receipts.html Normal file
View file

@ -0,0 +1,243 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>6. Global timestamped receipts &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="7. Peergos security evaluations in Europe" href="peergos-eu-evaluations.html" />
<link rel="prev" title="5. Encryption at rest — IPFS blocks and Peergos" href="data-at-rest.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">2. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">6. Global timestamped receipts</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#why-hashes-are-not-enough-by-themselves">6.1. Why hashes are not enough by themselves</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-a-verae-receipt-is">6.2. What a Verae receipt is</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-is-registered-and-what-is-not">6.3. What is registered, and what is not</a></li>
<li class="toctree-l2"><a class="reference internal" href="#first-registration-wins">6.4. First registration wins</a></li>
<li class="toctree-l2"><a class="reference internal" href="#sequence">6.5. Sequence</a></li>
<li class="toctree-l2"><a class="reference internal" href="#bundles">6.6. Bundles</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-a-receipt-does-not-prove">6.7. What a receipt does not prove</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="data-at-rest.html" title="previous chapter"><span class="section-number">5. </span>Encryption at rest — IPFS blocks and Peergos</a></li>
<li>Next: <a href="peergos-eu-evaluations.html" title="next chapter"><span class="section-number">7. </span>Peergos security evaluations in Europe</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="global-timestamped-receipts">
<h1><span class="section-number">6. </span>Global timestamped receipts<a class="headerlink" href="#global-timestamped-receipts" title="Link to this heading"></a></h1>
<section id="why-hashes-are-not-enough-by-themselves">
<h2><span class="section-number">6.1. </span>Why hashes are not enough by themselves<a class="headerlink" href="#why-hashes-are-not-enough-by-themselves" title="Link to this heading"></a></h2>
<p>A cryptographic hash of a document proves that two copies are
bit-for-bit the same, or that they are not. It does <strong>not</strong> prove
<strong>when</strong> the document first existed. Anyone can hash a file
tomorrow and claim they hashed it last year. Anyone can hash a
rewritten file and present the new hash as if it were the old
one.</p>
<p>Compliance programs that care about books and records, legal
holds, intellectual-property precedence, or “produce the original
prompt that the model saw” therefore need a second primitive:
<strong>a receipt, issued at the time of first registration, bound to
the hash, that a later examiner can check without trusting the
file’s custodian.</strong></p>
</section>
<section id="what-a-verae-receipt-is">
<h2><span class="section-number">6.2. </span>What a Verae receipt is<a class="headerlink" href="#what-a-verae-receipt-is" title="Link to this heading"></a></h2>
<p>A Verae <strong>global timestamped receipt</strong> is proof of:</p>
<ul class="simple">
<li><p>the <strong>hash</strong> of a block of digital information;</p></li>
<li><p>the <strong>time</strong> at which that hash was first registered;</p></li>
<li><p>the <strong>sequence</strong> of that registration relative to other
registrations.</p></li>
</ul>
<p>The block of digital information may be a message, an image, a
document, a log segment, an AI prompt, an AI completion, or any
other object that can be stored in digital media. The receipt is
about the <strong>bits</strong>, not about the medium they happened to sit on
when they were hashed. That is the Haber–Stornetta distinction
from 1991, applied here as a product: time-stamp the data, not
the disk.</p>
</section>
<section id="what-is-registered-and-what-is-not">
<h2><span class="section-number">6.3. </span>What is registered, and what is not<a class="headerlink" href="#what-is-registered-and-what-is-not" title="Link to this heading"></a></h2>
<p>Verae’s public description of sealing is that <strong>only a
fingerprint leaves the customer’s systems</strong>. The object itself
can remain in the customer’s DataCube. The central service
therefore does not need — and in the intended design does not
get — the plaintext in order to issue a receipt.</p>
<p>That split is the difference between a notary who reads the
document and a notary who stamps a sealed envelope whose
contents they never saw. The second notary can still later
confirm that <em>this envelope, with this unbroken seal, was
presented at this time</em>. They cannot tell you what was inside.
For HIPAA, GDPR, and ordinary commercial secrecy, that is the
desired shape.</p>
</section>
<section id="first-registration-wins">
<h2><span class="section-number">6.4. </span>First registration wins<a class="headerlink" href="#first-registration-wins" title="Link to this heading"></a></h2>
<p>A hash registry that allowed a later write to overwrite the
timestamp of an earlier write would be a forgery machine. The
rule is: <strong>the first SHA-256 (and companion hash) and its
receipt win</strong>. A second presentation of the same hash returns
the original receipt. A different hash is a different object —
which is exactly how a revision should be modeled. Revisions
get their own receipts. They do not steal the original’s time.</p>
</section>
<section id="sequence">
<h2><span class="section-number">6.5. </span>Sequence<a class="headerlink" href="#sequence" title="Link to this heading"></a></h2>
<p>Time on a wall clock is a social convention and a NTP
configuration. Sequence inside a registration service is a
data-structure fact: this hash was committed after that hash,
in this chain, in this Merkle tree, in this cross-chain bundle.
Verae receipts carry <strong>sequence</strong> so that an examiner can see
order even when two wall-clock stamps are close enough to argue
about.</p>
</section>
<section id="bundles">
<h2><span class="section-number">6.6. </span>Bundles<a class="headerlink" href="#bundles" title="Link to this heading"></a></h2>
<p>A receipt does not have to travel as a bare timestamp. It can
travel inside a <strong>digital bundle</strong> that also holds:</p>
<ul class="simple">
<li><p>private metadata the organization needs (matter id, hold flag,
classification);</p></li>
<li><p>attached files that should be produced together;</p></li>
<li><p>an internal chain that cross-verifies the organizational
server against Verae’s central server.</p></li>
</ul>
<p>The bundle is the unit an examiner is handed: “here is the
object (or a capability to it), here is the receipt, here is
the metadata we claim goes with it, here is the verification
path.”</p>
</section>
<section id="what-a-receipt-does-not-prove">
<h2><span class="section-number">6.7. </span>What a receipt does not prove<a class="headerlink" href="#what-a-receipt-does-not-prove" title="Link to this heading"></a></h2>
<p>A receipt does not prove that the person who registered the
hash was authorized to do so. That is an access-control and
identity problem.</p>
<p>A receipt does not prove that the object is true, only that
<strong>those bits existed at that time</strong>. A false document can be
timestamped as honestly as a true one.</p>
<p>A receipt does not prove that the organization retained the
object. Proof of existence is not proof of retention. Retention
is the write-once archive (Chapter 9) plus the organization’s
retention schedule.</p>
<p>A receipt is not a HIPAA, SOC 2, or ISO certificate. It is
evidence that a technical control ran.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

238
build/html/what-verae-provides.html Normal file
View file

@ -0,0 +1,238 @@
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>2. What Verae provides — and what it does not &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=050b9d5b" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="3. The Verae DataCube Server Solution" href="datacube-server.html" />
<link rel="prev" title="1. Executive summary" href="executive.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="executive.html">1. Executive summary</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">2. What Verae provides — and what it does not</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#the-boundary">2.1. The boundary</a></li>
<li class="toctree-l2"><a class="reference internal" href="#the-tools">2.2. The tools</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-the-organization-must-still-do">2.3. What the organization must still do</a></li>
<li class="toctree-l2"><a class="reference internal" href="#why-the-distinction-matters-in-an-exam">2.4. Why the distinction matters in an exam</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">3. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">4. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">5. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">6. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">7. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">8. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1"><a class="reference internal" href="iceberg-archive.html">9. Write-once Iceberg archive</a></li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">10. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">11. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">12. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">13. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">14. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">15. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">16. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">17. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="executive.html" title="previous chapter"><span class="section-number">1. </span>Executive summary</a></li>
<li>Next: <a href="datacube-server.html" title="next chapter"><span class="section-number">3. </span>The Verae DataCube Server Solution</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="what-verae-provides-and-what-it-does-not">
<h1><span class="section-number">2. </span>What Verae provides — and what it does not<a class="headerlink" href="#what-verae-provides-and-what-it-does-not" title="Link to this heading"></a></h1>
<section id="the-boundary">
<h2><span class="section-number">2.1. </span>The boundary<a class="headerlink" href="#the-boundary" title="Link to this heading"></a></h2>
<p>Verae sells and operates <strong>software infrastructure</strong> and a
<strong>timestamping service</strong>. Customers use that infrastructure to store
objects, to send messages, to register hashes, to verify receipts,
and to produce an audit trail of what their own systems did.</p>
<p>Verae does <strong>not</strong> sell a HIPAA certificate. HIPAA is a United
States <strong>statute</strong> (and implementing regulations), not a product
seal. A covered entity or business associate becomes “HIPAA
compliant” only in the ordinary-language sense that it has performed
a risk analysis, implemented the Security Rule’s required and
addressable controls as reasonable and appropriate, executed
Business Associate Agreements where required, trained its workforce,
and can respond to OCR. No software vendor can substitute for that
work.</p>
<p>Verae does <strong>not</strong> sell a SOC 2 report covering the customer’s
organization. SOC 2 is an <strong>attestation</strong> by a licensed CPA firm
against the AICPA Trust Services Criteria, for a named entity, over
a named period, with a named system description. The customer’s
auditor must still walk the customer’s controls.</p>
<p>Verae does <strong>not</strong> sell an ISO 27001 certificate covering the
customer’s organization. ISO 27001 is a <strong>management-system</strong>
standard. A registrar certifies that a named organization operates
an Information Security Management System (ISMS) over a named
scope. Installing a DataCube does not create an ISMS.</p>
</section>
<section id="the-tools">
<h2><span class="section-number">2.2. </span>The tools<a class="headerlink" href="#the-tools" title="Link to this heading"></a></h2>
<p>Within that boundary, the Verae DataCube Solution is built to make
the <strong>technical</strong> work of those programs less painful. Concretely,
it gives the organization the ability to:</p>
<p><strong>Store.</strong> Digital objects — messages, images, documents, logs,
model prompts, model outputs, attachments — can be written into an
encrypted DataCube. The cube is a customer-controlled container.
Verae is designed so that the <strong>contents stay in the customer’s
storage</strong>. What leaves the customer’s perimeter for sealing is a
<strong>fingerprint</strong> (a cryptographic hash), not the object.</p>
<p><strong>Communicate.</strong> Endpoints exchange messages with point-to-point
encryption. The body is unreadable to the router. Destination and
subject remain visible because a network that cannot see a
destination cannot route.</p>
<p><strong>Timestamp.</strong> The first time a hash is registered, Verae records
that registration against a time and a sequence. Later, anyone with
the receipt and the object (or the object hash) can check that the
object existed, in that exact bit pattern, no later than that time.</p>
<p><strong>Verify.</strong> Verification does not require trusting Verae’s word, the
customer’s archive administrator, or a hosting vendor. It requires
recomputing a hash, checking a receipt, and — for stored objects
— checking IPFS content identifiers. A regulator can be handed
proof rather than a vendor assurance letter.</p>
<p><strong>Audit.</strong> Admin history, inspect events, and message-handling
summaries are written so that an examiner can see <em>that</em> an action
occurred, <em>who</em> authorized it, and <em>which</em> object it touched,
without the log itself becoming a second copy of the sensitive
payload.</p>
</section>
<section id="what-the-organization-must-still-do">
<h2><span class="section-number">2.3. </span>What the organization must still do<a class="headerlink" href="#what-the-organization-must-still-do" title="Link to this heading"></a></h2>
<p>Those five verbs — store, communicate, timestamp, verify, audit
— are the technical portion. The rest of a certification or
attestation program is organizational:</p>
<p><strong>Policies.</strong> Acceptable use, encryption, key custody, access
control, retention, legal hold, incident response, vendor
management, change management, and (where HIPAA applies) a
sanctions policy and a named Privacy Officer and Security Officer.</p>
<p><strong>Procedures.</strong> How a new hire is provisioned, how a leaver is
deprovisioned, how a restore is tested, how a key is rotated, how a
legal hold is placed on a cube, how an inspector is authorized
under k-of-n, how a SOC evidence request is answered.</p>
<p><strong>Internal controls.</strong> Dual control on inspect. Separation of the
author of a change from the officers who approve it. Signed
configuration so an unsigned file is rejected. Log-before-reveal so
an inspect cannot happen in the dark. Hash-registry “first write
wins” so a later rewrite cannot pretend to be the original.</p>
<p><strong>Independent examination.</strong> A CPA firm (SOC 2), a registrar
(ISO 27001), OCR or a HIPAA assessor, FINRA or SEC examination
staff, or an internal audit function that is actually independent.
They will ask for evidence that the controls ran during the period,
not that a vendor has a nice architecture diagram.</p>
</section>
<section id="why-the-distinction-matters-in-an-exam">
<h2><span class="section-number">2.4. </span>Why the distinction matters in an exam<a class="headerlink" href="#why-the-distinction-matters-in-an-exam" title="Link to this heading"></a></h2>
<p>Examiners are trained to notice category errors. If a firm says
“we are SOC 2 because our storage vendor was pentested in Berlin,”
the next hour of the meeting is spent unwinding that claim. If a
firm says “we use a component that was independently evaluated in
the EU; here is the public report, labeled as a component
evaluation; here is <em>our</em> system description, <em>our</em> key-custody
procedure, <em>our</em> restore test from last quarter, and <em>our</em> Type II
report,” the meeting can proceed.</p>
<p>This chapter exists so that nobody using this briefing makes the
first speech. Verae provides tools, background, and software
infrastructure. The organization provides the program. The auditor
provides the opinion. Those three roles do not collapse into one
product SKU.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>

BIN
build/latex/VeraeFullLogo.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
build/latex/peergos-making-yourself-audit-ready-with-verae-datacubes.pdf
View file

Binary file not shown.

BIN
source/_static/VeraeFullLogo.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 27 KiB

47
source/_static/verae.css Normal file
View file

@ -0,0 +1,47 @@
/* Verae branded Sphinx HTML */
body {
font-family: "Source Serif 4", "Georgia", serif;
color: #111;
}
div.document {
padding-top: 0.5em;
}
div.sphinxsidebar h3, div.sphinxsidebar h4 {
color: #5B2C8B;
}
div.body h1, div.body h2, div.body h3 {
color: #5B2C8B;
}
div.related {
background: #1A0A24;
color: #fff;
}
div.related a {
color: #e8d7f5;
}
div.footer {
background: #1A0A24;
color: #e8d7f5;
padding: 1.1em 1.5em;
margin-top: 2em;
}
div.footer a {
color: #d7b8f0;
}
.verae-page-footer {
border-top: 2px solid #5B2C8B;
margin-top: 2.5em;
padding-top: 0.8em;
font-size: 0.9em;
color: #5B2C8B;
}
div.sphinxsidebarwrapper img.logo,
img.logo {
background: #1A0A24;
padding: 8px;
border-radius: 4px;
max-width: 100%;
}
.admonition.important, .admonition.warning, .admonition.note {
border-left: 4px solid #5B2C8B;
}

10
source/_templates/layout.html Normal file
View file

@ -0,0 +1,10 @@
{% extends "!layout.html" %}
{% block footer %}
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
{{ super() }}
{% endblock %}

139
source/architecture.rst
View file

@ -1,43 +1,126 @@
Architecture (audit interview)
==============================
Architecture for an audit interview
===================================
The picture
-----------
::
Endpoint (keys stay here / HSM)
│ HPKE content (NPE suite)
│ routing: dest + subject in the clear
▼
Untrusted NATS (cannot read bodies)
│
▼
Verae DataCube chain (append-only hashes)
│ written through Peergos client
▼
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
▼
IPFS (distributed, hash-verified ciphertext)
| 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
* **At rest:** Peergos cryptree + IPFS. Hosts with disk/backup see
**opaque hashed ciphertext**, not PHI, if they lack keys.
* **In transit (NATS):** HPKE-Base to directory public keys. Broker is
honest-but-curious: destinations yes, bodies no.
* **Integrity:** cube JSONL chain + dual hash + IPFS CID check on
restore (re-fetch blocks, re-verify hashes — not a plaintext tape).
Walkthrough, in the order an examiner usually asks
--------------------------------------------------
NATS remains an untrusted router. Production E2E is NPE/HPKE.
Passthrough means destination in the clear; the body is ciphertext.
**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: https://pfc.georgelambert.org/v1/npe/keys (public keys only).
Controls: https://docs.pfc.georgelambert.org/controls.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
See companion ``peergos-for-compliance.pdf`` (same folder) for
controls, custody, and variables chapters.
Companion PDFs, same folder as this file (relative PDF
hrefs, not Markdown):
.. raw:: latex
\href{peergos-for-compliance.pdf}{peergos-for-compliance.pdf}
\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}

140
source/baa-dpa.rst
View file

@ -1,76 +1,104 @@
BAAs and DPAs when ciphertext has no host keys
==============================================
BAAs, DPAs, and ciphertext without host keys
============================================
This is **guidance for an evidence pack**, not legal advice.
This chapter is **guidance for an evidence pack**. It is not
legal advice. Counsel has to sign the actual determination.
The operator statement
----------------------
The technical fact
------------------
Data at rest lives in the **encrypted Peergos cryptree**. Restore uses
**distributed, hash-verified, encrypted IPFS blocks**. Hosts and backup
media see **opaque blobs** (and random CHAMP labels), not filenames, not
PHI, not social graph — if keys never leave the client / customer HSM.
Data at rest lives in the **encrypted Peergos cryptree**.
Restore uses **distributed, hash-verified, encrypted IPFS
blocks**. Hosts and backup media see **opaque blobs** (and
random CHAMP labels), not filenames, not PHI, not the share
graph --- **if** private keys never leave the client or the
customer's HSM.
That is **true of the Peergos design** (see :doc:`verification`).
It **changes the BAA/DPA conversation**. It does **not** auto-delete the
need for contracts.
That fact is true of the Peergos design and is the design
Cure53 reviewed in Berlin. It **changes** the Business
Associate and GDPR-processor conversation. It does **not**
automatically delete the need for contracts.
HIPAA (US) — Business Associate
-------------------------------
HIPAA --- Business Associate
----------------------------
A Business Associate is a person who **creates, receives, maintains, or
transmits ePHI** for a covered entity.
A Business Associate is a person who **creates, receives,
maintains, or transmits ePHI** for a covered entity.
**Technical argument you can make (and should document):**
A technical argument the organization can document:
1. ePHI is encrypted **before** it leaves the endpoint (Peergos client /
DataCube writer).
2. The storage node, IPFS, disk, and backup hold **ciphertext + hashes**.
3. Private keys **do not** reside on the storage host (customer HSM /
client). Hash verification detects tampering.
4. Therefore the host **cannot maintain ePHI in intelligible form**.
1. ePHI is encrypted **before** it leaves the endpoint.
2. The storage node, IPFS, disk, Iceberg archive, and backup
hold **ciphertext plus hashes**.
3. Private keys **do not** reside on the storage host.
Hash verification detects substitution.
4. Therefore the host **cannot maintain ePHI in intelligible
form**.
HHS distinguishes **conduits** and parties that never have access to
ePHI. Many programs still **sign a BAA** when a vendor touches
infrastructure, because misconfiguration, support exports, or logs could
later expose plaintext. OCR looks at **your** risk analysis.
HHS has distinguished **conduits** and parties that never
have access to ePHI. Many programs still **sign a BAA**
whenever a vendor touches infrastructure, because
misconfiguration, a support export, or a log could later
expose plaintext. OCR will look at **the organization's**
risk analysis, not at Verae's architecture diagram.
**Practical pack:** risk analysis memo citing cryptree + IPFS hash checks
+ key custody; BAA **or** written determination that the vendor is
**not** a BA because they cannot decrypt; list every party with
disk/backup (ns1, IPFS cluster, offsite replica).
Practical pack:
GDPR (EU/UK) — processor vs technical measure
---------------------------------------------
* a risk-analysis memo citing cryptree, IPFS hash checks,
key custody, and the two public Peergos evaluations;
* a BAA **or** a written determination that a named vendor
is **not** a BA because they cannot decrypt;
* a list of every party with disk, VM, backup, IPFS, or
Iceberg credentials.
Encrypted data can still be **personal data** if it is reasonably
attributable (usernames, IPs, invoice identity). GDPR **Art. 32** lists
encryption as a security measure.
GDPR --- processor versus technical measure
-------------------------------------------
Peergos is designed so the **server is an adversary** for content and
most metadata. EU-based **independent pentests** (Cure53 DE, ROS NL)
evaluated that design. Processing location for **self-host** is *your*
ns1 / customer region, not peergos.net’s Germany hosting, unless you use
peergos.net.
Encrypted data can still be **personal data** if it is
reasonably attributable (usernames, IPs, invoice identity).
GDPR Article 32 lists encryption as a security measure, not
as an exemption from Article 28.
You may still need a **DPA (Art. 28)** with anyone who **processes**
personal data (usernames, logs, billing). Ciphertext-only storage
**narrows** the DPA’s technical annex.
Peergos is designed so the **server is an adversary** for
content and most metadata. EU-based independent pentests
evaluated that design. Processing location for **self-host**
is the customer's region, not peergos.net's Germany, unless
the customer uses peergos.net.
A DPA may still be required with anyone who **processes**
usernames, logs, or billing. Ciphertext-only storage
**narrows** the technical annex. It does not always
eliminate the DPA.
NATS operators
--------------
NATS is an **untrusted broker**. Content is HPKE; destinations and
subjects are in the clear. A NATS operator **cannot** read bodies without
endpoint private keys; **can** see routing metadata; **can** drop/delay
copy **ciphertext**. Treat like a transit provider: DPA/BAA depends on
whether routing metadata is personal data in your jurisdiction.
NATS is an untrusted broker. Content is HPKE. Destinations
and subjects are in the clear. A NATS operator **cannot**
read bodies without endpoint private keys. They **can** see
routing metadata. They **can** drop, delay, or copy
ciphertext. Treat them like a transit provider: whether a
DPA or BAA is needed depends on whether routing metadata is
personal data in the relevant jurisdiction.
What “making yourself audit-ready” means
----------------------------------------
Verae as timestamping service
-----------------------------
You are **not** buying Peergos’s Cure53/ROS reports as *your* SOC 2.
You are **reusing** those public evaluations as **vendor/component
assurance**, then adding your scope, RoPA, key-custody, inspect k-of-n,
admin-history, instance evidence, and contracts that match who can
actually see plaintext.
If Verae receives **only fingerprints**, Verae's role for
**content** is not "stores the records." Verae's role is
"registers hashes and issues receipts." That is a narrower
processing. Counsel still has to decide whether the
fingerprint, plus whatever account data exists (company
name, billing, operator emails), requires a DPA or a BAA.
Do not let a sales sentence skip that memo.
Component assurance versus the organization's report
----------------------------------------------------
Attaching Cure53 2019 and ROS 2024 is **vendor / component
assurance**. It is appropriate. It is **not** the
organization's SOC 2, ISO 27001, or HIPAA program. Those
still require the organization's scope, Record of
Processing, key-custody, inspect k-of-n, admin-history,
instance evidence, restore tests, and the contracts that
match who can actually see plaintext.

96
source/bio-george-lambert.rst Normal file
View file

@ -0,0 +1,96 @@
George Lambert
==============
Role
----
**George Lambert** is an Internet technical architect and a
New Hampshire public official. Public candidate listings
(BallotReady) identify him as **CTO / Chief Architect, Verae
LLC**, from **2019**. He is the architect of the DataCube
**server** side of the solution described in this briefing:
the assembly of encrypted storage, point-to-point messaging,
public-key directory, organizational timestamping link, and
write-once archive that an organization actually runs.
Internet technical architect, from 1994
---------------------------------------
Lambert's public account of his engineering work begins in
the **earliest days of the commercial Internet**, when
shipping an application that could speak TCP/IP was still a
specialist task.
In **1994--1995** he was moving through senior application
engineering and sales roles (Terralogics; Serif) at the
moment Borland's developer tools were being connected to
the public network. He then founded **NetMasters LLC**
(New Hampshire, formed 1996; he describes the product work
from 1995). At NetMasters he **personally designed and
built FastNet Tools** --- the **Internet integration
technology that shipped with Borland's Delphi and C++
Builder** products.
Those tools are the historically important fact. They
enabled a generation of Delphi and C++ Builder developers
to Internet-enable applications as a shipped part of
Borland's commercial toolchain, not as a research demo.
Lambert's own summary is that FastNet Tools "enabled
millions of developers to internet-enable their
applications in minutes." That is the beginning of the
through-line that ends, in this briefing, at a DataCube
server: **make the hard network problem a product that
other people can operate**.
He continued as **Vice President of Engineering** at
GoldenWare / **FlightLookup** (from 1995, for two decades
on the public listings), building airline-information
systems, and later as founder of PodKey Solutions
(2004--2010) and as an interim/contract CTO.
New Hampshire public office
---------------------------
Lambert is a **Republican** from **Litchfield, New
Hampshire**, born **4 September 1968** in Sanford, Maine
(Wikipedia; Vote Smart).
* **Litchfield Board of Selectmen**, from 2007 (Vote Smart
lists council of town selectmen, Town of Litchfield,
2007--present on the biography page then current).
* **New Hampshire House of Representatives**:
Hillsborough 27th district, December 2010 -- December
2012; Hillsborough 44th district, December 2012 --
December 2014.
* Subsequent campaigns for the New Hampshire Senate,
District 18 (2014, 2018, 2020, 2022 Republican primary
winner in several of those cycles).
Vote Smart records a diploma from **Pelham High School,
1986**; family (wife Rhonda, children); home city
Litchfield. He has also served on the **National Grange
Strategic Planning Task Force** (1999--2004).
His public technical site, https://georgelambert.org/,
describes three decades at the intersection of technology,
governance, and sound money, and repeats the FastNet /
Borland fact as the credential for knowing what scalable
architecture looks like.
Why this biography is in the briefing
-------------------------------------
The DataCube Server Solution is not only a timestamping
API. It is a **running system**: keys, brokers, cryptree,
replicas, admin-history, Iceberg export. Lambert is the
person whose public career is the **implementation** of
Internet integration from the Borland era through to this
server stack, and whose public service is New Hampshire
legislative and municipal office. The biography is here so
that a reader who asks "who architected the server side,
and on what history?" has a sourced answer.
It is not a substitute for a pentest, a Type II, or a
restore test. Code either runs or it does not; Lambert's
own stated ethic. This briefing is the description of what
the code is for, and of what it cannot certify by existing.

110
source/bio-james-garfinkel.rst Normal file
View file

@ -0,0 +1,110 @@
James H. Garfinkel
==================
Name and sources
----------------
This chapter summarizes **James H. Garfinkel** (the spelling on
the FINRA BrokerCheck individual report; also styled Garfinkle
in some informal references). Two public sources were used, as
requested:
* **FINRA BrokerCheck**, CRD number **5052743**,
https://files.brokercheck.finra.org/individual/individual_5052743.pdf
* **verae.com**, which names Stuart Haber as co-founder and
describes the DataCube product. As of this writing the public
marketing site does **not** carry a dedicated biography page
for Garfinkel. The product and company description below is
therefore taken from verae.com's company narrative plus
Garfinkel's own public statement of role, not from a
fabricated "about the CEO" page.
Role at Verae
-------------
Public professional listings (including a long-standing
Facebook work listing) identify Garfinkel as **CEO of Verae
LLC**, from **January 2020**, based in **New York, New York**.
In that listing he describes Verae's technology as
blockchain-authenticated containers called **DataCubes**,
"which conveniently and securely ensure integrity and enable
selective sharing of digital information and records of all
sorts," and he quotes Stuart Haber on the original motivation
for timestamping digital objects.
That description matches the public verae.com product: records
remain in customer-controlled storage; Verae seals a
fingerprint; the scientific core is Haber-style cryptographic
timestamping, aimed at compliance and examinations rather than
at operating a public chain.
FINRA BrokerCheck (CRD 5052743)
-------------------------------
The following facts are from the public BrokerCheck report.
They are **registration history**, not a Verae claim and not an
endorsement by FINRA.
* **Name on the report:** James H. Garfinkel
* **CRD:** 5052743
* **Current registration:** this broker is **not currently
registered**
* **Disclosed events:** the report summary states **no**
events disclosed about this broker
* **Examinations recorded on the summary:** 0
principal/supervisory exams; 3 general industry/product
exams; 3 state securities law exams
* **Investment adviser:** BrokerCheck points readers to the
SEC IAPD site for any IAR record
**Prior broker registrations** listed on the report:
* **LPL Financial LLC**, CRD 6413, New York, NY,
**January 2013 -- March 2024**, registered representative
* **Hornor, Townsend & Kent, Inc.**, CRD 4031, New York, NY,
**November 2011 -- December 2012**
* **Park Avenue Securities LLC**, CRD 46173, New York, NY,
**April 2008 -- October 2009**
Other employment lines that appear in the same public report
family include **Abbott Solutions Inc.** (insurance advisor,
from November 2009) and **MPWM Advisory Solutions LLC**
(investment adviser representative, January 2014 -- November
2020). Readers should treat the PDF as the living source;
registration status changes.
Education (public professional listings)
----------------------------------------
Public professional listings state:
* **Hamilton College**, B.A. Economics, class of **1980**
* **United Nations International School**, class of **1975**
Other ventures listed on professional-directory sites (not
FINRA, not verae.com) have included Beryl Consulting, Intaglio
Blockchain, and earlier broker-dealer roles. Those directory
sites are secondary; they are noted here only so that a reader
who searches the name is not surprised. They are not used as
primary evidence of Verae corporate structure.
Why this biography is in the briefing
-------------------------------------
A compliance briefing is not a pitch deck. Garfinkel's
biography is here because the user of this system is entitled
to know **who is on the commercial and regulatory-facing side
of Verae**, and because a broker-dealer or RIA CCO will
**look the name up on BrokerCheck anyway**. The honest
presentation is:
* CEO of Verae LLC (public listing, from 2020);
* a long New York securities-industry registration history
ending March 2024 at LPL, **not currently registered**;
* **no** BrokerCheck disclosed events on the current report;
* **not** given a biography block on verae.com at the time
this document was compiled --- Haber is the scientist the
site puts on the homepage.
Do not treat a CRD number as a product certification. Do not
treat a CEO biography as a control.

110
source/bio-stuart-haber.rst Normal file
View file

@ -0,0 +1,110 @@
Stuart Haber
============
Role at Verae
-------------
**Stuart Haber** is a **co-founder of Verae**. The company's
public site introduces him as one of the creators of
blockchain and as the inventor, in 1991, of cryptographic
timestamping --- "the science that lets you prove a record
hasn't been altered, and the foundation under every
blockchain since." The site quotes him:
"I co-founded Verae to make blockchain accessible to
enterprises without having to deal with the complexity of
blockchain."
--- Stuart Haber, Co-Founder of Verae; co-inventor of
blockchain timestamping, 1991
Verae's product claim is that this is the proof Haber has
been building toward: simple enough for a compliance team,
precise enough for an SEC exam, with the customer's records
remaining in the customer's storage and only a fingerprint
being sealed.
The scientific work
-------------------
Haber is a cryptographer. He worked at **Bellcore** (Bell
Communications Research) in Morristown, New Jersey, in the
late 1980s and 1990s, in the research culture descended from
Bell Labs. With physicist **W. Scott Stornetta** he posed a
problem that looks obvious only after it is solved: digital
documents live on media that can be altered without a mark;
how do you certify **when the bits existed**, without
trusting the disk, and without handing the document to the
timestamping service?
**1991.** Stuart Haber and W. Scott Stornetta, "How to
Time-Stamp a Digital Document," *Journal of Cryptology*,
volume 3, number 2, pages 99--111. This is the paper that
introduces computationally practical digital timestamping
so that a user cannot back-date or forward-date a document
even with the collusion of a timestamping service, while
keeping the document itself private. Bitcoin's white paper
cites it as reference **[3]**.
**1993.** Dave Bayer, Stuart Haber, and W. Scott Stornetta,
"Improving the Efficiency and Reliability of Digital
Time-Stamping," in *Sequences II: Methods in Communication,
Security and Computer Science*, pages 329--334. Merkle
trees, efficient certificates, publication of a compact
root. Bitcoin's white paper cites it as reference **[4]**.
**1997.** Stuart Haber and W. Scott Stornetta, "Secure names
for bit-strings," *Proceedings of the 4th ACM Conference on
Computer and Communications Security*, pages 28--35. Bitcoin's
white paper cites it as reference **[5]**.
Those three papers are **three of the eight** citations in
Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash
System" (2008). Haber has remarked that this is a .375
batting average, and that Bitcoin is an application built on
top of the early blockchain rather than the invention of the
data structure itself. That is a historical statement, not a
claim that Verae is Bitcoin.
Surety, 1994: first commercial blockchain
-----------------------------------------
Haber and Stornetta took the research into production as
**Surety**. Surety hashed customer documents, linked those
hashes in a chain of certificates, and published a weekly
summary hash in the classified section of the Sunday *New
York Times*. That analog publication is widely described as
the oldest surviving public blockchain: a commitment that
does not depend on Surety's servers remaining honest or
online, because the *Times* is independently archived. The
design idea --- **commit a compact fingerprint to a widely
witnessed record, without revealing the documents** --- is
the same idea Verae productizes for enterprise compliance.
Other cryptographic publications
--------------------------------
Haber's research record is broader than timestamping. It
includes work on minimum-knowledge interactive proofs,
symmetric public-key encryption, and secure multi-party
protocols (including "Cryptographic Computation: Secure
Fault-Tolerant Protocols and the Public-Key Model"). A
reader who wants the academic trail should start with the
three Bitcoin-cited papers and the 1991 *Journal of
Cryptology* article, then the ACM CCS 1997 paper.
Why this biography is in the briefing
-------------------------------------
Timestamping in this document is not a metaphor. It is a
specific scientific object --- hash, time, sequence, privacy
of the document from the notary --- that Haber defined in
print in 1991, commercialized in 1994, and is now building
into Verae so that a CCO can produce a receipt instead of a
vendor letter. The biography is here as **provenance of the
receipt**, not as a substitute for the organization's
controls.
The same honesty that applies to Peergos applies here:
Haber co-invented the timestamping chain; he did not issue
the customer's SOC 2.

124
source/checklist.rst
View file

@ -1,62 +1,96 @@
Audit-ready checklist
=====================
Use this as a working list. Check items only when **evidence exists**
(screenshot, log export, signed policy, ticket). This list is not a
certificate.
Use this as a working list. Check an item only when
**evidence exists** (screenshot, log export, signed policy,
ticket, receipt). This list is not a certificate. Software
having been installed does not tick these boxes.
A. Scope and data map
---------------------
A. Scope and honesty
--------------------
* Named legal entity and systems in scope (console, Drive, NATS, IPFS, ns1)
* Data-flow diagram: endpoint → HPKE/NATS → cryptree/IPFS
* What is PHI / personal data vs ciphertext vs routing metadata
* Peergos verification chapter attached (:doc:`verification`)
* Named legal entity and systems in scope (console, Drive,
message fabric, IPFS, timestamping link, Iceberg archive)
* Written sentence in the system description: **software is
not our HIPAA / SOC 2 / ISO 27001 certificate**
* Data-flow diagram: endpoint → HPKE → DataCube →
Peergos/IPFS → receipt → Iceberg
* PHI / personal data vs ciphertext vs routing metadata,
named
* Peergos evaluation chapter attached, labeled **component
security evaluation**
B. Keys and encryption
----------------------
B. Data in transit
------------------
* Production algorithm is HPKE (or documented successor),
not a lab construction
* Destinations and subjects documented as **visible by
design**
* Error paths carry codes and lookup ids, not bodies
* Public-key directory lists public keys only; private keys
mode 0600 or HSM
* Broker operator named; metadata vs content in the annex
C. Data at rest
---------------
* Customer holds Peergos / Drive keys; not on storage host
* NPE/HPKE endpoint keys in directory; private 0600; no xor content
* Signed Ed25519 config; unsigned rejected; admin-history prev+new+diff
* HSM or documented lab-to-HSM path
* Peergos hash verification on write and on read, evidenced
* Restore test: recover a cube from content-addressed
ciphertext **without** a plaintext tape
* Dual-hash cube chain; first-hash-wins registry
C. Access
---------
D. Timestamping
---------------
* Console ``PFC_REQUIRE_AUTH=1``, TOTP; Drive login separate
* Inspect k-of-n; author is not an officer; log-before-reveal
* First-registration rule documented and tested (second
submit returns original receipt)
* Organizational node **linked** to central Verae, **or**
direct sync, named in the diagram
* Sample bundle: receipt + private metadata + attachment
pointer, redacted for the evidence pack
* Verae receives fingerprints, not objects --- stated in
the data map
E. Write-once archive
---------------------
* Iceberg (or equivalent) export job exists and has a dated
last-run
* Object-lock / dual-control / separate account --- evidence
that no **single** party can delete a committed snapshot
* Retention schedule written by records/counsel, not by
engineering folklore
* Legal-hold procedure extends retention; ticket example
F. Access and change
--------------------
* Console requires authentication (TOTP or equivalent);
Drive login is a separate plane
* Inspect is k-of-n; author is not an officer; log-before-reveal
* Joiner / mover / leaver for console users
* Google SSO does **not** unwrap cubes
* Signed configuration; unsigned rejected; admin-history
prev + new + diff
* HSM or a dated plan to move lab keys to HSM
D. Integrity and backup
-----------------------
* Cube chain append-only JSONL; dual hash
* Hash registry: first SHA-256 and receipt win
* Peergos/IPFS: hash-verified encrypted blocks (restore = re-fetch CIDs)
* Restore test: recover a cube from content-addressed ciphertext without
plaintext backup tapes
E. Logging
----------
* Inspect audit events
* SM summaries: codes + lookup_id only (no bodies)
* Admin-history cube for config
F. Contracts (counsel)
G. Contracts (counsel)
----------------------
* Written BA / not-a-BA determination for disk, VM, backup, IPFS
* DPA Art. 28 where usernames/logs/IPs are processed
* NATS operator: metadata vs content in the annex
* Peergos component assurance: attach Cure53 2019 + ROS 2024 PDFs
(public; not your org’s ISO/SOC report)
* Written BA / not-a-BA determination for disk, VM, backup,
IPFS, Iceberg
* DPA Article 28 where usernames, logs, or IPs are processed
* NATS operator: metadata vs content
* Verae timestamping: fingerprint-only processing described
* Peergos PDFs attached and labeled "not our Type II / ISO"
G. Independent audit of *you*
-----------------------------
H. Independent examination of *this* organization
-------------------------------------------------
* SOC 2 Type I/II engagement **or** ISO 27001 registrar **or** HIPAA
risk analysis + policies (pick the program you actually need)
* SOC 2 Type I/II engagement, **or** ISO 27001 registrar,
**or** HIPAA risk analysis plus policies --- **the program
actually chosen**, not all three as wallpaper
* Evidence window (Type II / surveillance) if applicable
* Named internal owner who will sit in the meeting and not
claim the software is the certificate

129
source/conf.py
View file

@ -1,24 +1,141 @@
# Sphinx configuration — Making yourself audit-ready with Verae DataCubes
# Logo on every page: https://www.verae.com/Assets/VeraeFullLogo.png
project = "Making yourself audit-ready with Verae DataCubes"
copyright = "2026, Verae"
author = "Verae / George Lambert"
copyright = "2026, Verae Inc"
author = "Verae Inc"
release = "2026.09"
version = "2.0"
extensions = []
templates_path = ["_templates"]
exclude_patterns = []
exclude_patterns = ["verification.rst"]
html_theme = "alabaster"
html_static_path = ["_static"]
html_title = project
html_logo = "_static/VeraeFullLogo.png"
html_favicon = "_static/VeraeFullLogo.png"
html_css_files = ["verae.css"]
html_copy_source = False
html_show_sourcelink = False
html_theme_options = {
"logo": "VeraeFullLogo.png",
"logo_name": False,
"description": "Tools for storage, communications, timestamping, verification, and audit — not a certificate.",
"fixed_sidebar": True,
"page_width": "980px",
"sidebar_width": "240px",
"show_powered_by": False,
}
latex_engine = "pdflatex"
latex_documents = [
(
"index",
"peergos-making-yourself-audit-ready-with-verae-datacubes.tex",
"Making yourself audit-ready with Verae DataCubes",
"Verae",
r"Making yourself audit-ready with Verae DataCubes",
r"Verae Inc",
"manual",
),
]
latex_additional_files = ["_static/VeraeFullLogo.png"]
latex_show_pagerefs = False
latex_show_urls = "footnote"
latex_toplevel_sectioning = "chapter"
_PREAMBLE = r"""
\usepackage{graphicx}
\usepackage{xcolor}
\usepackage{fancyhdr}
\usepackage{needspace}
\DeclareUnicodeCharacter{2014}{---}
\DeclareUnicodeCharacter{2013}{--}
\DeclareUnicodeCharacter{201C}{``}
\DeclareUnicodeCharacter{201D}{''}
\DeclareUnicodeCharacter{2018}{`}
\DeclareUnicodeCharacter{2019}{'}
\DeclareUnicodeCharacter{25BC}{v}
\definecolor{veraepurple}{HTML}{5B2C8B}
\definecolor{veraedark}{HTML}{1A0A24}
\definecolor{veraeink}{HTML}{111111}
% Extra headroom so the logo never collides with body text.
\setlength{\headheight}{44pt}
\addtolength{\topmargin}{-14pt}
\newcommand{\VeraeLogo}{\includegraphics[height=0.92cm]{VeraeFullLogo.png}}
\newcommand{\VeraeFooter}{%
\footnotesize\color{veraepurple}%
Verae Inc \textbullet\ https://www.verae.com \textbullet\
Book a call at verae.com \textbullet\ app.verae.com}
\fancypagestyle{normal}{
\fancyhf{}
\fancyhead[L]{\colorbox{veraedark}{\VeraeLogo}}
\fancyhead[R]{\small\color{veraepurple}Audit-ready with Verae DataCubes}
\fancyfoot[L]{\VeraeFooter}
\fancyfoot[R]{\footnotesize\color{veraepurple}\thepage}
\renewcommand{\headrulewidth}{0.6pt}
\renewcommand{\footrulewidth}{0.4pt}
\renewcommand{\headrule}{\hbox to\headwidth{\color{veraepurple}\leaders\hrule height \headrulewidth\hfill}}
\renewcommand{\footrule}{\hbox to\headwidth{\color{veraepurple}\leaders\hrule height \footrulewidth\hfill}}
}
\fancypagestyle{plain}{
\fancyhf{}
\fancyhead[L]{\colorbox{veraedark}{\VeraeLogo}}
\fancyfoot[L]{\VeraeFooter}
\fancyfoot[R]{\footnotesize\color{veraepurple}\thepage}
\renewcommand{\headrulewidth}{0.6pt}
\renewcommand{\footrulewidth}{0.4pt}
}
\pagestyle{normal}
% Each Sphinx chapter already starts a new page in the manual class.
% Keep first-page headers branded as well.
\makeatletter
\let\sphinx@originalchapter\chapter
\renewcommand{\chapter}{\clearpage\thispagestyle{plain}\sphinx@originalchapter}
\makeatother
"""
latex_elements = {
"papersize": "letterpaper",
"pointsize": "11pt",
"preamble": r"\usepackage{hyperref}",
"preamble": _PREAMBLE,
"fncychap": r"\usepackage[Sonny]{fncychap}",
"printindex": "",
"maketitle": r"""
\begin{titlepage}
\thispagestyle{empty}
\vspace*{1.4cm}
\begin{flushleft}
\colorbox{veraedark}{\includegraphics[width=7.2cm]{VeraeFullLogo.png}}
\end{flushleft}
\vspace{1.6cm}
{\color{veraepurple}\rule{\textwidth}{1.6pt}}
\vspace{0.7cm}
{\Huge\bfseries Making yourself audit-ready\\[0.25em] with Verae DataCubes\par}
\vspace{0.55cm}
{\Large Software is not a HIPAA, SOC 2, or ISO 27001 certificate.\par}
\vspace{0.35cm}
{\large A technical briefing on what the Verae DataCube Server Solution
provides for data in transit and data at rest --- and what every
organization must still do itself.\par}
\vspace{0.9cm}
{\color{veraepurple}\rule{\textwidth}{0.6pt}}
\vspace{0.7cm}
{\large Verae Inc\\[0.2em]
https://www.verae.com\\[0.2em]
Book a call at verae.com\\[0.2em]
app.verae.com\par}
\vfill
{\small September 2026 \textbullet\ Document version 2.0\par}
\end{titlepage}
\clearpage
""",
"tableofcontents": r"""
\tableofcontents
\clearpage
""",
}

45
source/contact.rst Normal file
View file

@ -0,0 +1,45 @@
Verae Inc --- contact
=====================
This page is the contact block that also appears in the
footer of every page of the PDF edition and at the bottom
of every HTML chapter.
**Verae Inc**
Website: https://www.verae.com
Product / activity console: https://app.verae.com
Book a conversation: use the "Book a call" path on
https://www.verae.com (the public site states that the
company will be in touch within one business day).
API (fingerprint seal, as described on the public site):
https://api.verae.com/v1/seal
This briefing (HTML and PDF):
* https://docs.pfc.georgelambert.org/audit-ready/
* https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes
A street address and telephone number are **not invented
here**. If a procurement file requires them, take them from
a current Verae engagement letter, W-9, or the form on
verae.com, not from this paragraph.
Closing reminder
----------------
Software alone does not make an organization HIPAA
certified, SOC 2 attested, or ISO 27001 certified.
The Verae DataCube Solution gives you tools to store,
communicate, timestamp, verify, and audit. Your
organization still has to write the policies, run the
procedures, operate the internal controls, and sit with an
independent auditor. Verae provides the tools, the
background, and the software infrastructure for the
**technical portion** of that work.
Verae Inc --- https://www.verae.com

136
source/data-at-rest.rst Normal file
View file

@ -0,0 +1,136 @@
Encryption at rest --- IPFS blocks and Peergos
==============================================
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.
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).
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.
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.
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.
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.
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.

111
source/data-in-transit.rst Normal file
View file

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

110
source/datacube-server.rst Normal file
View file

@ -0,0 +1,110 @@
The Verae DataCube Server Solution
==================================
Purpose
-------
A Verae DataCube Server Solution is the on-premises or
customer-hosted assembly that gives an organization a place to put
sensitive digital objects, a way to move them, a way to prove when
they first existed, and a way to show an examiner that the bits
have not been silently rewritten.
It is a **server solution** in the sense that an organization runs
(or has run for it) a set of cooperating services: encrypted
storage, a message fabric, a public-key directory, a timestamping
link to Verae's central service, and an archival export path. It is
not a single binary, and it is not a cloud folder with a padlock
icon.
The DataCube as a container
---------------------------
A **DataCube** is a customer-controlled container for digital
objects and for the metadata that makes those objects examinable.
Typical contents include:
* the object bytes (a message body, a document, an image, a log
extract, an AI prompt and completion, or any other digital
media);
* **private metadata** that the organization needs but does not
necessarily share (internal identifiers, matter numbers, legal-hold
flags);
* **attached files** that travel with the object;
* an **internal chain** of hashes so that the cube itself has a
history --- each new write names the previous write.
Verae's public product description is consistent with this split:
records stay in **storage the customer controls**; Verae seals a
**fingerprint**. The server solution is the machinery that makes
that split operational rather than rhetorical.
Two information states, one operational picture
-----------------------------------------------
Classical security training divides information into **data in
transit** and **data at rest**. The DataCube Server Solution is
built around that division.
**In transit**, the problem is an untrusted network. Messages must
be readable at the destination and nowhere else along the path, yet
the path must still be able to deliver them. Chapter 4 treats that
problem in full: point-to-point encryption, visible routing,
honest-but-curious brokers.
**At rest**, the problem is an untrusted disk, an untrusted backup
operator, and an untrusted replica. Bytes must be stored so that a
host who does not hold keys sees opaque blocks, and so that a
restore can prove it brought back the same blocks that were
written. Chapter 5 treats that problem in full: IPFS
content-addressed ciphertext, Peergos hash verification,
tamper-evident restore.
A third problem sits beside those two: **time**. Storage and transit
prove confidentiality and integrity of *what* was stored or sent.
They do not, by themselves, prove *when* it first existed, or that
a later rewrite is not being offered as the original. Timestamped
receipts (Chapter 6) and the cross-blockchain timestamping
architecture (Chapter 8) address that.
What "server" means in practice
-------------------------------
In a typical deployment the organization runs, or links:
* a **Peergos** instance (or equivalent cryptree client) that
writes encrypted, content-addressed blocks;
* an **IPFS** layer that stores and replicates those blocks by
hash;
* a **message fabric** (NATS in the reference deployment) that
carries HPKE-sealed bodies with destinations in the clear;
* a **public-key directory** so every endpoint can find every
other endpoint's encryption key without a private-key leak;
* an **organizational timestamping node** that either syncs with
Verae's central timestamping server or is linked to it;
* an **admin-history** cube that records configuration changes as
previous state, new state, and diff;
* an **Iceberg write-once export** that takes cubes out of any
single party's delete path (Chapter 9).
Each of those pieces can be drawn on a whiteboard in an audit
interview. Each of them also has a failure mode that the
organization's procedures must name: lost keys, a mis-issued
directory entry, a broker that drops messages, a replica that
serves a wrong block (detected by hash), a timestamping link that
is down, an archive job that did not run.
What the server solution is not
-------------------------------
It is not a substitute for workforce training. It is not a
substitute for a Business Associate Agreement analysis. It is not a
substitute for access reviews. It is not, by itself, "the HIPAA
control set" or "the SOC 2 system." It is the **technical
substrate** on which those controls can be implemented with less
faith in honest administrators and more reliance on hashes,
receipts, and keys the customer holds.
The following four chapters unpack the substrate: transit, rest,
receipts, and the European evaluations of the Peergos storage
layer.

159
source/executive.rst Normal file
View file

@ -0,0 +1,159 @@
Executive summary
=================
Software alone does not make an organization HIPAA certified, SOC 2
attested, or ISO 27001 certified.
That sentence is the point of this document. It is also the sentence
that is most often skipped when a vendor, an integrator, or an internal
champion shows encryption, hashing, or a pentest PDF and treats the
conversation as finished. It is not finished. Encryption is a control.
A pentest is an evaluation of a component. A certificate, an attestation,
or a covered-entity determination is a statement about **an organization**
--- its legal entity, its people, its written policies, its operating
procedures, its internal controls, the evidence those controls produce,
and the independent party that examined that evidence.
The Verae DataCube Solution gives an organization tools to **store**,
**communicate**, **timestamp**, **verify**, and **audit** for compliance.
Those tools are real, they are specific, and they are described in the
chapters that follow. They are still only tools. To obtain HIPAA-aligned
status as a covered entity or business associate with a defensible
program, a SOC 2 Type I or Type II report, or an ISO 27001 certificate,
the organization must still:
* write and live by **policies** (what the organization says it will do);
* operate **procedures** (how staff actually do it, every day);
* design and test **internal controls** (the checks that catch failure);
* retain **evidence** (logs, tickets, screenshots, signed approvals,
restore tests, training records);
* engage an **independent auditor**, CPA firm, or ISO registrar, as the
chosen program requires.
Verae cannot issue those certificates. Verae cannot sit in the
organization's chair during an OCR investigation, a SOC 2 fieldwork
week, or an ISO Stage 2 audit. What Verae can do --- and what this
briefing is written to make precise --- is provide the **tools**, the
**background**, and the **software infrastructure** that make it easier
to implement the **technical portion** of those programs.
What a Verae DataCube Server Solution does
------------------------------------------
A Verae DataCube Server Solution provides **secure communications and
storage** for two classical information-security states:
* **Data in transit** --- messages, objects, and control traffic while
they move from one endpoint to another.
* **Data at rest** --- messages, objects, metadata, and receipts while
they sit on disk, in a replica, or in an archive.
Those two states are not the same problem, and they are not solved by
the same mechanism. This document treats them separately on purpose.
Data in transit
---------------
Verae uses best-in-class encryption for messaging **from point to
point**. The content of a message is sealed so that only the intended
endpoints can open it. Routing, however, **must remain visible**: a
message that cannot be addressed cannot be delivered. Subjects,
destination handles, and size or timing metadata are therefore
visible to the transport. The transport is treated as
**honest-but-curious**. It can drop, delay, or copy ciphertext. It
cannot read the body if it does not hold endpoint private keys.
Data at rest
------------
Encryption at rest is performed through **IPFS content-addressed
blocks**. Each block is named by its hash. Peergos verifies those
hashes on read and on write. A restore is therefore
**tamper-evident**: if a block was altered, its hash no longer
matches, and the client refuses it. This is not a plaintext tape
backup. It is a re-fetch of hashed ciphertext plus a verification
that the bits are the bits that were stored.
Global timestamped receipts
---------------------------
Independently of who stores the bytes, Verae issues **global
timestamped receipts** based on **document hashes**. A receipt is
proof of the **time and sequence of the first registration** of a
block of digital information --- a message, an image, a document, or
any other digital object that can be stored in digital media. The
receipt does not require Verae to see the object. It requires a
fingerprint of the object, registered at a time that can later be
shown to third parties.
Peergos, evaluated in Europe
----------------------------
The offline storage and replication system used with Peergos was
**audited twice in Europe**, and the protocol was designed under
work that was independently reviewed:
* **2019 --- Cure53, Berlin, Germany.** Pentest, source-code audit,
and **crypto/design review** (May--June 2019). No fundamental
architectural or cryptographic problems. Issues found were fixed.
Cure53 stated that the platform **passed this evaluation**.
* **2024 --- Radically Open Security B.V., Amsterdam, Netherlands.**
Crystal-box pentest plus code audit of the Peergos web UI
(September--November 2024). **Zero** findings rated extreme, high,
or elevated; **two** moderate; **six** low. Peergos states all
were fixed. No data exposure and no integrity compromise (the
issues were mostly UI crashes).
Both firms are **EU-based**. Both full reports are **public**. That
is a **security evaluation of the Peergos protocol and
implementation**. It is **not** a HIPAA certificate, a SOC 2 report,
or an ISO 27001 certificate for Peergos, for Verae, or for any
customer.
Verae global timestamping
-------------------------
The Verae Global Timestamping and receipt solution is a
**cross-blockchain** design. It certifies the time and date stamp of
a digital object and stores that information in a **digital bundle**
that can carry private metadata, attached files, and an internal
blockchain. That organizational chain is **cross-verified** either:
* from an organizational server **linked to the central Verae
server**, or
* by **directly syncing** with Verae's central timestamping server.
The result is **proof of existence** of a digital object at a
specific time and date. When the organization wants the object
itself stored --- not only its fingerprint --- the object can live
inside an **encrypted Peergos DataCube**.
Write-once Iceberg archive
--------------------------
Those DataCubes are archived into a **write-once external Iceberg
file-storage solution** for compliance reasons. The archive is
designed to sit **outside the deletion control of any single
party**. That is a retention and legal-hold property, not a
marketing slogan: once a cube is committed to the write-once tier,
neither the customer operator, nor Verae, nor a hosting vendor
should be able to quietly erase it.
What this briefing is, and is not
---------------------------------
This briefing describes the **technical portion** of a compliance
program that an organization can build with Verae DataCubes. It
indexes each of the points above as its own chapter, in enough
detail that a CISO, a CCO, outside counsel, or an auditor can
distinguish:
* what the software **does**;
* what the independent **Peergos evaluations** actually said;
* what **Verae timestamping** actually proves;
* what the organization **must still write, operate, and have
examined**.
It does not claim that installing this software finishes HIPAA,
SOC 2, or ISO 27001. Anyone who says otherwise is not describing
this product honestly.

138
source/global-timestamping.rst Normal file
View file

@ -0,0 +1,138 @@
Verae global timestamping --- a cross-blockchain receipt
========================================================
Lineage
-------
The scientific problem Verae is productizing is not new. In
1991, Stuart Haber and W. Scott Stornetta published "How to
Time-Stamp a Digital Document" in the *Journal of
Cryptology*. They asked how to certify when a digital
document was created or last changed **without trusting the
medium** and **without giving the timestamping service the
document**. In 1993, with Dave Bayer, they showed how Merkle
trees make that efficient. In 1997 they published "Secure
names for bit-strings." Satoshi Nakamoto's 2008 Bitcoin
white paper cites those three papers as references [3], [4],
and [5] --- three of the eight citations in that document.
Haber co-founded **Surety** in 1994, widely described as the
first commercial blockchain: a hash-linked chain of document
certificates, with a weekly summary published in the Sunday
*New York Times* so that the day's commitments sat in a
public, widely archived analog record.
Haber is a **co-founder of Verae**. Verae's public site
states the aim directly: make that proof simple enough for a
compliance team and precise enough for an SEC exam, without
forcing the enterprise to operate a public blockchain. The
quote on verae.com is: "I co-founded Verae to make
blockchain accessible to enterprises without having to deal
with the complexity of blockchain."
What "cross-blockchain" means here
----------------------------------
A single private log, held only by the vendor, is a vendor
assurance letter with extra steps. A single public chain may
be operationally and commercially the wrong place to put an
enterprise's registration traffic. Verae's design is
**cross-blockchain** in the following sense:
* an **organizational chain** runs at the customer, inside
or beside the DataCube, recording hashes, metadata, and
sequence;
* a **central Verae chain** records fingerprints and issues
receipts;
* the two are **cross-verified**, so that neither side can
rewrite history without the other side's record disagreeing;
* when policy calls for it, commitments can be **anchored
further** --- additional public or consortium chains --- so
that proof of existence does not collapse if one operator
disappears.
The customer does not have to become a blockchain operator
to use this. That is the product claim. The examiner does
not have to trust a single vendor's database to verify a
receipt. That is the scientific claim, inherited from
Haber--Stornetta.
Two deployment patterns
-----------------------
**Linked organizational server.** The organization runs a
timestamping node next to its DataCube server. That node is
linked to the central Verae timestamping server. Local
registrations are committed locally (low latency, private
metadata stays home) and cross-verified centrally (receipt
the rest of the world can check).
**Direct sync.** An organization that does not want to run
the organizational node can sync registrations directly with
Verae's central timestamping server. Proof of existence at a
specific date and time still issues. Private metadata and
attached files, if any, remain the organization's problem to
store --- typically in the encrypted Peergos DataCube.
Both patterns produce the same external artifact: a receipt
bound to a hash, a time, and a sequence. They differ in
where the organizational metadata lives and in how much
infrastructure the customer operates.
The digital bundle
------------------
The unit of production is a **digital bundle**:
* the **receipt** (hash, time, sequence, verification path);
* **private metadata** (classification, matter, hold,
internal identifiers) that need not be on a public chain;
* **attached files** that should be produced together;
* a pointer or capability to the object in the encrypted
DataCube, when the organization chose to store the object
and not only its fingerprint.
An examiner can be given the bundle, or a redacted bundle,
without being given a login to the production console and
without Verae ever having seen the object bytes.
Proof of existence versus proof of custody
------------------------------------------
Timestamping answers: **did these bits exist by this time?**
The DataCube answers: **does the organization still have
them, encrypted, hash-checkable?**
The Iceberg write-once tier answers: **can anyone quietly
delete them anyway?**
A complete production to a regulator often needs all three.
Timestamping alone is not an archive. An archive without a
receipt is a pile of files with a clock on the filesystem
that the administrator can set.
What this does, and does not, satisfy
-------------------------------------
For SEC Rule 17a-4, FINRA books-and-records, and similar
regimes that demand records in a non-rewriteable,
non-erasable form **with the ability to produce the
original**, timestamped receipts plus write-once archive are
the **technical portion** of the answer: you can show when
the record was sealed, that the bits match, and that the
archive copy is not under ordinary delete.
They do not satisfy:
* the requirement to **capture the channel in the first
place** (if the team used an unsealed tool, there is
nothing to timestamp);
* the requirement to have **written procedures** for
production, legal hold, and supervision;
* the requirement that a **named principal** own the
recordkeeping obligation.
Software seals what it is shown. The organization must still
show it the right things, on time, under a policy someone
will sign.

67
source/howto.rst
View file

@ -1,30 +1,65 @@
How to use this pack
====================
How to use this briefing
========================
1. Read :doc:`verification` so you do not over-claim Peergos audits.
2. Fill :doc:`checklist` with **your** instance evidence (ns1, keys, users).
3. Give :doc:`baa-dpa` to counsel with the data-flow from :doc:`architecture`.
4. Point auditors at live technical surfaces (do not give them private keys).
1. Read the **executive summary** aloud in the first five
minutes of any vendor, board, or auditor meeting that
touches this system. If anyone says "so we are certified,"
stop and reread Chapter 1.
2. Read **What Verae provides** so the five verbs (store,
communicate, timestamp, verify, audit) are not confused
with an ISMS, a Type II, or a HIPAA program.
3. Read the **transit**, **rest**, **receipts**, **Peergos
evaluations**, **timestamping**, and **Iceberg** chapters
in that order. They are the technical portion, in the
order an examiner usually probes: "can the wire read it,
can the disk read it, can you prove when, who looked at
the crypto, can you produce it later."
4. Fill the **checklist** with **this instance's** evidence.
Empty checkboxes are not a moral failing; they are the
work remaining.
5. Give **BAAs and DPAs** to counsel with the architecture
diagram. Do not let engineering declare a vendor "not a
BA."
6. Attach the two **public** Peergos reports as **vendor
security evaluations**, with a cover slip that says they
are not the organization's SOC 2, ISO 27001, or HIPAA
certification.
7. Point auditors at **live technical surfaces** (health,
public-key listing, Drive). Do not give them private
keys. Do not give them a story that the pentest PDF is
the Type II.
8. Keep the **biographies** at the back of the PDF for
provenance --- who built the timestamping science, who
is building the product, who architected the internet
integration and the DataCube server side --- without
substituting biography for controls.
.. only:: html
Reference instance (not a certificate):
* https://pfc.georgelambert.org/health
* https://pfc.georgelambert.org/v1/npe/keys (public keys only)
* https://docs.pfc.georgelambert.org/controls.html
* https://docs.pfc.georgelambert.org/custody.html
* Peergos Drive (cryptree) on your host
* https://git.georgelambert.org/marchon/peergos-for-compliance
* https://git.georgelambert.org/marchon/system-git-sync
* https://git.georgelambert.org/marchon/secure-messaging
5. Attach the two **public** Peergos pentest PDFs from the Peergos
``audits/`` tree as **vendor security evaluations**, labeled “not our
SOC 2 / ISO certificate”.
* https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes
* https://www.verae.com
.. only:: latex
Companion system PDF (same folder):
Companion system PDFs in the same folder:
.. raw:: latex
\href{peergos-for-compliance.pdf}{peergos-for-compliance.pdf}
\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}

131
source/iceberg-archive.rst Normal file
View file

@ -0,0 +1,131 @@
Write-once Iceberg archive
==========================
The deletion problem
--------------------
Encryption at rest stops a disk operator from **reading**.
Hash verification stops a replica from **substituting**.
Timestamped receipts stop a custodian from **back-dating**.
None of those, by themselves, stop a person with legitimate
administrative power from **deleting**.
Deletion is the failure mode that turns a recordkeeping
program into a fine. Off-channel messaging cases at
broker-dealers were, at bottom, failures to **produce**. A
record that existed and was then removed, "cleaned up," or
rotated out of the only copy is, to an examiner, a record
that cannot be produced.
Compliance therefore needs a tier where **ordinary
administrative power does not include delete**.
What "write-once Iceberg" means in this solution
------------------------------------------------
DataCubes --- the encrypted, hash-chained containers --- are
**archived** into an **external, write-once file-storage
solution** built on the **Iceberg** table/file model (a
layout of immutable data files plus a metadata log that
records new snapshots rather than rewriting old ones).
Properties the solution is specified to have:
* **Write once.** A committed archive object is not updated
in place. A correction is a **new** object with a **new**
receipt. The original remains.
* **External.** The archive is not the same disk as the
live Peergos instance. Compromising the live server should
not confer delete on the archive.
* **Outside any single party's deletion control.** The
customer operator, Verae, and the hosting vendor are each
insufficient, by themselves, to erase a committed archive
file. Practical implementations of that requirement use
some combination of object-lock / WORM flags, dual-control
hold, independent cloud or tape accounts, and contractual
prohibition on early delete --- plus the technical fact
that Iceberg snapshots are new files, not overwrites.
* **For compliance reasons.** This tier exists because
retention schedules, legal holds, and examiner production
require it --- not because it is a convenient backup.
How cubes move into the archive
-------------------------------
A live DataCube is an operational object: it receives new
writes, it is replicated as encrypted IPFS blocks, it is
readable by holders of the right capabilities. On a schedule
and on events (legal hold, period close, exam notice), the
server solution **exports** a cube snapshot:
1. freeze a CID set and cube-chain head;
2. confirm Peergos hash verification of every block in the
set;
3. register that snapshot's hash with Verae timestamping
(first registration of *this* snapshot);
4. write the encrypted snapshot into Iceberg as a new
immutable data file (or set of files) under a snapshot
id that never reuses a previous id;
5. record, in admin-history, that the archive job ran, who
authorized it, and which receipt was issued.
A restore from the archive is the same tamper-evident path
as a restore from IPFS: re-fetch, re-verify hashes, decrypt
only with customer keys.
What "outside the control of any party for deletion" is
and is not
-------------------------------------------------------
It is **not** a claim that physics forbids destruction of
every copy in a fire, a court order, or a coordinated
malicious act by every holder of every credential. No
storage system honestly claims that.
It **is** a claim that the **ordinary** delete path --- the
button, the ``rm``, the lifecycle rule, the "empty trash,"
the support ticket to "please remove that customer folder"
--- is not available to any one party acting alone against a
committed archive object. Dual control, object lock, and
separation of the archive account from the live-server
account are the organizational complements to the file
format.
The organization's retention policy still has to name:
* how long a class of record stays in write-once;
* who can place a legal hold that **extends** that period;
* who, under **what dual control**, may allow a record to
age out **after** the policy period, if aging out is
legally permitted at all.
Software can refuse a delete API. It cannot write the
retention schedule. Counsel and the records officer do that.
Relation to classical WORM
--------------------------
Broker-dealer Rule 17a-4 and similar texts speak of
non-rewriteable, non-erasable media, originally meaning
optical WORM, later allowing disk with object-lock semantics
and a designated third party. Verae's public comparison is
that conventional WORM is **immutable by policy** (a vendor
setting), whereas Verae **seals** a record with
cryptographic proof. The Iceberg write-once tier is where
those two ideas meet: the file is not overwritten **and**
the snapshot hash is receipted. An examiner can check the
receipt even if they do not trust the vendor's "WORM was
on" screenshot.
What this does, and does not, satisfy
-------------------------------------
This is the **technical portion** of retention and
production: committed cubes are not under a single delete
key, they are hash-checkable, and they carry a time of
archival.
It does not satisfy a retention **policy** that was never
written, a legal hold that was never placed, or a production
request that the organization answers from a laptop copy
instead of from the archive. Those are procedures.

77
source/index.rst
View file

@ -1,61 +1,40 @@
Making yourself audit-ready with Verae DataCubes
================================================
How to **prepare an organization** for HIPAA-aligned, SOC 2, or ISO 27001
work using Verae DataCubes on **Peergos** (encrypted cryptree + hashed
IPFS) and HPKE on an **untrusted NATS** broker.
.. only:: html
**This document is not a HIPAA, SOC 2, or ISO certificate.**
Peergos’s public pentests are **not** your Type II or ISO registrar
certificate. They are **component security evaluations** you can attach.
.. image:: _static/VeraeFullLogo.png
:width: 280px
:alt: Verae
:class: logo
This volume is a technical briefing. It is **not** a certificate.
The table of contents below is the document map. In the PDF edition,
each chapter starts on a new page and the contents list includes
**section titles with page numbers**. In HTML, each chapter is its own
page with the Verae wordmark in the sidebar and Verae Inc contact
information in the footer.
.. toctree::
:maxdepth: 2
:numbered:
:caption: Contents
verification
executive
what-verae-provides
datacube-server
data-in-transit
data-at-rest
timestamped-receipts
peergos-eu-evaluations
global-timestamping
iceberg-archive
architecture
baa-dpa
checklist
howto
What we verified about Peergos (EU)
-----------------------------------
See the full sourced table in :doc:`verification`.
* Encrypted client-side filesystem (cryptree); keys not on the storage
server — **yes** (Peergos book + Cure53 design review).
* IPFS blocks content-addressed; Peergos verifies hashes — **yes**.
* Independent **EU** security audits, reports published — **yes, two:**
Cure53 Berlin (2019); Radically Open Security Amsterdam (2024).
* “Peergos is HIPAA/SOC 2/ISO certified” — **no.** Those audits are
pentest/code/design reviews, not management-system certificates.
Peergos **was designed as a trust-minimized encrypted filesystem**,
**evaluated in Europe** by two specialist firms, with **public reports**.
That supports the **at-rest / backup** story. It does **not** finish
*your* audit.
.. only:: html
Live technical surfaces:
* https://pfc.georgelambert.org/health
* https://pfc.georgelambert.org/v1/npe/keys
* https://docs.pfc.georgelambert.org/controls.html
* https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes
Companion system docs (HTML): https://docs.pfc.georgelambert.org/
.. only:: latex
Companion PDFs in the **same directory** as this file (relative PDF
links, 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}
bio-james-garfinkel
bio-stuart-haber
bio-george-lambert
contact

140
source/peergos-eu-evaluations.rst Normal file
View file

@ -0,0 +1,140 @@
Peergos security evaluations in Europe
======================================
What was evaluated
------------------
The offline storage and replication system used with Verae
DataCubes is **Peergos**: an encrypted, peer-to-peer filesystem
whose blocks live on IPFS. Peergos was designed as a
trust-minimized store --- the server is treated as an adversary
for content and for most metadata --- and that design was
submitted to independent European security firms **twice**.
Those engagements are **security evaluations of the Peergos
protocol and implementation**. They are pentests, source-code
audits, and (in 2019) a cryptographic and design review. They
are **not**:
* a HIPAA certification of Peergos, Verae, or any customer;
* a SOC 2 Type I or Type II report;
* an ISO 27001 certificate of an ISMS;
* a government "certified filesystem" designation.
Both firms are **EU-based**. Both full reports are **public**.
That combination --- independent, European, public, repeat ---
is unusual and is worth attaching to a vendor-assurance file,
**labeled correctly**.
2019 --- Cure53, Berlin, Germany
--------------------------------
* **Firm:** Cure53
* **Location:** Berlin, Germany
* **When:** May--June 2019
* **Scope:** pentest, source-code audit, and
**crypto / design review**
* **Outcome:** no fundamental architectural or cryptographic
problems were identified. Issues that were identified were
fixed. Cure53 stated that the platform **passed this
evaluation**.
A crypto/design review is a stronger statement than a
black-box pentest of a web form. It is an expert reading of
whether the cryptree, the chunk encryption, the identity
model, and the threat model hang together. "Passed" in
Cure53's language is not an ISO mark. It is a specialist
firm saying: we looked at the cryptography and the
architecture, we did not find a fatal flaw, and the issues we
did find were addressed.
Primary sources (public):
* https://peergos.org/posts/security-audit
* https://cure53.de/pentest-report_peergos.pdf
* https://github.com/Peergos/Peergos/tree/master/audits
2024 --- Radically Open Security B.V., Amsterdam
------------------------------------------------
* **Firm:** Radically Open Security B.V.
* **Location:** Amsterdam, Netherlands
* **When:** September--November 2024
* **Scope:** crystal-box pentest plus code audit of the
Peergos **web UI**
* **Funding context:** the 2024 audit post states support
from **NLnet** (Netherlands) and refers to European Union
Horizon 2020 **NGI-POINTER**, grant **871528**.
* **Outcome:** **0** findings rated extreme, high, or
elevated; **2** moderate; **6** low. Peergos states that
all were fixed. There was **no data exposure** and **no
integrity compromise**. The issues were described as
mostly UI crashes.
A crystal-box (clear-box) engagement means the testers had
source. A web-UI scope is narrower than the 2019
crypto/design review: it is evidence about the interface
that humans actually click, which is where many "encrypted
backend" products fail in practice. Zero high-severity
findings, no data exposure, no integrity compromise, and a
public report are the facts. They are good facts. They are
still not a customer's Type II.
Primary sources (public):
* https://peergos.org/posts/security-audit-2024
* https://github.com/Peergos/Peergos/tree/master/audits
How to present these reports to an auditor
------------------------------------------
Correct:
"Our at-rest layer is Peergos. Peergos was independently
evaluated in Berlin in 2019 (crypto and design) and in
Amsterdam in 2024 (web UI, crystal box). Both reports are
public. We attach them as **component security
evaluations**. They are not our SOC 2, not our ISO 27001,
and not a HIPAA certification. Our own controls, our own
period of examination, and our own auditor are separate."
Incorrect:
"We are HIPAA certified because Peergos was audited in
Europe."
"Peergos is ISO 27001."
"The EU certified this filesystem."
EU funding is not a certification. NGI-POINTER grant 871528
is a research-and-innovation funding fact. It is worth
listing under "provenance." It is not a registrar's mark.
Hosted Peergos versus self-hosted DataCubes
-------------------------------------------
Peergos's hosted privacy notice has stated that peergos.net
uses servers in **Germany**. A **self-hosted** organizational
DataCube is a **different processing location**. The
customer's Record of Processing, BAA pack, and ISO scope
must name *that* location --- the customer's ns1, region, or
chosen host --- not peergos.net's Germany, unless the
customer actually uses peergos.net.
The evaluations still apply to the **protocol and
implementation**. Location of processing is an
organizational fact on top.
What "designed under funding from Cure53 / ROS" is not
------------------------------------------------------
The 2019 Cure53 work and the 2024 ROS work are **evaluations**
of a system that was designed by the Peergos authors. They
are not a claim that Cure53 or Radically Open Security
designed Peergos. The accurate statement is: the storage and
replication system was **independently audited twice in
Europe**, by Cure53 in Berlin (2019) and by Radically Open
Security in Amsterdam (2024), with public reports, and the
2019 work included a cryptographic and design review of the
architecture that Verae DataCubes rely on for data at rest.

112
source/timestamped-receipts.rst Normal file
View file

@ -0,0 +1,112 @@
Global timestamped receipts
===========================
Why hashes are not enough by themselves
---------------------------------------
A cryptographic hash of a document proves that two copies are
bit-for-bit the same, or that they are not. It does **not** prove
**when** the document first existed. Anyone can hash a file
tomorrow and claim they hashed it last year. Anyone can hash a
rewritten file and present the new hash as if it were the old
one.
Compliance programs that care about books and records, legal
holds, intellectual-property precedence, or "produce the original
prompt that the model saw" therefore need a second primitive:
**a receipt, issued at the time of first registration, bound to
the hash, that a later examiner can check without trusting the
file's custodian.**
What a Verae receipt is
-----------------------
A Verae **global timestamped receipt** is proof of:
* the **hash** of a block of digital information;
* the **time** at which that hash was first registered;
* the **sequence** of that registration relative to other
registrations.
The block of digital information may be a message, an image, a
document, a log segment, an AI prompt, an AI completion, or any
other object that can be stored in digital media. The receipt is
about the **bits**, not about the medium they happened to sit on
when they were hashed. That is the Haber--Stornetta distinction
from 1991, applied here as a product: time-stamp the data, not
the disk.
What is registered, and what is not
-----------------------------------
Verae's public description of sealing is that **only a
fingerprint leaves the customer's systems**. The object itself
can remain in the customer's DataCube. The central service
therefore does not need --- and in the intended design does not
get --- the plaintext in order to issue a receipt.
That split is the difference between a notary who reads the
document and a notary who stamps a sealed envelope whose
contents they never saw. The second notary can still later
confirm that *this envelope, with this unbroken seal, was
presented at this time*. They cannot tell you what was inside.
For HIPAA, GDPR, and ordinary commercial secrecy, that is the
desired shape.
First registration wins
-----------------------
A hash registry that allowed a later write to overwrite the
timestamp of an earlier write would be a forgery machine. The
rule is: **the first SHA-256 (and companion hash) and its
receipt win**. A second presentation of the same hash returns
the original receipt. A different hash is a different object ---
which is exactly how a revision should be modeled. Revisions
get their own receipts. They do not steal the original's time.
Sequence
--------
Time on a wall clock is a social convention and a NTP
configuration. Sequence inside a registration service is a
data-structure fact: this hash was committed after that hash,
in this chain, in this Merkle tree, in this cross-chain bundle.
Verae receipts carry **sequence** so that an examiner can see
order even when two wall-clock stamps are close enough to argue
about.
Bundles
-------
A receipt does not have to travel as a bare timestamp. It can
travel inside a **digital bundle** that also holds:
* private metadata the organization needs (matter id, hold flag,
classification);
* attached files that should be produced together;
* an internal chain that cross-verifies the organizational
server against Verae's central server.
The bundle is the unit an examiner is handed: "here is the
object (or a capability to it), here is the receipt, here is
the metadata we claim goes with it, here is the verification
path."
What a receipt does not prove
-----------------------------
A receipt does not prove that the person who registered the
hash was authorized to do so. That is an access-control and
identity problem.
A receipt does not prove that the object is true, only that
**those bits existed at that time**. A false document can be
timestamped as honestly as a true one.
A receipt does not prove that the organization retained the
object. Proof of existence is not proof of retention. Retention
is the write-once archive (Chapter 9) plus the organization's
retention schedule.
A receipt is not a HIPAA, SOC 2, or ISO certificate. It is
evidence that a technical control ran.

115
source/what-verae-provides.rst Normal file
View file

@ -0,0 +1,115 @@
What Verae provides --- and what it does not
============================================
The boundary
------------
Verae sells and operates **software infrastructure** and a
**timestamping service**. Customers use that infrastructure to store
objects, to send messages, to register hashes, to verify receipts,
and to produce an audit trail of what their own systems did.
Verae does **not** sell a HIPAA certificate. HIPAA is a United
States **statute** (and implementing regulations), not a product
seal. A covered entity or business associate becomes "HIPAA
compliant" only in the ordinary-language sense that it has performed
a risk analysis, implemented the Security Rule's required and
addressable controls as reasonable and appropriate, executed
Business Associate Agreements where required, trained its workforce,
and can respond to OCR. No software vendor can substitute for that
work.
Verae does **not** sell a SOC 2 report covering the customer's
organization. SOC 2 is an **attestation** by a licensed CPA firm
against the AICPA Trust Services Criteria, for a named entity, over
a named period, with a named system description. The customer's
auditor must still walk the customer's controls.
Verae does **not** sell an ISO 27001 certificate covering the
customer's organization. ISO 27001 is a **management-system**
standard. A registrar certifies that a named organization operates
an Information Security Management System (ISMS) over a named
scope. Installing a DataCube does not create an ISMS.
The tools
---------
Within that boundary, the Verae DataCube Solution is built to make
the **technical** work of those programs less painful. Concretely,
it gives the organization the ability to:
**Store.** Digital objects --- messages, images, documents, logs,
model prompts, model outputs, attachments --- can be written into an
encrypted DataCube. The cube is a customer-controlled container.
Verae is designed so that the **contents stay in the customer's
storage**. What leaves the customer's perimeter for sealing is a
**fingerprint** (a cryptographic hash), not the object.
**Communicate.** Endpoints exchange messages with point-to-point
encryption. The body is unreadable to the router. Destination and
subject remain visible because a network that cannot see a
destination cannot route.
**Timestamp.** The first time a hash is registered, Verae records
that registration against a time and a sequence. Later, anyone with
the receipt and the object (or the object hash) can check that the
object existed, in that exact bit pattern, no later than that time.
**Verify.** Verification does not require trusting Verae's word, the
customer's archive administrator, or a hosting vendor. It requires
recomputing a hash, checking a receipt, and --- for stored objects
--- checking IPFS content identifiers. A regulator can be handed
proof rather than a vendor assurance letter.
**Audit.** Admin history, inspect events, and message-handling
summaries are written so that an examiner can see *that* an action
occurred, *who* authorized it, and *which* object it touched,
without the log itself becoming a second copy of the sensitive
payload.
What the organization must still do
-----------------------------------
Those five verbs --- store, communicate, timestamp, verify, audit
--- are the technical portion. The rest of a certification or
attestation program is organizational:
**Policies.** Acceptable use, encryption, key custody, access
control, retention, legal hold, incident response, vendor
management, change management, and (where HIPAA applies) a
sanctions policy and a named Privacy Officer and Security Officer.
**Procedures.** How a new hire is provisioned, how a leaver is
deprovisioned, how a restore is tested, how a key is rotated, how a
legal hold is placed on a cube, how an inspector is authorized
under k-of-n, how a SOC evidence request is answered.
**Internal controls.** Dual control on inspect. Separation of the
author of a change from the officers who approve it. Signed
configuration so an unsigned file is rejected. Log-before-reveal so
an inspect cannot happen in the dark. Hash-registry "first write
wins" so a later rewrite cannot pretend to be the original.
**Independent examination.** A CPA firm (SOC 2), a registrar
(ISO 27001), OCR or a HIPAA assessor, FINRA or SEC examination
staff, or an internal audit function that is actually independent.
They will ask for evidence that the controls ran during the period,
not that a vendor has a nice architecture diagram.
Why the distinction matters in an exam
--------------------------------------
Examiners are trained to notice category errors. If a firm says
"we are SOC 2 because our storage vendor was pentested in Berlin,"
the next hour of the meeting is spent unwinding that claim. If a
firm says "we use a component that was independently evaluated in
the EU; here is the public report, labeled as a component
evaluation; here is *our* system description, *our* key-custody
procedure, *our* restore test from last quarter, and *our* Type II
report," the meeting can proceed.
This chapter exists so that nobody using this briefing makes the
first speech. Verae provides tools, background, and software
infrastructure. The organization provides the program. The auditor
provides the opinion. Those three roles do not collapse into one
product SKU.