Cryptography
Cryptography is the mathematical foundation for confidentiality, integrity, authentication, and non-repudiation. It protects HTTPS, password storage, encrypted messaging, disk encryption, software updates, package signatures, and cloud secrets.
This module focuses on what security practitioners and developers need to know: which primitives solve which problems, where they fail, and how they support modern defenses such as signed releases and package provenance.
Symmetric Encryption
In symmetric encryption, the same secret key encrypts and decrypts data.
| Algorithm | Status | Common use |
|---|
| AES-GCM | Standard modern choice | TLS, file encryption, disk encryption |
| ChaCha20-Poly1305 | Modern alternative | Mobile, software-only environments, WireGuard |
| 3DES | Deprecated | Legacy systems only |
| DES | Broken | Never use |
Asymmetric Encryption
Asymmetric cryptography uses a key pair:
- Public key: Shared openly.
- Private key: Kept secret.
Data encrypted with one key can only be decrypted with the matching key. In practice, asymmetric cryptography is used for key exchange, digital signatures, identity, and certificate-based trust.
| Algorithm | Based on | Typical use |
|---|
| RSA | Integer factorization | Legacy encryption and signatures |
| ECDSA / ECDH | Elliptic curves | Signatures and key exchange |
| Ed25519 | Edwards curves | SSH, modern signatures, developer tooling |
Hybrid Encryption
Most real systems use both symmetric and asymmetric cryptography:
- Use asymmetric cryptography to authenticate and establish a shared secret.
- Derive symmetric session keys.
- Use fast symmetric encryption for bulk data.
This is how TLS, secure messaging protocols, and many encrypted storage systems work.
TLS 1.3
TLS powers HTTPS and many other encrypted protocols. TLS 1.3 is the modern baseline.
Client Hello
The client sends supported cipher suites, protocol version, random data, and a key share.
Server Hello
The server selects parameters, sends its key share, and presents a certificate.
Key Agreement
Both sides compute the same shared secret without sending the secret itself.
Encrypted Communication
The session uses derived symmetric keys to protect application data.
Hashing
A hash function produces a fixed-size output from any input. Secure hashes are one-way and collision-resistant.
Properties
- Deterministic: Same input produces the same hash.
- One-way: You cannot recover the input from the hash.
- Avalanche effect: A tiny input change produces a very different output.
- Collision resistance: It should be infeasible to find two inputs with the same hash.
Algorithm Comparison
| Algorithm | Status | Use |
|---|
| MD5 | Broken | Never use for security |
| SHA-1 | Broken | Never use for security |
| SHA-256 / SHA-384 | Secure | File integrity, signatures, certificates |
| bcrypt | Secure | Password hashing |
| Argon2id | Preferred for passwords | Password hashing with memory hardness |
Password Hashing
Passwords should never be stored in plaintext. They should be processed with a slow, salted password hashing algorithm.
Key terms:
- Salt: Random data added to each password before hashing.
- Work factor: A cost setting that makes guesses expensive.
- Memory hardness: A design that makes GPU and ASIC cracking harder.
password = "example passphrase"
salt = random_bytes(16)
hash_value = argon2id(password, salt, time_cost=3, memory_cost=65536)
stored_value = salt + hash_value
Do not use plain SHA-256, MD5, or SHA-1 for password storage. Fast hashes are good for file integrity, but they are bad for passwords because attackers can guess too quickly.
Digital Signatures
Digital signatures prove integrity and origin when the private key is protected.
Sign
The sender hashes the content and signs the hash with a private key.
Verify
The recipient checks the signature with the public key and recomputes the hash.
Certificate Chains
Browsers trust a website certificate because it chains back to a trusted root certificate authority.
Root CA
-> Intermediate CA
-> Website certificate
Code Signing and Software Provenance
Supply chain attacks often target the gap between “this software came from somewhere” and “this software is safe to run.” Cryptography helps, but only if signing keys, build systems, and release processes are protected.
What Signing Can Prove
- A package, binary, commit, or container image was signed by a specific key.
- Content has not changed since it was signed.
- A release came from a controlled workflow, if provenance is configured.
What Signing Cannot Prove Alone
- The maintainer account was not compromised.
- The signed code is free of malware.
- The build system was not tampered with.
- The signing key was not stolen.
Practical Controls
- Require signed commits or signed releases for critical projects.
- Use short-lived signing credentials where possible.
- Protect signing keys with hardware-backed storage or managed signing services.
- Generate SBOMs for releases.
- Use provenance systems such as Sigstore and SLSA-inspired build attestations.
- Verify signatures in CI/CD before deployment.
In a supply chain incident, cryptography helps answer “what changed” and “who signed it.” Logs, review, endpoint telemetry, and incident response are still needed to answer “was the signer compromised?”
Key Management
Strong algorithms fail if keys are mishandled.
Good key management:
- Generate keys with secure randomness.
- Store private keys in a password manager, hardware security module, cloud KMS, or secret manager.
- Rotate keys after exposure or on a planned schedule.
- Scope keys to the smallest necessary use.
- Separate development, staging, and production keys.
- Revoke keys that are unused or exposed.
- Log key use where possible.
Bad key management:
- Hardcoding secrets in source code.
- Sharing private keys over chat or email.
- Reusing one key across unrelated systems.
- Keeping long-lived tokens on developer laptops without monitoring.
Post-Quantum Cryptography
Large-scale quantum computers could eventually break RSA and elliptic curve cryptography. This creates a “harvest now, decrypt later” concern for data that must stay confidential for many years.
NIST has standardized post-quantum algorithms for future migration:
| Algorithm | Type | Purpose |
|---|
| ML-KEM | Lattice-based | Key establishment |
| ML-DSA | Lattice-based | Digital signatures |
| SLH-DSA | Hash-based | Digital signatures |
Practical Lab Ideas
- Hash a file with SHA-256, change one byte, and compare the new hash.
- Store a password with Argon2id and inspect the salt and cost settings.
- Create an Ed25519 key pair and sign a file.
- Verify a signed Git commit or release artifact.
- Inspect a website certificate chain in your browser.
- Generate a small SBOM and discuss what it does and does not prove.
Key Takeaways
- Use the right primitive for the job.
- Fast hashes are not password hashes.
- TLS protects connections, not compromised endpoints.
- Digital signatures protect integrity only if keys and workflows are protected.
- Software provenance matters in supply chain defense.
- Post-quantum migration is a planning problem, not a panic problem.
