Update CSE4303_E1.md

content/CSE4303/CSE4303_E1.md

@@ -6,7 +6,7 @@ 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
+    - One 8.5" X 11" paper of notes, single-sided only, typed or hand-written
 
 Topics covered:
 
@@ -170,7 +170,7 @@ 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.
+encryption algorithm E that outputs a **ciphertext** C for M.
 
 #### Cryptography goals
 
@@ -234,7 +234,7 @@ In practice, relax this assumption gets "Stream ciphers"
 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
+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
@@ -302,15 +302,269 @@ Forward network:
     - $L_d = R_{d-1},\ \ R_d = L_{d-1} \oplus f_d(R_{d-1})$
   - Output: $(L_d, R_d)$
 
+#### Block ciphers: block modes: ECB
+
+New attacker model for multi-use keys (e.g. multiple blocks): CPA (Chosen Plaintext)-capable, not just CT-only
+
+- Attacker sees many PT/CT pairs for same key
+- Conservative model: attacker submits arbitrary PT (hence "C"PA)
+- Cipher goal: maintain semantic security against CPA
+
+#### CPA indistinguishability game
+
+- Updated adversarial game for a CPA attacker:
+  - Let $E = (E, D)$ be a cipher defined over $(K, M, C)$. For $b \in \{0,1\}$ define $\operatorname{EXP}(b)$ as:
+
+- Experiment $\operatorname{EXP}(b)$:
+  - Challenger samples $k \leftarrow K$.
+  - For each query $i = 1,\ldots,q$:
+    - Adversary outputs messages $m_{i,0}, m_{i,1} \in M$ such that $|m_{i,0}| = |m_{i,1}|$.
+    - Challenger returns $c_i \leftarrow E(k, m_{i,b})$.
+
+- Encryption-oracle access (CPA):
+  - If the adversary wants $c = E(k, m)$, it queries with $m_{j,0} = m_{j,1} = m$ (so the response is $E(k,m)$ regardless of $b$).
+
+#### Semantic security under CPA
+
+- Def: $E$ is semantically secure under CPA if for all "efficient" adversaries $A$,
+  - $\operatorname{Adv}^{\operatorname{CPA}}[A,E] = \left|\Pr[\operatorname{EXP}(0)=1] - \Pr[\operatorname{EXP}(1)=1]\right|$
+  - is negligible.
+
+### Summary for symmetric encrption
+
+1. Stream ciphers
+   - Rely on secure PRG
+   - No key re-use
+   - Fast, low-mem, less robust
+2. Block ciphers
+   - Rely on secure PRP
+   - Allow key re-use (usually only across blocks, not sessions)
+   - Provide authenticated encryption in some modes (e.g. GCM)
+   - Slower, higher-mem, more robust
+   - Used in practice for most crypto tasks (including secure network channels)
+
 ## Hash functions
 
+### Hash function security properties
+
+- Given a function $h:X \to Y$, we say that $h$ is:
+
+- 1. Preimage resistant (one-way) if:
+  - given $y \in Y$ it is computationally infeasible to find a value $x \in X$ s.t. $h(x) = y$
+
+- 2. 2nd preimage resistant (weak collision resistant) if:
+  - given a specific $x \in X$ it is computationally infeasible to find a value $x' \in X$ s.t. $x' \ne x$ and $h(x') = h(x)$
+
+- 3. Collision resistant (strong collision resistant) if:
+  - it is computationally infeasible to find any two distinct values $x', x \in X$ s.t. $h(x') = h(x)$
+
+### Collision resistance: adversarial definition
+
+- Let $H: M \to T$ be a hash function ($|M| \gg |T|$).
+- A function $H$ is collision resistant if for all (explicit) "efficient" algorithms $A$,
+  - $\operatorname{Adv}^{\operatorname{CR}}[A,H] = Pr[$A outputs a collision for $H$ $]$
+  - is negligible
+
+### Hash function integrity applications
+
+1. Delayed knowledge verification
+2. Password storage
+3. Trusted timestamping / blockchains
+4. Integrity check on software
+
 ## Asymmetric key cryptography
 
+## Asymmetric crypto overview
+
+- Parties: sender, recipient, attacker (eavesdropping)
+- Goal: sender encrypts a plaintext to a ciphertext using a public key; recipient decrypts using a private key.
+
+#### Public-key encryption system
+- Def: a public-key encryption system is a triple of algorithms $(G, E, D)$:
+  - $G()$: randomized algorithm that outputs a key pair $(pk, sk)$
+  - $E(pk, m)$: randomized algorithm that takes $m \in M$ and outputs $c \in C$
+  - $D(sk, c)$: deterministic algorithm that takes $c \in C$ and outputs $m \in M$ or $\bot$
+- Consistency: for all $(pk, sk)$ output by $G$, for all $m \in M$,
+  - $D(sk, E(pk, m)) = m$
+
+## Public-key building block: trapdoor function
+
+#### Trapdoor function
+- Def: a trapdoor function $X \to Y$ is a triple of efficient algorithms $(G, F, F^{-1})$:
+  - $G()$: randomized algorithm that outputs a key pair $(pk, sk)$
+  - $F(pk, \cdot)$: deterministic algorithm that defines a function $X \to Y$
+  - $F^{-1}(sk, \cdot)$: defines a function $Y \to X$ that inverts $F(pk, \cdot)$
+- More precisely: for all $(pk, sk)$ output by $G$, for all $x \in X$,
+  - $F^{-1}(sk, F(pk, x)) = x$
+
+## Symmetric vs. asymmetric security: attacker models
+
+- Symmetric ciphers: two security notions for a passive attacker
+  - One-time security (stream ciphers: ciphertext-only)
+  - Many-time security (block ciphers: CPA)
+  - One-time security $\Rightarrow$ many-time security
+  - Example: ECB mode is one-time secure but not many-time secure
+- Public-key encryption: single notion for a passive attacker
+  - Attacker can encrypt by themselves using the public key
+  - Therefore one-time security $\Rightarrow$ many-time security (CPA)
+  - Implication: public-key encryption must be randomized
+  - Analogous to secure block modes for block ciphers
+
+## Semantic security of asymmetric crypto (IND-CPA)
+
+#### IND-CPA game for public-key encryption
+- For $b \in \{0,1\}$ define experiments $\mathrm{EXP}(0)$ and $\mathrm{EXP}(1)$:
+
+- Experiment $\mathrm{EXP}(b)$:
+  - Challenger runs $(pk, sk) \leftarrow G()$
+  - Challenger sends $pk$ to adversary $A$
+  - Adversary outputs $m_0, m_1 \in M$ such that $|m_0| = |m_1|$
+  - Challenger returns $c \leftarrow E(pk, m_b)$
+  - Adversary outputs a bit $b' \in \{0,1\}$ (often modeled as outputting 1 if it "guesses $b=1$")
+
+#### Semantic security (IND-CPA)
+- Def: $E = (G, E, D)$ is semantically secure (a.k.a. IND-CPA) if for all efficient adversaries $A$,
+  - $\mathrm{Adv}^{\mathrm{SS}}[A, E] = \left|\Pr[\mathrm{EXP}(0)=1] - \Pr[\mathrm{EXP}(1)=1]\right|$
+  - is negligible
+- Note: inherently multiple-round because the attacker can always encrypt on their own using $pk$ (CPA power is "built in").
+
+## RSA cryptosystem: overview
+
+- Setup:
+  - $n = pq$, with $p$ and $q$ primes
+  - Choose $e$ relatively prime to $\phi(n) = (p-1)(q-1)$
+  - Choose $d$ as the inverse of $e$ in $\mathbb{Z}_{\phi(n)}$
+- Keys:
+  - Public key: $K_E = (n, e)$
+  - Private key: $K_D = d$
+- Encryption:
+  - Plaintext $M \in \mathbb{Z}_n$
+  - $C = M^e \bmod n$
+- Decryption:
+  - $M = C^d \bmod n$
+
+- Example:
+  - Setup:
+    - $p = 7$, $q = 17$
+    - $n = 7 \cdot 17 = 119$
+    - $\phi(n) = 6 \cdot 16 = 96$
+    - $e = 5$
+    - $d = 77$
+  - Keys:
+    - public key: $(119, 5)$
+    - private key: $77$
+  - Encryption:
+    - $M = 19$
+    - $C = 19^5 \bmod 119 = 66$
+  - Decryption:
+    - $M = 66^{77} \bmod 119 = 19$
+
+- Security intuition:
+  - To invert RSA without $d$, attacker must compute $x$ from $c = x^e \pmod n$.
+  - Best known approach:
+    - Step 1: factor $n$ (hard)
+    - Step 2: compute $e$-th roots modulo $p$ and $q$ (easy once factored)
+  - Notes (as commonly stated in lectures):
+    - 1024-bit RSA is within reach; 2048-bit is recommended usage
+
+## Diffie-Hellman key exchange (informal)
+
+- Fix a large prime $p$ (e.g., 2000 bits)
+- Fix an integer $g \in \{1,\ldots,p\}$
+
+- Protocol:
+  - Alice chooses random $a \in \{1,\ldots,p-1\}$ and sends $A = g^a \bmod p$
+  - Bob chooses random $b \in \{1,\ldots,p-1\}$ and sends $B = g^b \bmod p$
+  - Shared key:
+    - Alice computes $k_{AB} = B^a \bmod p = g^{ab} \bmod p$
+    - Bob computes $k_{AB} = A^b \bmod p = g^{ab} \bmod p$
+
+- Hardness assumptions:
+  - Discrete log problem: given $p, g, y = g^x \bmod p$, find $x$
+  - Diffie-Hellman function: $\mathrm{DH}_g(g^a, g^b) = g^{ab} \bmod p$
+
+## Diffie-Hellman: security notes
+
+- As described, the protocol is insecure against active attacks:
+  - A man-in-the-middle (MiTM) can insert themselves and create 2 separate secure sessions
+- Fix idea: need a way to bind identity to a public key
+  - In practice: web of trust (e.g., GPG) or Public Key Infrastructure (PKI)
+
+## Implementing trapdoor functions securely
+
+- Never encrypt by applying $F$ directly to plaintext:
+  - Deterministic: cannot be semantically secure
+  - Many attacks exist for concrete TDFs
+  - Same plaintext blocks yield same ciphertext blocks
+
+- Naive (insecure) sketch:
+  - $E(pk, m)$: output $c \leftarrow F(pk, m)$
+  - $D(sk, c)$: output $F^{-1}(sk, c)$
+
+## Public-key encryption from TDFs
+
+- Components:
+  - $(G, F, F^{-1})$: secure TDF $X \to Y$
+  - $(E_s, D_s)$: symmetric authenticated encryption over $(K, M, C)$
+  - $H: X \to K$: a hash function
+
+- Construction of $(G, E, D)$ (with $G$ same as in the TDF):
+  - $E(pk, m)$:
+    - sample $x \leftarrow X$, compute $y \leftarrow F(pk, x)$
+    - derive $k \leftarrow H(x)$, compute $c \leftarrow E_s(k, m)$
+    - output $(y, c)$
+  - $D(sk, (y, c))$:
+    - compute $x \leftarrow F^{-1}(sk, y)$
+    - derive $k \leftarrow H(x)$, compute $m \leftarrow D_s(k, c)$
+    - output $m$
+
+- Visual intuition:
+  - header: $y = F(pk, x)$
+  - body: $c = E_s(H(x), m)$
+
+- Security theorem (lecture-style statement):
+  - If $(G, F, F^{-1})$ is a secure TDF, $(E_s, D_s)$ provides authenticated encryption, and $H$ is modeled as a random oracle, then $(G, E, D)$ is CCA-secure in the random oracle model (often denoted CCA-RO).
+  - Extension exists to reach full CCA (outside the RO idealization).
+
+## Wrapup: symmetric vs. asymmetric systems
+
+- Symmetric: faster, but key distribution is hard
+- Asymmetric: slower, but key distribution/management is easier
+- Application: secure web sessions (e.g., online shopping)
+  - Use symmetric-key encrypted sessions for bulk traffic
+  - Exchange symmetric keys using an asymmetric scheme
+  - Authenticate public keys (PKI or web of trust)
+
+## Key exchange: summary
+
+- Symmetric-key encryption challenges:
+  - Key storage: one per user pair, $O(n^2)$ total for $n$ users
+  - Key exchange: how to do it over a non-secure channel?
+
+- Possible solutions:
+
+- 1) Trusted Third Party (TTP)
+  - All users establish separate secret keys with the TTP
+  - TTP helps manage user-user keys (storage and secure channel)
+  - Applicability:
+    - Works for local domains
+    - Popular implementation: Kerberos for Single Sign On (SSO)
+  - Challenges:
+    - Scale: central authentication server is not suitable for the entire Internet
+    - Latency: requires online response from central server for every user-user session
+
+- 2) Public/private keys with certificates
+  - All users have a single stable public key (helps with key storage and exchange)
+  - Users exchange per-session symmetric keys via a secure channel using public/private keys
+  - Trusting public keys: binding is validated by a third-party authority (Certificate Authority, CA)
+    - Why better than TTP? CAs can validate statically by issuing certificates, then be uninvolved
+  - CA/certificate process covered in a future lecture
+
 ## 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.
+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).**
 
@@ -318,21 +572,21 @@ Feistel-based here: **DES, 3DES, CAMELLIA, SEED, GOST 28147-89 (and thus GOST89M
 
 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).
+- **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).
+- **ALL** — (selection) all suites except `eNULL`, in a default preference order (OpenSSL-defined ordering).
-- **COMPLEMENTOFALL*- — (selection) suites excluded from `ALL` (currently `eNULL`).
+- **COMPLEMENTOFALL** — (selection) suites excluded from `ALL` (currently `eNULL`).
-- **HIGH / MEDIUM / LOW*- — (selection) groups suites by effective key strength class (OpenSSL policy buckets).
+- **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.
+- **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.
+- **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).
+- **CBC** — (mode selector) selects suites using **CBC mode** for symmetric encryption (confidentiality only unless paired with a MAC).
 
 ---
 
-### B) “No encryption” / “no authentication” flags
+### 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).
+- **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.
+- **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.
+- **ADH / AECDH** — **authentication: none**; **cipher method: N/A**; core idea: anonymous (EC)DH establishes a shared secret but without identity binding → MITM-friendly.
 
 ---
 
@@ -342,63 +596,63 @@ These describe *how keys are negotiated- and/or *how the peer is authenticated*,
 
 #### 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).
+- **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).
+- **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).
+- **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.
+- **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).
+- **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.
+- **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.
+- **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).
+- **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)
+### 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.
+- **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.
+- **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.
+- **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.
+- **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)*
+- **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.
+- **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)*
+- **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)*
+- **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.
+- **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).
+- **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).
+- **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)*
+- **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).
+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).
+- **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).
+- **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).
+- **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.
+- **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)*
+- **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)*