Hashing vs Encryption vs Signing: Developer Cheat Sheet

Quickstart

Use this when you’re in the middle of building an API, storing secrets, or shipping files—and you just need the right crypto tool without a rabbit hole.

Overview

Crypto bugs often come from correct code built with the wrong primitive. A few real-world examples: teams “encrypt” passwords by hashing them (can’t be verified properly), teams “sign” webhooks by hashing with no secret (anyone can forge), or teams encrypt but forget integrity (bit-flips become exploits).

Core concepts

Think in terms of properties. Most product requirements translate to: confidentiality, integrity, and authenticity. Different crypto primitives provide different properties.

Hashing (unkeyed): “fingerprint this data”

A cryptographic hash function takes input of any size and produces a fixed-size digest. Good hashes are designed so that: it’s infeasible to find two different inputs with the same digest (collision resistance) and infeasible to reverse the digest to recover the original input (preimage resistance).

• Use when: you need a stable identifier or integrity check (file fingerprinting, caching keys, deduping)
• Don’t use when: you need secrecy (hashing does not hide data)
• Common safe default: SHA-256

HMAC (keyed hash): “prove the sender knows a secret”

HMAC combines a secret key with a hash function to produce a message authentication code (MAC). It gives you integrity + authenticity between parties that share the same secret.

• Use when: signing webhooks, internal service-to-service message authentication, API request signing with a shared secret
• Key insight: without the key, anyone can compute a plain hash and forge it
• Common safe default: HMAC-SHA-256

Encryption: “hide this data”

Encryption transforms plaintext into ciphertext using a key. Decryption reverses it with the appropriate key. Modern application encryption should almost always use AEAD (Authenticated Encryption with Associated Data) so you get integrity too.

Digital signatures: “prove who authored this”

A digital signature uses a private key to sign data so that anyone with the corresponding public key can verify it. This gives you authenticity (and integrity), with a public-verification model—great for releases, tokens, and distributed systems.

• Use when: software updates, artifact signing, JWT signatures, verifying data from an untrusted network
• Key insight: verification does not require sharing a secret with verifiers
• Common safe defaults: Ed25519 or RSA-PSS (depending on ecosystem requirements)

One more concept: encoding vs encryption

Encoding (like base64, hex, URL encoding) changes representation for transport/storage. It provides zero security properties. If you can decode it without a key, it’s not encryption.

Step-by-step

This is a practical workflow you can reuse in designs, code reviews, and incident fixes. The goal is to choose the right primitive, pick safe defaults, and avoid subtle footguns (nonces, integrity, key handling).

Step 1 — Write the requirement as properties

Don’t start with “we should encrypt it.” Start with: confidentiality, integrity, authenticity, replay protection, and who verifies.

Step 2 — Choose the primitive and “safe default” algorithms

Step 3 — Prefer “encrypt-then-authenticate” by default (AEAD)

A common mistake is encrypting but not authenticating. Modern AEAD modes include an authentication tag so the receiver can detect tampering. If verification fails, you must treat the ciphertext as untrusted and abort.

Step 4 — Implement the primitive with a vetted library (avoid DIY crypto)

In practice, implementation bugs are more common than algorithm failures. Use a standard library or a mature dependency, and stick to documented “recipes.” Below are three copy/paste patterns you can adapt.

Example 1: Hash a file for integrity (SHA-256)

Use this when you need a stable fingerprint for downloads, build artifacts, backups, or caching keys. This does not hide content.

import hashlib
from pathlib import Path

def sha256_file(path: str, chunk_size: int = 1024 * 1024) -> str:
    h = hashlib.sha256()
    with Path(path).open("rb") as f:
        for chunk in iter(lambda: f.read(chunk_size), b""):
            h.update(chunk)
    return h.hexdigest()

if __name__ == "__main__":
    # Example: print the SHA-256 fingerprint of a file
    print(sha256_file("release.tar.gz"))

Example 2: Encrypt/decrypt data safely (AES-256-GCM)

Use AEAD for application-level encryption (secrets, tokens, PII). Never reuse the same (key, nonce) pair. Store nonce + ciphertext + tag together. Keep keys in a KMS/secret manager in real systems.

import crypto from "node:crypto";

// 32 bytes = AES-256 key. In production: load from KMS/secret manager, not hardcoded.
const key = crypto.randomBytes(32);

export function encryptAesGcm(plaintextUtf8, aadUtf8 = "") {
  const nonce = crypto.randomBytes(12); // 96-bit nonce is standard for GCM
  const cipher = crypto.createCipheriv("aes-256-gcm", key, nonce);

  if (aadUtf8) cipher.setAAD(Buffer.from(aadUtf8, "utf8"));

  const ciphertext = Buffer.concat([
    cipher.update(Buffer.from(plaintextUtf8, "utf8")),
    cipher.final(),
  ]);

  const tag = cipher.getAuthTag(); // integrity/authentication tag

  // Store/transmit: nonce || ciphertext || tag
  return Buffer.concat([nonce, ciphertext, tag]).toString("base64");
}

export function decryptAesGcm(payloadB64, aadUtf8 = "") {
  const payload = Buffer.from(payloadB64, "base64");
  const nonce = payload.subarray(0, 12);
  const tag = payload.subarray(payload.length - 16);
  const ciphertext = payload.subarray(12, payload.length - 16);

  const decipher = crypto.createDecipheriv("aes-256-gcm", key, nonce);
  if (aadUtf8) decipher.setAAD(Buffer.from(aadUtf8, "utf8"));
  decipher.setAuthTag(tag);

  const plaintext = Buffer.concat([decipher.update(ciphertext), decipher.final()]);
  return plaintext.toString("utf8");
}

Example 3: Sign and verify data (Ed25519 with OpenSSL)

Use signatures when verifiers shouldn’t share a secret with the signer (public verification): release files, artifacts, configuration bundles, or messages published to many consumers. Protect the private key; rotate if compromised.

# Generate an Ed25519 keypair
openssl genpkey -algorithm ED25519 -out ed25519_private.pem
openssl pkey -in ed25519_private.pem -pubout -out ed25519_public.pem

# Sign a file (creates a detached signature)
openssl pkeyutl -sign -inkey ed25519_private.pem -rawin -in artifact.bin -out artifact.sig

# Verify the signature
openssl pkeyutl -verify -pubin -inkey ed25519_public.pem -rawin -in artifact.bin -sigfile artifact.sig

Step 5 — Add “verification points” in your system

Crypto only helps if you verify at the right place. A few typical verification points:

Step 6 — Design your “crypto envelope” format

Most bugs happen at boundaries: what do you store, and how do you parse it safely? A simple envelope is: version, algorithm, key id, and the payload (nonce/ciphertext/tag or signature). This makes rotation and backwards compatibility manageable.

Common mistakes

These are the mistakes that show up in real apps. The fixes are usually straightforward once you know what property you actually need.

FAQ

Is hashing “more secure” than encryption?

No—hashing and encryption do different jobs. Hashing gives you a one-way fingerprint; encryption gives you confidentiality because it’s reversible with a key. If you need to hide data, use encryption (ideally AEAD).

What should I use to store passwords?

Use a password hashing function like Argon2id, bcrypt, or scrypt with a unique salt per password. Don’t use SHA-256/MD5 for password storage, and don’t encrypt passwords for later retrieval.

When do I use HMAC instead of digital signatures?

Use HMAC when both sides share a secret and you only need trusted parties to verify. Use digital signatures when verifiers should not share secrets with the signer (public verification), such as verifying releases or distributing signed messages to many consumers.

Does AES encryption automatically guarantee integrity?

Only if you use an authenticated mode (AEAD). AES is a block cipher; the mode matters. AES-GCM provides confidentiality and integrity; AES-CBC alone does not (it needs a separate MAC).

Is it safe to “encrypt then base64” a token?

Yes, as long as encryption is real encryption. Base64 is fine for transport once you already have ciphertext. Just remember: base64 adds no security, and you still need strong keys, nonces, and authentication tags.

How do I choose between SHA-256 and SHA-512?

Either is generally fine for integrity fingerprinting in modern systems. SHA-256 is the most common default and widely interoperable. The bigger difference is: don’t use obsolete hashes (MD5/SHA-1), and don’t use fast hashes for password storage.

What’s the simplest way to avoid crypto design mistakes?

Start from the property you need (confidentiality/integrity/authenticity), then pick a standard primitive and a documented library recipe. Avoid DIY constructions and build key rotation into your data formats.

Cheatsheet

Keep this as your “crypto pocket guide.” It’s designed to be scanned quickly during design reviews and implementations.

Wrap-up

The clean way to remember this post: hashing is for fingerprints, encryption is for secrecy, and signing is for proving authorship. Most production systems combine them—just don’t swap their roles.

If you want to deepen this, the related posts below cover threat modeling, DevSecOps controls, and how real apps get hacked— which is where crypto decisions become concrete.

Related posts

• OWASP Top 10 in Real Life: How Apps Actually Get Hacked
• Threat Modeling in 45 Minutes: A Lightweight Template
• Passkeys, MFA, Sessions: Modern Authentication Done Right
• API Security Checklist: Auth, Rate Limits, and Abuse Cases
• DevSecOps Basics: Add Security to CI/CD Without Chaos
• Dependency Attacks: How One Package Can BurnYour App