Book-Notes Section 7 Flashcards
Difference Between Out-of-Band and In-Band Exchange:
When two parties need to share encryption keys, they can exchange them in two main ways:
In-Band Exchange – Sending the key through the same channel as the encrypted message.
Out-of-Band Exchange – Sending the key through a separate, secure channel to avoid interception.
In-Band Exchange (Same Channel)
🔹 Definition: The key is exchanged over the same network or communication channel where encrypted messages are sent.
🔹 Risk: If a hacker is eavesdropping on the channel, they could steal the key and decrypt the messages.
Out-of-Band Exchange (Separate Channel)
🔹 Definition: The key is exchanged using a different method or channel to prevent interception.
🔹 More Secure: Even if someone spies on the main communication, they won’t see the key.
🔹 Example in Symmetric Cryptography:
Alice and Bob want to use AES encryption, but instead of sending the key over the internet, Alice calls Bob on the phone or hands him a USB drive with the key.
The actual messages are sent encrypted over the internet, but the key never travels there, making it safer.
What is a 512-bit Block Size?
🔹 SHA-1 processes data in chunks of 512 bits (64 bytes) at a time.
🔹 This means that if a message is longer than 512 bits, SHA-1 splits it into multiple blocks.
🔹 Each block is processed separately but contributes to the final output.
- What is a 160-bit Message Digest?
🔹 No matter how long the input message is, SHA-1 always produces a 160-bit (20-byte) output called the message digest.
🔹 This digest is a unique fingerprint of the original data.
🔹 Even a small change in the input creates a completely different 160-bit digest.
What is HMAC in Simple Terms?
HMAC (Hash-based Message Authentication Code) is a way to verify that a message has not been tampered with by using a secret key. It combines a hashing algorithm (like SHA-1 or SHA-256) with a secret key to ensure data integrity and authenticity.
How is HMAC Different from Regular Hashing (SHA-1, SHA-256, etc.)?
🔹 Regular Hashing (SHA-1, SHA-256, etc.):
Takes an input message and produces a fixed-length hash (digest).
No secret key is involved → Anyone can compute the hash.
Used for data integrity but not authentication.
🔹 HMAC (SHA-1, SHA-256 + Secret Key):
Uses both a hash function and a secret key.
Ensures only someone with the secret key can verify the message.
Provides message authentication and integrity.
Example: Regular Hashing vs. HMAC
Let’s say Alice sends a message to Bob:
1️⃣ Regular Hashing (SHA-256)
Alice hashes “Hello Bob” using SHA-256 → gets a hash.
She sends both the message and the hash to Bob.
Bob recalculates the hash. If it matches, the message hasn’t changed.
❌ Problem: A hacker (Eve) can change the message and recompute the hash.
🔍 No authentication, only integrity is provided.
2️⃣ HMAC (SHA-256 + Secret Key)
Alice has a secret key that only she and Bob know.
She computes HMAC(“Hello Bob”, secret key) → gets a unique HMAC.
She sends both the message and the HMAC to Bob.
Bob recalculates the HMAC using his copy of the secret key.
If it matches, the message is authentic and unchanged.
❌ If Eve intercepts the message, she can’t modify it because she doesn’t know the secret key.
Why Does HMAC Provide Integrity but NOT Non-Repudiation?
✅ Integrity:
Ensures the message was not altered during transmission.
If the HMAC matches, the message is valid.
❌ No Non-Repudiation:
Both Alice and Bob share the secret key.
Bob can’t prove that only Alice sent the message.
Alice could deny sending it, saying Bob faked it.
Non-repudiation requires a private/public key system (like digital signatures), not HMAC.
How Does the HMAC Secret Key Look?
It is a random string of bits, typically 128, 256, or 512 bits long.
It can be represented as a series of numbers or hexadecimal values.
Example of a 256-bit key (32 bytes in hex):
A3F1C7D9834E2A68FF23D9B768A4B5C0E921DF8B2EFA017CB9E4B3D291A6F4C3
How HMAC Works Step-by-Step
Both parties (sender & receiver) must have the same secret key beforehand.
This key is shared securely before communication starts.
If someone doesn’t have the key, they can’t verify the message.
The sender creates the HMAC by mixing the secret key into the hashing process.
Instead of just hashing the message like in SHA-256, the sender uses this formula:
HMAC=Hash((SecretKey)+(Message))
This ensures that only someone with the secret key can recreate the same HMAC.
The sender sends both the original message and the HMAC to the receiver.
The message itself is not encrypted by HMAC.
HMAC is just used to verify that the message wasn’t changed.
The receiver uses the same secret key to verify the HMAC.
The receiver recalculates HMAC using the received message and their copy of the secret key.
If the recalculated HMAC matches the one sent, the message is authentic and unchanged.
If the HMAC doesn’t match, the message was tampered with or the sender is not authentic.
Certificate Pinning & How It Works
Certificate pinning is a security technique that ensures an app or system only trusts a specific certificate (or its public key), rather than trusting any certificate issued by a Certificate Authority (CA). This prevents Man-in-the-Middle (MITM) attacks and CA compromise risks.
🔹 Why is Certificate Pinning Needed?
✔ Normally, an app/browser trusts any valid certificate from a CA.
✔ But if a CA is compromised, an attacker can obtain a fraudulent certificate for a website.
✔ Without pinning, the app might trust the fake certificate, allowing MITM attacks.
✔ Pinning ensures the app only trusts the real certificate’s public key, rejecting fake certificates.
🔹 The Certificate Pinning Process (Step-by-Step)
1️⃣ During Development: The Developer Pins the Public Key
Extract the public key from the website’s SSL certificate.
Hash the public key using SHA-256 to create a fingerprint.
Store (pin) the fingerprint inside the app’s source code.
2️⃣ During App Runtime: The App Verifies the Certificate
The app requests a secure connection (e.g., user logs in to secure-bank.com).
The server provides its SSL/TLS certificate.
The app extracts the public key from the received certificate.
The app hashes the public key and compares it with the pinned fingerprint.
✅ If they match → Connection is allowed.
❌ If they don’t match → Connection is blocked (possible attack).
🔹 What Certificate Pinning Protects Against
✔ Compromised CAs → Stops attackers from using fake certificates.
✔ MITM Attacks → Prevents hackers from intercepting data.
✔ Fake Websites → Ensures users only connect to the real server.
🔹 Downsides of Certificate Pinning
❌ If the pinned certificate expires or changes, the app must be updated.
❌ If the app is not updated with the new public key, users might get connection errors.
❌ Managing pinning in large systems can be complex due to certificate renewals.
Why Can a Fake Certificate Be Used If the Server Provides It?
You’re right that the website’s server is the one that provides the SSL/TLS certificate during a secure connection, not the Certificate Authority (CA) itself.
However, the problem arises when a hacker tricks a CA into issuing a fraudulent certificate for the same domain. Here’s how this can happen:
🔹 How a Fake Certificate Can Be Used (Even Though the Server Provides It)
1️⃣ A Hacker Gets a Fraudulent Certificate from a Compromised CA
Normally, only the real owner of a domain (e.g., secure-bank.com) can get a certificate from a trusted CA.
But if a hacker tricks a CA (or if the CA is hacked), they can obtain a fake certificate for secure-bank.com.
This fake certificate has a different public key but is still signed by a trusted CA.
2️⃣ The Hacker Sets Up a Fake Server
The hacker creates a malicious version of secure-bank.com.
They install their fraudulent certificate on their fake server.
3️⃣ A Man-in-the-Middle (MITM) Attack Occurs
The hacker intercepts a user’s connection (e.g., through public Wi-Fi, DNS hijacking, or malware).
Instead of the user connecting to the real secure-bank.com, they unknowingly connect to the hacker’s fake website.
The hacker’s server presents the fraudulent certificate to the user’s app.
4️⃣ The User’s App Might Accept the Fake Certificate (If No Pinning Is Used)
Since the fraudulent certificate is issued by a trusted CA, the app/browser might think it’s legitimate and accept the connection.
The hacker can now steal login credentials, session tokens, or sensitive data.
🔹 How Certificate Pinning Prevents This
✔ If the app pinned the public key of the real website’s certificate, it will only trust that specific key.
✔ Even if the hacker’s fake certificate is from a trusted CA, the app will reject it because the public key won’t match the pinned one.
Does the fabrication only happens at the early stages of CSR?
Yes! The fabrication of a fraudulent certificate happens at the early stages of the Certificate Signing Request (CSR) process.
🔹 The CSR process is when a website owner requests a digital certificate from a Certificate Authority (CA).
🔹 Normally, only the real owner of the domain can request a certificate.
🔹 However, if a CA is tricked, compromised, or hacked, it can issue a fraudulent certificate to an attacker.
🔹 How Fake Certificates Can Be Created (CSR Process Exploitation)
1️⃣ The Legitimate Process (How It Should Work)
A website owner (e.g., secure-bank.com) generates a CSR containing their public key and domain name.
The CA verifies that the requester actually owns secure-bank.com (e.g., through domain validation).
Once verified, the CA signs the certificate and issues it to secure-bank.com.
2️⃣ The Attack (How a Fake Certificate is Created)
A hacker tricks a CA into issuing a certificate for secure-bank.com (without owning the domain).
This can happen if: ✅ The CA has a security vulnerability.
✅ The CA’s domain validation process is bypassed (e.g., DNS hijacking, email spoofing).
✅ The CA itself is hacked (like the DigiNotar attack).
The CA signs the fake certificate, making it look legitimate.
Now, the hacker has a valid certificate for secure-bank.com, which they can use in a Man-in-the-Middle attack.
🔹 What Happens After the Fraudulent Certificate is Issued?
The hacker sets up a fake website that looks like secure-bank.com.
They install the fraudulent certificate on their fake server.
If a victim’s browser or app does NOT use certificate pinning, it will trust the fake certificate because it’s issued by a valid CA.
The hacker can now steal login credentials, session tokens, or sensitive data.
🔹 How Certificate Pinning Prevents This
✅ The app pins the public key of the original certificate.
✅ Even if a fake certificate is issued by a rogue CA, it will have a different public key.
✅ The app rejects the connection if the received certificate does not match the pinned key.
does the public key originated from the CA or the domain owner?
The Public Key Originates from the Domain Owner, NOT the CA.
What is a Known Plaintext Attack (KPA) vs. Chosen Plaintext Attack (CPA)?
Both Known Plaintext Attack (KPA) and Chosen Plaintext Attack (CPA) are cryptanalysis techniques where an attacker tries to break encryption by studying how plaintext and ciphertext relate.
The difference is how much control the attacker has over the plaintext.
1️⃣ Known Plaintext Attack (KPA)
✔ The attacker already has some plaintext-ciphertext pairs but did not choose them.
✔ They analyze these pairs to figure out the encryption key or pattern.
✔ Used when an attacker intercepts messages but doesn’t control the input.
🔹 Example of a KPA:
A spy intercepts multiple encrypted messages (ciphertext).
They also find out some original messages (plaintext) that match the encrypted versions.
By studying how the plaintext turns into ciphertext, they try to reverse-engineer the encryption method or find the key.
📌 Real-World Example:
WWII Enigma Machine → Allied forces knew that Nazi messages often ended with “Heil Hitler”.
They used this known plaintext to crack the Enigma cipher and decode messages.
2️⃣ Chosen Plaintext Attack (CPA)
✔ The attacker can choose specific plaintexts and see how they get encrypted.
✔ This helps them find patterns and reverse-engineer the encryption method or key.
✔ Used when an attacker can send input to the encryption system and analyze the output.
🔹 Example of a CPA:
A hacker has access to an encryption tool but not the secret key.
They keep feeding different plaintexts into the system and observing the ciphertext output.
By carefully selecting inputs, they try to figure out how the encryption works and crack it.
📌 Real-World Example:
Padding Oracle Attack (on older SSL/TLS) → Attackers sent specially crafted plaintexts to an encrypted website connection and analyzed the system’s response.
This helped them break SSL encryption and steal sensitive data.
🔹 What is a Related-Key Attack (RKA)?
A Related-Key Attack (RKA) is a type of cryptographic attack where the attacker doesn’t know the encryption key but has access to multiple ciphertexts that were encrypted using different but related keys.
🔹 The attacker exploits the mathematical relationship between the keys to eventually recover the secret key or decrypt data.
🔹 How Does a Related-Key Attack Work?
1️⃣ The attacker observes ciphertext outputs from a cryptographic system.
2️⃣ These ciphertexts were encrypted using different keys, but the attacker knows how the keys are related (e.g., slight variations of the same key).
3️⃣ The attacker studies patterns in the encryption process and uses the relationship between the keys to figure out the secret key.
🔹 Example of a Related-Key Attack
Imagine a company uses AES encryption but follows this bad practice:
They derive different keys from the same master key by adding 1 to the previous key.
Key 1: A1B2C3D4E5F6…
Key 2: A1B2C3D4E5F7… (Key 1 + 1)
Key 3: A1B2C3D4E5F8… (Key 2 + 1)
If an attacker discovers how the keys are related, they can predict the next key and decrypt messages.
📌 Real-World Example: Related-Key Attacks
1️⃣ Microsoft Office 2007 Encryption Weakness
Older versions of Microsoft Office used encryption keys derived in a predictable way.
Attackers exploited the related-key weakness to decrypt Office documents.
2️⃣ Weak AES Implementations
AES itself is secure, but some poor implementations of AES key scheduling allow related-key attacks.
Researchers have demonstrated related-key attacks on reduced-round versions of AES (not full AES-256).
🔹 What is Key Stretching?
Key stretching is a technique used to make weak passwords or keys stronger by processing them many times through a hashing or encryption function.
🔹 Why? If a password is too short or weak, attackers can crack it quickly using brute force.
🔹 Solution? Key stretching adds extra computation time, making brute-force attacks much slower and harder.
🔹 How Does Key Stretching Work?
1️⃣ The user enters a password (weak key).
2️⃣ The password is passed through a key stretching algorithm.
3️⃣ The algorithm processes the password thousands or even millions of times, making it much harder to crack.
4️⃣ The result is a stronger derived key, which is used for encryption or authentication.
🔹 Example of Key Stretching in Action
Without Key Stretching (Weak Password)
Password: 123456
Hash: e10adc3949ba59abbe56e057f20f883e
❌ Hackers can crack this hash instantly using a lookup table.
With Key Stretching (Strong Derived Key)
Password: 123456
Algorithm: PBKDF2 (applies 100,000 iterations)
Hash: d98a7e98f42d18b1a7b9df4f6f908d7eacac…
✅ Now, brute-force attacks take much longer!
🔹 What is a Birthday Attack?
A birthday attack is a cryptographic attack that takes advantage of probability to find collisions in a hash function faster than expected.
🔹 It’s based on the “Birthday Paradox” in probability, which states that in a group of just 23 people, there’s a 50% chance that two people share the same birthday (even though there are 365 days in a year).
🔹 Similarly, in hashing, an attacker can find two different inputs that produce the same hash (collision) faster than brute force.
🔹 How Does a Birthday Attack Work?
1️⃣ Hash functions are supposed to create unique outputs for different inputs.
2️⃣ But because hash functions have a finite number of possible outputs, collisions (same hash for different inputs) are possible.
3️⃣ Instead of testing every possible input (brute force), an attacker generates random inputs and looks for a match.
4️⃣ Due to mathematical probability (Birthday Paradox), a collision can happen much sooner than expected.
🔹 Example of a Birthday Attack
🔹 Imagine a hashing function that produces 8-bit hashes (only 256 possible hash values).
🔹 A brute force attack would take up to 256 attempts to find a specific hash.
🔹 But with a birthday attack, an attacker only needs about 16 attempts to find a collision (two different inputs with the same hash).
👉 Real-world case: In 2017, researchers used a birthday attack to break SHA-1 by finding two different PDF files that produced the same hash. This was called the SHAttered Attack.
🔹 Why is the Birthday Attack Important?
✅ It breaks weak hash functions (like MD5 and SHA-1), making them insecure.
✅ It’s a major reason why modern cryptography uses SHA-256 and SHA-3, which have better collision resistance.
✅ It shows why short hash lengths are risky, because they make finding collisions easier.
