Hashing

A cryptographic hash function takes any input (a byte, a file, a 10MB JSON payload) and produces a fixed-length output called a digest. The same input always produces the same digest. A single changed byte in the input produces a completely different digest.

Three properties make a hash function cryptographically useful:

• Pre-image resistance: Given a digest, you cannot recover the original input.
• Collision resistance: You cannot find two different inputs that produce the same digest.
• Avalanche effect: One changed bit in the input flips roughly half the output bits.

SHA-256 produces a 256-bit (32-byte) digest. It is part of the SHA-2 family standardized by NIST and is the default choice for most new systems.

Input:  "amount=50000&currency=INR&timestamp=2024-01-15T10:30:00Z"
Output: a3f1d8c2e9b4f7a1c0e3d6f9b2c5a8e1f4d7g0b3c6e9a2d5f8b1c4e7a0d3f6

In BFSI systems, SHA-256 shows up in:

• Webhook payload signing (RazorPay, Cashfree, and most payment gateways use HMAC-SHA256)
• API request signing (AWS Signature V4, UPI NPCI checksums)
• TLS certificate fingerprints
• JWT signatures when using HS256

SHA-512 produces a 512-bit (64-byte) digest. On 64-bit hardware it is often faster than SHA-256 because the internal operations are 64-bit word operations (not 32-bit as in SHA-256).

Use SHA-512 when:

• You need a longer digest for higher collision resistance (archival integrity, long-term document signing)
• You are deriving keys using HKDF-SHA512 or PBKDF2-SHA512
• A counterparty or standard explicitly requires it

For most API-level use cases, SHA-256 is sufficient. SHA-512 is not "more secure" in practice for webhook verification.

SHA-1 produces a 160-bit digest. Collision attacks against SHA-1 were demonstrated in 2017 (SHAttered attack). Chrome and most browsers have removed SHA-1 from TLS. You should not use SHA-1 in any new system.

MD5 produces a 128-bit digest. Practical collision attacks have existed since 2004. It is completely broken for security purposes.

A plain hash verifies data integrity but not authenticity. Anyone who intercepts the payload can compute the same SHA-256 and forge a valid-looking request.

HMAC (Hash-based Message Authentication Code) mixes a secret key into the hash so only parties that know the key can produce or verify the digest.

HMAC-SHA256(key, message) = SHA256(key XOR opad || SHA256(key XOR ipad || message))

Webhook verification example:
  key    = your webhook secret from the provider
  input  = raw request body bytes
  result = compare against X-Signature header

Every payment gateway webhook (RazorPay, Stripe, Cashfree, PhonePe) uses HMAC-SHA256 for payload verification. Getting this wrong means an attacker can send fake payment confirmations to your server.

Hash functions are affected by quantum computers through Grover's algorithm, which provides a quadratic speedup for brute-force search. This effectively halves the security level in bits:

• SHA-256: 256-bit classical security, 128-bit post-quantum. Still considered secure.
• SHA-512: 512-bit classical security, 256-bit post-quantum. Very comfortable margin.
• SHA-1: already broken classically. Worse post-quantum. Never use.

Unlike RSA and ECDH (broken completely by Shor's algorithm), hash functions only need larger outputs to stay secure. SHA-256 does not need to be replaced for quantum safety.