How does cronStamp work?

cronStamp uses blockchain technology to provide a decentralized, secure, and immutable method for document timestamping. If you are unfamilar with the concepts of blockchain and document hashing, you can read about them here.

The process involves two steps:

Document timestamping ensures that the document's existence at a specific time is recorded on the blockchain in an immutable and tamper-proof way. During timestamping a certificate of authenticity is issued for the document which is required for later verification and has to be stored alongside the document.

Document verification allows users to verify the integrity of their documents, ensuring they have not been tampered with since the initial timestamping. Verification requires both the document hash and the certificate that was issued during timestamping.

The cronStamp server is only required for document timestamping. Document verification takes place entirely within the client and is a simple algorithm which can be performed even manually as explained here. Thus, your certificates will always be valid and are completely independent of cronStamp.

Step 1: Document Timestamping

Document timestamping works as follows:

Diagram of document timestamping with cronStamp

File hashing: A unique hash of the document is generated on the client side, e.g. in your web browser.

Hash submission: The document hash and only the hash (never the document) is sent to the cronStamp server. On the server the hash is concatenated with a salt (random character string) and hashed again. All subsequent steps use this salted hash instead of the original document hash.

Aggregation: The server aggregates the salted hash with other salted document hashes, submitted in a fixed time interval, in a Merkle tree. Aggregation reduces the cost of timestamping as a single blockchain transaction can be expensive.

Blockchain entry: The root hash of the Merkle tree is included in a transaction on one or multiple blockchain(s).

Precert issuance: The client fetches a preliminary certificate (precert) from the server. The precert contains for each blockchain the transaction ID, block timestamp, salted document hash, and a splice of the Merkle tree, a detail needed for verification as explained here.

Certificate creation: The client extends the downloaded precert with the salt, the original document hash, and meta information, e.g. the blockchains and backend version used. This ceritifate contains everything needed to verify the document.

Below you can find an examplary precert and the corresponding certificate.

json
{
	"blockchains": {
		"xrp": {
			"transaction": "A5C5547C67DC4BAAB1793F8DC83616B5AA988AB261F425AA459AF2B2B7812C00",
			"block_timestamp": 786501601,
			"merkle_tree_splice": [
				"7fDcxqo67ghGTV1HyJpscanO0EEerhijtXYA0USlxnk=",
				"",
				"IOxNJ/fhVpu5w+oOYXg4CIyfvBiKZ3ozPs2XnplyTBo="
			]
		},
		"solana": {
			"transaction": "2j1tNuEP5LxcW9tKsi2Scr3fvjLkpJ1xcszzC8RdGwoJioppt7JzWSyJniTCGhSZorFNnR3y2nKZTs18nCfYADgr",
			"block_timestamp": 1733187600,
			"merkle_tree_splice": [
				"7fDcxqo67ghGTV1HyJpscanO0EEerhijtXYA0USlxnk=",
				"",
				"IOxNJ/fhVpu5w+oOYXg4CIyfvBiKZ3ozPs2XnplyTBo=",
				"56dme4H5OOa4yLMuyvK7KPMrXKFj/u/BHCc9RYmWHlk=",
				"Cz1F06Khmq1QmDxJ77PPNnmDSuWapPu/9HFyIY0AdZU=",
				"pGIWsoAJm+bVKvGVEUGaGK5Cb92+nnLYEgi5QUdHhVA=",
				"Nr/8EqtWd+XJhseUg2+6vNc4ST9j/FqjVdDewABwkTk=",
				"fVxcnHkJAS4vtJuWYg5HtDr3XKeK65rEo60IKpsr3Rg="
			]
		}
	},
	"info": {
		"hash_algorithm": "SHA-256",
		"salted_hash": "o0X9rt38cyVpTmfKmegkkXkjr1Z48T8ihsvxDFa1wCg="
	}
}

Step 2: Document Verification

Document verification works as follows:

Diagram of document timestamping with cronStamp

File and certificate provisioning: The user provides document and certificate for verification to the client.

Hash regeneration: The salted document hash of the provided document is computed considering the salt and other meta information from the certificate.

Deaggregation: To revert the aggregation that took place during timestamping, the salted document hash is subsequently hashed with all hashes in the Merkle tree splice. This yields the Merkle tree root hash.

Blockchain lookup: For each blockchain in the certificate, the client looks up the transaction based on the transaction ID and gets the Merkle tree root hash stored in the transaction.

Hash comparison: For each blockchain, the Merkle tree root hash fetched from the blockchain is compared with the regenerated Merkle tree root hash.

Verification result: If the root hashes match for all blockchains, the document is verified as unchanged since the initial timestamping. If a mismatch occurs for at least one blockchain, the document has been altered.

For a more detailed description of the verification algorithm that you can use for manual document verification see this page.