Helpful first: Symmetric and asymmetric cryptography: ciphers, modes, and hybrid envelopes
Key points
- Distinguish unkeyed hashes (SHA-256/SHA-3), keyed MACs (HMAC), and asymmetric digital signatures across integrity, authenticity, and non-repudiation
- Explain the Birthday Paradox collision math (2^(n/2)) and why MD5 and SHA-1 are deprecated for collision resistance
- Trace X.509 PKI hierarchies (Root CA, Intermediate CA, RA) and revocation checking (CRL vs OCSP vs OCSP Stapling)
Hashes, HMAC, and digital signatures: what each proves
A cryptographic hash function (such as SHA-256, SHA-384, or SHA-3) takes an arbitrary-length input and produces a fixed-length digest. Strong hash functions enforce three properties: Pre-image resistance (one-way: given digest H(M), you cannot recover M), Second pre-image resistance (given M1, you cannot find M2 != M1 with the same hash), and Collision resistance (you cannot find any two distinct inputs M1 and M2 where H(M1) == H(M2)). Because of the Birthday Paradox, finding any random collision requires roughly 2^(n/2) operations for an n-bit hash (so a 256-bit hash provides 128 bits of collision resistance). Legacy algorithms MD5 (128-bit) and SHA-1 (160-bit) suffer practical collision attacks and must never be used for security signatures.
An unkeyed hash alone only proves integrity if the digest is delivered over a separate trusted channel; if an attacker intercepts a download and swaps both the binary and the published SHA-256 string, the victim’s hash check still passes. An HMAC (Hash-based Message Authentication Code) mixes a shared secret key into the hash calculation, proving both integrity and authenticity between two parties who share that secret. However, because both parties hold the same symmetric key, neither can prove to a third-party judge which one generated the HMAC.
To achieve Non-Repudiation (proof that the sender cannot later deny having signed the message), practitioners use an asymmetric Digital Signature (such as ECDSA, Ed25519, RSA-PSS, or post-quantum ML-DSA). The sender computes the cryptographic hash of the message and signs that digest using the sender’s own Private Key. Any recipient can verify the signature using the sender’s Public Key, proving both that the bytes were not altered (integrity) and that only the holder of the sender’s private key could have signed them (authenticity and non-repudiation).
| Mechanism | Key used | What it guarantees |
|---|---|---|
| Unkeyed Hash (SHA-256, SHA-3) | None | Integrity against accidental corruption (or tampering if the digest is stored separately in a trusted location). |
| HMAC (HMAC-SHA256) / CMAC | Shared symmetric secret key | Integrity + Authenticity between key holders. Does NOT provide non-repudiation because the key is shared. |
| Digital Signature (ECDSA, Ed25519, RSA-PSS) | Sign: Sender’s Private Key; Verify: Sender’s Public Key | Integrity + Authenticity + Non-Repudiation. Does NOT encrypt the message (no confidentiality). |
| Sign-then-Encrypt Envelope | Sender Private Key (sign) + Ephemeral AES/Recipient Public Key (encrypt) | Full CIA + Non-Repudiation: proves who sent it, prevents tampering, and keeps payload confidential. |
Public Key Infrastructure (PKI) and X.509 certificate chains
Digital signatures and TLS handshakes only work if you know a public key genuinely belongs to chronos.orbital and not an impostor on the network. Public Key Infrastructure (PKI) solves this by binding an identity (such as a DNS Subject Alternative Name or workload SPIFFE ID) to a public key inside an X.509 digital certificate signed by a trusted Certificate Authority (CA).
A production PKI uses a two- or three-tier hierarchy to protect the trust anchor. At the top sits the Root CA, whose private key is kept air-gapped offline inside a physical HSM and used only to sign Intermediate (Issuing) CA certificates and root revocation lists. Online Intermediate CAs issue short-lived leaf certificates to servers and workloads; if an Intermediate CA is compromised, the Root CA can revoke it without replacing the root trust store on millions of devices.
Before a CA signs a certificate, a Registration Authority (RA) verifies the requester’s identity and domain ownership (via ACME DNS/HTTP challenges for Domain Validation, or legal organization checks for OV/EV). An RA validates identity requests and forwards them to the CA, but an RA never signs certificates itself.
Certificate revocation (CRL, OCSP, Stapling) and mutual TLS (mTLS)
What happens when a server’s private key is stolen six months before its X.509 certificate expires? The CA must revoke the certificate by serial number. Historically, clients downloaded a Certificate Revocation List (CRL), a signed file listing all revoked serial numbers, which grew large and stale between periodic updates.
The Online Certificate Status Protocol (OCSP) improved freshness by letting a browser query the CA’s OCSP responder for a single certificate serial number in real time. However, standard OCSP introduces latency on every TLS connection, leaks which websites the client is visiting to the CA, and often forces browsers to "soft-fail" (allow the connection) if the OCSP server is unreachable. OCSP Stapling (and short-lived automated ACME certificates) fixes all three problems: the web server itself queries the CA periodically, caches a timestamped, CA-signed OCSP proof, and "staples" that proof directly into the TLS handshake.
Inside zero-trust service meshes and high-security ground-station APIs, Meridian enforces Mutual TLS (mTLS): the client verifies the server’s X.509 certificate, and the server also requires and verifies a client X.509 certificate, authenticating both endpoints cryptographically at the transport layer.
CHECK YOUR JUDGMENT
Flight Director Vera Vance needs to transmit a critical orbital maneuver command from Meridian Mission Control (chronos.orbital) to an automated relay station. The relay station must verify both that the command bytes were not altered in transit and that the command undeniably originated from Vera’s specific hardware signing key (non-repudiation), while also keeping the maneuver coordinates confidential from eavesdroppers. How should the cryptographic operations be structured?
NEXT FIELD LESSON