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.

5 chapters

1Core principles
2Symmetric and asymmetric cryptography
3Hashing, MACs and signatures
4Certificates, PKI and TLS
5Attack classes worth naming

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	$n (n - 1) /2$	$2 n$
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,))

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.

5 chapters

1Core principles
2Symmetric and asymmetric cryptography
3Hashing, MACs and signatures
4Certificates, PKI and TLS
5Attack classes worth naming

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	$n (n - 1) /2$	$2 n$
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

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,))

Security & Cryptography

If you remember nothing else

Core principles

Symmetric and asymmetric cryptography

Hashing, MACs and signatures

Certificates, PKI and TLS

Attack classes worth naming

Self-check

Security & Cryptography

If you remember nothing else

Core principles

Symmetric and asymmetric cryptography

Hashing, MACs and signatures

Certificates, PKI and TLS

Attack classes worth naming

Self-check

Security & Cryptography

If you remember nothing else

1Core principles

2Symmetric and asymmetric cryptography

3Hashing, MACs and signatures

4Certificates, PKI and TLS

5Attack classes worth naming

Security & Cryptography

If you remember nothing else

1Core principles

2Symmetric and asymmetric cryptography

3Hashing, MACs and signatures

4Certificates, PKI and TLS

5Attack classes worth naming

Core principles

Symmetric and asymmetric cryptography

Hashing, MACs and signatures

Certificates, PKI and TLS

Attack classes worth naming

Core principles

Symmetric and asymmetric cryptography

Hashing, MACs and signatures

Certificates, PKI and TLS

Attack classes worth naming