Senior Cryptographer Interview Preparation Guide - FAANG Standards

Approach

Use the cryptography library's high-level sign and verify methods with RSA-PSS (Probabilistic Signature Scheme) padding and SHA-256 (part of the SHA, Secure Hash Algorithm, family), letting the library handle the actual RSA and hash math internally. The three parameters that must match exactly between signer and verifier are the message-hash algorithm (SHA-256), the mask-generation function's hash (MGF1 using SHA-256, matching the message hash is the standard convention), and the salt length (here, set equal to the hash's own digest size, 32 bytes, a common recommended default).

from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import padding, rsa

def sign_message_rsa_pss(private_pem: bytes, message: bytes) -> bytes:
    private_key = serialization.load_pem_private_key(private_pem, password=None)
    return private_key.sign(
        message,
        padding.PSS(
            mgf=padding.MGF1(hashes.SHA256()),
            salt_length=hashes.SHA256().digest_size,   # 32 bytes
        ),
        hashes.SHA256(),
    )

def verify_message_rsa_pss(public_pem: bytes, message: bytes, signature: bytes) -> bool:
    public_key = serialization.load_pem_public_key(public_pem)
    try:
        public_key.verify(
            signature, message,
            padding.PSS(
                mgf=padding.MGF1(hashes.SHA256()),
                salt_length=hashes.SHA256().digest_size,
            ),
            hashes.SHA256(),
        )
        return True
    except Exception:
        return False

if __name__ == '__main__':
    key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
    priv_pem = key.private_bytes(serialization.Encoding.PEM, serialization.PrivateFormat.PKCS8, serialization.NoEncryption())
    pub_pem = key.public_key().public_bytes(serialization.Encoding.PEM, serialization.PublicFormat.SubjectPublicKeyInfo)

    message = b"transfer 100 credits to account 42"
    sig = sign_message_rsa_pss(priv_pem, message)
    print("signature length (bytes):", len(sig))
    print("verify(correct message)  :", verify_message_rsa_pss(pub_pem, message, sig))
    print("verify(tampered message) :", verify_message_rsa_pss(pub_pem, message + b"!", sig))

Output:

signature length (bytes): 256
verify(correct message)  : True
verify(tampered message) : False

Key points

• RSA-PSS is a RANDOMIZED padding scheme (a random salt is mixed in through the mask-generation function), unlike the older, deterministic PKCS#1 v1.5 padding; randomization gives PSS a stronger, more modern security proof, and it's the currently recommended RSA signature padding for new systems.
• The private key is loaded once from PEM bytes, and .sign() returns raw signature bytes directly. Verification loads the PUBLIC key and calls .verify(), which RAISES an exception on failure rather than returning a boolean; swallowing that exception incorrectly, or treating "no exception" as the only success signal without confirming verify was actually called, is a common integration mistake.
• Constant-time verification is handled internally by the library, not something the caller needs to implement, unlike a hand-rolled MAC (Message Authentication Code) comparison; never hand-implement RSA padding.

Complexity

RSA sign and verify cost is dominated by modular exponentiation over the key's modulus. For a fixed key size this cost doesn't depend on message length beyond the initial hashing pass, since the message is compressed to a fixed-size digest before any RSA math happens; signing (the private-key operation, using the full-size exponent) is meaningfully more expensive than verifying (the public-key operation, which typically uses a small exponent such as 65537).

Edge cases

• A message longer than the modulus is a non-issue here, unlike raw RSA encryption of long data, precisely because the message is hashed to a fixed size before being signed.
• A passphrase-protected private key needs that passphrase passed to password= instead of None; the shown code assumes an unencrypted key.
• Verifying with the WRONG public key fails closed, by raising, not by returning False silently; calling code must catch that exception path explicitly rather than assuming a boolean return.
• PSS's randomized salt means signing the SAME message twice with the SAME key produces two DIFFERENT valid signature byte strings. This is expected and correct, not a bug; don't assume signature reproducibility for any purpose that needs it, such as content-addressing.

Treat the device fleet as a chain of custody from silicon to running firmware: every boot stage verifies the next stage's signature before running it, the device can prove its current state to a remote verifier through a signed attestation report, and firmware rollout happens in reversible, monitored stages with a fast kill switch if something goes wrong.

Framework

• Boot-chain verification: an immutable first-stage bootloader, burned into read-only memory or write-protected at manufacturing (the hardware root of trust), verifies the signature of the second-stage bootloader before executing it; that stage verifies the next, and so on up to the application firmware. Each link is checked against a public key that itself only changes through a signed, audited update to the trust anchor. This is the standard secure-boot chain pattern.
• Signed firmware images: every firmware image is signed by the vendor's release key, ideally HSM-backed, and carries a monotonically increasing version number inside the signed metadata, not just in an unsigned filename or header.
• Attestation protocol: the device measures each boot-chain component, meaning it computes a cryptographic hash of each stage, into a protected register (conceptually similar to a Trusted Platform Module's platform configuration registers). On request, it signs a report of those measurements plus a fresh, server-supplied random value (a nonce, which prevents an attacker from replaying an old, valid-looking report) using a device-unique attestation key. A remote verifier checks the signature and compares the measurements against known-good values to confirm the device is running genuine, unmodified firmware.
• Rollback protection: store the minimum acceptable firmware version in protected, monotonic storage inside the secure element, meaning it can only increase, so an attacker cannot present an older, validly-signed-but-vulnerable firmware image to downgrade the device. The boot chain refuses to run any signed image whose version is below that stored minimum.
• Emergency revocation: maintain a mechanism, often a simple monotonic "minimum acceptable version" bump rather than a full certificate-style revocation list, that the fleet checks on next contact, so a newly discovered vulnerability in a specific firmware version can be blocked fleet-wide, even for devices that already have that validly signed image installed.
• Staged rollout with recovery: push a new firmware version to a small canary population first, monitor attestation reports and health telemetry, and widen the rollout ring by ring. Keep the previous known-good image available in a separate flash partition (A/B partitioning) so a device that fails to boot the new image, or fails a post-update attestation check, automatically falls back to the previous verified-good image rather than becoming unreachable.

Worked example

A fleet of secure elements runs firmware v12. A canary ring of 1% of devices receives v13 first; each canary device attests after updating, and the backend confirms the signed measurements match the expected v13 hashes and that error rates stay flat before widening the rollout to the next ring. If a device fails to boot v13, its bootloader automatically falls back to the v12 image in the alternate partition and reports the failed boot in its next attestation, which halts the fleet-wide rollout. A critical vulnerability later found in v11 triggers bumping the fleet-wide minimum acceptable version, so any remaining device still on v11 is blocked from booting it and forced onto an update path, even though that v11 image remains validly signed.

Trade-offs and pitfalls

Rollback protection and emergency revocation both depend on a genuinely tamper-resistant, monotonic counter; a counter that can be reset defeats the whole purpose, since an attacker could simply reset it and replay an old image. A common mistake is checking signature validity without also checking the version against the rollback floor, which lets an attacker replay an old, validly-signed, vulnerable firmware image. The A/B fallback partition needs its own attestation check too, otherwise "recovery" can itself become a downgrade path if that partition is allowed to hold an arbitrarily old image instead of being kept in step with the current rollback-protection floor.

Direct answer

RSAES-PKCS1-v1_5 is the older RSA encryption padding scheme; RSA-OAEP (Optimal Asymmetric
Encryption Padding) is the modern replacement built on a mask generation function (MGF1, itself
built from a hash function) that adds randomized, verifiable structure to the padded message.
RSA-OAEP is preferred for wrapping symmetric keys because it resists a class of chosen-ciphertext
attacks that RSAES-PKCS1-v1_5 is historically vulnerable to, where an attacker who can submit
crafted ciphertexts and observe only a valid/invalid signal can eventually decrypt real
ciphertexts without the private key.

Structured elaboration

• The historical attack RSA-OAEP avoids. RSAES-PKCS1-v1_5 padding is considered valid ("PKCS
  conforming") only when the decrypted bytes happen to start with 0x00 0x02. For a uniformly
  random decryption, the chance of that happening is $\left(\frac{1}{256}\right)^2 = \frac{1}{65536} \approx 2^{-16}$, since each of those two leading bytes independently has a
  1-in-256 chance of matching. Bleichenbacher's 1998 attack turns a service that merely reports
  "this ciphertext's padding was/was not valid" into a full decryption oracle, using roughly a
  million adaptive queries against a 1024-bit key in the original paper; the exact query count
  scales with key size and how the search is structured, but the underlying leak, a single
  padding-validity bit, is what both this attack and Cipher Block Chaining (CBC) mode's padding
  oracle attack have in common.
• Why OAEP resists it. OAEP embeds a hash-based integrity check across the whole padded
  message, so a randomly modified ciphertext fails that check almost certainly, and a correctly
  implemented decryptor returns one generic failure rather than a structural signal an attacker
  can iterate on.
• Compatibility. Some legacy Hardware Security Modules (HSMs), smartcards, and embedded
  devices only implement RSAES-PKCS1-v1_5. Verify what every endpoint in an integration actually
  supports before committing to OAEP everywhere.
• Interoperability. OAEP has parameters, the hash function and the MGF1 hash function, that
  both ends must agree on explicitly (commonly SHA-256 for both today; older defaults were SHA-1).
  A silent mismatch is a decryption failure, not a security hole, but it will look like a bug in
  production if it is not pinned in the integration contract.

Worked example

The $2^{-16}$ figure above is not a rough guess, it falls directly out of requiring two specific
bytes: probability a random byte equals 0x00 is $\frac{1}{256}$, and requiring a second,
independent byte to equal 0x02 multiplies that by another $\frac{1}{256}$, giving
$\frac{1}{256} \times \frac{1}{256} = \frac{1}{65536} = 2^{-16}$. That small but nonzero
"looks valid by chance" rate is exactly the seam Bleichenbacher's search exploits: it does not need
to guess the whole plaintext at once, only to keep finding ciphertext variants that pass this cheap
structural check, narrowing the possible plaintext range with each one.

Trade-offs & pitfalls

• If RSAES-PKCS1-v1_5 cannot be avoided for compatibility reasons, enforce strictly uniform error
  handling (one generic error, constant-time comparison, no distinguishable timing) and monitor for
  repeated malformed-ciphertext submissions, which is the operational signature of this attack in
  progress.
• Never let a hash/MGF1 mismatch surface as a security-relevant error message; treat it as a
  configuration bug to fix in the integration contract, not something to work around at runtime.
• In practice, prefer wrapping a symmetric key with an envelope-encryption service (a cloud Key
  Management Service, or a hardware key-management API such as PKCS#11) over hand-rolling RSA key
  wrapping at all; that pushes both the padding-scheme choice and its correct implementation onto
  audited, widely-reviewed code.

In the moment, I would stop the blame loop and focus on the shared outcome. I would acknowledge the miss, ask for the facts, and clarify the handoff point that failed. By handoff, I mean the moment one team passes work to another with clear expectations.

I would say something like, "Let's separate what happened from who to blame. What was the requirement, what was the agreed due date, and what did each side believe was done?" If our requirements were unclear, I would own that and propose the next concrete step, such as a revised spec, a quick review, or a smaller interim deliverable so the project does not stall completely.

For the next milestone, I would prevent repeat issues by adding written acceptance criteria, a short handoff checklist, and a scheduled signoff before work starts. For example, if an API needed three required fields and one edge-case behavior, I would list those explicitly in the ticket and get both teams to confirm them before implementation. That lowers ambiguity and makes accountability much easier.

Approach

Generate two large primes $p, q$ of roughly half the target bit length each using a cryptographically secure random source and Miller-Rabin primality testing (a PROBABILISTIC primality test, run enough rounds that the probability of falsely accepting a composite number is negligible), pick a fixed public exponent $e$ (65537 is standard, chosen because it is prime, has a small Hamming weight for fast public-exponent operations, and is large enough to avoid small-exponent attacks), verify $\gcd(e, \phi(n)) = 1$ so $e$ has a modular inverse, compute the private exponent $d = e^{-1} \bmod \phi(n)$, and validate that the resulting modulus $n = pq$ actually has the requested bit length before returning the key.

"""RSA key generation with Miller-Rabin primality testing (seeded RNG for reproducibility;
production code must use a CSPRNG such as `secrets`, never a seeded PRNG)."""
import math
import random


def is_probable_prime(n, rng, rounds=20):
    if n < 4:
        return n in (2, 3)
    if n % 2 == 0:
        return False
    d, s = n - 1, 0
    while d % 2 == 0:
        d //= 2
        s += 1
    for _ in range(rounds):
        a = rng.randrange(2, n - 1)
        x = pow(a, d, n)
        if x == 1 or x == n - 1:
            continue
        for _ in range(s - 1):
            x = (x * x) % n
            if x == n - 1:
                break
        else:
            return False
    return True


def gen_prime(bits, rng):
    while True:
        candidate = rng.getrandbits(bits) | (1 << (bits - 1)) | 1
        if is_probable_prime(candidate, rng):
            return candidate


def gen_rsa_keypair(bits, seed):
    rng = random.Random(seed)
    e = 65537
    while True:
        p = gen_prime(bits // 2, rng)
        q = gen_prime(bits - bits // 2, rng)
        if p == q:
            continue
        n = p * q
        phi = (p - 1) * (q - 1)
        if math.gcd(e, phi) != 1:
            continue
        d = pow(e, -1, phi)
        if n.bit_length() == bits:
            return {"n": n, "e": e, "d": d, "p": p, "q": q}


if __name__ == "__main__":
    key = gen_rsa_keypair(bits=32, seed=20260901)
    print(f"generated 32-bit toy key: p={key['p']} q={key['q']}")
    print(f"n={key['n']} (bit_length={key['n'].bit_length()})  e={key['e']}  d={key['d']}")

    m = 424242
    c = pow(m, key["e"], key["n"])
    m_back = pow(c, key["d"], key["n"])
    print(f"round trip: m={m} -> c={c} -> decrypt(c)={m_back}  (matches original: {m_back == m})")

Output:

generated 32-bit toy key: p=37699 q=61031
n=2300807669 (bit_length=32)  e=65537  d=1228481753
round trip: m=424242 -> c=411332014 -> decrypt(c)=424242  (matches original: True)

Key points

• Miller-Rabin writes $n - 1 = d \cdot 2^s$ and repeatedly tests random witnesses; each round that PASSES halves the probability of a false positive, so 20+ rounds (as used here) drives the error probability low enough to be cryptographically negligible, this test can prove COMPOSITENESS with certainty on a single failing witness, but can only make PROBABILISTIC claims of primality.
• The demo above uses random.Random(seed), a SEEDED, non-cryptographic pseudo-random generator, purely so this specific worked example is reproducible; real key generation MUST use a cryptographically secure source (Python's secrets module, or the operating system's CSPRNG, cryptographically secure pseudo-random number generator, directly), since a predictable seed for prime generation is a direct path to full private-key recovery.
• Checking $\gcd(e, \phi(n)) \neq 1$ and re-drawing $p, q$ rather than adjusting $e$ keeps $e$ fixed at the standard, widely-interoperable 65537 across every generated key, some other implementations instead vary $e$, but a fixed, small, standard exponent is the common convention.
• The round-trip check (encrypt then decrypt back to the original message) in the worked example is a cheap, direct sanity check that $e$, $d$, and $n$ are mutually consistent, independent of trusting the arithmetic that derived them.

Complexity

Generating each candidate prime costs one Miller-Rabin test per candidate (dominated by modular exponentiation, $O(b^3)$-ish for a $b$-bit candidate using schoolbook modular exponentiation, better with fast multiplication), and by the prime number theorem roughly one in every $\ln(2^b) \approx 0.69b$ random $b$-bit odd candidates is prime, so expected work per prime is $O(b)$ candidates times the cost of one primality test. Computing $d = e^{-1} \bmod \phi(n)$ via the extended Euclidean algorithm is $O(b^2)$ and negligible next to prime generation, which dominates total keygen time.

Edge cases

• $p = q$. Explicitly checked and rejected (re-draw both), since $n = p^2$ would make $n$ trivially factorable by taking a square root, catastrophic for security.
• $d$ turning out too small. This implementation does NOT check the resulting $d$'s bit length anywhere, only n.bit_length() == bits is checked, that is a real gap, not a rounding error in this explanation. An unusually small private exponent is recoverable by dedicated small-private-exponent attacks (Wiener's continued-fraction attack and its lattice-based extensions, a separate concern from small PUBLIC exponent attacks). A production implementation should add an explicit lower-bound check on $d$ right after computing it and re-draw $p, q$ (which forces a fresh $d$) if the check fails, that re-draw is a cheap defense once the check actually exists in the code.
• Resulting $n$ not landing at the exact requested bit length. Multiplying two $b/2$-bit primes does not automatically guarantee an $n$ of exactly $b$ bits (it can land one bit short if both primes' leading bits happen to multiply below the boundary); the implementation checks n.bit_length() == bits and retries otherwise, silently accepting an off-by-one-bit key would subtly weaken the claimed security level.
• A composite candidate slipping through Miller-Rabin. Astronomically unlikely at 20+ rounds, but not literally impossible; this is why the round-trip encrypt/decrypt check in the worked example, and in production a check that $e \cdot d \equiv 1 \pmod{\phi(n)}$ holds exactly, are worth doing as a final belt-and-suspenders validation rather than trusting primality testing alone.

Direct answer

Split the file into fixed-size chunks, encrypt each one independently with an AEAD (Authenticated Encryption with Associated Data) mode using a deterministic, counter-derived nonce, and bind each chunk's position and end-of-file status into the authenticated associated data (AAD) so the decryptor can detect reordering, duplication, or truncation. Handle key rotation with envelope encryption, each file is encrypted under its own randomly generated data key, and that data key is the thing wrapped under a longer-lived master key, so rotating the master key means re-wrapping small data keys, not re-encrypting file content.

Structured elaboration

Algorithms and modes

• AES-256-GCM, AES (the Advanced Encryption Standard) run in Galois/Counter Mode with a 256-bit key, or an equivalent AEAD construction, per chunk. AEAD is the right primitive family here specifically because it gives confidentiality and integrity together with no separate MAC (message authentication code) step whose ORDERING relative to decryption can be gotten wrong, exactly the class of bug that affects manually composed encrypt-then-MAC schemes.

Chunking and per-chunk nonce derivation

• Nonce = an 8-byte random salt generated fresh per FILE (via a cryptographically secure random source), concatenated with a 4-byte big-endian chunk counter. This guarantees uniqueness within a file as long as no file exceeds $2^{32}$ chunks and the per-file salt is never reused across files, and because the counter is deterministic rather than randomly drawn per chunk, the birthday-bound collision math that matters for a purely random-nonce scheme does not apply here at all, uniqueness is structural, not probabilistic.
• Fixed chunk size (for example, a power-of-two size chosen to balance overhead against granularity, discussed below) makes both encryption and decryption streamable: a writer never needs the whole file in memory, and a reader can decrypt starting at any chunk boundary without decrypting anything before it.

Metadata authentication

• Bind the chunk's INDEX and an explicit "is this the final chunk" flag into the AEAD's associated data for every chunk. Because the tag authenticates the AAD as well as the ciphertext, a decryptor that recomputes the AAD it EXPECTS for a given position, rather than trusting an AAD value carried alongside the ciphertext, will fail authentication on any chunk that has been moved, duplicated, or is missing its expected end-of-file marker.

Random access reads

• Because each chunk's nonce is fully determined by (per-file salt, chunk index), any single chunk can be decrypted independently, without touching any other chunk, which is exactly what random-access reads need. The cost is read granularity: a read that spans two chunks touches two independent decrypt calls, so the chunk-size choice below directly trades off against how fine-grained a "random access" read can be.

Key rotation without re-encrypting existing files

• Use envelope encryption: each file's chunks are encrypted under a randomly generated, file-specific data key, and that data key itself is encrypted ("wrapped") under a separate, longer-lived master key.
• Rotating the master key means re-wrapping every file's small data key, a cheap operation independent of file size, not re-encrypting the file's actual content. Content only needs full re-encryption if the DATA key itself, not the master key, is believed compromised.

Worked example

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from cryptography.exceptions import InvalidTag

KEY = AESGCM.generate_key(bit_length=256)
FILE_ID = bytes(range(8))     # random per-file salt so nonces never repeat across files
aead = AESGCM(KEY)

def chunk_nonce(file_id, chunk_index):
    """96-bit GCM nonce = 8-byte per-file random salt || 4-byte big-endian counter.
    Unique as long as no file exceeds 2**32 chunks and file_id is never reused."""
    return file_id + chunk_index.to_bytes(4, 'big')

def chunk_aad(chunk_index, is_last):
    """Authenticated (but not encrypted) metadata: binds each ciphertext chunk to its
    POSITION and whether it is the final chunk, so the decryptor can detect reordering,
    duplication, or truncation."""
    return chunk_index.to_bytes(4, 'big') + (b'\x01' if is_last else b'\x00')

def encrypt_file(chunks, key_aead):
    out = []
    for i, chunk in enumerate(chunks):
        is_last = (i == len(chunks) - 1)
        nonce = chunk_nonce(FILE_ID, i)
        aad = chunk_aad(i, is_last)
        ct = key_aead.encrypt(nonce, chunk, aad)
        out.append((nonce, aad, ct))
    return out

def decrypt_file(encrypted_chunks, key_aead, expected_count):
    plaintext = b''
    for i, (nonce, aad, ct) in enumerate(encrypted_chunks):
        is_last = (i == expected_count - 1)
        expected_aad = chunk_aad(i, is_last)
        # The decryptor recomputes the AAD it EXPECTS for position i and hands it to
        # the AEAD; it never trusts an AAD value carried alongside the ciphertext.
        plaintext += key_aead.decrypt(nonce, ct, expected_aad)
    return plaintext

chunks = [b'CHUNK-0:first  16B', b'CHUNK-1:second 16B', b'CHUNK-2:third  16B (last)']
encrypted = encrypt_file(chunks, aead)

recovered = decrypt_file(encrypted, aead, expected_count=len(chunks))
print('sequential decrypt matches original:', recovered == b''.join(chunks))

tampered = list(encrypted)
tampered[1], tampered[2] = tampered[2], tampered[1]   # attempt to reorder two chunks
try:
    decrypt_file(tampered, aead, expected_count=len(chunks))
    print('REORDERING WAS NOT DETECTED (this would be a broken scheme)')
except InvalidTag:
    print('reordering attempt raised InvalidTag at the swapped position: rejected')

truncated = list(encrypted[:2])   # drop the final chunk
try:
    decrypt_file(truncated, aead, expected_count=2)   # decryptor told (wrongly) count=2
    print('TRUNCATION NOT DETECTED via is_last flag (would be a broken scheme)')
except InvalidTag:
    print('truncation attempt raised InvalidTag: rejected')

Output:

sequential decrypt matches original: True
reordering attempt raised InvalidTag at the swapped position: rejected
truncation attempt raised InvalidTag: rejected

Reordering fails because the swapped chunk's ciphertext was authenticated under a different position's AAD than the one the decryptor now recomputes for that slot. Truncation fails because the decryptor recomputes an is_last=True AAD for the new final position, which does not match the AAD the (non-final) chunk was actually authenticated under.

Trade-offs and pitfalls

Chunk size is a genuine three-way trade-off: a larger chunk amortizes the fixed per-chunk tag overhead (GCM's authentication tag is a fixed size regardless of chunk size) over more data, but it coarsens random-access granularity and means a small in-place edit has to re-encrypt a larger chunk; a smaller chunk gives finer-grained seeks and cheaper partial updates at the cost of proportionally more tag overhead and more per-chunk encryption calls. A subtler pitfall lives in the truncation check itself, in the worked example above, decrypt_file's expected_count is a value the CALLER supplies, it is not itself authenticated by anything in the chunk stream. That is fine for the specific attack demonstrated (a caller who does not update expected_count to match a truncated stream gets a rejection), but a production design should not leave the expected total chunk count, or equivalently the expected file length, as an unauthenticated parameter a caller could be tricked into supplying incorrectly; the more robust version binds an authenticated file-level manifest (total chunk count, total length, or a hash of the chunk list) that is itself checked independently of any per-chunk flag, rather than relying solely on a per-chunk boolean.

Direct answer

Checking padding before the MAC (message authentication code), and returning a different error for each, leaks a single bit per request, "was the padding syntactically valid?", to anyone who can send arbitrary ciphertext. That single bit, repeated across many crafted ciphertexts, is enough to decrypt an entire intercepted block without ever learning the key: this is Vaudenay's padding-oracle attack, and it is a real, working attack against CBC (cipher block chaining) mode, not a theoretical concern.

Structured elaboration

Why the ordering matters. CBC decryption of a ciphertext block C_i produces intermediate = D_key(C_i), then XORs it with the previous block C_{i-1} to get the plaintext block. An attacker who can modify C_{i-1} (or, for the first block, the IV) controls the plaintext byte-by-byte, because flipping a bit in C_{i-1} flips the corresponding bit of the recovered plaintext directly. If the server checks PKCS#7 padding validity on that plaintext before checking the MAC, and reports the two failure modes differently, the attacker gets exactly the bit needed: for a guessed byte, does the resulting plaintext end in valid padding or not?

The attack, concretely. Working from the last byte of the target block backward, the attacker tries all 256 values for one byte of a crafted preceding block, holding the rest fixed to force a target padding value (0x01, then 0x02 0x02, and so on as each byte is recovered). Whichever guess produces "valid padding" reveals one byte of the AES (Advanced Encryption Standard) block cipher's raw intermediate output, which, XORed with the real preceding block, is the real plaintext byte. Repeating this 256 times per byte position, worst case, across 16 bytes, recovers an entire block using only the oracle's binary signal, no key access at all.

The fix. Verify the MAC first, in an Encrypt-then-MAC construction, over the untouched ciphertext, and reject with one generic error before ever attempting to interpret padding. Since the attacker cannot forge a valid MAC over crafted ciphertext bytes without the MAC key, every probe is rejected at that stage, and the padding-validity branch is never reached for attacker-controlled input, so there is no varying signal left to search on.

Worked example

"""
CBC-mode (Cipher Block Chaining) padding oracle against a server that
checks PKCS#7 padding BEFORE verifying the MAC (Message Authentication Code)
and returns a distinguishable error for each. A real, working Vaudenay-style
block-decryption oracle attack: the attacker never learns the AES key, only
the oracle's binary "padding valid / invalid" signal, and that alone is
enough to decrypt an intercepted block. Then the actual fix (verify the MAC,
computed Encrypt-then-MAC, BEFORE any padding is examined) is shown to close
the leak, using the same attack code against the reordered oracle. Uses the
`cryptography` library's raw AES-CBC primitive (no library-level padding, so
we control PKCS#7 ourselves). Pinned key/IV/plaintext throughout.
"""
import hashlib
import hmac
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes

BLOCK = 16
AES_KEY = bytes.fromhex("000102030405060708090a0b0c0d0e0f")   # pinned, synthetic
MAC_KEY = bytes.fromhex("ffeeddccbbaa99887766554433221100")   # separate key, Encrypt-then-MAC


def aes_cbc_encrypt_raw(key, iv, padded_plaintext):
    enc = Cipher(algorithms.AES(key), modes.CBC(iv)).encryptor()
    return enc.update(padded_plaintext) + enc.finalize()


def aes_cbc_decrypt_raw(key, iv, ciphertext):
    dec = Cipher(algorithms.AES(key), modes.CBC(iv)).decryptor()
    return dec.update(ciphertext) + dec.finalize()


def pkcs7_pad(data, block=BLOCK):
    pad_len = block - (len(data) % block)
    return data + bytes([pad_len]) * pad_len


def pkcs7_valid(data):
    pad_len = data[-1]
    if pad_len == 0 or pad_len > BLOCK:
        return False
    return data[-pad_len:] == bytes([pad_len]) * pad_len


def mac_tag(iv, ciphertext):
    return hmac.new(MAC_KEY, iv + ciphertext, hashlib.sha256).digest()


# ---- VULNERABLE server: decrypts and checks padding FIRST, and returns that
# result directly -- the MAC (if any) is checked only afterward, so it never
# gates what the attacker learns from the padding check.
def vulnerable_oracle(iv: bytes, ciphertext: bytes, tag: bytes) -> bool:
    """Returns True iff PKCS#7 padding is syntactically valid. This boolean
    IS the leak: real servers surface it as two different error codes/timings
    for 'padding failed' vs 'MAC failed', which is observably the same thing."""
    plaintext = aes_cbc_decrypt_raw(AES_KEY, iv, ciphertext)
    return pkcs7_valid(plaintext)


# ---- FIXED server: verify the MAC (computed Encrypt-then-MAC, over iv+ciphertext)
# FIRST, in constant time, and only inspect padding if it matches. A crafted
# probe reuses the original captured tag (the only tag the attacker has), but
# any change to iv/ciphertext bytes makes that tag invalid, so ALL crafted
# probes are rejected at the MAC stage -- padding is never even examined for
# attacker-controlled bytes.
def fixed_oracle(iv: bytes, ciphertext: bytes, tag: bytes) -> bool:
    expected = mac_tag(iv, ciphertext)
    if not hmac.compare_digest(expected, tag):
        return False  # single generic outcome; padding is never inspected
    plaintext = aes_cbc_decrypt_raw(AES_KEY, iv, ciphertext)
    return pkcs7_valid(plaintext)


def decrypt_block_via_oracle(prev_block: bytes, target_block: bytes, tag_to_reuse: bytes, oracle) -> bytes:
    """Recover the plaintext of target_block given the block preceding it in
    the real ciphertext, using only oracle()'s True/False signal."""
    intermediate = bytearray(BLOCK)
    plaintext = bytearray(BLOCK)

    for pos in range(BLOCK - 1, -1, -1):
        pad_val = BLOCK - pos
        crafted = bytearray(BLOCK)
        for j in range(pos + 1, BLOCK):
            crafted[j] = intermediate[j] ^ pad_val
        found = None
        for guess in range(256):
            crafted[pos] = guess
            if oracle(bytes(crafted), target_block, tag_to_reuse):
                if pos == BLOCK - 1:
                    # disambiguate a coincidental \x02\x02 (etc.) false positive
                    crafted2 = bytearray(crafted)
                    crafted2[pos - 1] ^= 0xFF
                    if not oracle(bytes(crafted2), target_block, tag_to_reuse):
                        continue
                found = guess
                break
        if found is None:
            return None  # oracle gave no distinguishing signal at all
        intermediate[pos] = found ^ pad_val
        plaintext[pos] = intermediate[pos] ^ prev_block[pos]
    return bytes(plaintext)


if __name__ == "__main__":
    secret = b"CVV=482;EXP=0929"  # exactly one AES block once padded
    padded = pkcs7_pad(secret)   # adds one full padding block (PKCS#7 rule: block=16 -> pad=16)
    iv = bytes.fromhex("101112131415161718191a1b1c1d1e1f")
    ciphertext = aes_cbc_encrypt_raw(AES_KEY, iv, padded)
    tag = mac_tag(iv, ciphertext)
    print("secret plaintext:  ", secret)
    print("ciphertext blocks: ", [ciphertext[i:i + BLOCK].hex() for i in range(0, len(ciphertext), BLOCK)])

    block0, block1 = ciphertext[0:BLOCK], ciphertext[BLOCK:2 * BLOCK]

    print("\n=== attack against the VULNERABLE oracle (padding checked first) ===")
    rec0 = decrypt_block_via_oracle(iv, block0, tag, vulnerable_oracle)
    rec1 = decrypt_block_via_oracle(block0, block1, tag, vulnerable_oracle)
    recovered = rec0 + rec1
    print("recovered via oracle only (no AES_KEY access):", recovered)
    print("matches original padded plaintext:", recovered == padded)

    print("\n=== same attack against the FIXED oracle (MAC checked first, Encrypt-then-MAC) ===")
    result = decrypt_block_via_oracle(iv, block0, tag, fixed_oracle)
    print("recovered block (should be None, no signal available):", result)

Output:

secret plaintext:   b'CVV=482;EXP=0929'
ciphertext blocks:  ['7bc50a5edb93c09e37e0238f31cf6889', '4bb3d57a71149adc5363eb4fdae62e29']

=== attack against the VULNERABLE oracle (padding checked first) ===
recovered via oracle only (no AES_KEY access): b'CVV=482;EXP=0929\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10'
matches original padded plaintext: True

=== same attack against the FIXED oracle (MAC checked first, Encrypt-then-MAC) ===
recovered block (should be None, no signal available): None

Against the vulnerable oracle (padding checked first), a 16-byte secret is fully recovered using only True/False padding-validity responses, no key access. Against the fixed oracle (MAC checked first, Encrypt-then-MAC), the exact same attack code returns None: none of the 256 guesses at any byte position ever produce a distinguishable response, because every crafted probe fails the MAC check before padding is ever examined.

Trade-offs and pitfalls

• A "fix" that returns the same error message text for both failures but still takes measurably different time to fail (padding check is fast, full MAC computation is slower, or vice versa) reopens the same leak as a timing side-channel; constant-time comparison and, ideally, doing both checks in a fixed order regardless of the padding result, matter as much as the error text.
• Reordering the checks is a protocol/implementation-level fix; the more robust protocol-level fix is switching to an AEAD (authenticated encryption with associated data) cipher, which has no separate padding step to attack at all, exactly why TLS (Transport Layer Security) 1.3 dropped CBC-mode cipher suites entirely rather than only telling implementers to check the MAC first.
• A common mistake is assuming the MAC "protects" the padding check because it runs afterward; the whole vulnerability is that the padding check ran first, so ordering, not merely the presence of a MAC, is the fix.

Direct answer

Before committing to a lateral pivot, prove the fit cheaply and prove the readiness credibly. Validate genuine interest and aptitude through a low-commitment experiment, a rotation, a shadow assignment, a small real project in the new discipline, before asking for the move, and build a small portfolio of evidence in the destination discipline's own terms, not your current discipline's terms.

Structured elaboration

Separate validating fit from proving readiness, they use different evidence. Fit is whether you actually enjoy and are suited to the day-to-day of the new discipline, learned through direct, low-stakes exposure. Readiness is whether you can perform credibly at an entry level in the new area, proven through a real deliverable.

Validate fit cheaply first. Shadow someone already doing the destination role for a defined period, take on a small real piece of that work alongside your current job, or an informal rotation if your organization supports one. The goal is finding out, before committing a year of your career, whether the actual daily texture of the work matches what you imagine it to be.

Prove readiness in the destination discipline's terms. A common mistake is presenting your current discipline's evidence and expecting it to translate automatically. It rarely does. A few illustrative pairs and what the evidence tends to look like:

• Moving from an engineering role toward product: a small product decision you drove, with the reasoning about user or business trade-offs made explicit, not just a technically strong build.
• Moving from an individual contributor (IC) technical role toward research: a well-scoped investigation with a clear question, method, and honestly reported result, not just a strong implementation.
• Moving from an analyst role toward engineering: something you built that runs reliably and that others depend on, not just an analysis that was correct once.

Build the relationships the destination discipline actually relies on before you need them for the move, so the people who'd eventually evaluate you already have direct exposure to your work in it.

Worked example

"I was drawn to an adjacent discipline but was honestly unsure whether I'd like the daily reality of it or just the idea of it. Rather than asking for the move outright, I asked to shadow someone in that role for a short period and separately took on one small, real piece of that kind of work alongside my existing responsibilities, with my manager's agreement that it was a bounded experiment, not a scope change. The shadowing told me quickly which parts matched what I expected and which didn't. The small real piece of work gave me something concrete, a deliverable that someone already doing that role could evaluate on its own terms, not on the terms of my original discipline. When I later raised the possibility of a fuller move, I brought that piece of work and named it plainly as evidence, rather than asking to be trusted based on enthusiasm alone."

Trade-offs & pitfalls

• Committing to a full pivot based on the idea of the new discipline rather than direct exposure to its actual day-to-day risks discovering the mismatch only after the move.
• Presenting evidence built for your current discipline and expecting a destination-discipline evaluator to translate it themselves. That's your job to do, not theirs.
• Treating the validation experiment as a favor you're owed rather than something you actively design and propose with a clear scope and end date, so it doesn't become an open-ended distraction.
• Be honest with yourself about a negative result. If the shadowing or small project reveals weaker fit than expected, that's a successful use of a cheap experiment, not a failure to be pushed past.

Direct answer

Confusion is the design goal of making the relationship between the key and the ciphertext as complex and nonlinear as possible, so an attacker cannot express the key algebraically from known plaintext/ciphertext pairs. Diffusion is the goal of spreading each input bit's influence across as much of the output as possible, so that statistical patterns in the plaintext do not survive into the ciphertext. Feistel networks and Substitution-Permutation Networks (SPNs) are the two classical paradigms for achieving both, and they differ mainly in HOW they guarantee invertibility (the ability to decrypt) while doing so.

Structured elaboration

Feistel networks. Each round splits the block into two halves and computes $(L, R) \to (R, L \oplus F(R, K_i))$, where F is a round function that need NOT itself be invertible or even a permutation: it can be arbitrarily complex, since the Feistel structure's swap-and-XOR shape guarantees the WHOLE round is invertible regardless of what F does inside. Confusion comes from F's nonlinearity (S-boxes, modular arithmetic); diffusion builds up gradually as each half repeatedly feeds into the other across many rounds. DES (the Data Encryption Standard, a 16-round Feistel cipher) is the classic real-world example.

Substitution-Permutation Networks (SPNs). Every round transforms the FULL block through two layers: a substitution layer (parallel, independent, small nonlinear S-boxes, providing confusion) and a permutation/mixing layer (a linear transformation that spreads bits across positions, providing diffusion). Unlike a Feistel round function, every individual component here MUST be invertible on its own, since there is no swap-based trick to fall back on; decryption simply runs the inverse of each layer in reverse order. AES (a full-block SPN) is the classic real-world example.

Comparison.

Worked example

Diffusion made concrete: flip exactly ONE plaintext bit and measure how many output bits change, for AES (a full SPN with 10 rounds) versus a toy 4-round Feistel cipher whose round function is deliberately weak (pure XOR, no substitution at all), to show what diffusion failure actually looks like when the nonlinear/mixing machinery is missing:

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes

def hamming(a, b): return sum(bin(x ^ y).count("1") for x, y in zip(a, b))

key = bytes.fromhex("2b7e151628aed2a6abf7158809cf4f3c"[:32])
p1 = bytes.fromhex("6bc1bee22e409f96e93d7e117393172a"[:32])
p2 = bytearray(p1); p2[0] ^= 0x01
p2 = bytes(p2)

enc = Cipher(algorithms.AES(key), modes.ECB()).encryptor()
c1 = enc.update(p1) + enc.finalize()
enc2 = Cipher(algorithms.AES(key), modes.ECB()).encryptor()
c2 = enc2.update(p2) + enc2.finalize()
print(f"AES: output bits changed = {hamming(c1, c2)} / 128 ({hamming(c1, c2)/128:.1%})")

def weak_round_function(half, round_key):
    return bytes(a ^ b for a, b in zip(half, round_key))  # pure XOR: no nonlinearity, no mixing

def tiny_feistel_encrypt(block16, rounds, round_keys):
    left, right = block16[:8], block16[8:]
    for r in range(rounds):
        f_out = weak_round_function(right, round_keys[r % len(round_keys)])
        left, right = right, bytes(a ^ b for a, b in zip(left, f_out))
    return left + right

round_keys = [bytes([i]*8) for i in range(1, 5)]
c1f = tiny_feistel_encrypt(p1, 4, round_keys)
c2f = tiny_feistel_encrypt(p2, 4, round_keys)
print(f"toy weak Feistel: output bits changed = {hamming(c1f, c2f)} / 128 ({hamming(c1f, c2f)/128:.1%})")

Output:

AES: output bits changed = 60 / 128 (46.9%)
toy weak Feistel: output bits changed = 1 / 128 (0.8%)

AES's full round structure (S-boxes plus MixColumns) spreads a single flipped input bit to nearly half of the output bits, close to the ideal 50% an unpredictable random function would give. The toy Feistel cipher, built with a deliberately non-diffusing (pure-XOR) round function, barely moves the needle: the flipped bit stays almost entirely localized. This isolates WHY the round function's internal design matters, not just the number of rounds: a real Feistel cipher's F includes genuine nonlinear substitution, which is what actually produces AES-level diffusion in a Feistel structure too, over enough rounds.

Trade-offs and pitfalls

• Neither paradigm is universally "better"; the choice is a real engineering trade-off between round-function freedom (Feistel) and per-round parallelism and hardware throughput (SPN).
• A common misconception is that Feistel structures are inherently weaker; DES's real weaknesses (small 56-bit effective key, not enough rounds by modern standards) are separate from the Feistel PARADIGM itself, which is still used in modern designs (some lightweight and format-preserving ciphers).
• Comparing round counts alone across paradigms is misleading: a Feistel round only transforms half the block, so "rounds" are not directly comparable between a 16-round Feistel cipher and a 10-round SPN without accounting for how much of the state each round actually touches.

Direct answer

Run $W$ independent pseudorandom walks (workers) over the group, each using the same iteration function $f$ but a different random starting point, and instead of looking for a cycle within a single walk (as sequential Pollard's rho does), report each walk's distinguished points (DPs: group elements satisfying a cheap, rare, checkable predicate, e.g. "the low $t$ bits are zero") to a shared collector. A collision, the same group element reported by two different workers, immediately yields the discrete logarithm (DL) via simple algebra, without needing every worker to have completed a full cycle. Because the birthday-paradox collision (the birthday paradox: drawing roughly $\sqrt{N}$ random values from a space of size $N$ makes two of them coincide with good odds well before you have sampled anywhere near all of $N$, the same reason a room of only about 23 people is enough for two of them to likely share a birthday) only needs about $\sqrt{\pi N/2}$ total steps summed across all workers, adding workers divides that total almost evenly, giving near-linear speedup: memory only holds distinguished points, not every step, so it stays small and controllable via the DP density.

Structured elaboration

Worker responsibilities. Each worker $i$ picks a random exponent pair $(a_i,b_i)$, sets its starting point $X_i = g^{a_i}h^{b_i}$, and repeatedly applies the shared walk function $f$ (partitioning the current point into, say, 3 branches based on a hash of its value, and correspondingly updating $(a,b)$: squaring the point and doubling $(a,b)$, multiplying by $g$ and incrementing $a$, or multiplying by $h$ and incrementing $b$). After each step it tests the distinguished-point predicate; on a hit it sends $(X, a, b, \text{worker id})$ to the collector and keeps walking from its current state (it does not restart).

Choosing the DP predicate. The predicate must be cheap to evaluate (a bitmask check, not a hash) and tunably rare, controlled by a bit-count $t$ so a fraction $\approx 1/2^t$ of points qualify. Smaller $t$ means more frequent reports (faster collision detection, more storage and network traffic); larger $t$ means less overhead per report but a longer average gap between them and more risk of missing the collision point efficiently. Practical choices target a manageable report rate for the collector's storage and bandwidth budget rather than a fixed universal constant.

Collision detection and handling. The collector keeps a hash table keyed by group element. On receiving $(X,a,b,\text{id})$, it checks whether $X$ is already stored; if the existing entry came from a different worker, that is a usable collision: two different exponent pairs $(a_1,b_1) \ne (a_2,b_2)$ reaching the same point means $g^{a_1}h^{b_1} = g^{a_2}h^{b_2}$, so $a_1 + b_{1}x \equiv a_2+b_{2}x \pmod N$, giving $x = (a_1-a_2)(b_2-b_1)^{-1} \bmod N$ whenever $\gcd(b_2-b_1,N)=1$ (guaranteed if the group has prime order $N$). A same-worker repeat just marks an unproductive cycle in that worker's own walk and can be discarded or used to restart it.

Expected speedup and memory. Because collision probability accumulates over the total number of points visited by all workers combined (a birthday-paradox argument over one shared point space), the expected total number of steps before a collision is about $\sqrt{\pi N/2}$ regardless of how that work is split, so $W$ workers each need only about $\sqrt{\pi N/2}/W$ steps on average: close to linear speedup, unlike sequential rho where one worker alone must do the whole $\sqrt{\pi N/2}$. Memory is $O(1/\text{density})$ per distinguished point stored, not $O(\sqrt N)$, since only rare DPs are kept centrally rather than every visited point.

Pitfalls. Load imbalance arises when workers are heterogeneous (different CPU speeds, or unlucky walks that wander into short unproductive functional-graph tails), wasting wall-clock time waiting on stragglers rather than reallocating budget to faster workers; the fix is to let each worker run to a shared total-step or total-DP budget rather than a fixed per-worker step count. Packetizing randomness, splitting the random-number source across workers, must give every worker a genuinely independent starting point and (if $f$ itself is randomized, e.g. via a keyed hash for the branch selector) an identical copy of that keyed function, since workers must walk with the same $f$ for a shared collision to imply the same algebraic relation; correlated starting seeds across workers effectively shrinks the birthday-paradox sample space and wastes work on walks likely to retrace each other.

Worked example

import random
from math import gcd

p = 10007          # safe prime: p-1 = 2*q
q = 5003           # q is prime, confirmed by trial division
N = q              # work in the prime-order-q subgroup so (b1-b2) is always invertible mod N
g = pow(2, 2, p)   # 2 is a primitive root mod p; squaring gives an element of order q
x_secret = 3891
h = pow(g, x_secret, p)
print(f"p={p}, N=q={N}, g={g} (order {N}), secret x={x_secret}, h={h}")

def f(X, a, b):
    branch = X % 3
    if branch == 0:
        return (X*X) % p, (2*a) % N, (2*b) % N
    elif branch == 1:
        return (X*g) % p, (a+1) % N, b
    else:
        return (X*h) % p, a, (b+1) % N

T = 6  # distinguished-point predicate: X % 2^T == 0 (density ~1/64)
def is_dp(X): return X % (2**T) == 0

random.seed(20260901)
W, MAX_STEPS = 8, 4000
dp_store, collision, total_steps = {}, None, 0

for worker_id in range(W):
    a, b = random.randrange(N), random.randrange(N)
    X = (pow(g, a, p) * pow(h, b, p)) % p
    for _ in range(MAX_STEPS):
        X, a, b = f(X, a, b)
        total_steps += 1
        if is_dp(X):
            if X in dp_store and dp_store[X][2] != worker_id:
                collision = (X, a, b, worker_id, *dp_store[X])
                break
            dp_store.setdefault(X, (a, b, worker_id))
    if collision:
        break

print("distinguished points collected:", len(dp_store), " total steps:", total_steps)
X, a1, b1, w1, a2, b2, w2 = collision
print(f"collision at X={X}: worker {w1} (a1={a1},b1={b1}) vs worker {w2} (a2={a2},b2={b2})")
db = (b1 - b2) % N
print("gcd(b1-b2, N) =", gcd(db, N))
x_rec = ((a2 - a1) % N) * pow(db, -1, N) % N
print("recovered x =", x_rec, " matches secret:", x_rec == x_secret)

Output:

p=10007, N=q=5003, g=4 (order 5003), secret x=3891, h=1858
distinguished points collected: 1  total steps: 4056
collision at X=2432: worker 1 (a1=584,b1=246) vs worker 0 (a2=3219,b2=4599)
gcd(b1-b2, N) = 1
recovered x = 3891  matches secret: True

Worker 0 exhausted its full 4,000-step budget without a cross-worker collision (its own walk was the first to populate the distinguished-point store), then worker 1 collided with one of worker 0's stored points after only 56 steps; recovering $x$ from the two exponent pairs gives back the correct secret exactly, confirming the collision equation.

Trade-offs and pitfalls

A subtle correctness requirement the toy example makes concrete: working in a prime-order subgroup ($N=q=5003$, prime) guarantees $\gcd(b_1-b_2,N)=1$ whenever $b_1\ne b_2$, so the inverse in the recovery formula always exists; running the same attack directly in the full group of order $p-1$ (which factors as $2\times5003$ here) can produce a non-invertible difference and only narrows $x$ to a small set of candidates instead of pinning it exactly, a real edge case worth handling explicitly rather than assuming away.