Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules
Key Takeaways
- Encryption gives confidentiality; hashing gives integrity; digital signatures give integrity, authentication, and non-repudiation.
- Symmetric encryption (AES) is fast for bulk data; asymmetric (RSA/ECC) handles key exchange, signatures, and public-key trust.
- PKI binds public keys to identities through certificates, certificate authorities, and a trust chain anchored at a protected root.
- Certificate failures map to expiration, name mismatch, untrusted issuer, revocation (CRL/OCSP), or private-key exposure.
- Store passwords with a salt and a slow algorithm (bcrypt/Argon2/PBKDF2), never reversible encryption or a bare fast hash.
Start With the Security Goal
Every crypto question is really asking what property do you need? If the goal is secrecy, think encryption. If the goal is detecting modification, think hashing or digital signatures. If the goal is binding a public key to a name, think certificates and PKI.
| Mechanism | Primary purpose | Key exam phrase |
|---|---|---|
| Symmetric encryption | Confidentiality with one shared secret key | fast bulk encryption (AES-256) |
| Asymmetric encryption | Public/private key operations | key exchange, encrypt to a public key (RSA, ECC) |
| Hashing | Integrity via a one-way digest | same input yields the same digest (SHA-256) |
| Salted password hash | Defends stored credentials | identical passwords get different stored hashes |
| Digital signature | Integrity + signer authentication + non-repudiation | sign with the private key, verify with the public key |
| Certificate | Binds a public key to an identity | issued by a CA, has a subject and validity period |
Remember the CIA mapping: encryption serves confidentiality, hashing and signatures serve integrity, and signatures add authentication and non-repudiation that a plain hash cannot.
Symmetric vs Asymmetric, and Why Both
Symmetric encryption uses one shared key for both encrypt and decrypt; it is fast, so it protects bulk data (full-disk encryption, database backups, VPN payloads). Its hard problem is getting the key to the other side. Asymmetric encryption uses a key pair: anything encrypted with the public key is decryptable only with the matching private key, and vice versa. It is slow, so real systems combine the two.
| Requirement | Best answer direction |
|---|---|
| Encrypt a large database backup efficiently | Symmetric (AES) |
| Safely agree on a session key with a remote website | Asymmetric key exchange, then symmetric session encryption |
| Verify a downloaded file was not altered | Hash comparison |
| Prove a package came from the developer unmodified | Digital signature |
| Bind a web server's public key to a domain | Certificate |
| Store user passwords | Salted, slow password hash |
| Make encrypted data instantly unrecoverable | Destroy the key (crypto-shredding) |
TLS is the canonical hybrid: asymmetric crypto authenticates the server and negotiates a shared secret, then a fast symmetric cipher protects the bulk traffic. That is why "asymmetric for key exchange, symmetric for the data" is a recurring correct answer.
Hashing, Salting, and Password Storage
A hash is a one-way digest: you cannot decrypt it back to the original. Good hashes resist collisions (two inputs, same digest), which is why MD5 and SHA-1 are deprecated and SHA-256 is preferred. For passwords, a plain fast hash is still wrong because attackers precompute rainbow tables.
| Defense | What it stops |
|---|---|
| Salt (unique random value per password) | Rainbow tables and identical-password matching |
| Pepper (secret added value, stored separately) | Offline cracking if only the database leaks |
| Key stretching (bcrypt, Argon2, PBKDF2) | Brute force, by making each guess deliberately slow |
Trap Callout: Hashing Is Not Encryption
There is no "decrypt the hash" step. A login system hashes the submitted password with the stored salt and compares digests. If a scenario needs the original data back, hashing is the wrong tool; if it needs proof of integrity, encryption alone is the wrong tool. HMAC adds a secret key to a hash so it also proves the message came from someone holding that key.
PKI, Certificates, and Failure Clues
Public Key Infrastructure (PKI) binds public keys to identities through signed certificates and a chain of trust.
| Component | Role |
|---|---|
| Certificate Authority (CA) | Issues and signs certificates |
| Registration Authority (RA) | Verifies identity before issuance in some designs |
| Certificate (X.509) | Holds subject, public key, issuer, validity, SAN, extensions |
| Private key | Must be protected; its exposure breaks trust for that cert |
| CRL / OCSP | Revocation checking (list vs real-time query) |
| Root CA | Offline trust anchor, guarded heavily |
| Intermediate CA | Issues certs so the root stays offline |
| Browser or service clue | Likely issue |
|---|---|
| Certificate expired yesterday | Validity-period problem |
| Valid for app.example.com but user visits pay.example.com | Name mismatch (subject/SAN) |
| Issuer is not trusted | Missing or untrusted CA chain |
| Private key was exposed | Revoke and reissue the certificate |
| Certificate was revoked | Do not trust even if dates look valid |
| Self-signed cert on a public site | Trust warning unless explicitly trusted |
Scenario Walkthrough
A team publishes an installer and wants customers to confirm it is unaltered and genuinely theirs. A bare hash detects accidental change, but an attacker can post a new hash beside a tampered file. A digital signature is stronger: the team signs with its private key and customers verify with the public key via a trusted certificate, delivering integrity, authentication, and non-repudiation at once.
A vendor wants customers to verify that a software update both came from the vendor and was not modified in transit. Which control best meets both goals?
A browser warns that a certificate is valid for files.example.com, but the user actually visited pay.example.com. What is the most likely problem?
Why is a unique random salt added before hashing each stored password?
Which choice correctly pairs the cryptographic need with the right tool for a TLS connection to a website?