George Lambert
4fcbb9ac95
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.
112 lines
4.2 KiB
ReStructuredText
112 lines
4.2 KiB
ReStructuredText
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.
|