Skip to content
Financial Context Wiki

Cryptographic hash functions

A verification-focused guide to cryptographic hash functions, covering security properties, byte encoding, SHA-2, SHA-3, Keccak, blockchain uses, and implementation risks.

Updated

For educational purposes only; not investment or cryptographic implementation advice. A matching digest does not by itself prove authenticity, ownership, authorization, finality, or data availability.

Direct answer

A cryptographic hash function deterministically maps a message represented as bytes to a digest with a defined output length. For a fixed-length n-bit hash, the basic relationship is:

h = H(m), where h is in {0,1}^n

The same bytes and algorithm produce the same digest. A one-bit input change should unpredictably alter many output bits, but this avalanche behavior is not the security definition. The principal security goals are preimage resistance (given a digest, finding an input that produces it is infeasible), second-preimage resistance (given one input, finding a different input with the same digest is infeasible), and collision resistance (finding any two distinct inputs with the same digest is infeasible).

Hashing is not encryption: there is no decryption key and no promise that the input can be recovered. Because infinitely many possible messages map into a finite output space, collisions must exist; security means that finding a useful one is computationally infeasible for the selected algorithm and output length.

A digest also provides no authenticity by itself. Recomputing a file’s hash detects a mismatch only when the expected digest and algorithm came through a trusted channel. Protocols obtain stronger guarantees by combining hashes with signatures, message-authentication codes, authenticated data structures, consensus rules, or proof-of-work.

How it works

  1. Define the exact bytes. Text encoding, capitalization, whitespace, field order, integer representation, length prefixes, and serialization all affect m. A protocol must specify a canonical encoding and bind the hash to an algorithm, version, network, and purpose.
  2. Run the specified construction. SHA-256 preprocesses a bounded-length message, divides it into blocks, and iteratively updates an internal state. SHA3-256 uses a KECCAK-based sponge construction. Both return 256-bit digests, but they are different functions and do not produce interchangeable outputs.
  3. Interpret security by the required property. For an ideal n-bit hash, generic preimage search takes about 2^n evaluations, while a generic collision search takes about 2^(n/2) because of the birthday effect. Output length alone is not enough if the algorithm is broken, the digest is truncated, or the surrounding protocol is flawed.
  4. Build the protocol around the digest. A digital-signature scheme can sign a digest of a message; HMAC adds a secret key for message authentication; a Merkle tree commits to many leaves with one root; and proof-of-work repeatedly hashes candidate block headers until a digest satisfies a target. These constructions provide different guarantees.
  5. Use the chain’s exact function. Bitcoin block headers and Merkle nodes use double SHA-256 in specified byte order. Ethereum execution uses Keccak-256 from the pre-standardization KECCAK design, not standardized SHA3-256. A label such as “256-bit hash” is therefore insufficient for verification.
  6. Verify context before meaning. Check the source of the expected digest, algorithm identifier, byte encoding, domain or chain, block and state reference, confirmation status, and any truncation. A correct computation against the wrong context is still a failed verification.

Worked examples

  • A tiny input change. SHA-256 of the five UTF-8 bytes for hello is 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. Replacing the first byte with uppercase H gives 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969. The differing digests do not reveal which byte changed.
  • Security strength is not digest length in every attack model. An ideal 256-bit hash offers roughly 2^256 preimage work but 2^128 collision work. This distinction matters when a protocol relies on collision resistance, as digital-signature workflows often do.
  • A Merkle proof authenticates inclusion relative to one root. A verifier hashes the encoded leaf with each supplied sibling in the specified order until it reconstructs the committed root. A match does not prove that the root is finalized, that the leaf data is true, or that omitted data is available.
  • Proof-of-work adds a target rule. Bitcoin validates a candidate header only when its double-SHA-256 value, interpreted according to the consensus rules, is less than or equal to the encoded target. The digest does not become more collision-resistant because miners performed more work.

Risks

  • Using a deprecated or unsuitable algorithm, especially relying on SHA-1 where collision resistance is required.
  • Treating SHA3-256, Keccak-256, SHA-256, double SHA-256, and differently truncated variants as interchangeable.
  • Hashing displayed text instead of the canonical bytes, or overlooking Unicode normalization, whitespace, endianness, field order, and length encoding.
  • Downloading a file and its expected digest from the same compromised location, which provides no independent integrity check.
  • Using a fast general-purpose hash directly for password storage instead of a salted, purpose-built password-hashing scheme with an appropriate work factor.
  • Using H(secret || message) as a homemade authentication code; some iterative hash constructions permit length-extension attacks, while HMAC is designed for keyed authentication.
  • Truncating digests without calculating the resulting collision and preimage security for the protocol’s scale and threat model.
  • Reusing an encoding across protocols without domain separation, allowing a digest valid in one context to be interpreted in another.
  • Assuming a transaction hash proves confirmation, finality, successful execution, ownership, or freedom from chain reorganization.
  • Assuming a content hash makes the referenced data retrievable; a commitment can remain valid while every available copy disappears.
  • Comparing explorer strings without checking byte order, prefix rules, serialization, or whether the interface displays an internal identifier differently.
  • Implementing cryptographic primitives without standard test vectors, maintained libraries, independent review, and upgrade procedures.

Common misconceptions

  • A hash is encrypted data. Encryption is reversible with the proper key; a cryptographic hash is a one-way digest with no decryption operation.
  • Different inputs can never share a digest. Collisions necessarily exist for a fixed-length output. A secure design makes them infeasible to find and exploit.
  • A 256-bit digest always provides 256 bits of security. Generic collision resistance is about 128 bits for an ideal 256-bit hash, and protocol choices can reduce it further.
  • Matching hashes prove who created the message. A bare hash has no secret and authenticates no sender; use a signature or a suitable MAC when origin matters.
  • Keccak-256 and SHA3-256 are two names for the same function. They use closely related designs but different standardization parameters and produce different digests.
  • An on-chain transaction hash proves settlement. It identifies encoded transaction data; chain inclusion, execution status, confirmations, and finality are separate facts.

Sources

Navigation

Search the wiki...