peergos-making-yourself-aud.../build/html/timestamped-receipts.html
George Lambert 4fcbb9ac95
Some checks are pending
ci / markdown (push) Waiting to run
Rewrite audit-ready briefing: software is not a certificate.
Open with an executive summary that HIPAA, SOC 2, and ISO 27001
are organizational programs. Verae DataCubes supply store,
communicate, timestamp, verify, and audit tools for the technical
portion only. Chapters cover transit (HPKE, visible routing), rest
(IPFS/Peergos hash-verified restore), receipts, EU Peergos
evaluations (Cure53 2019, ROS 2024), cross-blockchain timestamping,
and write-once Iceberg archive. PDF is branded with the Verae logo
top-left and Verae Inc contact in the footer; last chapters are
sourced bios for Garfinkel (FINRA CRD 5052743), Haber, and Lambert.
2026-09-16 00:55:21 -04:00

243 lines
No EOL
12 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!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
files 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 HaberStornetta 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>Veraes public description of sealing is that <strong>only a
fingerprint leaves the customers systems</strong>. The object itself
can remain in the customers 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 originals 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 Veraes 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 organizations
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>