# Principles and Limitations of VerixID Hash Verification

VerixID functions as a mathematical witness recording the existence of a digital file at a specific point in time. This document outlines the system mechanics, operational best practices, and technical limitations of our architecture.

---

## 01 · WHAT A HASH PROVES

A cryptographic hash is a deterministic mathematical representation of a file's bitstream. VerixID utilizes the **SHA-256** algorithm to generate a unique digital fingerprint—a 64-character hexadecimal string that can only originate from an exact, bit-for-bit identical file.

| What It Proves | Description |
| :--- | :--- |
| **Data Integrity** | Any modification—even a single altered bit—dramatically changes the output hash (avalanche effect). No tampering goes undetected. |
| **Proof of Existence** | The ledger entry mathematically proves that a file producing this specific hash existed at the exact timestamp of registration. |
| **Deterministic Consistency** | The exact same file will consistently compute to the identical SHA-256 hash across any device or environment, indefinitely. |

> **Key Understanding**
> A hash does not describe or expose the file's contents; it represents its underlying data structure. VerixID does not inspect, evaluate, or validate the substantive content of your files.

---

## 02 · CRYPTOGRAPHIC PRIMITIVES

Four technical properties of SHA-256 make hashes suitable as tamper-evident proof in legal, compliance, and auditing contexts:

* **Deterministic:** Identical inputs always yield the exact same hash output—without variation across time, operating systems, or devices.
* **Avalanche Effect:** Modifying a single bit causes a complete cascade, changing approximately 50% of the output hash bits.
* **Collision Resistance:** It is computationally infeasible for two distinct files to yield the same SHA-256 hash. The probability is roughly 1 in 2²⁵⁶—mathematically negligible.
* **One-Way Function:** Hashes cannot be reverse-engineered to reconstruct the original source file. Knowing a hash reveals zero information about file contents.

These properties make cryptographic hashing the global standard for data auditing, software security, file distribution verification, and digital forensics.

---

## 03 · CLIENT-SIDE HASHING

Within the VerixID architecture, hash generation occurs locally on the user's device via the browser's native **Web Crypto API**—never on our infrastructure.

| Aspect | Technical Reality |
| :--- | :--- |
| **Zero File Transmission** | Only the hash string (`64 hex chars`) and metadata timestamp are transmitted to VerixID servers. |
| **Privacy by Design** | VerixID has no access to your document contents—by architectural design, not merely policy. No mechanism exists to upload files to our servers. |
| **Zero-Custody Architecture** | The system never holds or stores user files. The risk of sensitive content leakage is zero by design. |

---

## 04 · INDUSTRY APPLICABILITY & USE CASES

Hashing is not proprietary to VerixID. It represents a foundational cybersecurity primitive used globally across technology industries:

| Industry / Use Case | Hashing Application |
| :--- | :--- |
| **Software Distribution** | Operating system ISOs, firmware, and software releases publish checksums (`SHA-256`, `MD5`) so users can verify file integrity prior to execution. |
| **Digital Forensics** | Hash matching ensures digital evidence remains uncorrupted throughout chain-of-custody handling—admissible in court jurisdictions worldwide. |
| **Data Archiving & Backups** | Hashes detect subtle data degradation (bit rot) in long-term storage without needing byte-by-byte comparisons. |
| **Distributed Ledgers** | Hashes preserve chain integrity—each block references the cryptographic hash of the preceding block to render past data immutable. |

> **Industry Standards**
> VerixID relies on established information security standards. SHA-256 is recommended by the National Institute of Standards and Technology (NIST) and utilized globally across enterprise software.

---

## 05 · DATA ALTERATION RISKS IN DISTRIBUTION

Cryptographic hashes are hyper-sensitive to bit alterations. Many messaging and communication networks automatically compress or modify files during transmission, altering the hash.

> **Systems That Automatically Alter Files**
> WhatsApp compresses images/videos · Instagram resizes media · Facebook strips EXIF metadata · Email gateways re-encode attachments · Cloud platforms alter metadata upon upload.

These modifications alter the underlying bitstream—causing verification to fail even if the visual content appears identical to the human eye.

**Recommended practices to preserve file integrity during distribution:**

* Send files as **Documents** rather than media attachments (e.g., in messaging apps, select "Document" instead of "Gallery/Photo").
* Package files within uncompressed **ZIP or 7z archives** to prevent channel re-encoding.
* Share direct **cloud storage download links** (e.g., Google Drive, Dropbox) with restricted edit permissions.
* Always re-verify the calculated hash of a received file before relying on it as proof.

---

## 06 · METADATA AND FILE VERSIONING

Modifying file metadata—even without changing visible content—generates a completely different hash. This is a direct consequence of deterministic hashing: the hash captures the file's entire bit structure, including embedded metadata.

**Examples of metadata alterations affecting hashes:**

* Updated modification timestamps generated when opening and re-saving a file.
* Application or software version tags embedded into PDF/Office document headers.
* Embedded thumbnails generated automatically inside image or presentation files.
* EXIF metadata in photos: GPS coordinates, camera model, orientation flags.
* Tracked changes, hidden comments, or revision history stored within Word/PDF files.

> **Best Practice: Establish a Master Copy Before Registration**
> Register files in their final, finalized state—prior to distribution or further edits. If a document is revised after registration, the updated version generates a distinct hash and should be registered as a new record with a new timestamp.

---

## 07 · THE ROLE OF COA IN VERIXID

A **Certificate of Authenticity (COA)** represents a ledger record as a formal, standardized document—enabling third parties to validate records without needing to parse ledger data manually.

| COA Component | Function |
| :--- | :--- |
| **File Hash** | The unique cryptographic mathematical identity of the registered document. |
| **Registration Timestamp** | The exact, immutable time of initial proof-of-existence logged on the ledger. |
| **Record Identifier** | Unique Record ID serving as a public verification reference. |
| **Server Signature** | Cryptographic Ed25519 signature proving issuance by VerixID system keys. |
| **Verification Reference** | Public URL for independent verification by third parties. |

> **Issuance Requirements**
> A COA can only be generated for an **active** record. Once issued, a COA remains a valid artifact for the duration of the record's ledger TTL (1 year).

---

## 08 · SYSTEM LIMITATIONS

Understanding system limitations is essential for proper operational use. The following constraints stem directly from our architectural design:

* **VerixID does not store user files.** If a user loses their original local file, verification cannot be performed—there are no server backups to recover files from.
* **VerixID does not validate document substance.** The system proves file integrity and existence at a specific time—not truthfulness, legality, or operational authenticity.
* **VerixID does not determine legal ownership.** A record proves a file was registered by a party at a specific timestamp—not that the registrant holds legal copyright or intellectual property rights.
* **VerixID is not a court, notary, or legal arbitrator.** The platform produces cryptographic facts; final evidentiary weight rests with presiding judicial authorities or regulatory bodies.
* **Public verification requires an active record.** Third parties cannot confirm record details on the Verify page if the record has expired or is inactive.

---

## 09 · USER RESPONSIBILITIES

The evidentiary strength of hash-based digital proof relies on user operational discipline. While the system guarantees ledger data integrity, users maintain custody and responsibility over their local files.

* Maintain **original master files** securely across at least two separate locations (local + encrypted cloud).
* Safeguard your **Ownership Key and Receipt** in non-volatile storage.
* Utilize distribution channels that **preserve raw bit integrity** (see Section 05).
* Register revised documents as **new records** whenever material changes occur.
* Ensure records are **active** when requesting formal third-party verifications.

---

## CORE PHILOSOPHY

VerixID does not judge who is right or wrong.

The system provides mathematical certainty that a specific data structure existed at a precise point in time. The interpretation and legal application of that proof rests entirely with the relying parties.

*"Math does not take sides."*

---

*Effective March 1, 2026 · Version 1.0 · Governed by the Laws of the Republic of Indonesia · Registered Electronic System Provider (PSE Komdigi) No. `022901.01/DJAI.PSE/04/2026`*