Hashing, HMACs & Digital Signatures

You downloaded a binary from the internet — the latest version of kubectl. The download page shows a SHA-256 checksum next to the link. You run sha256sum kubectl and compare. But what exactly are you verifying? And what if the attacker modified both the binary and the checksum on the download page?

Hashing tells you whether data was modified. HMACs tell you whether data was modified by someone without the secret key. Digital signatures tell you whether data was created by a specific entity — and that is what TLS certificates, container image signing, and Kubernetes admission webhooks all rely on.

This lesson completes the cryptographic foundation. After this, you will understand every primitive used in TLS.

Part 1: Hash Functions — The One-Way Fingerprint

A cryptographic hash function takes an input of any size and produces a fixed-size output (the hash or digest). It has three critical properties:

1. One-way: given the hash, you cannot reconstruct the input
2. Deterministic: the same input always produces the same hash
3. Collision-resistant: it is computationally infeasible to find two different inputs that produce the same hash

# SHA-256 produces a 256-bit (32-byte) hash, displayed as 64 hex characters
echo -n "hello" | sha256sum
# 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

# Change one character: completely different hash (avalanche effect)
echo -n "Hello" | sha256sum
# 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

# Hash a large file — same 256-bit output regardless of input size
sha256sum /usr/bin/kubectl
# a1b2c3d4... kubectl

Hash Functions You Will Encounter

Where Hashes Appear in Kubernetes

Hashes are everywhere in your infrastructure:

# Docker image digests are SHA-256 hashes
docker pull nginx@sha256:a1b2c3d4e5f6...
# The digest uniquely identifies the exact image content
# Tags (like "latest") can change; digests cannot

# Kubernetes uses image digests for admission control
kubectl get pod -o jsonpath='{.status.containerStatuses[0].imageID}'
# docker-pullable://nginx@sha256:a1b2c3d4e5f6...

# Helm chart integrity verification
helm verify mychart-0.1.0.tgz
# Uses SHA-256 hash + signature to verify the chart

# etcd stores data with revision hashes
etcdctl get /registry/secrets/default/my-secret --print-value-only | sha256sum

# Pin container images by digest instead of tag for immutability
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: app
          # BAD: tag can be overwritten
          # image: myapp:v1.2.3
          # GOOD: digest is immutable
          image: myapp@sha256:a1b2c3d4e5f6789...

Part 2: HMACs — Hash-Based Message Authentication

A plain hash verifies integrity (was the data modified?) but not authenticity (who sent it?). If an attacker intercepts a message and its hash, they can modify both — the receiver has no way to know.

HMAC (Hash-based Message Authentication Code) solves this by incorporating a secret key into the hash computation:

HMAC(key, message) = Hash((key XOR opad) || Hash((key XOR ipad) || message))

Where:
  key   = shared secret between sender and receiver
  ipad  = inner padding (0x36 repeated)
  opad  = outer padding (0x5c repeated)

The receiver computes the HMAC using the same key and message. If the results match, the message is both unmodified (integrity) and from someone who knows the key (authenticity).

HMAC in Practice: Webhook Verification

Every webhook system in your infrastructure uses HMAC to verify authenticity:

# GitHub webhook signature verification
# GitHub sends: X-Hub-Signature-256: sha256=<HMAC>
# You verify by computing HMAC with your webhook secret

# Stripe webhook verification uses the same pattern
# Stripe sends: Stripe-Signature: t=<timestamp>,v1=<HMAC>

# Example: verify a webhook signature in bash
WEBHOOK_SECRET="whsec_abc123..."
PAYLOAD='{"event":"payment.completed"}'
EXPECTED_SIGNATURE="sha256=a1b2c3d4..."

COMPUTED=$(echo -n "$PAYLOAD" | openssl dgst -sha256 -hmac "$WEBHOOK_SECRET" | awk '{print $2}')
echo "sha256=$COMPUTED"
# Compare with EXPECTED_SIGNATURE

# Kubernetes webhook admission controller
# The API server sends requests to your webhook endpoint
# The TLS certificate authenticates the connection
# But HMAC concepts apply in the token review API and service account tokens
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: my-webhook
webhooks:
  - name: validate.myapp.io
    clientConfig:
      caBundle: <base64-CA-cert>  # Verifies webhook server identity
      service:
        name: my-webhook
        namespace: default

Part 3: Digital Signatures — Proving Identity at Scale

HMAC requires a shared secret between sender and receiver. This works for two parties but does not scale. If a server needs to prove its identity to millions of clients, it cannot share a secret with each one.

Digital signatures solve this using asymmetric cryptography:

1. The signer hashes the message (SHA-256)
2. The signer encrypts the hash with their private key — this is the signature
3. Anyone with the signer's public key can decrypt the signature and compare the hash
4. If the hashes match, the message is authentic (only the private key holder could have created the signature) and unmodified (the hash verifies integrity)

Signing:
  1. hash = SHA-256(message)
  2. signature = Encrypt(hash, private_key)
  3. Send: message + signature

Verification:
  1. hash1 = SHA-256(message)           # hash the received message
  2. hash2 = Decrypt(signature, public_key)  # decrypt the signature
  3. If hash1 == hash2: valid signature
     Else: message was modified or signer is fake

How TLS Certificates Use Digital Signatures

A TLS certificate is essentially a document that says "this public key belongs to devopsbeast.com," signed by a Certificate Authority (CA):

Certificate contents:
  Subject: CN=devopsbeast.com
  Public Key: (EC P-256 public key)
  Issuer: CN=Let's Encrypt Authority X3
  Valid: 2024-01-15 to 2024-04-15
  Serial Number: 03:a1:b2:c3...
  Signature Algorithm: SHA256withRSA

The CA signed this certificate by:
  1. Hashing all the certificate fields above with SHA-256
  2. Signing the hash with the CA's private key

Your browser verifies by:
  1. Hashing the certificate fields with SHA-256
  2. Decrypting the signature with the CA's public key (from the trusted root store)
  3. Comparing the hashes
  4. If they match: the certificate is legitimate

# View a certificate's signature details
openssl x509 -in cert.pem -noout -text | grep -A 2 "Signature Algorithm"
# Signature Algorithm: ecdsa-with-SHA256
#     30:45:02:21:00:b3:c4:d5... (the actual signature bytes)

# Verify a certificate against its issuer
openssl verify -CAfile ca-cert.pem server-cert.pem
# server-cert.pem: OK

Part 4: Container Image Signing with Cosign

Digital signatures extend beyond TLS. Cosign (part of the Sigstore project) signs container images so you can verify they were built by your CI pipeline and not tampered with:

# Sign a container image with cosign
cosign sign --key cosign.key myregistry.io/myapp:v1.2.3

# Verify a container image
cosign verify --key cosign.pub myregistry.io/myapp:v1.2.3
# Verification for myregistry.io/myapp:v1.2.3 --
# The following checks were performed on each of these signatures:
#   - The cosign claims were validated
#   - The signatures were verified against the specified public key

# Keyless signing with Sigstore (uses OIDC identity, not long-lived keys)
cosign sign myregistry.io/myapp:v1.2.3
# Generates an ephemeral key pair, signs with your OIDC identity
# Signature and certificate recorded in the Rekor transparency log

# Kubernetes admission policy to require signed images
# Using Kyverno
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  validatingAdmissionPolicy: true
  rules:
    - name: check-image-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "myregistry.io/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
                      -----END PUBLIC KEY-----

Part 5: How All Four Primitives Work Together in TLS

The four cryptographic primitives from this module combine in TLS:

Putting It All Together: Kubernetes Certificate Chain

When your browser connects to an application behind a Kubernetes ingress, the full chain of cryptographic operations looks like this:

# View the full certificate chain
openssl s_client -connect app.example.com:443 -showcerts 2>/dev/null | \
  openssl x509 -noout -text | head -20
# Certificate:
#     Data:
#         Version: 3 (0x2)
#         Serial Number: 04:a1:b2:c3:d4:e5
#         Signature Algorithm: ecdsa-with-SHA256    ← digital signature
#         Issuer: C=US, O=Let's Encrypt, CN=R3     ← CA that signed it
#         Validity
#             Not Before: Jan 15 00:00:00 2024 GMT
#             Not After : Apr 15 00:00:00 2024 GMT
#         Subject: CN=app.example.com
#         Subject Public Key Info:
#             Public Key Algorithm: id-ecPublicKey  ← asymmetric key
#                 Public-Key: (256 bit)             ← P-256 curve
#                 ASN1 OID: prime256v1

Key Concepts Summary

• Hash functions produce a fixed-size fingerprint of arbitrary data — one-way, deterministic, collision-resistant
• SHA-256 is the standard hash for security — 256-bit output, used in TLS, Docker digests, git (moving to), and Kubernetes
• MD5 and SHA-1 are broken — never use for security; practical collision attacks exist
• HMAC adds a secret key to hashing — proves both integrity (unmodified) and authenticity (from someone with the key)
• Digital signatures use asymmetric crypto (sign with private key, verify with public key) — provide non-repudiation at scale without shared secrets
• TLS certificates are digitally signed documents — the CA signs "this public key belongs to this domain" and anyone can verify with the CA's public key
• Container image signing (cosign) applies the same principle to supply chain security — sign images in CI, verify before deployment
• All four primitives compose in TLS: hashing for fingerprints, signatures for authentication, ECDHE for key exchange, AES-GCM for data encryption

Common Mistakes

• Using MD5 or SHA-1 for any security-critical purpose — both have practical collision attacks
• Confusing hashing with encryption — hashing is one-way (you cannot recover the input), encryption is two-way (you can decrypt with the key)
• Not verifying webhook HMAC signatures — allows attackers to forge webhook events
• Assuming a hash checksum on a download page proves authenticity — if an attacker controls the page, they can replace both the file and the checksum; only digital signatures (GPG/cosign) prove authenticity
• Confusing signing with encryption — signing uses the private key and anyone can verify; encryption uses the public key and only the private key holder can decrypt
• Deploying container images by tag instead of digest — tags are mutable, digests (SHA-256 hashes) are not