HardTechnical

28 practiced

Implement RSA key generation and signature using Chinese Remainder Theorem (CRT) optimization in your language of choice. The implementation should: generate strong primes, compute CRT parameters (dp, dq, qinv), sign via CRT, and include a blinding step to mitigate timing attacks. After coding, explain security considerations such as prime quality, randomness, blinding correctness, and side-channel/fault attack mitigations.

Sample Answer

**Approach (brief)**- Generate two strong primes p,q (each with a large prime factor in p-1 and p+1), compute n=p*q, φ=(p-1)*(q-1), choose e (65537), compute d = e^{-1} mod φ, CRT params dp=d mod (p-1), dq=d mod (q-1), qinv=q^{-1} mod p. - Sign using CRT on a blinded message to mitigate timing: pick random r∈Z_n^*, compute m' = m * r^e mod n, compute s' = (m')^d via CRT, unblind s = s' * r^{-1} mod n.

Code (Python, minimal dependencies):

python

import secrets
from math import gcd

# modular inverse
def inv(a,m): return pow(a, -1, m)

# Miller-Rabin
def is_prime(n, k=16):
    if n<2 or n%2==0: return n==2
    d, s = n-1, 0
    while d%2==0:
        d//=2; s+=1
    for _ in range(k):
        a = secrets.randbelow(n-3)+2
        x = pow(a,d,n)
        if x in (1, n-1): continue
        for __ in range(s-1):
            x = (x*x) % n
            if x==n-1: break
        else: return False
    return True

# generate a "strong" prime: ensure p-1 has a large prime factor r
def gen_strong_prime(bits):
    while True:
        r = secrets.randbits(bits//2) | 1
        if not is_prime(r): continue
        # try p = k*r + 1
        k = secrets.randbits(bits - r.bit_length())
        p = k * r + 1
        p |= (1 << (bits-1)) | 1
        if p.bit_length()!=bits: continue
        if is_prime(p): return p

def generate_rsa(bits=2048, e=65537):
    half = bits//2
    p = gen_strong_prime(half); q = gen_strong_prime(half)
    if p==q: q = gen_strong_prime(half)
    n = p*q
    phi = (p-1)*(q-1)
    d = inv(e, phi)
    dp = d % (p-1); dq = d % (q-1)
    qinv = inv(q, p)
    return {'n':n,'e':e,'d':d,'p':p,'q':q,'dp':dp,'dq':dq,'qinv':qinv}

# CRT sign (assumes 0 <= m < n)
def crt_sign(m, key):
    p=key['p']; q=key['q']; dp=key['dp']; dq=key['dq']; qinv=key['qinv']
    s1 = pow(m, dp, p)
    s2 = pow(m, dq, q)
    h = ((s1 - s2) * qinv) % p
    return (s2 + q*h) % (p*q)

# blinded signing
def sign_with_blinding(m, key):
    n=key['n']; e=key['e']
    while True:
        r = secrets.randbelow(n-1)+1
        if gcd(r,n)==1: break
    r_e = pow(r, e, n)
    m_bl = (m * r_e) % n
    s_bl = crt_sign(m_bl, key)
    r_inv = inv(r, n)
    return (s_bl * r_inv) % n

Security considerations- Prime quality: strong primes reduce certain classical factoring/torus attacks; ensure primes pass many MR rounds, use vetted generators and entropy from CSPRNG. - Randomness: secrets module or OS CSPRNG; seed leaks are catastrophic. - Blinding correctness: use r∈Z_n^*, unblind by r^{-1}; ensure ephemeral r per operation and check gcd(r,n)=1. - Side-channels/faults: CRT reduces time — but introduces fault attack risks (Bellcore). Use CRT with verification step: after CRT signature compute s and verify s^e ≡ m (mod n); if mismatch, fall back to full pow(m,d,n) or abort. Protect implementation with constant-time modular exponent routines, avoid branches on secret data, and harden against induced faults (redundant computation, RSA-CRT error-detection).

MediumTechnical

31 practiced

Explain zero-knowledge proofs (ZKPs): define completeness, soundness, and zero-knowledge. Distinguish interactive ZKPs from non-interactive variants (Fiat-Shamir heuristic), and give a practical use-case (for example, authentication without revealing a secret). Describe a project where you used or would use ZKPs and how you handled performance and trust assumptions.

EasyTechnical

23 practiced

Describe your experience using or contributing to cryptographic libraries (such as OpenSSL, BoringSSL, libsodium, cryptography.io, or hardware SDKs). Provide concrete examples: APIs you used, bug fixes or features you implemented, tests you wrote, security reviews you participated in, and lessons learned about safe integration and dependency management.

Sample Answer

**Summary of experience**

I have 5+ years integrating and contributing to cryptographic libraries (OpenSSL, libsodium, BoringSSL) and to hardware crypto SDKs (TPM2.0, Intel SGX crypto enclaves) in production systems.

**Concrete examples**

- APIs used: OpenSSL EVP (EVP_DigestInit/Update/Final, EVP_CipherInit_ex, EVP_PKEY_* for signatures), libsodium high-level APIs (crypto_box, crypto_aead_chacha20poly1305_ietf, crypto_sign), and BoringSSL primitives when porting TLS stacks.- Bug fix: Identified and fixed a non-constant-time modular reduction path in a project wrapper using OpenSSL BN_mod_exp which leaked key-dependent timing. Rewrote hot path to use constant-time modular functions and added comment referencing the timing risk.- Feature: Added libsodium-based hybrid key agreement (X25519 + HKDF) into our key-management module, exposing a simple authenticated-encryption API for application teams.

**Testing & reviews**

- Wrote unit tests covering edge cases (zero/non-canonical inputs), interoperability tests against reference vectors (RFC 8439, RFC 7748), and property tests using randomized inputs.- Added CI fuzzing with LibFuzzer and corpus seeds from Wycheproof; triaged crashes and upstreamed fixes where appropriate.- Participated in security reviews: threat modeling for key lifecycle, cryptographic parameter review (curve choices, AEAD modes), and dependency security triage for CVEs. Supported a CVE patch backport for an OpenSSL CVE in our distro packaging.

**Lessons learned / best practices**

- Always prefer vetted high-level APIs (libsodium/Easy) over raw primitives unless you must implement new protocols.- Enforce constant-time constraints, validate inputs, and use canonical encoding to prevent malleability.- Pin dependencies, subscribe to security feeds, and maintain reproducible builds; stage upgrades with interoperability and fuzz tests.- Document security rationale in code reviews so reviewers can verify design choices.

This experience balances cryptographic design, safe integration, and operational vulnerability management.

HardTechnical

31 practiced

You discover a replay vulnerability in a company's custom authentication protocol. Propose a concrete redesign that prevents replay attacks (choose between nonces, timestamps with freshness windows, sequence numbers, or challenge-response), explain the protocol flows, describe how you would test the fix, and outline a backward-compatible migration plan for existing clients.

Sample Answer

**Approach (choice & rationale)** I would adopt a challenge–response protocol using nonces (server-generated) combined with per-session keys and optional timestamps for freshness. Challenge–response with server nonces prevents replay without requiring client clocks and keeps messages short and provable.

**Protocol flows (concrete)** 1. Client -> Server: Hello, ClientID 2. Server -> Client: Nonce_S, SessionParams, Sig_S(Nonce_S, ClientID, Params) 3. Client verifies Sig_S, computes Response = MAC_K(ClientSecret, Nonce_S || Timestamp_opt), sends Client -> Server: ClientID, Response, Sig_C(Response || Nonce_S) 4. Server verifies Sig_C and MAC, checks Nonce_S unused for this ClientID and within expiry, then issues session token.

Notes: Signatures protect negotiation; MAC binds secret to server nonce. Server keeps short-lived store of seen nonces per client (e.g., bloom filter or keyed hash with expiry).

**Why secure** - Replayed Response using old Nonce_S fails because server only accepts current/non-replayed nonces. - No reliance on client clock eliminates drift issues. - Combining signatures and MACs prevents nonce substitution and MitM.

**Testing plan** - Unit tests: verify rejects duplicate Nonce_S, invalid MAC/Sig. - Fuzzing: mutate messages, reorder. - Integration: simulate network delays and replays (capture&replay tools). - Formal model: model protocol in Tamarin/ProVerif to prove injective agreement and replay resistance.

**Backward-compatible migration** - Phase 1: Server supports legacy and new modes; advertise supported modes in Hello/HelloAck. - Phase 2: Roll out client SDK update; prefer new mode when available. - Phase 3: Monitor usage and gradually deprecate legacy after analytics and security window (e.g., 90 days). - For older clients that cannot update, require network-level compensations (TLS mutual auth) or issue short-lived bridging tokens and schedule mandatory upgrade.

**Operational considerations** - Nonce store: use bounded LRU or time-partitioned keyed HMAC logs to avoid unbounded memory. - Rate-limit authentication attempts and log anomalies. - Rotate keys and include key identifiers in messages for smooth key rollover.

MediumTechnical

25 practiced

Walk through your threat-modeling process for a new cryptographic protocol. List assets, define attacker capabilities and goals, identify trust boundaries, enumerate attack vectors (including side-channels and supply chain risks), state security goals and assumptions, and explain how you prioritize mitigations and validate them.

Sample Answer

**Overview / approach**I follow a repeatable, risk-driven threat-model: enumerate assets, define adversary model & goals, map trust boundaries, enumerate attack vectors (including side‑channels and supply chain), state security goals and assumptions, then prioritize and validate mitigations iteratively.

**Assets**- Long‑term keys, session keys, ephemeral randomness- Plaintext confidentiality, integrity, auth tags- Protocol state, logs, key‑management infrastructure, firmware/binaries

**Attacker capabilities & goals**- Passive eavesdropper; active MITM; chosen‑plaintext/ciphertext; insiders; supply‑chain adversary who can modify code or hardware; physical access enabling side‑channels- Goals: key extraction, message forgery, downgrade, replay, privacy compromise

**Trust boundaries**- Client ↔ server network; HSM/TPM vs host; CI/CD pipeline vs production; vendor firmware vs device

**Attack vectors**- Cryptanalysis (algorithm/parameter weaknesses)- Protocol flaws (replay, binding issues)- Implementation bugs (padding, RNG)- Side‑channels: timing, power, electromagnetic, cache- Supply chain: compromised libraries, CI artifacts, hardware trojans

**Security goals & assumptions**- Confidentiality, integrity, forward secrecy, resistance to key compromise impersonation- Assume adversary can't break recommended primitives (e.g., AES‑GCM, X25519) within security margin; assume secure entropy source unless audited

**Prioritization of mitigations**- Risk = likelihood × impact. Prioritize: cryptanalysis/algorithmic flaws and key‑exposure paths > implementation bugs > low‑probability hardware trojans- Apply layered defenses: choice of conservative primitives, defense in depth (HSMs, signed artifacts), hardened implementations, constant‑time coding, code audits, reproducible builds

**Validation**- Formal methods for core protocol proofs (game‑based), TLA+/ProVerif for protocol logic- Fuzzing, differential testing, side‑channel leakage testing (TVLA), hardware probes- Supply‑chain: SBOM, signed CI artifacts, reproducible builds, vendor audits, ephemeral keys for provisioning- Threat re‑assessment after changes; red‑team exercises and responsible disclosure handling

This process balances mathematical assurance, implementation hygiene, and operational controls to reduce both theoretical and practical attack surfaces.

Your Background in Cryptography Questions

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Unlock Full Question Bank