Senior Cryptographer Interview Preparation Guide - FAANG Standards

Experiment design — goal: confirm whether secret-dependent instantaneous power leaks information exploitable by DPA.

1. Test vectors

• Use chosen-plaintexts/plaintexts randomized per capture; include both (a) fixed key, many random inputs (10k–1M traces) and (b) fixed intermediate value sets (to amplify leakage) for controlled checks.
• Target a single intermediate (e.g., S-box output bit or Hamming weight of byte after key xor) per hypothesis.

2. Measurement equipment & setup

• High-bandwidth oscilloscope or digitizer (≥200–500 MHz analog BW, ≥1 GS/s) or specialized SCA board (ChipWhisperer, Riscure Inspector).
• Low-inductance current probe on Vdd/GND or a small shunt resistor with differential amplifier; ground reference and common-mode rejection.
• Trigger: device-driven trigger (GPIO) marking start of crypto operation.
• Environmental control: Faraday cage, regulated power supply, temperature control.

3. Trace acquisition & preprocessing

• Capture 10k–1M aligned traces per experiment depending on SNR.
• Align traces using the hardware trigger; refine with cross-correlation/template matching or feature-based alignment (peak correlation, dynamic time warping).
• Preprocess: DC removal, band-pass or low-pass filtering, decimation, optional PCA/ICA or wavelet denoising to increase SNR.

4. Statistical methods to confirm leakage

• Classic Difference-of-Means DPA: partition traces by predicted bit (0/1) and compute D(t) = mean0(t) − mean1(t); peaks imply leakage.
• Correlation Power Analysis (CPA): compute Pearson correlation between predicted power model (Hamming weight/bit) and measured samples across time; evaluate maximum correlation.
• Welch’s t-test (non-profiled): compute t-statistic across fixed vs random sets; use threshold (e.g., |t|>4.5) to claim leakage.
• Template attack (profiling) if practical: build multivariate Gaussian models from profiling device and test on target.
• Metrics: SNR, maximum correlation, number of traces to success, guessing entropy.

Countermeasures

1. Algorithmic — Masking

• First-order Boolean masking: split sensitive intermediate x into x1,x2 with x = x1 ⊕ x2; ensure fresh randomness per operation and independent masks.
• Higher-order masking for protection against higher-order DPA; use secure logic for non-linear ops (secure S-box evaluation via table recombination or arithmetic masking).
• Threshold Implementation (TI): implement masked nonlinear functions with provable first-order security and glitch resistance in hardware description.
• Implementation notes: ensure independent randomness source with proper CTRNG/DRNG conditioning; avoid reuse, protect randomness path, enforce constant-time and avoid secret-dependent control flow.

2. Hardware — noise & hiding

• Addition of randomized clock jitter or frequency dithering to decorrelate alignment.
• Current flattening: decoupling capacitors and on-chip regulators, switched-capacitor smoothing.
• Dual-rail/pre-charge logic or WDDL to balance instantaneous power independently of data.
• Random instruction injection / dummy operations to increase required trace count.
• Physical shielding: grounded Faraday cage, on-die metal shields; PCB layout: separate analog ground, low-inductance power rails; insertion of EMI filters.
• Sensors/tamper-detection to disable crypto when probing suspected.

Testing plan to verify mitigations

• Baseline: reproduce original DPA and quantify traces-to-success (TTS), SNR, max correlation, guessing entropy.
• For each mitigation: incrementally deploy (masking only; masking+TI; hiding only; combo) and rerun attacks with identical acquisition conditions.
• Metrics to collect: TTS vs attack type (CPA, DPA, higher-order), success rate, SNR reduction, leakage t-test pass/fail, entropy reduction.
• Use higher-order attacks and profiling (template) to validate masking; use combined CPA+alignment attacks to test hiding efficacy.
• Acceptance criteria: TTS increases beyond practical bound (e.g., >1e7 traces), t-test below threshold, guessing entropy near keyspace level for realistic budgets.
• Continuous validation: randomized production-sample testing and fault-injection / side-channel certification tests (e.g., ISO 17825 / Common Criteria SCA guidance).

Reasoning: choose Hamming-weight/bit models because internal CMOS switching correlates with bit transitions; use correlation and t-tests to detect both linear and mean shifts; combine algorithmic masking (removes data-dependency) with hiding/noise (reduces SNR) and confirm via quantitative metrics so mitigations are measurable and not security-by-obscurity.

Scope & Goals
Define an X.509 profile that lets a relying client verify a chain using either a classical signature (e.g., ECDSA) or a post-quantum (PQ) signature (e.g., Dilithium). Support three operational modes: Transition (either signature acceptable), Dual-signed (both signatures present and verifiable), and Hybrid (single signature using a hybrid scheme OID).

Certificate additions / changes

• Leave core fields unchanged (tbsCertificate, signatureAlgorithm, signatureValue).
• Require SubjectPublicKeyInfo (SPKI) to carry primary public key and optionally an alternative public key:
  • id-ce-altSubjectPublicKeyInfo (NEW extension; ASN.1 SEQUENCE of { algorithm OID, publicKey BIT STRING })
  • non-critical for transition; MUST be critical for Dual-signed mode to prevent downgrade.
• Carry alternative signature(s):
  • id-ce-altSignature (NEW extension; SEQUENCE of one or more { sigAlg OID, signature OCTET STRING, signerInfo OPTIONAL }) — non-critical in transition, critical in Dual-signed mode.
• Policy/control OIDs:
  • id-pe-dualAlgPolicy (NEW authority policy OID) indicating mode: transition/dual/hybrid, and minimum acceptable algorithms and parameter sets.
• CertificatePolicies: include explicit policy OIDs for algorithm acceptance sets.
• KeyUsage/ExtendedKeyUsage: unchanged but must be compatible with each SPKI.

How to convey alternative signatures

• Primary signature remains in certificate.signatureValue using signatureAlgorithm OID (classical or PQ).
• Alternative signatures packed into id-ce-altSignature as additional (sigAlg, signature) entries.
• If a different public key is needed to verify an altSignature, include corresponding id-ce-altSubjectPublicKeyInfo entry with matching algorithm OID. Map altSignature entries to altSPKI by index or signerInfo reference.

Client trust and verification decisions
Verification algorithm:

1. Discover policy: read id-pe-dualAlgPolicy or CertificatePolicies to learn allowed modes and alg sets.
2. Build chain as usual. For each cert in chain, collect available (SPKI, signatureAlg, signature) pairs: (primarySPKI, primarySig), plus each (altSPKI if present, altSig).
3. Policy-driven acceptance:
   • Transition mode: accept chain if any consistent sequence of signatures verifies from leaf up to a trusted root using allowed algorithms.
   • Dual-signed mode: require that for each certificate either (a) both signatures verify (if both present) or (b) the cert is rejected if a required signature is missing/invalid. If critical alt extensions present and missing/invalid, reject.
   • Hybrid mode: require that signatureAlgorithm OID is a hybrid OID; verify accordingly.
4. Algorithm policy checks: ensure each algorithm/scheme and parameter set is in the allowed list and not deprecated. Enforce key sizes/parameter checks for SPKIs.
5. Anti-downgrade: if chain contains mixed algorithm levels, consult policy: reject if attacker could substitute a weaker single-signed cert where a dual-signed critical extension mandates both signatures.
6. Trust anchors: trust stores must enumerate acceptable algorithm families or specify per-anchor policy (e.g., accept anchor ECDSA but require at least one PQ-signed cert in chain).

Security considerations & trade-offs

• Dual-signed critical enforces stronger transition safety but increases certificate size and CA complexity.
• Non-critical alt extensions ease deployment but permit downgrade attacks unless clients enforce local policy.
• Mapping altSignature to altSPKI must be unambiguous; include signerInfo index to avoid confusion.
• Recommend canonical OIDs: reuse existing signatureAlgorithm OIDs for known hybrids where standardized; otherwise register new OIDs for id-ce-altSignature and id-ce-altSubjectPublicKeyInfo.

Operational notes

• CA must include both SPKIs when issuing alt signatures referencing different keys.
• CRLs/OCSP: responses should indicate which signature was verified if relevant to policy auditing.
• Recommend initial Transition mode with non-critical alt extensions, then gradually move to Dual-signed critical for maturity.

Approach summary
Describe criteria that separate a theoretical reduction in complexity from a real-world break, then propose an empirical test to validate exploitability.

Heuristics / criteria (≥5)

• Attack complexity vs. concrete costs — compare asymptotic savings to wall-clock and CPU/GPU costs (energy, $). A 2^1.1 vs 2^n is meaningless if constant factors make it slower.
• Required resources — memory, parallelism, special hardware (FPGA/ASIC/GPU) and whether those are practical or proprietary.
• Data/model assumptions — need for chosen plaintext, many target keys, oracle access, latency-free interaction, or quantum resources.
• Success probability and error rates — whether attack needs many retries or has low probability per trial.
• Precomputation and amortization — large precompute (table, sieves) may be feasible for mass surveillance but not targeted attacks.
• Implementation/side-channel dependence — if attack relies on idealized math but real implementations leak or mitigate differently.
• Time-to-exploit and operational constraints — setup time, detectability, and required protocol modifications.

Empirical test
Implement a proof-of-concept on realistic hardware: build the attack pipeline with same libraries, measure end-to-end time, memory, success rate on a representative sample, and attempt to break a test instance under protocol constraints (network latency, limited queries). Record resource consumption and extrapolate to target scale; if measured cost << defender’s operational thresholds, treat as practically exploitable.

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.

Situation / core issue
If an ECDH implementation accepts unvalidated public points, an attacker can send a point that lies off the intended large prime-order subgroup (on a small-order subgroup or on the twist). The resulting shared secret = [d]Q then reveals d modulo the small subgroup order, leaking private-key bits across repeated interactions.

Attack sketch (small-subgroup / invalid-curve)

• Attacker chooses Q of small order r (e.g., r = 2, 4, 8 or other small factor).
• Honest party computes S = [d]Q. Because Q has order r, S takes only r possible values; attacker observes or derives S (or a function of it) and learns d mod r.
• Repeating with points of different small orders (or different twists) yields congruences on d; attacker combines them (CRT-like) to recover d or enough bits to mount further attacks (key recovery, impersonation).

Key equation (subgroup check):

[n] Q  =  O

Plain English: multiplying Q by group order n should give the point at infinity O for a valid subgroup element.

Why twist attacks matter
A point on the quadratic twist satisfies the twist curve equation, not the intended curve; naive on-curve checks can be bypassed if implementers check a wrong curve model. Shared secret computed with twist point still leaks d mod order(twist-subgroup).

Comprehensive defense checklist

• Point validation (mandatory for static keys):
  • Reject O (point at infinity).
  • Verify the affine/curve equation exactly for the intended curve model.
  • Check subgroup membership: confirm [n]Q = O (where n is prime group order) or equivalently validate that cofactor-cleared point is not O.
• Cofactor handling:
  • For curves with cofactor h > 1, perform cofactor clearing: Q' = [h]Q before using in key derivation, or use scalar multiplication that inherently multiplies by the secret scalar ensuring result lies in prime subgroup.
  • Be cautious: cofactor clearing can mask some misuse; prefer prime-order groups when possible.
• Protocol-level mitigations:
  • Use authenticated key-exchange (SIGMA, TLS with ephemeral keys + certificates) and explicit key confirmation; do not accept unauthenticated raw ECDH outputs as long-term secrets.
  • Derive keys through a KDF with domain separation and include both parties' public keys and transcripts to bind identity.
  • Limit reuse of static private keys for unauthenticated exchanges.
• Safer curve choices:
  • Prefer prime-order curves (e.g., NIST P-256 with subgroup checks) or use cofactor-avoiding encodings (Ristretto/Decaf over Curve25519/Edwards25519) that provide a prime-order abstraction and remove twist vulnerabilities.
  • Use Montgomery/Edwards ladder implementations with built-in clamping and cofactor-aware processing (e.g., X25519 specification prescribes scalar clamping and mapping that mitigates small-subgroup leaks when used correctly).

Implementation best practices

• Always perform explicit subgroup check [n]Q = O for received static public keys; for ephemeral keys in constrained environments, at minimum perform cofactor clearing and use authenticated protocols.
• Fail closed: any point failing validation must be rejected.
• Test against known invalid-curve and small-subgroup vectors; use vetted libraries (libsodium, BoringSSL, OpenSSL with up-to-date ECDH checks).

Takeaway
Point validation + correct cofactor handling + protocol-level authentication/KDF binding (or use of prime-order abstractions like Ristretto) are required to prevent invalid-curve and twist small-subgroup leakage that can expose private-key bits.

Approach (brief)
Compute AES S-box algebraically: 1) multiplicative inverse in GF(2^8) (0 -> 0), implemented via constant-time field operations and a fixed addition chain to compute x^(254) = x^-1; 2) apply the affine transform. No table lookups or secret-dependent branches.

C implementation (constant-time bit ops, no tables)

#include <stdint.h>

/* GF(2^8) AES irreducible poly: x^8 + x^4 + x^3 + x + 1 -> 0x11B */
static inline uint8_t gf_mul(uint8_t a, uint8_t b) {
    uint8_t res = 0;
    for (int i = 0; i < 8; ++i) {
        /* conditional xor without branch */
        uint8_t mask = -(b & 1);
        res ^= a & mask;
        uint8_t hi = a & 0x80;
        a <<= 1;
        /* reduce if overflow */
        a ^= (uint8_t)((hi >> 7) * 0x1B);
        b >>= 1;
    }
    return res;
}
static inline uint8_t gf_square(uint8_t a) { return gf_mul(a, a); }

/* compute x^254 = inverse for x != 0 using fixed addition chain */
static uint8_t gf_inv(uint8_t x) {
    if (!x) return 0;
    uint8_t x2  = gf_square(x);         // x^2
    uint8_t x3  = gf_mul(x2, x);        // x^3
    uint8_t x5  = gf_mul(x3, x2);       // x^5
    uint8_t x10 = gf_square(x5);        // x^10
    uint8_t x20 = gf_square(x10);       // x^20
    uint8_t x40 = gf_square(x20);       // x^40
    uint8_t x50 = gf_mul(x40, x10);     // x^50
    uint8_t x100= gf_square(x50);       // x^100
    uint8_t x200= gf_square(x100);      // x^200
    /* combine to get x^254 = x^(200+50+4) */
    uint8_t t = gf_mul(x200, x50);      // x^250
    uint8_t x4  = gf_square(x2);        // x^4
    return gf_mul(t, x4);               // x^254
}

uint8_t aes_sbox_nontable(uint8_t in) {
    uint8_t y = gf_inv(in);
    /* affine transform: b = A*y ^ c, where A is fixed matrix; implement bitwise */
    uint8_t out = 0;
    uint8_t c = 0x63;
    for (int i = 0; i < 8; ++i) {
        /* compute bit i as y_i ^ y_{(i+4)%8} ^ y_{(i+5)%8} ^ y_{(i+6)%8} ^ y_{(i+7)%8} ^ c_i */
        uint8_t bit = ((y >> i) & 1)
                    ^ ((y >> ((i+4)&7)) & 1)
                    ^ ((y >> ((i+5)&7)) & 1)
                    ^ ((y >> ((i+6)&7)) & 1)
                    ^ ((y >> ((i+7)&7)) & 1)
                    ^ ((c >> i) & 1);
        out |= bit << i;
    }
    return out;
}

Key points & reasoning

• Multiplication uses branchless shift/xor and constant loop count (8 iterations) so no secret-dependent memory or timing from branches.
• Inversion via fixed addition chain yields fixed sequence of multiplies/squares; avoids data-dependent loops or table indexes.
• Affine transform is bitwise and branchless.

Performance vs table-driven S-box

• Table approach (256-byte lookup) is much faster (single memory read) and simpler; CPU latency >> arithmetic here.
• Table lookups are vulnerable to cache-timing attacks if attacker can observe cache state (shared cache, speculative attacks).
• Algebraic implementation is slower (many GF multiplies per byte) but constant-time and side-channel resistant at software-level.

Hardware AES acceleration trade-offs

• AES-NI (or ARM Crypto) does SBOX internally in microcode/hardware constant-time and is both fastest and side-channel resistant for typical usage — prefer hardware when available and trusted.
• If hardware not available or untrusted, algebraic / bit-sliced implementations or masked variants provide resistance at higher CPU cost.

Notes & extensions

• For high-throughput, consider bit-slicing and SIMD to amortize cost across many bytes; combine with masking for stronger resistance against power/EM side channels.
• Validate against test vectors and ensure compiler doesn't optimize branches or table replacements—use volatile or inline asm guards if needed.

Overview / Goals
Design CI automation to ensure correctness, interoperability, resistance to misuse, performance, and lack of regressions (including side-channels) for a hash/MAC implementation.

Test categories

• Unit tests
  • Pure-function tests for compress/hash block, incremental updates, finalize; edge cases (zero-length, single-byte updates, max-length).
• Standard vectors (FIPS/NIST)
  • Run NIST SHA/CMAC/HMAC test vectors, Monte Carlo tests, known-answer tests (KATs).
• Differential testing
  • Compare outputs against OpenSSL/BoringSSL/libgcrypt across random inputs, boundary inputs, and API variants (init/update/final).
• Property-based tests
  • Use Hypothesis/QuickCheck: associativity of incremental updates, idempotence of finalize, collision-resistance checks for small-space inputs.
• Fuzzing
  • AFL/LibFuzzer targets: API misuse (double finalize, reinit), malformed length/padding fields, truncated updates, streaming inputs; incorporate dictionary of known problematic blobs (length fields, repeating patterns).
• Side-channel regression tests
  • Microbenchmark per-run timing/statistics under controlled CPU/core/power states; constant-time assertion harness (e.g., test vectors differing only in secret) with statistical tests (t-test, Welch) and threshold alarms.
• Performance regression tests
  • Throughput/latency benchmarks (single-thread and parallel) measured in CI; baseline and allowed regression percentage; measure CPU cycles, memory, and SIMD PATHS.

CI integration & triage

• Pipeline steps: unit → vectors → differential → property → fuzz (scheduled longer runs) → side-channel/perf.
• Automated artifacts: failing inputs, crash dumps, sanitizer logs (ASan/UBsan), coverage, perf graphs, timing distributions.
• Triage process: auto-classify by failure type (crash, mismatch, timing anomaly). Assign severity: crash/exploit > correctness mismatch > side-channel > perf regression.
• Repro & debug: store deterministic seed + corpus for fuzz, reproduce job in an isolated environment, attach stack traces and diffs against reference. Use issue template with steps-to-reproduce, minimal test case, and impact.
• Continuous monitoring: nightly extended fuzz + telemetry; alerting on flaky tests; weekly review of coverage and corpus growth.

This strategy balances cryptographic correctness, practical robustness, and measurable resistance to timing/implementation leaks suitable for production cryptographic libraries.

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.

Brief approach — why not memcmp
memcmp returns on first differing byte and its implementation (and the CPU) can short-circuit, creating data-dependent timing. For tags, this leaks equality information to attackers. A constant-time compare must process all bytes and avoid data-dependent branches and memory-access patterns.

Constant-time implementation (C)

#include <stddef.h>
/* Returns 0 if equal, non-zero otherwise. Constant-time byte-wise compare. */
int ct_compare(const unsigned char *a, const unsigned char *b, size_t n) {
    unsigned char diff = 0;
    size_t i;
    for (i = 0; i < n; ++i) {
        /* XOR each byte and OR into accumulator; no branches */
        diff |= a[i] ^ b[i];
    }
    /* Normalize to 0 or 1-ish integer result */
    return (int)diff;
}

Why this is constant-time

• No data-dependent branches; loop length is fixed by n.
• Each iteration performs identical operations regardless of data.
• Using bitwise ops avoids early exit.

Compiler / CPU pitfalls and mitigations

• Compiler might optimize or vectorize; use -O flags carefully or a well-reviewed primitive (e.g., OpenSSL/ libsodium CRYPTO_memcmp). Consider compiler barriers or mark pointers volatile only if necessary (volatile isn’t a full solution).
• Speculative execution and microarchitectural optimizations can still leak via caches or branch predictors. Avoid secret-dependent memory accesses; here accesses are linear but attacker could use cache-timing to infer addresses if tags are not in accessible memory.
• Page faults and copy-on-write: accessing pages with secret-dependent access order can leak. Ensure both buffers are resident and touched deterministically before compare.
• Use constant-time library primitives where available and review assembly to ensure no branches or conditional moves expose timing.

Definition — P, NP, NP‑hard

• P: problems solvable in polynomial time by a deterministic Turing machine (efficiently solvable).
• NP: problems for which a candidate solution can be verified in polynomial time; equivalently solvable in poly time by a nondeterministic TM.
• NP‑hard: at least as hard as the hardest problems in NP — any NP problem can be reduced to an NP‑hard problem in polynomial time. NP‑hard problems need not be in NP (may be undecidable or optimization problems).

Cryptographic meaning

• Basing security on an NP‑hard problem means that breaking the scheme can be reduced to solving an NP‑hard problem. Practically we want a reduction that shows an efficient adversary for the cryptosystem yields an efficient solver for the NP‑hard problem.

Limitations

• Worst‑case vs average‑case: NP‑hardness is a worst‑case notion; cryptography needs average‑case hardness (most instances hard). Many NP‑hard problems have easy instances.
• Decision vs search/targeted tasks: Reductions often target decision versions; attackers need to solve specific search or inversion tasks.
• Tightness and efficiency: Reductions may be non‑tight or non‑constructive, giving weak concrete security.
• Quantum and parameterized attacks: Quantum algorithms or special parameter regimes can break assumptions.
• Practical choice: Prefer problems with proven average‑case hardness (e.g., lattice problems like Learning With Errors) and well-studied reductions.

This answer reflects how a cryptographer reasons about hardness assumptions beyond the NP taxonomy.