What is a cryptographic hash?
A cryptographic hash is a method of computation that turns data into a fixed-length digest. Whether the input is a single sentence or a large file, the same hash algorithm always produces a result of the length that algorithm specifies. That result is called a hash value or a digest.
It works much like a "fingerprint" for data: as long as the input stays the same, the computed hash value stays the same, and changing even one character of the input usually produces a visibly different result. Someone else can therefore recompute the hash value to check whether the data they received matches the original, without comparing all the content character by character.
The metaphor has limits. A hash value is not an abbreviation of the data and cannot be used to recover the original text, and it is not an absolutely unique identifier either. What a secure cryptographic hash aims for is making it computationally very hard to work backwards to the input or to deliberately find the same result — not a mathematical guarantee that collisions can never occur.
The input and output of a hash computation
A hash algorithm operates on a definite string of binary data. Text, images and transactions all have to be converted into bytes before computation; a different character encoding, field order, or way of arranging structured information into bytes produces a different input and therefore a different result. That arranging process is usually called serialization.
SHA-256, for example, always outputs 256 bits, which is 32 bytes. Hash values are often written as 64 hexadecimal characters for readability by people and software. The two inputs below differ only in the case of one letter, yet the results are completely different:
| Input | SHA-256 hash value |
|---|---|
hello |
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 |
Hello |
185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969 |
The same input reliably yields the same result, so different participants can verify it independently. A visibly different result makes a change in the input easy to notice. But "looks random" alone cannot establish whether an algorithm is secure; security also depends on whether the algorithm resists specific attacks.
Three important properties of a cryptographic hash
A cryptographic hash generally has to make the following three things hard to do under real computing conditions:
- Given a hash value, it should be hard to find an input that produces that result. This is called preimage resistance. In plain terms, a hash value is not a compressed file you can simply decode.
- Given one input, it should be hard to find a second, different input that produces the same hash value. This is called second preimage resistance.
- It should be hard to find any two different inputs that produce the same hash value. This is called collision resistance.
Because the number of possible inputs is far greater than the number of fixed-length outputs, collisions must exist mathematically. The security goal is not to eliminate collisions but to leave an attacker unable to find a usable collision at a feasible cost.
"Hard to reverse" also does not mean a hash can hide every secret. If the range of inputs is small or easy to guess — common passwords, for instance — an attacker can try candidate values one by one and compare results. Storing passwords therefore usually calls for a purpose-built password hashing scheme, mixing in random data unique to each record (a salt) and setting how much computation each guess requires (a cost parameter). A single ordinary fast hash of a password is not enough.
How hashing, encryption, digital signatures and checksums differ
These techniques may all be used to process or check data, but they solve different problems:
| Method | Main purpose | Can the original data be recovered | Is a key required |
|---|---|---|---|
| Cryptographic hash | Produces a digest of data to help check integrity or to build other cryptographic mechanisms | Designed so the input cannot be derived from the digest | Not for an ordinary hash |
| Encryption | Prevents unauthorized parties from reading content | Can be decrypted with the correct key | Yes |
| Digital signature | Shows that a party holding the corresponding private key authorized specific data, and checks whether the data was altered | A signature is not meant to recover the original data | Signing and verification use a key pair |
| Ordinary checksum | Detects accidental errors in transmission or storage | Cannot be used to recover the original data | Usually not |
A hash by itself cannot establish who created the data. A digital signature system usually computes a digest of the data first, then has the private key sign the result associated with that data; a verifier additionally needs the public key and the signature rules to check the authorization relationship. An ordinary checksum mainly guards against accidental corruption and usually cannot withstand an attacker deliberately modifying data.
How blockchains use hashing
A blockchain does not maintain its ledger on a single hash value. Hashing is normally used alongside digital signatures, network validation, consensus and data structures, where it takes on the following tasks.
Identifying transactions or other data
Some networks compute an identifier from transaction data arranged in the protocol's format. A Bitcoin transaction identifier (TXID), for example, comes from a hash of the transaction's serialized data. As long as participants apply the same rules to the same data, they can compute the same identifier independently.
A "transaction hash" is not, however, a universal number for which every network uses the same algorithm or the same input format. The network name, the algorithm and the serialization rules are all part of the meaning, and copying a string of characters alone may not identify an object unambiguously.
Linking blocks and surfacing changes to history
A block can store the hash of the previous block header. When data in the previous block changes, its hash changes too, and the value stored in later blocks no longer matches. Both Bitcoin block headers and Ethereum blocks contain hash information pointing at the preceding block.
This linkage makes changes to history easy to surface, but it does not physically stop anyone from recomputing hashes. Deciding which history the network ultimately accepts still requires validation rules, a consensus mechanism and participants' assessment of the network state.
Summarizing large amounts of data and providing inclusion proofs
Data structures such as Merkle trees combine and hash multiple items layer by layer, arriving at a single root hash. A verifier can use a small number of intermediate hashes to check whether an item is included in an already committed set of data, instead of transferring all the content each time. Ethereum's Merkle Patricia trie is one structure that uses hashing to link state data.
A root hash can only establish whether given data is consistent with that cryptographic commitment. It cannot establish that the input information came from a trustworthy source, nor that an offchain event actually happened.
Taking part in proof of work
In a proof-of-work system, participants repeatedly adjust data in a candidate block and compute hashes, looking for a result that meets the protocol's difficulty condition. Other nodes can quickly check whether the result qualifies. Hashing here supplies a repeatable puzzle and a verifiable result, but whose block the network accepts is still determined by the complete consensus rules.
Hash algorithms are not interchangeable
SHA-256, SHA-3 and other cryptographic hashes are different families of algorithm. Even when two algorithms both output 256 bits, they will not produce the same result for the same input. A protocol or file verification instruction must state both the algorithm name and how the input is processed; "compute a hash" on its own is not enough.
Commonly used secure hash algorithms include the SHA-2 and SHA-3 families. The Secure Hash Standard from the US National Institute of Standards and Technology (NIST) covers the SHA-2 family, and the SHA-3 standard covers the SHA-3 family. Similar algorithm names also do not mean the implementation details match. A system should use the algorithm its protocol explicitly requires and that remains suitable for the current purpose; the fact that an older algorithm still produces output does not mean it still meets security requirements.
FAQ
Can a hash value be decrypted?
An ordinary cryptographic hash cannot be "decrypted", because hashing is not encryption and there is no corresponding decryption key. An attacker may find a matching value by guessing the input, exhausting a small input space or exploiting a weakness in the algorithm, but that is not recovering the original text directly from the digest.
If two pieces of data have the same hash value, must the content be the same?
Not in the sense of mathematical certainty, because fixed-length output necessarily allows collisions. When an algorithm still has adequate collision resistance and both sides are confirmed to use the same encoding and computation rules, an identical hash value can usually serve as strong evidence that the data matches.
Does seeing a hash value confirm a file is safe to use?
No. You also need to know where the expected hash value came from. If an attacker replaced both the file and the hash value on the page, recomputing it may still "match". Hashing can check whether data is consistent with a known digest, but the digest itself has to be obtained through a trustworthy channel.
If a blockchain uses hashing, does that make onchain information true?
No. Hashing can help check whether data has changed and whether different data structures match, but it cannot judge whether the input content describes the real world. Data provenance, signature authorization, network validation and consensus still have to be assessed separately.
Related concepts
Continue with block, blockchain, public key and private key, or return to the Crypto Glossary.
Sources
- NIST: cryptographic hash function definition — fixed-length digests, preimage resistance, second preimage resistance and collision resistance.
- NIST FIPS 180-4: Secure Hash Standard — the SHA-2 family, digest lengths and integrity uses.
- NIST FIPS 202: SHA-3 Standard — the SHA-3 family and its relationship to SHA-2.
- NIST SP 800-63B: password verifiers — password hashing schemes, salts and cost parameters.
- Bitcoin Developer Reference: transactions — serialized transaction data and the TXID.
- Bitcoin Developer Reference: block chain — previous block header hash, Merkle root and proof of work.
- Ethereum.org: blocks — the preceding block hash together with state and transaction root hashes.
- Ethereum.org: Merkle Patricia trie — hash-linked data structures and inclusion proofs.
