Trance-0/NoteNextra-origin
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
eb476b26cef064ba2d8af1d9c7f274554222c0d0
NoteNextra-origin/content/CSE4303/CSE4303_E1.md
Trance-0 eb476b26ce updates
2026-03-03 12:41:30 -06:00

17 KiB
Raw Blame History

CSE4303 Introduction to Computer Security (Exam Review)

Details

Time and location

– In class exam – Thursday, 3/5 at 11:30 AM – What is allowed: - One 8.5” X 11” paper of notes, single-sided only, typed or hand-written

Topics covered:

– Security fundamentals – TCP/IP network stack – Crypto fundamentals – Symmetric key cryptography – Hash functions – Asymmetric key cryptography

Security fundamentals

Defining security

  • Understand principles of security analysis
    • The security of a system, application, or protocol is always relative to
      • A set of desired properties
      • An adversary with specific capabilities ("threat model")

Key security concepts

C.I.A. triad:

  • Integrity: Prevent unauthorized modification of data, and/or detect if modification occurred.
    • ARP poisoning (ARP spoofing)
    • Authentication codes
  • Confidentiality: Prevent unauthorized parties from learning the contents of data (in transit or at rest).
    • Packet sniffing / eavesdropping
    • Data encryption
  • Availability: Ensure systems and data are accessible to authorized users when needed.
    • Denial-of-Service (DoS) / Distributed DoS (DDoS)
    • Rate limiting + traffic filtering (often with DDoS protection/CDN)

Other security goals:

  • Authenticity: identity of an entity (issuer of info/message) is verified
  • Anonymity: identity of an entity remains unknown
  • Non-repudiation: messages can't be denied or taken back (e.g. online transaction commitments)

Modeling attacks

Common components:

  • System being attacked (usually a model, with assumptions and abstractions)
  • Threat model
  • Attack surface: what can be attacked
    • Open ports and exposed services
    • Public APIs and their parameters
    • Web endpoints, forms, cookies
    • File system permissions
    • Hardware interfaces (USB, JTAG)
    • User roles and privilege boundaries
  • Attack vector: how the attacker attacks
    • SQL injection via POST /login
    • Phishing to steal credentials, then SSH login
    • Buffer overflow in a network daemon
    • Cross-site scripting through a comment field
    • Supply-chain poisoning of a dependency
  • Vulnerability: what the attacker can do
  • Exploit: how the attacker exploits the vulnerability
  • Damage: what the attacker can do
  • Mitigation: mitigate vulnerability
  • Defense: close vulnerability gap

Importance of correct modeling

  • Attack-surface awareness guides defenses
    • E.g. pre-Covid-19 vs. post-Covid attack surface of company servers
  • Match resources to expected threat actors
    • "Script kiddie": individual or group running off-the-shelf attacks
      • Caveat: off-the-shelf attacks can still be quite powerful! Metasploit, Shodan, dark web market.
    • "Insider attack": employee with access to internal machines/networks
    • "Advanced Persistent Threat (APT)": nation-state level resources and patience
    • All these threats have different motivations, require different defenses/responses!
  • Reevaluate often
    • Threat capabilities change over time

TCP/IP network stack

Local and interdomain routing

  • TCP/IP for routing and messaging
  • BGP for routing announcements

Domain Name System

  • Find IP address from symbolic name (cse.wustl.edu)

Layer Summary

Application: the actual sending message Transport (TCP, UDP): segment Network (IP): packet Data Link (Ethernet): frame

Types of Addresses in Internet

  • Media Access Control (MAC) addresses in the network access layer
    • Associated w/ network interface card (NIC)
    • 00-50-56-C0-00-01
  • IP addresses for the network layer
    • IPv4 (32 bit) vs IPv6 (128 bit)
    • 128.1.1.3 vs fe80::fc38:6673:f04d:b37b%4
  • IP addresses + ports for the transport layer
    • E.g., 10.0.0.2:8080
  • Domain names for the application/human layer
    • E.g., www.wustl.edu

Routing and Translation of Addresses

(All of them are attack surfaces)

  • Translation between IP addresses and MAC addresses
    • Address Resolution Protocol (ARP) for IPv4
    • Neighbor Discovery Protocol (NDP) for IPv6
  • Routing with IP addresses
    • TCP, UDP for connections, IP for routing packets
    • Border Gateway Protocol for routing table updates
  • Translation between IP addresses and domain names
    • Domain Name System (DNS)

Summary for security

  • Confidentiality
    • Packet sniffing
  • Integrity
    • ARP poisoning
  • Availability
    • Denial of service attacks
  • Common
    • Address translation poisoning attacks (DNS, ARP)
    • Packet spoofing
  • Core protocols not designed for security
    • Eavesdropping, packet injection, route stealing, DNS poisoning
    • Patched over time to prevent basic attacks
  • More secure variants exist:
    • IP \to IPsec (IPsec is )
    • DNS \to DNSsec
    • BGP \to sBGP

Crypto fundamentals

  • Well-defined statement about difficulty of compromising a system
    • ...with clear implicit or explicit assumptions about:
      • Parameters of the system
      • Threat model
      • Attack surfaces
  • Example: "A one-time pad cipher is secure against any cryptanalysis, including a brute-force attack, assuming:
    • the key is the same length as the plaintext,
    • the key is truly random, and
    • the key is never re-used."

Common roles in cryptography

Alice and Bob: Sender and receiver

Eve: Adversary that can see but not create any packets

Mallory: Man in the middle, can create and modify packets

The message M is called the plaintext.

Alice will convert plaintext M to an encrypted form using an encryption algorithm E that outputs a *ciphertext- C for M.

Cryptography goals

Confidentiality:

  • Mallory and Eve cannot recover original message from ciphertext

Integrity:

  • Mallory cannot modify message from Alice to Bob without detection by Bob

Threat models

  • Attacker may have (with increasing power):
    • a) collection of ciphertexts (ciphertext-only attack)
    • b) collection of plaintext/ciphertext pairs (known plaintext attack: KPA)
    • c) collection of plaintext/ciphertext pairs for plaintexts selected by the attacker (chosen plaintext attack: CPA)
    • d) collection of plaintext/ciphertext pairs for ciphertexts selected by the attacker (chosen ciphertext attack: CCA/CCA2)

Symmetric key cryptography

Classical cryptography

Techniques: substitution and transposition

  • Substitution: 1:1 mapping of alphabet onto itself

  • Transposition: permutation of elements (i.e. rearrange letters)

  • Caesar cipher: rotate each letter by k positions (k is fixed)

  • Vigenère cipher: If length of key is known, split letters into groups based on index within key and do frequency analysis within groups

The three steps in cryptography:

  • Precisely specify threat model
  • Propose a construction
  • Prove that breaking construction under threat mode will solve an underlying hard problem

Perfect secrecy

Ciphertext attack reveal no "info" about plaintext under ciphertext only attack

Def: A cipher (E, D) over (K, M, C) has perfect secrecy if

  • \forall m_0, m_1 \in M (|m_0| = |m_1|) and \forall c \in C,
    • \Pr[E(k, m_0) = c] = \Pr[E(k, m_1) = c] where k \leftarrow K

XOR One-time pad (perfect secrecy)

Assumptions:

  • Key is as long as message
  • Key is random
  • Key is never re-used

In practice, relax this assumption gets "Stream ciphers"

Stream cipher

  • Use pseudorandom generator as keystream for xore encryption (security is guaranteed by pseudorandom generator)

Security abstraction:

  1. XOR transfers randomness of keystream to randomness of CT regardless of PT’s content
  2. Security depends on G being “practically” indistinguishable from random string and “practically” unpredictable
  3. Idea: shouldn’t be able to predict next bit of generator given all bits seen so far

Semantic security

  • (E, D) has semantic secrecy if \forall m_0, m_1 \in M (|m_0| = |m_1|),
    • \{E(k, m_0)\} \approx_p \{E(k, m_1)\} where k \leftarrow K
  • ...and the adversary exhibits m_0, m_1 \in M explicitly

The advantage of adversary is defined as the probability of distinguishing E(k, m_0) from E(k, m_1).

Weakness for stream ciphers

  • Week pseudorandom generator
  • Key re-use
  • Predicable effect of modifying ciphertext or decrypted plaintext.

Block cipher

View cipher as a Pseudo-Random Permutation (PRP)

Pseudorandom permutation

  • PRP defined over (K, X):

    • E: K \times X \to X
    • such that:
      1. There exists an "efficient" deterministic algorithm to evaluate E(k, x).
      2. The function E(k, \cdot) is one-to-one.
      3. There exists an "efficient" inversion algorithm D(k, y).

  • i.e. a PRF that is an invertible one-to-one mapping from message space to message space

Security of block ciphers

Intuition: a PRP is secure if: a random function in Perms[X] is indistinguishable from a random function in SF (real random permutation function)

The adversarial game is to let adversary decide x, then we choose random key k and give E(k,x) and real random permutation Perm(X) to let adversary decide which is which.

Block cipher constructions: Feistel network

Forward network:

Feistel network

  • Forward (round i): given (L_{i-1}, R_{i-1}) \in \{0,1\}^n \times \{0,1\}^n,

    • L_i = R_{i-1}
    • R_i = L_{i-1} \oplus f_i(R_{i-1})

  • Proof (construct the inverse):

    • Suppose we are given the output of round i, namely (L_i, R_i).
    • Recover the previous right half immediately:
      • R_{i-1} = L_i
    • Then recover the previous left half by undoing the XOR:
      • L_{i-1} = R_i \oplus f_i(R_{i-1}) = R_i \oplus f_i(L_i)
    • Therefore each round map is invertible, with inverse transformation:
      • R_{i-1} = L_i
      • L_{i-1} = f_i(L_i) \oplus R_i
    • Applying this inverse for i=d,d-1,\ldots,1 recovers (L_0,R_0) from (L_d,R_d), so the whole Feistel network F is invertible.

  • Notation sketch (each wire is n bits):

    • Input: (L_0, R_0)
    • Rounds:
      • L_1 = R_0,\ \ R_1 = L_0 \oplus f_1(R_0)
      • L_2 = R_1,\ \ R_2 = L_1 \oplus f_2(R_1)
      • \cdots
      • L_d = R_{d-1},\ \ R_d = L_{d-1} \oplus f_d(R_{d-1})
    • Output: (L_d, R_d)

Hash functions

Asymmetric key cryptography

Appendix for additional algorithms and methods

Feistel network (used by several items below)

A *Feistel network- splits a block into left/right halves and iterates rounds of the form (L_{i+1},R_{i+1})=(R_i, L_i\oplus F(R_i,K_i)), so decryption reuses the same structure with subkeys in reverse order.

Feistel-based here: DES, 3DES, CAMELLIA, SEED, GOST 28147-89 (and thus GOST89MAC uses a Feistel block cipher internally).

A) Cipherlist *filters / set operations- (not crypto primitives)

These don’t implement encryption or authentication; they just include/exclude suites.

  • *COMPLEMENTOFDEFAULT- — (selection) picks suites in ALL that are not enabled by default (notably RC4/anonymous, depending on build).
  • *ALL- — (selection) all suites except eNULL, in a default preference order (OpenSSL-defined ordering).
  • *COMPLEMENTOFALL- — (selection) suites excluded from ALL (currently eNULL).
  • *HIGH / MEDIUM / LOW- — (selection) groups suites by effective key strength class (OpenSSL policy buckets).
  • *TLSv1.2 / TLSv1.0 / SSLv3- — (selection) restricts to suites whose *minimum supported protocol version- is at least that value.
  • *SUITEB128 / SUITEB128ONLY / SUITEB192- — (selection) enforces “Suite B”-style constraints: only very specific ECDHE-ECDSA-AES-GCM suites and curves/hashes.
  • *CBC- — (mode selector) selects suites using *CBC mode- for symmetric encryption (confidentiality only unless paired with a MAC).

B) “No encryption” / “no authentication” flags

  • *eNULL, NULL- — encryption/decryption: none; cipher method: N/A; core idea: the record payload is not encrypted at all (plaintext).
  • *aNULL- — *authentication: none- (no peer authentication); cipher method: N/A; core idea: uses anonymous key agreement (no cert/signature), enabling MITM.
  • *ADH / AECDH- — authentication: none; cipher method: N/A; core idea: anonymous (EC)DH establishes a shared secret but without identity binding → MITM-friendly.

C) Key exchange and authentication selectors (not symmetric encryption, not MAC)

These describe *how keys are negotiated- and/or how the peer is authenticated, not whether payload is a block/stream cipher.

RSA / DH / ECDH families

  • *kRSA, RSA- — (key exchange) the premaster secret is sent encrypted under the server’s RSA public key (classic TLS RSA KX).
  • *aRSA, aECDSA, aDSS, aGOST, aGOST01- — (authentication) the server identity is proven via a certificate signature scheme (RSA / ECDSA / DSA / GOST).
  • *kDHr, kDHd, kDH- — (key exchange) *static- DH key agreement using DH certificates (obsolete/removed in newer OpenSSL).
  • *kDHE, kEDH, DH / DHE, EDH / ECDHE, EECDH / kEECDH, kECDHE, ECDH- — (key exchange) *ephemeral- (EC)DH derives a fresh shared secret each handshake; “authenticated” variants bind it to a cert/signature.
  • *aDH- — (authentication selector) indicates DH-authenticated suites (DH certs; also removed in newer OpenSSL).

PSK family

  • *PSK- — (keying model) uses a pre-shared secret as the authentication/secret basis.
  • *kPSK, kECDHEPSK, kDHEPSK, kRSAPSK- — (key exchange) PSK combined with (EC)DHE or RSA to derive/transport session keys.
  • *aPSK- — (authentication) PSK itself authenticates endpoints (except RSA_PSK where cert auth may be involved).

D) Symmetric encryption / AEAD (this is where “block vs stream” applies)

AES family

  • *AES128 / AES256 / AES- — encryption/decryption; block cipher; core algorithm: AES is an SPN (substitution–permutation network) of repeated SubBytes/ShiftRows/MixColumns/AddRoundKey rounds.
  • *AESGCM- — both encryption + message authentication (AEAD); *both- (AES block cipher used in counter mode + auth); core algorithm: encrypt with AES-CTR and authenticate with GHASH over ciphertext/AAD to produce a tag.
  • *AESCCM / AESCCM8- — both encryption + message authentication (AEAD); both; core algorithm: compute CBC-MAC then encrypt with CTR mode, with 16-byte vs 8-byte tag length variants.

ARIA family

  • *ARIA128 / ARIA256 / ARIA- — encryption/decryption; block cipher; core algorithm: ARIA is an SPN-style block cipher with byte-wise substitutions and diffusion layers across rounds.

CAMELLIA family

  • *CAMELLIA128 / CAMELLIA256 / CAMELLIA- — encryption/decryption; block cipher; core algorithm: Camellia is a *Feistel network- with round functions plus extra FL/FL$^{-1}$ layers for nonlinearity and diffusion. (Feistel: yes)

ChaCha20

  • *CHACHA20- — encryption/decryption; stream cipher; core algorithm: ChaCha20 generates a keystream via repeated ARX (add-rotate-xor) quarter-rounds on a 512-bit state and XORs it with plaintext.

DES / 3DES

  • *DES- — encryption/decryption; block cipher; core algorithm: DES is a 16-round *Feistel network- using expansion, S-boxes, and permutations. (Feistel: yes)
  • *3DES- — encryption/decryption; block cipher; core algorithm: applies DES three times (EDE or EEE) to increase effective security while retaining the *Feistel- DES core. (Feistel: yes)

RC4

  • *RC4- — encryption/decryption; stream cipher; core algorithm: maintains a 256-byte permutation and produces a keystream byte-by-byte that is XORed with plaintext.

RC2 / IDEA / SEED

  • *RC2- — encryption/decryption; block cipher; core algorithm: mixes key-dependent operations (adds, XORs, rotates) across rounds with “mix” and “mash” steps (not Feistel).
  • *IDEA- — encryption/decryption; block cipher; core algorithm: combines modular addition, modular multiplication, and XOR in a Lai–Massey-like structure to achieve diffusion/nonlinearity (not Feistel).
  • *SEED- — encryption/decryption; block cipher; core algorithm: a 16-round *Feistel network- with nonlinear S-box-based round functions. (Feistel: yes)

E) Hash / MAC / digest selectors (message authentication side)

These are not “ciphers” but are used for integrity/authentication (often as HMAC, PRF, signatures).

  • *MD5- — *message authentication component- (typically via HMAC, historically); cipher method: N/A; core algorithm: iterated Merkle–Damgård hash compressing 512-bit blocks into a 128-bit digest (now considered broken for collision resistance).
  • *SHA1, SHA- — *message authentication component- (typically HMAC-SHA1 historically); N/A; core algorithm: Merkle–Damgård hash producing 160-bit output via 80-step compression (collisions known).
  • *SHA256 / SHA384- — *message authentication component- (HMAC / TLS PRF / signatures); N/A; core algorithm: SHA-2 family Merkle–Damgård hashes with different word sizes/output lengths (256-bit vs 384-bit).
  • *GOST94- — *message authentication component- (HMAC based on GOST R 34.11-94); N/A; core algorithm: builds an HMAC tag by hashing inner/outer padded key with the message using the GOST hash.
  • *GOST89MAC- — message authentication; block-cipher-based MAC (so “block” internally); core algorithm: computes a MAC using the GOST 28147-89 block cipher in a MAC mode (cipher-based chaining). (Feistel internally via GOST 28147-89)