Some checks are pending
ci / markdown (push) Waiting to run
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.
243 lines
No EOL
12 KiB
HTML
243 lines
No EOL
12 KiB
HTML
<!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 — 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>
|
||
· <a href="https://www.verae.com">https://www.verae.com</a>
|
||
· Book a call at <a href="https://www.verae.com">verae.com</a>
|
||
· <a href="https://app.verae.com">app.verae.com</a>
|
||
</div>
|
||
|
||
<div class="footer">
|
||
©2026, Verae Inc.
|
||
|
||
</div>
|
||
|
||
|
||
|
||
|
||
|
||
</body>
|
||
</html> |