Reviewed and updated: October 19, 2026.
Hashes, digital signatures and encryption solve different problems. Treating them as interchangeable produces misleading claims about blockchain privacy and security. A useful analysis starts by naming the property required: detecting a change, authorizing an action, hiding information or agreeing on a shared history.
Three cryptographic tools
| Tool | Main purpose | What it does not establish by itself |
|---|---|---|
| Cryptographic hash | Produce a fixed-size digest useful for integrity checks | The author, truth or confidentiality of the input |
| Public-key digital signature | Verify authorization of particular data under a public key | The signer's legal identity or whether the authorized action was sensible |
| Encryption | Make data readable only with the appropriate decryption capability | The correctness of the plaintext or the security of a compromised endpoint |
MDN's Web Crypto documentation exposes separate digest, sign/verify and encrypt/decrypt operations. That separation is a useful practical reminder. A hash is not encrypted text waiting to be decrypted, and a public blockchain is not confidential merely because cryptography is involved.
Worked example: an invoice that changes from 100 to 1,000
Imagine a supplier sends a file stating an invoice amount of 100 units. The recipient stores its hash. If someone later changes the amount to 1,000, hashing the changed bytes will ordinarily produce a different digest. Comparing the new digest with the previously trusted one detects a mismatch.
If an attacker can replace both the file and the saved reference hash, the comparison no longer establishes authenticity. The reference needs protection too. Likewise, identical hashes are a computational integrity check under the algorithm's assumptions, not a mathematical promise that collisions cannot exist.
Now add a signature over the invoice data. Verification with the expected public key can establish that the signed data matches that signature. But if the authorized supplier deliberately signs a false invoice, the signature can verify perfectly. Cryptography does not inspect the physical delivery or decide whether the bill is fair.
Encryption adds confidentiality, with conditions
A recipient can use encryption to keep the invoice contents from unauthorized readers in transit or storage. The intended recipient still needs to decrypt it, and a compromised device may expose the plaintext there. Key distribution, storage and recovery therefore remain part of the security design.
Symmetric and public-key encryption have different key-management models. Public-key encryption is not automatically more secure simply because it uses two keys. Algorithm choice, parameters, authenticated encryption and correct implementation matter. MDN's encryption documentation distinguishes these mechanisms and explains why authentication is important.
Consensus supplies another property
A blockchain combines records and validation rules with a method for agreeing on history. Hash links can reveal that a local copy was altered, but links alone do not tell competing participants which history to accept. That depends on the network's consensus rules and assumptions.
NIST's blockchain overview describes tamper evidence and resistance rather than an unconditional inability to change any record. Key theft, software defects, governance changes and failure of consensus assumptions remain distinct concerns. No single claim of immutability resolves all of them.
Ask four permission questions
- Read: who can see the records and associated metadata?
- Submit: who can request a transaction or contract action?
- Validate: who can participate in confirming the history?
- Govern: who can change software, permissions or administrator controls?
These permissions need not belong to the same group. A network can restrict validators while exposing transaction data, or offer public access through an interface controlled by one operator. Write down the specific property and failure scenario before calling a system secure, private or decentralized. That produces a testable explanation instead of a collection of reassuring labels.
Sources and scope
- MDN: cryptographic digests
- MDN: signatures and verification
- MDN: encryption and authentication
- NIST IR 8202: Blockchain Technology Overview
Continue reading: A practical blockchain learning path · A simple blockchain explanation · Wallet signing and key security
Editorial update: Separated hashing, signatures and encryption; removed absolute immutability and anonymity claims; added an invoice-integrity example and a four-part permissions framework.