Security & Cryptography
The security vocabulary every CS graduate is expected to have: the CIA triad, symmetric and asymmetric cryptography, hashing, digital signatures, TLS, and the attack classes that keep recurring.
If you remember nothing else
- Confidentiality, Integrity, Availability — every security control serves at least one, and controls often trade one against another.
- Authentication is who you are; authorisation is what you may do. Authentication always comes first.
- Symmetric encryption is fast but needs a shared key; asymmetric is slow but solves key distribution — real systems use asymmetric to exchange a symmetric key.
- Hashing is one-way and is not encryption; there is no 'decrypting' a hash.
- Passwords must be salted and hashed with a deliberately slow function (bcrypt, argon2), never with a fast one like MD5 or SHA-256 alone.
- A digital signature gives integrity, authentication and non-repudiation — encryption alone gives none of those.
Core principles
| CIA triad | Guarantees | Broken by | Provided by |
|---|---|---|---|
| Confidentiality | Only authorised parties can read the data | Eavesdropping, data breach | Encryption, access control |
| Integrity | Data has not been altered undetectably | Tampering, corruption | Hashes, MACs, digital signatures |
| Availability | The system is usable when needed | Denial of service, hardware failure | Redundancy, backups, rate limiting |
- Least privilege — every user and process gets the minimum access needed for its task, and no more. Limits the blast radius of any compromise.
- Defence in depth — layer independent controls so that no single failure is fatal. A firewall and input validation and least privilege.
- Fail securely — when a control errors, it must deny rather than allow. An authentication service that is unreachable should reject, not admit.
- Never rely on obscurity — Kerckhoffs's principle: a system must remain secure even if everything about it except the key is public. Secret algorithms get reverse-engineered; secret keys can be rotated.
- Non-repudiation — a party cannot credibly deny having performed an action. Only digital signatures provide it, because only the key holder could have produced the signature.
Symmetric and asymmetric cryptography
| Symmetric | Asymmetric (public key) | |
|---|---|---|
| Keys | One shared secret key | A key pair — public and private |
| Encrypt with | The shared key | The recipient's public key |
| Decrypt with | The same shared key | The recipient's private key |
| Speed | Fast — suitable for bulk data | Slow — often 100–1000× slower |
| Key distribution | The hard problem — how do both parties get the key? | Solved — the public key may be published |
| Keys for n parties | ||
| Algorithms | AES, DES, 3DES, ChaCha20 | RSA, ECC, Diffie-Hellman, ElGamal |
| Property | Achieved by |
|---|---|
| Confidentiality | Encrypt with the recipient's public key |
| Authentication & non-repudiation | Sign with your own private key |
| Both | Sign with your private key, then encrypt the result with their public key |
Hashing, MACs and signatures
| Algorithm | Digest | Status |
|---|---|---|
| MD5 | 128 bits | Broken — collisions are trivially constructible |
| SHA-1 | 160 bits | Broken — practical collisions demonstrated in 2017 |
| SHA-256 / SHA-3 | 256 bits | Secure for integrity; too fast for passwords |
| bcrypt / scrypt / Argon2 | Varies | Correct for passwords — deliberately slow and tunable |
Plain textStoring a password correctly
WRONG: store(password) plaintext - catastrophic
WRONG: store(md5(password)) broken hash, no salt
WRONG: store(sha256(password)) unsalted; GPUs try billions/sec
BETTER: store(sha256(salt + password), salt) salted, but still fast
RIGHT: store(argon2(password, salt, cost)) salted AND deliberately slow
Verification never decrypts. It re-computes:
hash(supplied_password, stored_salt) == stored_hash ?
The cost factor is tunable: raise it as hardware gets faster, so an
offline guessing attack stays expensive for decades.| Mechanism | Provides | Requires | Non-repudiation? |
|---|---|---|---|
| Hash | Integrity only | Nothing — anyone can recompute it | No |
| MAC / HMAC | Integrity and authentication | A shared secret key | No — either party could have produced it |
| Digital signature | Integrity, authentication and non-repudiation | The signer's private key | Yes — only the key holder could sign |
Certificates, PKI and TLS
Public-key cryptography solves key distribution but creates a new problem: how do you know a public key really belongs to the party it claims? The answer is a certificate — a public key plus identity information, signed by a Certificate Authority that both parties already trust.
Client hello
The client sends the TLS versions and cipher suites it supports, plus a random value.Server hello and certificate
The server picks a cipher suite, sends its own random value, and presents its certificate chain.Certificate validation
The client verifies the CA's signature, checks the hostname matches, checks the expiry date, and checks revocation. Any failure aborts the connection.Key agreement
Both sides derive a shared symmetric session key — in modern TLS via ephemeral Diffie-Hellman, which gives forward secrecy.Encrypted session
All further traffic is encrypted symmetrically with that session key.
Attack classes worth naming
| Attack | Mechanism | Primary defence |
|---|---|---|
| SQL injection | User input is concatenated into a query and changes its structure | Parameterised queries — never string concatenation. Input validation is secondary |
| XSS (cross-site scripting) | Attacker-supplied script is stored or reflected and runs in another user's browser | Context-aware output encoding, Content Security Policy, HttpOnly cookies |
| CSRF | A victim's authenticated browser is tricked into issuing an unintended request | Anti-CSRF tokens, SameSite cookies, checking the Origin header |
| Buffer overflow | Writing past a buffer's bounds overwrites the return address | Bounds checking, stack canaries, ASLR, non-executable stack, memory-safe languages |
| Man-in-the-middle | An attacker relays and possibly alters traffic between two parties | TLS with certificate validation; certificate pinning |
| Replay attack | A valid captured message is retransmitted later | Nonces, timestamps, sequence numbers |
| Privilege escalation | Gaining rights beyond those granted | Least privilege, patching, careful setuid use |
PythonSQL injection, and the only real fix
# VULNERABLE - user input becomes part of the query's STRUCTURE
query = "SELECT * FROM users WHERE name = '" + name + "'"
# name = "' OR '1'='1" -> WHERE name = '' OR '1'='1' (matches everything)
# name = "'; DROP TABLE users; --" (two statements)
# SAFE - the query structure is fixed before the data is ever seen.
# The driver sends structure and parameters separately, so input can
# never be reinterpreted as SQL.
cursor.execute("SELECT * FROM users WHERE name = %s", (name,))Self-check
10 questions on Security & Cryptography · nothing is stored