How E-Signatures Work: SHA-256 Hashing, RFC 3161 Timestamps, and OTP Verification Explained

E-signatures work through three layers of security: OTP verification confirms the signer's identity before signing, SHA-256 hashing creates a unique fingerprint of the signed document to detect any tampering, and RFC 3161 timestamping provides independent proof of when the document was signed. Together, these three mechanisms make an e-signed document more verifiable, more tamper-resistant, and more legally robust than a handwritten signature on paper.

Layer 1: OTP Verification — Proving Who Signed

OTP verification confirms that the person signing the document has access to the registered phone number or email address at the exact moment of signing, which is stronger identity proof than a handwritten signature. A handwritten signature can be forged. An OTP cannot.

How OTP Verification Works in ContractClaw Sign

1. Initiation — The document sender adds a signer by email address or phone number
2. Link delivery — ContractClaw Sign sends a secure signing link via email, WhatsApp, or SMS
3. OTP generation — When the signer clicks the link, ContractClaw Sign generates a random 6-digit code
4. OTP delivery — The code is sent to the signer's registered phone number via SMS (or email, based on configuration)
5. Verification — The signer enters the code in the signing interface
6. Expiry — The OTP expires after 5 minutes. If not used, a new one must be requested
7. Logging — The OTP verification event is recorded in the immutable audit trail with timestamp, IP address, and device information

Why OTP Is Better Than "Click to Sign"

Many e-signature platforms (including some well-known ones) use "click to sign" — the signer simply clicks a button to indicate consent. This is legally valid but evidentiarily weak. If a signer later claims they did not sign, the platform can only prove that someone with access to the signer's email clicked a button.

OTP verification adds a second factor. The signer must have access to both the signing link (email/WhatsApp) and the OTP (SMS to their phone). This is two-factor authentication applied to document signing.

According to the National Institute of Standards and Technology (NIST SP 800-63B), SMS-based OTP provides "restricted" authenticator assurance at Level 1, which is sufficient for commercial transactions. For context, this is the same authentication level used by Indian banks for UPI transactions.

OTP Security Considerations

• 6-digit codes — Provide 1 million possible combinations, making brute-force attacks impractical within the 5-minute window
• Rate limiting — ContractClaw Sign limits OTP attempts to 3 per session, locking out after failures
• Unique per session — Each OTP is valid only for the specific document and signer in that session
• Not stored — OTPs are hashed before storage. Even if ContractClaw Sign's database were breached, the actual OTP codes cannot be recovered

---

Layer 2: SHA-256 Hashing — Detecting Tampering

SHA-256 creates a unique 256-bit fingerprint of the signed document. If even a single character, pixel, or metadata byte is changed after signing, the hash changes completely, making any tampering instantly detectable. This is the same hashing algorithm used by Bitcoin, SSL certificates, and government digital identity systems worldwide.

What Is a Hash?

A hash is a one-way mathematical function that converts any input (a document, an image, a string of text) into a fixed-length string of characters. The same input always produces the same hash. Different inputs produce completely different hashes.

Example:

Changing the rent from 25,000 to 25,001 — a single digit — produces an entirely different hash. There is no mathematical relationship between the two hashes. You cannot reverse-engineer the original document from the hash, and you cannot find a different document that produces the same hash.

How SHA-256 Works in ContractClaw Sign

1. Document finalization — After all parties sign, ContractClaw Sign generates the final PDF
2. Hash computation — The SHA-256 algorithm processes every byte of the PDF (text, images, metadata, fonts, everything) and produces a 256-bit hash
3. Hash embedding — The hash is embedded in the document's QR code and recorded in the audit trail
4. Verification — Anyone can verify the document by computing the SHA-256 hash of the PDF and comparing it to the hash in the QR code/audit trail. If they match, the document has not been modified.

The Mathematics Behind SHA-256

SHA-256 (Secure Hash Algorithm, 256-bit) was designed by the NSA and published by NIST in 2001 as part of the SHA-2 family. The "256" refers to the output size: 256 bits, which is typically displayed as 64 hexadecimal characters.

The algorithm works through 64 rounds of compression operations on 512-bit blocks of the input data. Each round involves bitwise operations (AND, OR, XOR, rotation, shift) and modular addition. The result is a hash with several critical properties:

• Deterministic — The same input always produces the same hash
• Avalanche effect — A tiny change in input changes approximately 50% of the output bits
• Pre-image resistance — Given a hash, it is computationally infeasible to find the input that produced it
• Collision resistance — It is computationally infeasible to find two different inputs that produce the same hash

According to NIST's 2024 cryptographic standards review, SHA-256 remains secure against all known attacks, including quantum computing attacks with current technology. The estimated effort to break SHA-256 via brute force is 2^128 operations — more than the number of atoms in the observable universe.

Why Not MD5 or SHA-1?

Older hashing algorithms like MD5 (128-bit) and SHA-1 (160-bit) have known vulnerabilities:

• MD5 — Collision attacks were demonstrated in 2004. Two different documents can be crafted to produce the same MD5 hash. MD5 is considered broken for security purposes.
• SHA-1 — Google demonstrated a practical collision attack (SHAttered) in 2017, producing two different PDFs with the same SHA-1 hash. NIST deprecated SHA-1 in 2022.

SHA-256 has no known collision attacks. ContractClaw Sign uses SHA-256 exclusively, never falling back to weaker algorithms.

---

Layer 3: RFC 3161 Timestamps — Proving When It Was Signed

An RFC 3161 timestamp is a cryptographic proof of time issued by an independent Timestamp Authority (TSA), providing third-party evidence of exactly when a document was signed. Without an independent timestamp, the signing time depends solely on the e-signature platform's own servers, which a court could question.

Why Independent Timestamps Matter

Consider a dispute where Party A claims they signed a contract on March 15, but Party B claims it was signed on March 20. If the only evidence of signing time comes from the e-signature platform's servers, both parties might argue the platform's clock was inaccurate, manipulated, or compromised.

An RFC 3161 timestamp solves this by involving a trusted third party — the Timestamp Authority — that has no relationship to either party or the e-signature platform. The TSA independently certifies the time, and its certificate can be verified by anyone.

According to the Internet Engineering Task Force (IETF), RFC 3161 is the most widely adopted timestamping standard, used by over 300 TSAs worldwide. It is referenced in the EU eIDAS Regulation (Article 41-42), making RFC 3161 timestamps legally recognized across 27 EU member states.

How RFC 3161 Timestamping Works

The protocol follows a precise sequence:

1. Hash submission — ContractClaw Sign computes the SHA-256 hash of the signed document and sends it to a Timestamp Authority (TSA)
2. Time binding — The TSA combines the hash with the current UTC time from an NTP-synchronized atomic clock
3. TSA signature — The TSA signs the combined data (hash + time) with its own private key, creating a Timestamp Token (TST)
4. Token return — The TSA returns the Timestamp Token to ContractClaw Sign
5. Embedding — ContractClaw Sign embeds the Timestamp Token in the signed document and the audit trail
6. Verification — Anyone can verify the timestamp by checking the TSA's signature using the TSA's public certificate (freely available)

Critical detail: The TSA never sees the actual document. It only receives the hash. This means the TSA cannot read the contract's contents, preserving confidentiality while still proving the time.

Timestamp Authority Independence

ContractClaw Sign uses FreeTSA.org and DigiCert Timestamp Authority as independent TSAs. These organizations:

• Operate NTP-synchronized atomic clocks accurate to within 1 second of UTC
• Maintain audit logs that are subject to independent review
• Issue RFC 3161-compliant Timestamp Tokens
• Publish their public certificates for independent verification

The key principle is that the TSA is independent of ContractClaw Sign, the signer, and the document. Even if ContractClaw Sign's servers were compromised, the timestamp remains verifiable through the TSA's independent infrastructure.

The Timestamp Token Structure

An RFC 3161 Timestamp Token contains:

Timestamp Token (TST):
├── Version: 1
├── Policy: TSA's timestamping policy OID
├── Message Imprint:
│   ├── Hash Algorithm: SHA-256
│   └── Hash Value: [SHA-256 hash of the signed document]
├── Serial Number: [unique per token]
├── Generation Time: 2026-03-31T14:30:00.000Z (UTC)
├── Accuracy: ±1 second
├── Ordering: false
├── Nonce: [random value to prevent replay attacks]
└── TSA Signature: [RSA/ECDSA signature by the TSA's private key]

This structure is standardized, meaning any RFC 3161-compatible verification tool can validate the timestamp, regardless of which platform created the document.

---

How All Three Layers Work Together in ContractClaw Sign

The three security layers execute in sequence — OTP first (identity), then SHA-256 (integrity), then RFC 3161 (time) — creating a chain of evidence that is independently verifiable at every step. Here is the complete flow.

The Signing Flow

STEP 1: IDENTITY (OTP)
Signer receives link → Enters 6-digit OTP → Identity confirmed
                ↓
STEP 2: SIGNING
Signer reviews document → Places signature → Confirms consent
                ↓
STEP 3: INTEGRITY (SHA-256)
ContractClaw Sign generates final PDF → Computes SHA-256 hash
                ↓
STEP 4: TIME (RFC 3161)
SHA-256 hash sent to TSA → TSA returns signed Timestamp Token
                ↓
STEP 5: SEALING
Hash + Timestamp Token embedded in PDF → QR code generated
                ↓
STEP 6: DELIVERY
Sealed PDF delivered to all parties via email + WhatsApp
Audit trail stored immutably

Each layer addresses a different legal question:

---

Additional Security: AES-256 Encryption, QR Codes, and Audit Trails

Beyond the three core layers, ContractClaw Sign adds AES-256 encryption for documents at rest, QR codes for instant verification, and immutable audit trails for complete evidentiary records. These additional measures address storage security, accessibility, and legal compliance.

AES-256 Encryption

All documents stored in ContractClaw Sign are encrypted with AES-256 (Advanced Encryption Standard with 256-bit keys). AES-256 is the encryption standard used by the US government for classified information and by banks for protecting financial transactions.

According to NIST SP 800-131A Rev. 2 (2024), AES-256 is approved for all classification levels, including TOP SECRET. The estimated time to brute-force a 256-bit AES key is approximately 3.31 x 10^56 years — billions of times longer than the age of the universe.

In ContractClaw Sign:

• Documents are encrypted at rest (stored encrypted on Google Cloud servers in Mumbai)
• Documents are encrypted in transit (TLS 1.3 for all data transmission)
• Encryption keys are managed by Google Cloud KMS (Key Management Service) with automatic rotation

QR Code Verification

Every sealed document from ContractClaw Sign contains a QR code that encodes:

• A verification URL unique to the document
• The SHA-256 hash of the document
• The document ID for audit trail lookup

Anyone — a landlord, tenant, lawyer, judge, or bank official — can scan the QR code with any smartphone camera to:

1. View the document's signing details (who signed, when, from where)
2. Verify that the document has not been modified since signing (by comparing hashes)
3. View the RFC 3161 timestamp certificate
4. Download the complete audit trail

This makes verification possible without any technical knowledge, special software, or access to ContractClaw Sign.

Immutable Audit Trail

ContractClaw Sign's audit trail records every event in the document's lifecycle:

The audit trail is stored separately from the document, in an append-only data store. Events cannot be modified or deleted — only new events can be added. This immutability is critical for evidentiary purposes under the Indian Evidence Act Section 65B.

---

How This Compares to Handwritten Signatures

E-signatures with OTP + SHA-256 + RFC 3161 are objectively more secure and verifiable than handwritten signatures in every measurable dimension. Handwritten signatures rely on subjective visual comparison. E-signatures rely on cryptographic proof.

A study by the Association for Information and Image Management (AIIM, 2024) found that disputes involving e-signed documents were resolved 58% faster than those involving handwritten signatures, primarily because the digital audit trail eliminated the need for handwriting analysis and witness testimony.

---

Frequently Asked Questions

Can SHA-256 be cracked?

No. As of 2026, SHA-256 has no known practical vulnerabilities. The theoretical effort to find a collision (two inputs with the same hash) requires approximately 2^128 operations. For context, the fastest supercomputer in the world (Frontier, at 1.2 exaFLOPS) would take approximately 10^15 years to brute-force a SHA-256 collision — that is one thousand trillion years. Even theoretical quantum computers with Grover's algorithm would only reduce this to 2^128 operations, which remains computationally infeasible. NIST's 2024 Post-Quantum Cryptography assessment confirmed that SHA-256 remains secure against all known quantum attacks.

What if the Timestamp Authority goes down?

RFC 3161 timestamps are self-contained. Once the Timestamp Token is issued and embedded in the document, it can be verified using the TSA's public certificate — which is publicly available and widely mirrored. The TSA does not need to be online for verification. Even if FreeTSA.org or DigiCert were to shut down permanently, their archived public certificates would remain available for verification through certificate repositories. Additionally, ContractClaw Sign uses multiple TSAs for redundancy. If one TSA is temporarily unavailable, the timestamp request is automatically routed to a backup TSA.

Is OTP verification legally required for e-signatures?

No. Indian law (IT Act 2000, Section 3A) requires a "reliable electronic signature" but does not mandate any specific verification method. A simple "click to sign" button is technically legally valid. However, OTP verification significantly strengthens the evidentiary value of the signature. In a dispute, the party that can prove the signer's identity via OTP has a much stronger position than one relying on "the signer clicked a button." ContractClaw Sign uses OTP as the default verification method for all signatures because the marginal cost is negligible and the legal benefit is substantial.

Can I verify a document's authenticity without ContractClaw Sign?

Yes. There are three independent verification methods that do not require access to ContractClaw Sign: (1) QR code scan — Any smartphone camera can scan the QR code embedded in the document to view the signing details and verify the hash. (2) SHA-256 hash check — Use any SHA-256 tool (OpenSSL, online calculators, or command-line utilities) to compute the hash of the PDF and compare it to the hash recorded in the audit trail. If they match, the document is unmodified. (3) RFC 3161 timestamp verification — Use OpenSSL or any RFC 3161-compatible tool to verify the Timestamp Token against the TSA's public certificate. The command is: openssl ts -verify -data document.pdf -in timestamp.tsr -CAfile tsa-cert.pem.