Computer Security — Complete Concept Reference

Full content coverage for interview preparation — extended depth (your area
of specialization)

How to use this document

This one goes deeper than the AI, Networking, and OS references, deliberately. Security is
your actual research area, so the risk isn’t that you don’t know the material — it’s that an
interviewer who knows you’re a security researcher will push past the standard undergrad-
course questions into places where surface-level answers fall apart. This document covers
the full standard course arc (Parts 1–8) at the same rigor as your other references, then
adds an extended depth layer (Parts 9–12) specifically calibrated to where your background
invites harder questions: cryptographic foundations, systems/OS security, and the
differential-privacy / adversarial-ML territory that’s your actual research. Read start to finish
once, then use it to drill.

Part 1: Foundational Security Principles

1.1 The CIA Triad — the absolute foundation

Confidentiality: preventing unauthorized disclosure of information. Achieved primarily
through encryption and access control.

Integrity: preventing unauthorized modification of information, and being able to detect

if it happened. Achieved through hashing, checksums, digital signatures, and access
control.

Availability: ensuring authorized users can access information/systems when needed.

Threatened by attacks like DoS/DDoS, and protected via redundancy, backups, and
capacity planning.

A precise way to state “how to ensure confidentiality” (a question your seniors were
directly asked): confidentiality is enforced at two complementary levels — access control
(deciding who is allowed to see the data at all — authentication + authorization) and
encryption (making the data unreadable to anyone who bypasses access control or
intercepts it in transit/at rest). A complete answer mentions both layers, not just encryption
alone.

How to ensure confidentiality of files specifically in a system (also directly asked): file
permissions/ACLs (restricting which users/processes can read a file), encryption at rest (so
even someone with raw disk access can’t read the contents without the key), and audit
logging (detecting unauthorized access attempts after the fact, a deterrent/detective
control alongside the preventive ones).

1.2 Principles Beyond CIA (a direct follow-up your seniors were asked)
Authenticity: verifying that an entity (a message, a user, a device) is genuinely
who/what it claims to be — distinct from confidentiality, and covered in depth in 1.3
below since it’s a recurring point of confusion worth being crisp about.

Non-repudiation: ensuring that a party cannot later deny having performed an action
(e.g., sending a message, authorizing a transaction) — typically achieved via digital
signatures, since only the holder of a private key could have produced a valid signature,
giving cryptographic proof of origin.

Accountability: the ability to trace actions back to the responsible entity, typically
through logging and auditing — related to non-repudiation but broader (accountability is
about traceability in general, non-repudiation is specifically about undeniable proof).

Accuracy (sometimes listed as an extension of integrity): ensuring data isn’t just

unmodified, but was correct to begin with — a subtler point than pure integrity, which
only guarantees “unchanged since it was stored,” not “was originally correct.”

1.3 Confidentiality vs Authenticity — the exact distinction asked

This is a classic point of confusion, and precision here reads as genuine understanding:

Confidentiality answers: “can anyone unauthorized read this?” — the mechanism is

encryption, and the property is about secrecy.

Authenticity answers: “is this really from who it claims to be, and unaltered in transit?”
— the mechanism is typically a digital signature or MAC (Message Authentication Code),
and the property is about verifiable origin and integrity, not secrecy at all.

The key insight that trips people up: these are orthogonal properties. A message can
be authentic but not confidential (a digitally signed public announcement — anyone can
read it, but you can verify who really sent it). A message can be confidential but not
authentic (encrypted with a shared key, but without a signature, a recipient can’t be
certain who among key-holders actually sent it). Real systems (like TLS) provide both
simultaneously, but they are achieved through different mechanisms and must be
 reasoned about separately.

1.4 AAA Framework (Authentication, Authorization, Accounting) — a useful

organizing model if pushed further
Authentication: verifying identity (“who are you”) — passwords, biometrics, tokens,
certificates

Authorization: determining what an authenticated entity is permitted to do (“what are

you allowed to access”)

Accounting/Auditing: tracking what was actually done, for accountability and forensics

1.5 Defense in Depth

The principle that security shouldn’t rely on any single control — layer multiple independent
defenses (network firewalls, host-based protections, encryption, access control,
monitoring) so that a failure in one layer doesn’t lead to total compromise. A very natural
concept to invoke when asked “what else should you keep in mind besides CIA,” since it’s a
strategy principle rather than a property like CIA/authenticity/non-repudiation.

1.6 Principle of Least Privilege

Every user, process, or system component should have only the minimum access necessary
to perform its function, and no more — limits the damage any single compromised
component can cause, since it never had excessive access to begin with.

Part 2: Cryptography Fundamentals

2.1 Symmetric Key Encryption

Same key used for both encryption and decryption.

Examples: AES (Advanced Encryption Standard — the modern standard, operates on

128-bit blocks with 128/192/256-bit keys), DES (Data Encryption Standard — older, now
considered insecure due to its short 56-bit key being brute-forceable with modern
hardware), 3DES (an interim fix applying DES three times, since superseded by AES).

Advantages: computationally fast, efficient for large volumes of data.

Core problem — key distribution: both parties need the same secret key before secure
communication can begin, but how do you securely share that key in the first place
without an already-secure channel? This single problem motivates the entire existence
 of asymmetric cryptography (2.2) and key exchange protocols (2.4).

Modes of operation (worth knowing exist, since block ciphers like AES encrypt fixed-
size blocks and need a mode to handle arbitrary-length data): ECB (Electronic
Codebook — simplest but insecure for structured data since identical plaintext blocks
produce identical ciphertext blocks, leaking patterns), CBC (Cipher Block Chaining —
each block is XORed with the previous ciphertext block before encryption, removing the
pattern-leakage problem), and stream-cipher-like modes (CTR, GCM) used in modern
practice — GCM specifically is worth knowing by name since it provides both encryption
and authentication (an “authenticated encryption” mode) in one operation, which is
what modern TLS actually uses.

2.2 Asymmetric (Public-Key) Encryption

Uses a mathematically linked key pair: a public key (shared freely) and a private key
(kept secret). Data encrypted with one key of the pair can only be decrypted with the
other.

RSA (Rivest-Shamir-Adleman): the classic example — security rests on the

computational difficulty of factoring the product of two large prime numbers. Given the
product (part of the public key), finding the original primes (needed to derive the private
key) is computationally infeasible for sufficiently large keys with current classical
computing.

Working principle, precisely (the exact question asked): to send a confidential

message, the sender encrypts with the recipient’s public key; only the recipient’s
corresponding private key can decrypt it — since the private key never needs to be
transmitted or shared, this solves the key-distribution problem symmetric encryption
has. The reverse use — encrypting with your own private key — is what enables digital
signatures (Part 2.5), since anyone with your public key can verify it, proving it came
from you.

Elliptic Curve Cryptography (ECC): an alternative mathematical foundation (based on

the difficulty of the elliptic curve discrete logarithm problem rather than factoring) that
achieves equivalent security to RSA with much smaller key sizes — worth knowing by
name as the modern efficiency-motivated alternative to RSA, increasingly the default in
real systems (e.g., mobile, IoT) where computational/bandwidth resources are
constrained.

Why asymmetric encryption is much slower than symmetric: the underlying

mathematical operations (modular exponentiation on large numbers, elliptic curve point
operations) are inherently more computationally expensive than the bit-shuffling
operations symmetric ciphers use — this single fact is why hybrid encryption (2.3) exists
 at all.

2.3 Hybrid Encryption — how real systems actually work

Real-world protocols (TLS/HTTPS being the everyday example) don’t choose one or the
other — they combine both:

1. Use asymmetric encryption briefly, during an initial handshake, to securely establish a

shared secret (a session key) between two parties who’ve never communicated before.

2. Use that session key with symmetric encryption for the actual bulk data transfer, since
it’s vastly faster.

This is the single most important practical synthesis in applied cryptography: asymmetric
encryption solves the key-distribution problem but is slow; symmetric encryption is fast but
needs a pre-shared key; hybrid encryption uses each exactly where its strength matters and
its weakness doesn’t.

2.4 Key Exchange

Diffie-Hellman Key Exchange: allows two parties to jointly establish a shared secret
over a public (potentially eavesdropped) channel, without ever transmitting the secret
itself — relies on the computational difficulty of the discrete logarithm problem. Worth
knowing conceptually: each party combines their own private value with public
parameters and the other party’s public value, arriving at the same shared secret via a
mathematical property, while an eavesdropper who sees only the public exchanges
cannot feasibly compute that shared secret.

Forward secrecy (a valuable property worth knowing by name): a property of some key
exchange schemes (e.g., ephemeral Diffie-Hellman) where even if a long-term private
key is later compromised, past session keys (and thus past recorded traffic) remain
secure, since each session used a fresh, temporary key that’s now discarded and
unrecoverable.

2.5 Hashing
A one-way function that maps input of any size to a fixed-size output (a “digest” or
“hash”), designed so that: (1) it’s computationally infeasible to reverse (find the input
given the output), (2) a tiny change in input produces a drastically different output
(avalanche effect), and (3) it’s computationally infeasible to find two different inputs
producing the same output (collision resistance).

Examples: SHA-256 (part of the SHA-2 family, current widely-used standard), MD5 and
SHA-1 (both now considered cryptographically broken — collisions have been practically
 demonstrated for both, so they should not be used for security-critical purposes
anymore, though MD5 in particular still shows up for non-security checksumming).

Hashing vs Encryption — the precise distinction (a classic point of confusion worth

nailing): encryption is reversible by design (that’s the whole point — someone with the
right key gets the original data back); hashing is irreversible by design (there is no
“key” to undo it). They solve different problems: encryption protects confidentiality;
hashing verifies integrity (has this data changed?) and enables secure password
storage (store the hash, not the actual password — even if the database leaks, the
actual passwords aren’t directly exposed).

Salting: a random value added to a password before hashing, unique per user, stored
alongside the hash — defeats precomputed rainbow table attacks (attackers can’t use
a single precomputed table of common-password hashes, since every user’s hash is
now computed against a different salt even if their underlying password is identical to
another user’s).

Key stretching / slow hashing (bcrypt, scrypt, Argon2): password hashing specifically
should use algorithms deliberately designed to be slow (unlike SHA-256, which is fast —
a desirable property for general-purpose hashing but a liability for password hashing,
since fast hashing makes brute-force attacks cheaper for an attacker). Worth
mentioning if the conversation goes deep into password security specifically.

2.6 Digital Signatures

Combines asymmetric encryption and hashing: the sender computes a hash of the
message, then encrypts that hash with their private key — this encrypted hash is the
signature, attached to the message.

Verification: the recipient computes their own hash of the received message, decrypts
the attached signature using the sender’s public key, and checks whether the two
hashes match.

What a match proves: integrity (the message wasn’t altered — if it had been, the
recipient’s freshly computed hash wouldn’t match) and authenticity/non-repudiation
(only the holder of the corresponding private key could have produced a signature that
decrypts correctly with that public key — so it genuinely came from that party, and that
party cannot credibly deny having sent it).

Why hash first, rather than encrypting the whole message with the private key:
efficiency — asymmetric operations are slow (2.2), so signing a small fixed-size hash
rather than a potentially large message is far cheaper, while still cryptographically
binding the signature to the exact content of the message (since any change to the
message changes its hash).
2.7 Certificates and PKI (Public Key Infrastructure)
The trust problem digital signatures alone don’t solve: if you receive a public key,
how do you know it genuinely belongs to the entity it claims to belong to, and isn’t an
attacker’s key substituted in a man-in-the-middle attack? Certificates solve this.

Digital certificate: a data structure binding a public key to an identity (e.g., a domain
name), digitally signed by a trusted third party — a Certificate Authority (CA).

Chain of trust: your browser/OS comes pre-loaded with a set of trusted root CA public
keys. A website’s certificate is typically signed by an intermediate CA, whose own
certificate is signed by a root CA — verifying a certificate means following this chain up
to a trusted root, confirming each signature along the way.

This is the mechanism that makes HTTPS practically trustworthy: without PKI,
asymmetric encryption alone only guarantees someone can decrypt your message with
the corresponding private key — it says nothing about who that someone actually is.

Part 3: Authentication and Access Control

3.1 Authentication Factors

Something you know — passwords, PINs

Something you have — a hardware token, a phone (for SMS/app-based codes), a smart
card

Something you are — biometrics (fingerprint, facial recognition)

Multi-Factor Authentication (MFA): combining two or more of the above categories

significantly increases security, since compromising multiple independent factors is
much harder than compromising one — worth explicitly noting that using two passwords
is not MFA (both are “something you know”), a distinction interviewers sometimes
probe.

3.2 Password Security (brief, ties directly to 2.5’s salting/hashing content)

Never store plaintext passwords — always store a salted, slow-hashed digest (see 2.5).

Common attacks: brute force (trying all possible passwords), dictionary attack (trying
common/likely passwords), credential stuffing (trying username/password pairs leaked
from other breaches, exploiting password reuse across sites).

3.3 Access Control Models

 Discretionary Access Control (DAC): the owner of a resource decides who else can
access it (e.g., standard file permissions in most operating systems) — flexible, but
security depends on individual users making good decisions.

Mandatory Access Control (MAC): access is governed by a central, system-enforced

policy that individual users/owners cannot override (e.g., military/government
classification systems: Confidential, Secret, Top Secret) — stricter and more consistent,
but less flexible.

Role-Based Access Control (RBAC): access permissions are assigned to roles (e.g.,
“admin,” “editor,” “viewer”), and users are assigned to roles rather than having
permissions set individually — scales much better in organizations, since adding a new
user just means assigning them a role rather than configuring individual permissions
from scratch. This is the standard practical mechanism worth naming for “how would
you control access to a database,” ties directly to the database security topic in Part 6.

3.4 Authorization Concepts

Access Control List (ACL): a list attached to a resource specifying exactly which
users/entities have which permissions on it.

Principle of least privilege (recap from 1.6, since it’s fundamentally an access-control
principle): grant only the minimum necessary permissions.

Part 4: Network Security

(This section deliberately keeps overlap with the standalone Networking reference brief —
full mechanics live there. Here the focus is the security-specific framing and attacks.)

4.1 Firewalls
A system that monitors and filters network traffic based on defined rules, sitting at a
network boundary.

Packet-filtering firewalls: inspect individual packets against rules (source/destination

IP, port, protocol) without tracking connection state — fast but limited.

Stateful firewalls: track the state of active connections, allowing more intelligent rules
(e.g., only allow inbound traffic that’s a response to an outbound request already
permitted) — the modern standard.

Application-layer (proxy) firewalls: inspect traffic at the application layer (e.g.,

understanding HTTP specifically), allowing much more granular filtering, at the cost of
 more processing overhead.

4.2 VPN (Virtual Private Network)

Creates an encrypted tunnel over a public network (typically the internet), allowing
traffic to traverse untrusted networks as if on a private, secure network — protects
confidentiality and integrity of traffic between endpoints, commonly used for remote
access to internal networks or to prevent eavesdropping on untrusted networks (e.g.,
public WiFi).

4.3 IDS/IPS (Intrusion Detection/Prevention Systems)

IDS (Intrusion Detection System): monitors network/system activity for signs of
malicious behavior and alerts administrators — passive, doesn’t block anything itself.

IPS (Intrusion Prevention System): does the same monitoring but can actively block
detected threats in real time — active, sits inline with traffic.

Signature-based detection: matches traffic against known attack patterns (fast, low
false-positive rate, but can’t catch novel/unknown attacks).

Anomaly-based detection: builds a baseline of “normal” behavior and flags deviations

— can catch novel attacks, but at the cost of a higher false-positive rate.

4.4 Common Network Attacks (deeper than the Networking reference’s brief
treatment)
Man-in-the-Middle (MITM): an attacker secretly intercepts (and potentially modifies)
communication between two parties who believe they’re communicating directly —
HTTPS/TLS with proper certificate validation is specifically designed to prevent this.

DoS/DDoS (Denial of Service / Distributed DoS): overwhelming a target’s resources

(bandwidth, connection slots, processing capacity) to make it unavailable to legitimate
users — DDoS specifically uses many distributed sources (often a botnet of
compromised machines), making it much harder to block via simple source-IP filtering
than a single-source DoS.

Spoofing: falsifying source information to impersonate a trusted entity — IP spoofing

(forging the source IP address of packets), ARP spoofing (sending falsified ARP
messages to associate an attacker’s MAC address with a legitimate IP on the local
network, enabling MITM on a LAN), DNS spoofing/cache poisoning (corrupting DNS
resolution to redirect victims to malicious servers).

Session hijacking: an attacker steals or predicts a valid session token/identifier to

impersonate an authenticated user without needing their actual credentials.
 Packet sniffing/eavesdropping: passively capturing network traffic to extract sensitive
information — the direct motivation for encrypting traffic (HTTPS, VPNs) rather than
relying on network-level access restriction alone, since any traffic on a
shared/compromised segment can potentially be captured.

Part 5: Application and Web Security

5.1 SQL Injection

Occurs when untrusted user input is directly concatenated into a SQL query string
without sanitization, allowing an attacker to inject malicious SQL logic (e.g., entering '
OR '1'='1 into a login field to bypass authentication logic, or appending a DROP TABLE
command).

Defense: parameterized queries / prepared statements — the query structure is

defined separately from the input values, so user input is always treated strictly as data,
never as executable query logic, regardless of what characters it contains. Input
validation/sanitization is a secondary, defense-in-depth layer, not a substitute for
parameterized queries.

5.2 Cross-Site Scripting (XSS)

Occurs when an application includes untrusted user input in a web page without proper
escaping, allowing an attacker to inject malicious client-side scripts that execute in
other users’ browsers.

Stored XSS: malicious script is permanently stored (e.g., in a database, via a comment
field) and served to every user who views the affected page.

Reflected XSS: malicious script is included in a request (e.g., a crafted URL) and
immediately reflected back in the response, typically requiring a victim to click a
malicious link.

Defense: proper output encoding/escaping of user-supplied content before rendering it

in HTML, and Content Security Policy (CSP) headers restricting what scripts can
execute.

5.3 Cross-Site Request Forgery (CSRF)

Tricks a victim’s browser into making an unwanted authenticated request to a site the
victim is currently logged into, exploiting the fact that browsers automatically attach
cookies/session credentials to requests regardless of which site initiated them.
 Defense: CSRF tokens (a unique, unpredictable value included in legitimate
forms/requests that an attacker’s forged request wouldn’t have) and checking request
origin headers.

5.4 Buffer Overflow

Occurs when a program writes more data to a fixed-size memory buffer than it can hold,
overwriting adjacent memory — in the worst case, an attacker can craft input that
overwrites a function’s return address on the stack, redirecting execution to attacker-
controlled code.

Why this is historically significant: one of the oldest and most impactful classes of
vulnerabilities, particularly in languages like C/C++ that don’t perform automatic bounds
checking.

Defenses: bounds checking (built into memory-safe languages), stack canaries (a

known value placed before the return address that’s checked before the function
returns — if overwritten, an overflow is detected and execution halted), ASLR (Address
Space Layout Randomization) (randomizing memory layout each run, making it much
harder for an attacker to reliably predict where their injected code/target address will
end up), and DEP/NX (Data Execution Prevention) (marking memory regions as non-
executable, preventing injected code in a data region from being run as code at all).

5.5 Other Application-Layer Concepts (brief)

Input validation: the general principle of never trusting user input, validating
format/type/range before processing — the first line of defense underlying most of the
specific attacks above.

Phishing: not a purely technical attack, but a social-engineering technique tricking

users into revealing credentials or installing malware via deceptive communication (fake
emails, fake login pages) — worth naming as a reminder that security isn’t purely a
technical problem; the human element is frequently the weakest link.

Part 6: Database Security

6.1 Should You Encrypt Database Entries? (the exact question asked)
This is genuinely a tradeoff question, not a yes/no — a strong answer weighs both sides:

Arguments for encrypting: protects data even if the database itself is breached/stolen
(defense against an attacker who gets past access controls entirely); required for
 regulatory compliance in many contexts (health data, financial data); protects against
insider threats with raw database access.

Arguments against/complicating factors: performance overhead

(encryption/decryption on every read/write); key management complexity (where is
the encryption key stored, and how is that protected — encrypting data just moves the
trust problem to protecting the key); breaks or complicates indexing and searching on
encrypted fields (you generally can’t efficiently run a SQL WHERE clause or range query
directly against ciphertext without specialized techniques).

A nuanced real answer: selective/field-level encryption for genuinely sensitive fields

(passwords — via hashing, not reversible encryption; SSNs; payment info) rather than
blanket full-database encryption, combined with strong access control as the primary
defense layer and encryption as defense-in-depth for the most sensitive data
specifically. This is exactly the kind of “it depends, here’s how I’d reason about it”
answer that reads as real expertise rather than a memorized rule.

6.2 Database-Specific Defenses

SQL Injection — covered in 5.1, but worth remembering as fundamentally a database
security issue surfacing through the application layer, a good example of how these
categories overlap in practice rather than being cleanly separate.

Least privilege for database accounts: application database accounts should have
only the specific permissions they need (e.g., a web app’s account shouldn’t have DROP
TABLE privileges even if a human admin account does).

Encryption in transit: connections between application and database servers should

themselves be encrypted (e.g., TLS), independent of whether data at rest is encrypted
— protects against network-level eavesdropping on database traffic.

Part 7: Malware and Threats

7.1 Malware Categories

Virus: malicious code that attaches itself to a legitimate program/file and requires that
host to execute and spread — needs some form of user action (running the infected
program) to propagate.

Worm: self-replicating malware that spreads autonomously across networks without

needing to attach to a host program or requiring user action — the self-propagation
without a host is the key distinguishing feature from a virus.
 Trojan (Trojan Horse): malware disguised as legitimate software, tricking the user into
installing it voluntarily — does not self-replicate, relies entirely on deception.

Ransomware: encrypts a victim’s data and demands payment for the decryption key —
a direct attack on availability (and implicitly confidentiality/integrity, depending on
whether data is also exfiltrated).

Spyware: covertly monitors and collects user information/activity without consent.

Rootkit: malware designed to gain and maintain privileged (root/administrator) access

to a system while actively concealing its own presence from detection.

Botnet: a network of compromised machines (“bots” or “zombies”) controlled remotely

by an attacker, commonly used to conduct large-scale DDoS attacks or distributed
spam/credential-stuffing campaigns.

7.2 Social Engineering

The broader category of attacks that exploit human psychology rather than technical
vulnerabilities — phishing (deceptive communication to extract credentials/info),
pretexting (fabricating a scenario to justify a request for information), baiting (offering
something enticing to lure a victim into a trap, e.g., an infected USB drive left where a
target will find and use it).

Worth explicitly noting in any broader security discussion: technical controls

(encryption, access control, firewalls) don’t protect against a user being socially
manipulated into voluntarily handing over access — this is a genuinely different threat
category requiring different defenses (training, verification procedures) rather than
purely technical fixes.

7.3 Zero-Day Vulnerabilities

A vulnerability that is unknown to the vendor/defenders (and thus unpatched) at the
time it’s discovered/exploited — “zero-day” refers to the vendor having had zero days to
fix it before exploitation began. Particularly dangerous because signature-based
defenses (4.3) that rely on known attack patterns are ineffective against them by
definition.

Part 8: Security Design Principles and Frameworks (brief)

Security by design: building security in from the start of a system’s design, rather than
adding it as an afterthought — retrofitting security is almost always more expensive and
less effective than designing for it from the beginning.
 Fail securely: when a system fails, it should default to a secure state (e.g., a failed
authentication check should default to denying access, not granting it) — a subtle but
critical design principle, since the failure mode of a system is often overlooked
compared to its normal operation.

Economy of mechanism: keep security-critical systems as simple as possible —

complexity is the enemy of security, since more complexity means more surface area for
bugs/vulnerabilities and makes correctness harder to verify.

Open design (Kerckhoffs’s principle): a cryptographic system should be secure even

if everything about the system, except the key, is public knowledge — security should
never rely on the secrecy of the algorithm itself (“security through obscurity” is explicitly
not a sound security principle), only on the secrecy of the key. Worth having ready, since
it’s a classic, foundational principle that connects directly back to why open, peer-
reviewed algorithms like AES and RSA are trusted precisely because their design is
public and has withstood open scrutiny.

Part 9 (Extended Depth): Cryptography Beyond the Basics

This is where the doubled effort starts — content unlikely to be asked of a typical candidate,
but exactly the territory a security-research-aware interviewer might probe you on
specifically.

9.1 Homomorphic Encryption — deep dive (directly asked, but worth going
further than the direct answer)
Main feature (the direct answer to what was asked): the ability to perform computations
directly on encrypted data and obtain an encrypted result that, when decrypted,
matches the result of performing the same computation on the plaintext — without the
computing party ever needing to see the actual unencrypted data.

Why this matters: enables secure computation/outsourcing — e.g., a cloud provider

can perform analysis on a client’s sensitive data without ever having access to the
underlying plaintext, which is a fundamentally different trust model than standard
encryption (where data must be decrypted before it can be computed on).

Levels of homomorphic encryption (worth knowing the distinction, since

“homomorphic encryption” isn’t monolithic):

Partially Homomorphic Encryption (PHE): supports only one type of operation on

ciphertexts (either addition or multiplication, not both) an unlimited number of times
— e.g., RSA is multiplicatively homomorphic, Paillier is additively homomorphic.
 Somewhat Homomorphic Encryption (SHE): supports both addition and
multiplication, but only up to a limited number of operations before noise
accumulation makes decryption fail.

Fully Homomorphic Encryption (FHE): supports arbitrary computation (unlimited

additions and multiplications), achieved via a bootstrapping technique that
periodically “refreshes” ciphertext noise — a landmark result (Craig Gentry, 2009)
that was previously an open problem.

Practical caveat worth mentioning: FHE is still computationally very expensive

compared to plaintext computation, which is the main barrier to widespread real-
world deployment despite being theoretically solved — a genuinely honest,
research-aware point to make if pushed on “why isn’t this used everywhere already.”

9.2 Differential Privacy — deep dive (directly connects to your thesis, be

ready to go further than the standard course depth)
Core idea: a formal, mathematical guarantee that the presence or absence of any single
individual’s data in a dataset has a bounded, quantifiable effect on the output of any
analysis/query performed on that dataset — meaning an observer of the output cannot
confidently determine whether any specific individual’s data was included, even with
significant auxiliary knowledge.

Mechanism: typically achieved by adding calibrated random noise to query results

(e.g., via the Laplace mechanism or Gaussian mechanism), where the amount of
noise is calibrated to the query’s sensitivity (how much a single individual’s data could
possibly change the result) and a privacy budget parameter ε (epsilon).

The epsilon (ε) privacy budget: smaller ε means stronger privacy guarantee (more
noise, less accurate results) — this is the fundamental privacy-utility tradeoff that’s
the central tension in the entire field, worth naming explicitly since it’s the first thing a
knowledgeable interviewer would probe.

Why you’d choose Differential Privacy over alternatives (the exact question asked,
and worth having a genuinely sharp, defensible answer for, since it’s your own research
territory):

vs k-anonymity: k-anonymity (ensuring each record is indistinguishable from at

least k-1 others on quasi-identifying attributes) is vulnerable to auxiliary-information
attacks and composition attacks (combining multiple k-anonymous releases can still
deanonymize), and provides no formal mathematical guarantee against a determined
adversary with background knowledge — DP provides a provable, composable
guarantee regardless of what auxiliary information an adversary has.
 vs pure encryption/access control: encryption protects data in transit or at rest
from unauthorized parties, but does nothing once a party is authorized to run
queries/analyses on the data — DP specifically protects against privacy leakage
through the legitimate outputs of authorized analysis, a fundamentally different
threat model than encryption addresses.

vs data anonymization/redaction generally: naive anonymization (removing

names/IDs) has repeatedly been shown to be reversible via linkage with other
datasets (the famous Netflix Prize and AOL search log de-anonymization cases are
the standard citable examples) — DP’s guarantee holds even against an adversary
with unbounded auxiliary data, which naive anonymization fundamentally cannot
promise.

Composability: a genuinely valuable property of DP worth mentioning — multiple

differentially private analyses can be combined, with a predictable, quantifiable
degradation of the overall privacy guarantee (the privacy budgets simply add up under
basic composition) — this makes it possible to reason rigorously about privacy loss
across a sequence of queries or across an entire system, which ad-hoc anonymization
techniques cannot offer.

Connection to Federated Learning (directly relevant to your DriftGhost/FL research):

differential privacy is commonly applied in federated learning contexts by adding noise
to gradient updates before they’re shared with a central aggregator, protecting against
attacks that attempt to reconstruct individual training examples from shared gradients
(a genuine, demonstrated vulnerability in naive FL) — this is a strong, specific example
to have ready if the conversation moves toward “how does this connect to your own
work.”

9.3 Secure Multi-Party Computation (MPC) — brief but worth knowing by

name
Allows multiple parties, each holding private input, to jointly compute a function over
their combined inputs without any party revealing their individual input to the others —
related to but distinct from homomorphic encryption (which involves one party
computing on encrypted data; MPC involves multiple parties jointly computing without
any single party seeing all the raw inputs). Worth a one-sentence definition if the
conversation moves into “other approaches to privacy-preserving computation” beyond
DP and HE specifically.

9.4 Adversarial Machine Learning — directly your research territory, but

worth the general-course framing too
Since this could come up framed generically (not assuming the interviewer knows your
specific thesis), have the general vocabulary ready:

Adversarial examples: inputs deliberately crafted with small, often human-

imperceptible perturbations designed to cause a machine learning model to misclassify
them — reveals that model decision boundaries can be exploited in ways that don’t
correspond to genuine semantic changes.

Evasion attacks: attacks that craft adversarial inputs at inference time to fool an
already-trained model (e.g., adversarial examples).

Poisoning attacks: attacks that corrupt the training data/process itself, causing the
resulting model to behave incorrectly or maliciously — directly relevant to your
Byzantine-attack research territory in federated learning, where malicious participants
can poison the shared model via corrupted local updates.

Byzantine attacks in distributed/federated settings (your specific research area):

malicious participants in a distributed system (like federated learning) that behave
arbitrarily/maliciously rather than simply failing — named after the Byzantine Generals
Problem in distributed systems theory, where the challenge is reaching reliable
consensus/agreement despite some participants being actively adversarial rather than
just faulty.

Defense concepts: adversarial training (training on adversarial examples to improve

robustness), robust aggregation (e.g., Byzantine-robust aggregation rules like Krum or
trimmed-mean, directly relevant to your DriftGhost defense work), and certified
defenses (providing provable robustness guarantees within a bounded perturbation
range).

Part 10 (Extended Depth): Systems and OS-Level Security

10.1 Privilege Levels and Isolation

Sandboxing: running untrusted or potentially risky code in an isolated environment with
restricted access to system resources, limiting the damage it can do even if
compromised or malicious.

Virtualization as a security boundary: hypervisors isolate virtual machines from each

other, providing a strong isolation boundary beyond standard process isolation — a
compromise within one VM should not (in a correctly implemented system) allow access
to other VMs or the host.

Containers vs VMs (brief security-relevant distinction): containers share the host OS

kernel (lighter weight, but a kernel-level vulnerability can potentially affect all containers
 on a host), while VMs have fully separate kernels (stronger isolation, more overhead) —
worth knowing as a genuine security-relevant tradeoff if the conversation moves into
modern infrastructure security.

10.2 Secure Boot and Trusted Computing

Secure boot: a process that verifies each stage of the boot process (firmware,
bootloader, OS kernel) using cryptographic signatures before allowing it to execute,
preventing malware from persisting by modifying boot-time code.

Trusted Platform Module (TPM): a dedicated hardware chip for securely

generating/storing cryptographic keys and performing certain cryptographic operations
in hardware, isolated from the main OS — providing a hardware root of trust that’s much
harder to compromise than a purely software-based key store.

10.3 Auditing and Logging

Comprehensive logging of security-relevant events (authentication attempts, access to
sensitive resources, configuration changes) is essential for both detective controls
(identifying an ongoing or past compromise) and forensic analysis (reconstructing what
happened after an incident) — worth naming as the practical backbone underlying the
accountability/non-repudiation principles from Part 1.

Part 11 (Extended Depth): Security Governance and Risk (brief

but complete awareness)
Less likely to be drilled deeply in a technical viva, but worth having a working vocabulary for,
since “why teaching, what’s your broader perspective” style questions can sometimes pivot
unexpectedly into “how do you think about security holistically.”

Risk = Threat × Vulnerability × Impact (a common conceptual framing): risk

assessment involves identifying threats (who/what could cause harm), vulnerabilities
(weaknesses that could be exploited), and impact (the consequence if exploited) —
security decisions are fundamentally about managing this risk to an acceptable level,
not eliminating it entirely (which is generally impossible).

CVE (Common Vulnerabilities and Exposures): a standardized identifier system for

publicly known security vulnerabilities, allowing consistent reference/tracking across
different tools and organizations.

Penetration testing vs vulnerability scanning: vulnerability scanning is largely

automated, checking systems against known vulnerability signatures; penetration
 testing involves actively (and with authorization) attempting to exploit a system the way
a real attacker would, often uncovering issues automated scanning misses (like logic
flaws or chained vulnerabilities).

Part 12: How This All Connects — The Big Picture

Same integrative habit as the other reference documents, but with an extra layer here given
the depth of this topic: security concepts organize around which property is being
protected (confidentiality/integrity/availability/authenticity) and at which layer of the
system (network, application, database, OS, or the human/organizational layer).

Protecting data in transit? → Network security (Part 4) — encryption, VPNs, firewalls

Protecting data being processed/computed on? → Advanced crypto (Part 9) —

homomorphic encryption, MPC, differential privacy

Protecting who can do what? → Authentication/Access Control (Part 3)

Protecting application logic from malicious input? → Application security (Part 5)

Protecting stored data specifically? → Database security (Part 6)

Protecting the machine/OS itself? → Systems security (Part 10)

Protecting against the human element? → Social engineering awareness (Part 7.2)

The single deepest insight to have ready, given your specific background: differential
privacy and homomorphic encryption solve different problems that are easy to conflate —
HE protects data during computation by an untrusted party (the computer never sees
plaintext), while DP protects individuals within a dataset from being identifiable through the
legitimate outputs of analysis (the analyst does see plaintext, but the output itself is
protected from leaking too much about any one individual). Being able to state this
distinction cleanly, unprompted, is exactly the kind of answer that signals genuine research
depth rather than course-level familiarity — and it directly justifies your own thesis’s use of
DP for exactly the reason above (protecting individual contributions within
federated/aggregated learning, not protecting a computation from an untrusted computer).

Quick Self-Test Checklist

Before your interview, you should be able to do all of the following without notes:

Define CIA, then name and define at least two principles beyond CIA (authenticity, non-
 repudiation) with a clean example each

Explain confidentiality vs authenticity as orthogonal properties, with an example of each

existing without the other

Explain symmetric vs asymmetric encryption, why hybrid encryption exists, and walk
through exactly how HTTPS uses both

Explain hashing vs encryption precisely, and explain salting and why it defeats rainbow
tables

Walk through exactly how a digital signature is created and verified, and what it proves

Explain what a certificate/CA solves that raw asymmetric encryption alone does not

Explain SQL injection and its actual defense (parameterized queries, not just “sanitize
input”)

Give a nuanced answer to “should you encrypt database entries” that weighs both sides

Explain the four Coffman-adjacent malware types (virus, worm, trojan, ransomware) by
their defining distinguishing feature

Explain homomorphic encryption’s core feature and the PHE/SHE/FHE distinction

Explain differential privacy’s core mechanism (noise + sensitivity + epsilon) and defend
DP over k-anonymity and over pure encryption with specific reasons

State the one clean sentence distinguishing what HE protects vs what DP protects

Explain your own thesis’s poisoning/Byzantine attack work using the general adversarial
ML vocabulary (evasion vs poisoning, Byzantine attacks) so it lands with a non-
specialist interviewer

Notes on Scope and Effort

Given this is your specialization, this document intentionally goes beyond the standard
undergraduate course depth used in the AI, Networking, and OS references. Parts 1–8 cover
the full standard course arc at the same rigor as those documents — nothing from a typical
security course is skipped. Parts 9–12 add a deliberate extra layer specifically where your
research background could invite deeper questioning: cryptographic depth beyond basic
definitions (homomorphic encryption’s levels, forward secrecy, Kerckhoffs’s principle),
OS/systems security, and — most importantly — the differential privacy and adversarial ML
content reasoned out at a level that should hold up even if an interviewer who does know
this space decides to press on it. If you want this pushed even further into your specific
thesis mechanics (CCVS, RGAR, the exact attack/defense math), that would be a natural
next document, since this one deliberately stayed at the general security course framing
plus adjacent research vocabulary rather than re-deriving your own thesis content.