Security Fundamentals

Question 1

What is symmetric encryption?

Answer 1

Symmetric encryption uses the same secret key to encrypt and decrypt data.

• Encryption algorithm takes (plaintext, key) and outputs ciphertext.
• Decryption algorithm takes (ciphertext, same key) and outputs plaintext.

Security depends on the key staying secret and on correct algorithm/mode usage.

Question 2

What is asymmetric encryption?

Answer 2

Asymmetric encryption uses a key pair: a public key and a private key.

• Sender encrypts to the recipient’s public key.
• Recipient decrypts with the matching private key.

• Security depends on private key secrecy; public key can be shared.

Question 3

What is the difference between symmetric and asymmetric encryption?

Answer 3

They differ in keys and performance.

• Symmetric: one shared secret key; fast for bulk data.
• Asymmetric: public/private key pair; slower, often used to establish shared secrets or encrypt small values.

• Many systems use asymmetric steps to set up symmetric session keys, then use symmetric encryption for data.

Question 4

What is hashing?

Answer 4

• Hashing is used for integrity checks and as a building block in other primitives.
• A secure hash is designed so you cannot feasibly recover input from digest. Hash functions are one-way by design.

• Hashing maps input data to a fixed-length digest.
• The system computes digest = hash(input).

Question 5

What is the difference between hashing and encryption?

Answer 5

Encryption is reversible with the right key; hashing is not designed to be reversible.

• Encryption: ciphertext can be decrypted back to plaintext if the key is known.
• Hashing: digest is a one-way summary; there is no decryption operation.

• If you need to recover the original data, you use encryption, not hashing.

Question 6

What are Message Authentication Codes (MACs)?

Answer 6

A Message Authentication Code (MAC) proves integrity and shared-key authenticity for a message.
- Sender computes tag = MAC(key, message).
- Receiver recomputes tag with the same key and compares.
- If tags match, receiver accepts that the message was not modified and came from someone with the key.

Question 7

What is HMAC?

Answer 7

HMAC (Hash-based Message Authentication Code) is a MAC built from a hash function and a secret key.
- Sender computes HMAC(key, message) and sends message + tag.
- Receiver recomputes HMAC with the same key and compares tags.

• HMAC provides integrity and shared-key authenticity, not confidentiality.

Question 8

What is randomness and entropy in security?

Answer 8

Entropy is the unpredictability available for generating secrets.
- Systems need high entropy to make keys and tokens hard to guess.
- Low entropy values are guessable by brute force because the search space is small.

• Security failures happen when “random” values are actually predictable.

Question 9

What is a nonce and how is it used?

Answer 9

A nonce is a value that must be unique for a specific context, usually per message or per session.
- Systems attach a nonce to a request or cryptographic operation.
- The receiver checks that the nonce is fresh (not seen before) or matches an expected sequence.
- Nonces help prevent replay because repeated messages can be detected.

Question 10

What is a replay attack?

Answer 10

A replay attack is reusing a previously valid message or token to repeat an action.
- Attacker captures a valid request, token, or signed message.
- Attacker resends it later.
- If the system only checks “valid format/signature” and does not check freshness, it accepts the replay.

Question 11

How do systems prevent replay attacks?

Answer 11

Systems prevent replay by adding and checking freshness.
- Nonce: receiver rejects previously seen nonces for a time window.
- Timestamp: receiver rejects messages outside an allowed time skew.
- Sequence number: receiver rejects out-of-order or repeated sequence values.

• Prevention requires a server-side freshness check; client-side checks alone are insufficient because attackers can bypass the client.

Question 12

What is a public key?

Answer 12

A public key is the shareable part of an asymmetric key pair.
- Others use it to verify signatures made by the private key or to encrypt data to the key owner.
- The public key does not need secrecy; its integrity matters so it cannot be swapped by an attacker.

Question 13

What is a private key?

Answer 13

A private key is the secret part of an asymmetric key pair.
- It is used to create digital signatures or to decrypt data encrypted to the matching public key.
- Anyone with the private key can impersonate the key owner in systems that trust that key.

Question 14

What is a key pair?

Answer 14

A key pair is a linked public key and private key generated together.
- The public key is distributed to verifiers or senders.
- The private key is kept secret by the owner.

• Systems trust key pair: private key signs and only matching public key can verify.

Question 15

What is key exchange?

Answer 15

Key exchange is a protocol that lets two parties derive a shared secret over an untrusted network.
- Both parties input data into a math protocol (like Diffie-Hellman) to compute identical secrets.
- Key exchange lacks authentication - parties verify the secret matches but not who generated it.

• Attacker sees all messages but can’t derive the secret without solving a hard math problem (e.g., discrete logarithm). Impersonation possible without extra auth.

Question 16

How does Diffie-Hellman key exchange work?

Answer 16

Step 1: Both sides agree on public parameters.
Step 2: Each side generates a private value and computes a public value from it.
Step 3: They exchange public values over the network.
Step 4: Each side combines its private value with the other side’s public value to derive the same shared secret.

Basic Diffie-Hellman does not prove who the other side is; it only derives a secret.

Question 17

Why must private keys remain secret?

Answer 17

Private keys must remain secret because possession equals authority in these systems.
- Systems accept signatures verified by the public key as proof from the owner.
- If an attacker has the private key, they can generate signatures that pass verification checks.
- That enables impersonation and unauthorized actions wherever that key is trusted.

Question 18

What is a digital signature?

Answer 18

A digital signature is a cryptographic proof bound to data and a private key.
- Signer computes signature = Sign(private key, message).
- Verifier checks Verify(public key, message, signature) returns valid.
- If valid, verifier knows the signature matches that message under that public key.

Question 19

What do digital signatures prove?

Answer 19

They prove message integrity and private-key possession at signing time.
- Integrity: the signed message cannot be modified without breaking verification.
- Authenticity (key-based): only someone with the private key could have produced the signature that verifies.
- Non-repudiation: “Can’t deny signing” - only works with your protected key + key proves it was you.

Question 20

What do digital signatures not prove?

Answer 20

They do not prove trust, intent, or safety of content.
- A valid signature does not mean the signer is authorized by your system unless you trust that key for that purpose.
- A valid signature does not mean the message is “good,” only that it was signed by the key holder and not altered.
- Signatures do not prevent replay unless the signed data includes nonces and the receiver checks it.

Question 21

What is a certificate?

Answer 21

A certificate binds an identity to a public key using a digital signature by a trusted issuer.
- It contains identity fields and a public key.
- A Certificate Authority (CA)** signs** it.
- Verifiers use the CA signature to decide whether to trust the binding.

Question 22

What is a Certificate Authority (CA)?

Answer 22

A Certificate Authority (CA) is an entity whose public key is trusted to sign certificates for others.
- The CA signs a certificate after applying its issuance rules.
- Verifiers accept the certificate only if they trust the CA public key and validation checks pass.

Question 23

What is a trust store?

Answer 23

A trust store is the set of CA certificates a verifier uses as trust anchors.
- During validation, the verifier checks whether a certificate chain can be built to one of these trusted CA roots.
- If no trusted anchor exists, validation fails because there is no trusted signer for the identity binding.

Question 24

What is a trust chain?

Answer 24

A trust chain is a sequence of certificates linking an** end-entity certificate** to a trusted CA root.
- Each certificate in the chain is signed by the next issuer up the chain.
- The verifier validates each signature and checks constraints.
- Validation succeeds only if the chain ends at a trusted root in the trust store.

Question 25

How does certificate validation work?

Answer 25

**Step 1:** **Build a chain** from the presented certificate to a trusted root in the trust store. **Step 2:** **Verify digital signatures** on each certificate in the chain. **Step 3:** **Check validity periods** and required extensions/constraints (like allowed key usage). **Step 4:** **Check revocation status** if required by the verifier’s policy. **Step 5:** **Match** the **certificate identity** to the **expected identity** (hostname or service identity).

Question 26

What is certificate revocation?

Answer 26

Certificate **revocation is marking a certificate as no longer trustworthy** before its expiration. - Revocation **exists** because **private keys can be compromised** or **certificates** can be **mis-issued**. - A **verifier** must **check revocation status** to **avoid trusting** a certificate that should no longer be accepted.

Question 27

What is a CRL?

Answer 27

CRL (Certificate Revocation List) is a **published list of revoked certificate identifiers**. - Verifier downloads the CRL for an issuer and **checks** whether the **certificate** is listed as **revoked**. - If listed, **validation fails** because the **certificate** is **no longer trusted**.

Question 28

What is OCSP?

Answer 28

OCSP (Online Certificate Status Protocol) is an **online query to get revocation status for a certificate**. - **Verifier asks** an OCSP responder for the **status** of a **specific certificate**. - If status indicates **revoked**, validation **fails**. - No large list downloads (**saves data**, ulike CRL), but needs **online server**. If **down** = **check fails**.

Question 29

What is a TLS handshake?

Answer 29

TLS (Transport Layer Security) handshake is the **setup phase that authenticates peers and derives shared session keys**. - The parties **negotiate** **protocol** and **cryptographic parameters**. - The **server proves identity via a certificate** (and optionally the client in mTLS). - They **perform key exchange** to **derive symmetric session keys** used for the **encrypted connection**.

Question 30

How does the TLS handshake work at a high level?

Answer 30

**Step 1:** Client and server negotiate TLS version and cipher suite options. **Step 2:** Server sends its certificate; client validates it against trust rules. **Step 3:** They run key exchange to derive shared secrets. **Step 4:** They derive symmetric session keys and switch to encrypted, integrity-protected traffic using those keys.

Question 31

What does TLS protect?

Answer 31

TLS **protects data in transit between endpoints** that successfully complete the handshake. - **Confidentiality**: encrypts traffic so observers cannot read contents. - **Integrity**: detects tampering in transit. - **Endpoint authentication**: typically server authentication via certificate validation; client authentication is added with mTLS.

Question 32

What does TLS not protect?

Answer 32

TLS **does not protect against endpoint compromise** or incorrect trust decisions. - If the client trusts the wrong certificate, TLS can secure a connection to an attacker. - If the server or client is compromised, TLS cannot stop data theft at the endpoint. - TLS does not inherently hide network metadata like IP addresses and ports.

Question 33

What is HTTPS?

Answer 33

HTTPS is **HTTP over TLS**. - HTTP **requests and responses** are carried **inside** a **TLS-protected connection**. - **Browser/client validates** the **server certificate** and then **sends HTTP over** the established **secure channel**. | HTTPS security depends on correct certificate validation and TLS configuration.

Question 34

What is mTLS?

Answer 34

mTLS (mutual TLS) is TLS where **both sides authenticate using certificates**. - **Server presents a certificate** and the **client validates** it. - **Client also presents a certificate** and the **server validates** it. - The server can bind requests/connection to the authenticated client identity from the client certificate.

Question 35

What are session keys?

Answer 35

Session keys are** symmetric keys derived during a handshake** for a **specific connection or session**. - They **encrypt** and **authenticate traffic** for the duration of the **session**. - They are different from long-term keys like certificate private keys. - If session keys are not stored, later theft of long-term keys does not reveal past session traffic.

Question 36

What is perfect forward secrecy?

Answer 36

Perfect forward secrecy means **past session traffic stays confidential even if a long-term private key is compromised later**. - It is achieved when session keys are derived from ephemeral key exchange that is not recoverable from the long-term key. - If an attacker later steals the certificate private key, they still cannot derive old session keys that were never stored.

Question 37

What is identity in security systems?

Answer 37

Identity is the label a system uses to represent a principal (user or service) in decisions. - The system binds actions to an identity after verifying proof. - Authorization decisions are evaluated against that identity and its attributes/roles.

Question 38

What is authentication?

Answer 38

Authentication is the system verifying a presented proof and binding it to an identity. - System checks credentials or cryptographic proof. - If proof verifies, system marks the caller as an identity for subsequent requests (session or token).

Question 39

What is authorization?

Answer 39

Authorization is the system deciding whether an authenticated identity may perform a specific action. - System evaluates policy for (identity, action, resource, context). - If policy allows, action executes; otherwise it is denied.

Question 40

What is the difference between authentication and authorization?

Answer 40

Authentication answers “who is calling”; authorization answers “what they may do.” - Authentication verifies proof and assigns an identity. - Authorization evaluates policy using that identity and the request details. - Authorization cannot be correct without a stable identity from authentication.

Question 41

What are credentials?

Answer 41

Credentials are the proof material used for authentication. - Examples include passwords, API keys, client certificates, and private-key signatures. - Systems verify credentials by comparison (shared secrets) or by cryptographic verification (cert/key signatures).

Question 42

What is proof of identity?

Answer 42

Proof of identity is what the system verifies to accept a claimed identity. - For shared secrets: system checks presented secret matches expected secret. - For asymmetric proof: system verifies a signature or a certificate-based handshake. - Proof is only meaningful if the system’s verification checks are correct and tied to the right identity.

Question 43

What are tokens in security systems?

Answer 43

Tokens are issued artifacts that represent an authenticated identity and possibly delegated permissions. - System issues a token after authentication. - Resource servers validate the token on each request and extract identity/claims for authorization. - Tokens reduce repeated credential use on every request.

Question 44

What is a bearer token?

Answer 44

A bearer token is accepted if the caller possesses it and it passes validation checks. - Server checks signature/lookup, expiry, issuer, and audience as applicable. - Server does not require an additional proof bound to the caller unless a separate mechanism is used. | If a bearer token leaks, an attacker can replay it until it is invalidated.

Question 45

How does token expiration work?

Answer 45

Token expiration is a validation check that rejects tokens outside their allowed time window. - Token contains an expiration time or the server stores an expiry for it. - On each request, the server compares current time to expiry and rejects if expired. - Expiration limits replay window but does not stop replay within the valid window.

Question 46

What are token scopes?

Answer 46

Token scopes are strings/claims the resource server compares to required permissions for an action. - Authorization server issues token with scope claims. - API maps operations to required scopes. - API checks token contains required scope before executing the operation.

Question 47

What is token audience and how is it enforced?

Answer 47

Audience is the intended recipient of a token. - Token includes an audience value (aud) identifying which API/service should accept it. - The API compares aud to its own identifier and rejects if they do not match. - Without this check, tokens meant for one service can be replayed to another service.

Question 48

What is token leakage?

Answer 48

Token leakage is when a token becomes accessible to unauthorized parties. - Validation checks still succeed for the stolen token because it is structurally valid and unexpired. - Attackers can replay it until expiry or enforced revocation/rotation makes it fail validation.

Question 49

What is a JWT?

Answer 49

JWT (JSON Web Token) is a compact token format commonly used for signed claims. - A server can validate a JWT by verifying its signature and checking required constraints. - A JWT can carry identity and authorization claims used by an API for policy decisions.

Question 50

What is JWT structure?

Answer 50

A JWT has three base64url parts separated by dots. - Header: declares token type and signing algorithm. - Payload: contains claims like subject, issuer, audience, expiry. - Signature: cryptographic signature over header+payload used for integrity and issuer authenticity.

Question 51

What is clock skew and why does it matter for tokens?

Answer 51

Clock skew is time mismatch between systems that validate time-based claims. - Validators compare current time to claims like expiration (exp) and not-before (nbf). - If clocks differ, a valid token can be rejected as “expired” or “not yet valid,” or an invalid token can be accepted longer than intended. | Systems often allow a small skew window, but that widens acceptance time slightly.

Question 52

What are secrets?

Answer 52

Secrets are values that must remain confidential because they grant access or authority when presented. - Systems verify secrets by direct matching (the same value must be presented). - If a secret is copied, the system cannot distinguish the attacker from the legitimate holder without additional controls.

Question 53

What are key properties of secrets?

Answer 53

Secrets must be hard to guess, tightly accessible, and replaceable. - High entropy so brute force is infeasible. - Access controls so only required identities can read/use them. - Rotation ability so a leaked secret can be replaced and old value rejected.

Question 54

What is the difference between secrets and keys?

Answer 54

Keys are used in cryptographic operations; secrets are any confidential values used for access. - A cryptographic key enables signing, encryption, or decryption operations verified by math. - A secret like an API key or password is typically verified by equality. - Both must be protected, but compromise impact differs by how systems verify and use them.

Question 55

What is the difference between secrets and certificates?

Answer 55

Certificates are signed public documents; secrets are confidential values. - A certificate can be public because it contains a public key and identity binding signed by a CA. - The private key corresponding to a certificate is secret; if stolen, it enables impersonation. | Certificate misuse risk is usually about weak validation or private key compromise, not about the certificate being public.