Entry-Level Cryptographer Interview Preparation Guide: FAANG Standard

Requirements & goals

• Protect private keys for TLS client auth and server signing, ensure availability, non-repudiation, auditable access, rapid compromise recovery, minimal downtime.

High-level choices

• Use FIPS 140-2/3 Level 3 HSMs (cloud-managed HSM cluster or on-prem HSM appliances) for primary key material. For multi-cloud ops, use Cloud KMS backed by HSMs (e.g., Cloud HSM/AWS KMS with custom key store) to get durability and key ceremony compliance.
• Keep offline encrypted backups of key material only when HSM export is permitted — prefer non-exportable keys and use wrapping keys / split knowledge (Shamir) for any backups.

Key lifecycle & rotation cadence

• Keys have explicit states: Active → Standby (dual-signing) → Retire → Destroy.
• Server signing keys: rotate every 90 days (or earlier if policy/regulator requires); TLS client-auth keys: rotate annually or on compromise.
• Use overlapping validity: provision new key, issue certs, run dual-signature period (e.g., 48–72 hours) to ensure in-flight sessions validate.

Zero-downtime rotation

• Generate new keypair inside HSM/KMS; publish new certificate while keeping old key active for existing sessions.
• For server signing, support dual-signing: sign with both old and new during transition; clients accept either signature using cert chain checks.
• Use rolling deployment across load-balanced servers; ensure old key remains available until all sessions using it expire.

Access controls & separation of duties

• RBAC: least privilege; distinct roles — Crypto Ops (can request rotation), Key Custodians (can approve export/sharing), Auditors (read-only).
• Use multi-party approval (M-of-N) for sensitive operations (export, emergency key recovery).
• HSM policies enforce key usage flags (sign-only, no-export) and require PINs or quorum.

Audit & monitoring

• Immutable audit logs for all key ops (create, sign, export attempt, rotate, destroy) shipped to SIEM with tamper-evident storage.
• Alerts on anomalous patterns (unexpected exports, failed auths, unusual frequency of sign ops).

Backups & offline storage

• If export required: wrap private key with a root-wrapping key split among custodians; store encrypted shares in geographically separated secure vaults (air-gapped or hardware-secured).
• Periodically test recovery with blinding ceremony.

Compromise & emergency procedures

• Immediate: revoke certificates, mark keys as compromised in KMS/HSM, rotate to new keys generated in HSM, publish CRLs/OCSP stapling and push to clients.
• For client-auth: revoke client certs and require re-issuance; for server-signing: re-sign recently issued artifacts where possible.
• Run post-mortem, rotate all related keys, update audit, notify stakeholders per incident response SLA.

Trade-offs / rationale

• HSMs provide cryptographic boundary and non-exportability; cloud KMS gives scalability and operational ease — choose both where compliance and scale demand. Split backups and M-of-N minimize insider risk while enabling recovery. Dual-signing and rolling deployments enable near zero downtime.

Requirements & threat model

• Protect against offline brute-force after DB compromise, server-side compromise, and side-channel leaks. Assume attacker can obtain stored hashes and salts but not server-only secrets unless fully compromised.

Algorithm choice

• Recommend Argon2id (resistant to GPU/ASIC and side-channels). Scrypt acceptable; bcrypt less memory-hard.
• Example production baseline: Argon2id with:
  • Memory: 64 MB (65_536 KB)
  • Time (iterations): 3
  • Parallelism: 4
  • Hash length: 32 bytes
• Tune per-platform: increase memory/time on auth servers with headroom for latency ~100–300ms.

Salts & pepper

• Per-user random salt: 16+ bytes from CSPRNG, stored with hash.
• Optional server-side pepper: 128-bit secret stored in HSM or separate key vault; not in DB. Combine as: Argon2id(password || pepper, salt, ...). Pepper protects when DB leaked but vault intact.

Versioning / parameter storage

• Store a metadata blob per credential: {algo: "argon2id", version: 1, mem_kb, time, parallelism, salt, hash, hash_len}
• On login, if stored params weaker than current policy, re-hash on successful auth and write upgraded hash.

Operational mitigations

• Rate-limit and progressive delays per IP/user, CAPTCHAs after thresholds.
• Multi-factor auth for sensitive ops.
• Monitor for anomalous auth patterns; alert and throttle.
• Breach response: rotate pepper (generate new pepper in HSM), force password resets or apply double-hashing transition: re-hash old hashes with new pepper until users re-authenticate.
• Key rotation: maintain key IDs for peppers; support decrypt/verify with historical peppers during transition windows.
• Regularly benchmark and update parameters; run offline cracking simulations to validate.

Notes as cryptographer

• Avoid homegrown KDFs; rely on vetted libs (libsodium, argon2 reference) and constant-time comparisons.
• Log only minimal metadata; never store plaintext or pepper in logs.

Approach / threat model

• Mallory (MitM) can flip S->C chosen_alg to a weaker KEX and, because the signature scheme is malleable, can adjust sig_server so the server still accepts. The goal: force both endpoints to use a weaker KEX without detection.

Exploit walkthrough

1. C sends alg_list = {A_strong, A_weak} and client_params.
2. S picks A_strong, sends chosen_alg = A_strong, server_params, sig_server = Sign_S(chosen_alg || server_params || transcript_fragment).
3. MitM flips chosen_alg → A_weak in transit to C and modifies sig_server to a different valid-looking signature under the malleable scheme (exploits malleability to map signatures between messages).
4. C verifies sig_server (scheme accepts forged/malleable signature), thinks server chose A_weak, sends client_key_share for A_weak and sig_client.
5. Server still thinks A_strong was chosen and uses A_strong key material — resulting in mismatch or attacker-mediated downgrade where MitM translates between key exchanges, exposing session keys.

Why it succeeds

• Signature does not cryptographically bind the server’s signature to the full, canonical transcript as seen by the client (missing explicit client data, chosen_alg integrity).
• Signature malleability allows forging a valid signature over the altered chosen_alg.

Explicit patch (concrete changes to protocol)

• Server must sign a canonical transcript including the client’s original alg_list and a client-provided nonce (or client_params). Example signed structure:

T_server = "ServerHello" || chosen_alg || Hash(client_hello) || server_params || client_nonce || server_nonce

• Signature:

sig_server = Sign_S( Hash(T_server) )

• Client MUST verify that chosen_alg ∈ its original alg_list and that sig_server verifies over Hash(T_server) computed locally (so Hash(client_hello) ties to the exact client message).
• Use a non-malleable signature scheme (e.g., RSA-PSS, Ed25519) or apply hash-then-sign with domain separation to prevent malleability.

Additional defenses

• Include explicit transcript binding into subsequent key derivation:

session_secret = HKDF( shared_secret, info = Hash( full_transcript ) )

so any transcript modification breaks key agreement.

• Reject any chosen_alg not in the client's advertised list.

Trade-offs

• Minimal cost: extra hashing and including client_hello data in signature. Slightly larger signatures. Robust against downgrade and signature-malleability attacks.

Direct answer

State the switch in one sentence with the real motivating reason (something you're moving toward, not just away from), then name two or three concrete transferable skills with one line of evidence each.

Structured elaboration

What this question screens for
Interviewers want to hear you're running toward something specific, not just escaping a job you didn't like (bored, underpaid, laid off, framed as a positive pivot). They also want a concrete transferable-skill mapping, not a hand-wavy "I'm good at learning," plus some evidence you've already started closing the gap: a course, a project, informational conversations.

Framework

1. Reason: why this switch, stated personally and specifically.
2. Bridge: what work you've already done toward the new discipline, before this interview.
3. Transfer map: a short, explicit list of old-discipline skills mapped to new-role activities.
4. The gap, named honestly: what depth you're still building, and your plan for it.

This question shows up in two common shapes, and both use the same structure above:

• An individual contributor pivoting into a more client-facing or leadership-adjacent discipline within the same broad field (for example, an engineer moving toward a solutions or architecture role). The "reason" here is usually about where you get energy, not a change of field.
• An early-career candidate choosing an applied or production track over research or pure analytics, after learning what each is actually like day to day. The "reason" here is usually a concrete moment where the applied side turned out to be what actually held your interest.

Transfer map (illustrative shape)

Worked example

Skeleton (swap in your own discipline pair):

"Situation: I spent [N years] in [old discipline or industry], doing [core activity]. Task: I decided to move into [new discipline] because [a specific, concrete trigger, for example a project where the client-facing or analytical side of the work energized me more than the deep technical build did]. Action: I [bridge work, for example took on more of that kind of work informally, built a portfolio project, took a course, shadowed someone in the role]. My transfer map is [old skill] carries over as [new-role application], and [old skill] carries over as [new-role application]. Result: I can point to [a specific piece of bridge work] as evidence this isn't just intent, it's already in motion, and I'm still actively closing [the specific gap you named] through [what you're doing about it]."

Trade-offs and pitfalls

• Red flag: framing the switch purely as escape from your current job rather than movement toward something specific.
• Red flag: transferable skills stated too generically ("I'm a fast learner," "I work well with people") without a mapped, concrete example.
• Pitfall: overselling readiness. Naming the specific gap you're still closing, and how, is more credible than claiming you're already there, since a follow-up question will find the gap anyway.
• Pitfall: badmouthing the old industry or employer, which reads as a red flag regardless of how the new role goes.

Clarify assumptions & threat model

• Attacker has offline access to hashed KDF outputs and salts (salts stored plaintext). GPU throughput = 1e9 KDF-trials/sec for a fast unsalted-like KDF (optimistic for attacker).

Entropy estimates

• Printable ASCII ≈ 95 chars. Password space size = 95^8 ≈ 6.6 × 10^15.
• Password entropy: log2(95^8) ≈ 52.6 bits.
• Salt size: 32 bits (2^32 ≈ 4.3 × 10^9).
  • If salt were secret, combined entropy ≈ 84.6 bits.
  • In practice salt is public, so it does NOT add entropy vs offline attacker for a single account.

Brute-force cost (single account)

• Full space trials = 6.6e15. At 1e9 trials/sec:

time_seconds = 6.6e15 / 1e9 = 6.6e6  (≈ 76 days)

• Average time ~38 days (expectation = half space).

Large-scale attacker (millions of accounts)

• Small salt (2^32) enables reuse/precomputation amortization: attacker can precompute tables per salt or focus on common salts; with 2^32 salts precomputation of full password space per salt is 6.6e15 × 2^32 ≫ infeasible, but collision probability across millions of accounts is high so attacker benefits by reusing work across accounts with identical salts.
• For N = 10^6 accounts, checking one candidate password against all hashes costs ~10^6 verifications; effective per-password throughput drops unless attacker parallelizes across GPUs. Practical outcome: many weak passwords (common choices) will be found quickly; exhaustive per-account brute force at 1e9/sec per GPU scales linearly in required hardware — cracking a single account remains ~weeks on one GPU; cracking many accounts requires proportionally many GPUs.

Recommendations

• Salt: use ≥ 128-bit cryptographically random salts (unique per account).
• KDF: switch to memory-hard KDF (Argon2id) with parameters targeting ~100ms per derivation on defender hardware (e.g., Argon2id time=2, memory=64–256 MB) so attacker throughput drops by ~10^2–10^3.
• Iterations: if using PBKDF2/HKDF variants, use ≥ 100k–1M iterations depending on target latency.
• Password policy: require minimum length 12–16 (prefer passphrases), allow wide charset/unicode, enforce banned-password list and rate-limited authentication, encourage MFA.
• Monitoring: detect mass hash-checking patterns, rotate KDF parameters, force rehash on login.

Net effect example

• If defender sets KDF to 100 ms/derivation, attacker throughput per GPU becomes ≈ 10 trials/sec instead of 1e9 — turning 76 days into astronomically large timeline for exhaustive search; combined with longer passwords (entropy ≥ 80 bits) renders offline brute force infeasible.

Direct answer

When a security or compliance team has the authority to block work and uses it, the goal isn't to overpower them, it's to give them a way to say yes that they would defend to their own leadership. That means understanding the actual concern, proposing controls that address it directly, and building a record that makes the eventual approval easy to justify upward, rather than skipping the concern to hit a deadline.

Structured elaboration

1. Understand the veto, not just the outcome

Ask what specifically drives the block: a known threat pattern, a regulatory obligation, a past incident. A block framed as 'this is too risky' usually decomposes into something concrete once you ask what evidence would change their mind.

2. Propose compensating controls, not blanket reassurance

Bring specific mitigations that map to the stated concern: scoped access, monitoring, a rollback plan, data masking, a smaller blast radius. 'Trust me' rarely moves a team whose job is to not just trust people; a control they can point to in an audit does.

3. Phase the ask so risk and trust build together

Instead of asking for full approval up front, propose a smaller, monitored first step, then expand once it holds up. This gives the blocking team evidence rather than a promise, and it gives you a faster initial yes.

4. When you need executives to sponsor it, not just the compliance team to approve it

Sometimes getting to yes isn't about convincing the blocking team at all, it's about persuading senior executives, without formal authority over them, to sponsor a security or compliance investment that trades short-term revenue for long-term risk reduction. That's a different move: build the case in terms an executive already weighs (the cost of the exposure versus the cost and timeline of the fix), find a credible sponsor who already has their ear, and time the ask to a moment they're already thinking about risk, such as a renewal, an audit, or a near-miss. State the trade-off plainly rather than downplaying either the revenue impact or the risk.

5. When the conflict runs the other direction

The pressure isn't always compliance blocking a launch. Sometimes compliance demands collecting more data for audit purposes, and that request conflicts with the team's own privacy commitments to users. Handle this the same way: scope exactly what the audit requirement needs, then look for a way to satisfy it without violating the privacy commitment, such as aggregating instead of storing per-user data, sampling instead of full capture, or purpose-limited access with automatic expiry. If a genuine conflict remains after that, escalate it as a policy conflict for someone empowered to decide between the two obligations, rather than either side unilaterally overriding the other.

Worked example

A security team initially blocks a new integration on a financial product, citing customer-data exposure risk. Working sessions with security and the app owner map the specific risk to two things: a broad data scope and no kill switch. The team proposes scoped test accounts, data masking, and a remote kill switch, then agrees to a phased rollout: verify the low-risk paths first, escalate to the higher-risk ones only after the first phase holds up under monitoring. Security signs off on the phased plan. Separately, when the same team later wants to expand data collection to satisfy a new audit requirement, they find that a sampled, time-limited collection window satisfies the auditors just as well as full, indefinite collection, so the privacy commitment to users doesn't have to give.

Trade-offs and pitfalls

• Working around a block quietly (shipping a smaller version without telling the blocking team) buys short-term speed and damages the relationship you will need next time; always close the loop even when you find a narrower path.
• Compensating controls that never get revisited become permanent scaffolding; agree upfront on when the phased approach graduates to full trust, not just how it starts.
• On the upward-influence path, leading with fear rather than a clear trade-off tends to get budget approved once and then quietly deprioritized later, because the executive never actually weighed the cost against the risk. Naming the trade-off explicitly is what makes the commitment durable.
• Overriding a genuine policy conflict (audit needs versus privacy commitments) unilaterally, instead of escalating it, tends to resurface as a bigger trust problem with users or regulators later than the original block would have cost in time.

Approach (brief)
Use HKDF per RFC 5869: Extract(salt, IKM) -> PRK; Expand(PRK, info, L) -> OKM. Use HMAC with chosen hash (e.g., SHA-256). Domain-separate each key via distinct info strings.

# Pseudocode (language-agnostic), H = hash function (e.g., SHA-256), HLen = output length of H
function HKDF_Extract(salt, IKM):
    if salt == null or salt.length == 0:
        salt = 0x00 repeated HLen           # RFC 5869: use zero salt
    PRK = HMAC(salt, IKM)
    return PRK

function HKDF_Expand(PRK, info, L):
    N = ceil(L / HLen)
    if N > 255:
        error "OKM length too large"
    T = empty byte string
    T_prev = empty byte string
    for i from 1 to N:
        T_i = HMAC(PRK, T_prev || info || byte(i))
        T = T || T_i
        T_prev = T_i
    OKM = first L bytes of T
    return OKM

# Example: derive three keys (enc, mac, iv) from IKM with optional salt and base_info
function Derive_Keys(IKM, salt, base_info):
    PRK = HKDF_Extract(salt, IKM)
    # Use distinct info strings for domain separation
    enc = HKDF_Expand(PRK, base_info || "enc-key", 32)   # 256-bit encryption key
    mac = HKDF_Expand(PRK, base_info || "mac-key", 32)   # 256-bit MAC key
    iv  = HKDF_Expand(PRK, base_info || "iv", 12)        # 96-bit IV
    return (enc, mac, iv)

Key concepts and reasoning

• Extract concentrates entropy; use salt if available, else zeros per RFC.
• Expand uses counter-based HMAC chaining to produce arbitrary-length OKM.
• Domain separation: include usage-specific labels in info to prevent key reuse.
• Check N <= 255 to follow RFC safety limits.

Edge cases & best practices

• Prefer non-empty, high-entropy salt (e.g., per-protocol random).
• Use constant-time HMAC implementations, zeroize secrets in memory.
• Avoid reusing PRK across unrelated protocols without distinct salt/info.

Approach (brief)
Use the extended Euclidean algorithm to compute integers x,y with ax + my = g = gcd(a,m). If g != 1 no inverse exists; otherwise a*x ≡ 1 (mod m) so x mod m is the modular inverse.

Python implementation

def modinv(a, m):
    # returns inverse of a mod m, or None if it doesn't exist
    a0, m0 = a % m, m
    if m0 == 0:
        return None
    # Extended Euclid iterations: (r, s, t) where r = s*a0 + t*m0
    r0, s0, t0 = m0, 0, 1
    r1, s1, t1 = a0, 1, 0
    while r1:
        q = r0 // r1
        r0, r1 = r1, r0 - q * r1
        s0, s1 = s1, s0 - q * s1
        t0, t1 = t1, t0 - q * t1
    # now r0 = gcd(a0,m0) and s0*a0 + t0*m0 = r0
    if r0 != 1:
        return None
    inv = s0 % m0
    return inv

Why it works (math)
Extended Euclid produces x,s.t. ax + my = gcd(a,m). If gcd = 1 then a*x ≡ 1 (mod m) so x is inverse; reducing x modulo m yields the canonical representative in [0,m-1].

Complexity
Let n = max(bit-length(a), bit-length(m)). Classical division-based extended Euclid runs in O(n^2) bit operations (more precisely O(M(n) log n) where M(n) is multiplication complexity).

Examples

• modinv(3, 11) -> 4 (because 3*4 ≡ 1 mod 11)
• modinv(6, 9) -> None (gcd=3, inverse doesn't exist)

As a cryptographer I use this routine when implementing key generation and modular arithmetic primitives; ensure inputs reduced mod m first and use constant-time variants where side-channel resistance is required.

Direct answer

A quantitative scoring system for cryptographic threats needs to split its five natural inputs, exploitability, attacker resources required, required cryptanalytic effort, data sensitivity, and cryptographic lifetime, into a likelihood side (the first three, since they describe how hard the threat is to pull off right now) and an impact side (the last two, since they describe how bad it is if it succeeds). Multiplying a 1-5 likelihood score by a 1-5 impact score gives a simple, defensible priority ranking, but a naive version of that formula systematically under-ranks one important class of crypto threat: attacks that are not feasible today but whose required secrecy window is long, which is why the worked example below deliberately includes a check beyond the raw multiplication.

Structured elaboration

Sorting the five named factors into likelihood and impact.

• Likelihood factors (how achievable is exploitation right now):
  • Exploitability ($E$, 1-5): how straightforward exploitation is once the weakness is identified, given current knowledge and tooling.
  • Attacker resources required ($AR$, 1-5): how much compute, specialized hardware, or organizational capability (nation-state versus individual) exploitation demands; scored so a HIGHER number means MORE resources are needed, which is why it gets inverted before combining, since more required resources means LOWER likelihood.
  • Required cryptanalytic effort ($CE$, 1-5): how novel or difficult the underlying cryptanalysis itself is, independent of raw compute; also inverted before combining for the same reason as attacker resources.
• Impact factors (how bad is it if the threat succeeds):
  • Data sensitivity ($DS$, 1-5): the harm from the protected data being exposed or forged.
  • Cryptographic lifetime ($CL$, 1-5): how long the data or key must remain protected; a longer required lifetime raises impact because it widens the window during which a future improvement in attacker capability could still compromise something that was supposedly already safe.

Scoring formula. Combine the three likelihood factors, inverting the two that are framed as "resistance," and the two impact factors, into a single risk score:

$L = \frac{E + (6-AR) + (6-CE)}{3}, \qquad I = \frac{DS + CL}{2}, \qquad \text{RawScore} = L \times I$

$\text{RawScore}$ ranges from 1 to 25; normalizing to a 0-10 scale, $\text{Score}_{10} = \frac{\text{RawScore}}{25}\times 10$, keeps it comparable to other risk scoring already in use elsewhere in the organization.

Worked example

Threat A: nonce reuse in an AES-GCM (Advanced Encryption Standard, Galois/Counter Mode) implementation, enabling forgery and partial plaintext recovery once a nonce repeats. Scores: $E=5$ (once identified, exploitation is well-documented and requires no novel research), $AR=1$ (a standard laptop suffices), $CE=1$ (a known algebraic technique, not new cryptanalysis).
$L = \frac{5 + (6-1) + (6-1)}{3} = \frac{5+5+5}{3} = 5.0$
Impact side: $DS=4$ (exposes session-level traffic integrity and confidentiality, serious but not a full historical archive), $CL=2$ (short-lived session keys, narrow exposure window).
$I = \frac{4+2}{2} = 3.0, \qquad \text{RawScore} = 5.0 \times 3.0 = 15.0, \qquad \text{Score}_{10} = \frac{15.0}{25}\times 10 = 6.0$

Threat B: harvest-now-decrypt-later against RSA-2048 key exchange protecting 20-year-retention health records, where an adversary collects encrypted traffic today intending to decrypt it once a sufficiently capable quantum computer exists. Scores: $E=1$ (not exploitable today, no such computer exists yet), $AR=5$ (requires a nation-state-scale, currently nonexistent capability), $CE=5$ (requires a fundamentally new computational capability, not incremental cryptanalysis).
$L = \frac{1 + (6-5) + (6-5)}{3} = \frac{1+1+1}{3} = 1.0$
Impact side: $DS=5$ (protected health information, highest sensitivity), $CL=5$ (a 20-year regulatory retention requirement, the longest lifetime on the scale).
$I = \frac{5+5}{2} = 5.0, \qquad \text{RawScore} = 1.0 \times 5.0 = 5.0, \qquad \text{Score}_{10} = \frac{5.0}{25}\times 10 = 2.0$

Naive multiplication ranks Threat A (score 6.0) well above Threat B (score 2.0), because Threat A's likelihood dominates the product even though Threat B's impact factors are both at the maximum. This is exactly the failure mode a quantitative crypto-risk model needs to catch rather than trust blindly: for any threat where $CL$ is high, apply a second, purpose-built check before accepting a low raw score, using Mosca's inequality, a widely used post-quantum migration planning heuristic. If $X + Y > Z$, where $X$ is the required data confidentiality lifetime, $Y$ is the time needed to migrate to quantum-safe cryptography, and $Z$ is the time until a cryptographically relevant quantum computer plausibly exists, the organization has a problem regardless of how low today's raw likelihood score reads. For Threat B, illustrative planning figures: $X = 20$ years (the retention requirement), $Y = 5$ years (an illustrative estimate for migrating this system's key exchange to a post-quantum algorithm), and treating $Z$ as genuinely uncertain but illustratively bounded around $15$ years for this exercise:
$X + Y = 20 + 5 = 25 > 15 = Z$
The inequality holds, flagging Threat B as urgent to begin migration planning for now, despite its raw multiplicative score of 2.0 ranking it below Threat A. Threat A needs no such override, since a short cryptographic lifetime means there is no long future window for a currently-infeasible capability to catch up to it.

Trade-offs and pitfalls

The central pitfall, deliberately built into the worked example above, is trusting a single multiplicative likelihood-times-impact score without checking it against a lifetime-aware overlay for any threat where cryptographic lifetime is high; naive multiplication structurally discounts low-likelihood-today, high-future-impact threats exactly when a long lifetime is the reason they deserve more attention, not less. A second pitfall is picking scores for exploitability, attacker resources, and cryptanalytic effort without documenting the reasoning behind each number, since these are judgment calls (unlike, say, a directly measured CVSS metric) and an unscored justification makes the model impossible for another reviewer to sanity-check or recalibrate as the underlying assumptions age, particularly for anything touching quantum timelines, which are inherently uncertain and will need periodic revisiting. A third is applying $Z$ (the estimated time until a cryptographically relevant quantum computer exists) as if it were a precise, known figure; it is a genuinely contested estimate across the field, so a defensible practice is to run the inequality check at a conservative (shorter) $Z$ for the highest-lifetime data and treat the result as a planning trigger rather than a certainty.

High-level goal

I would design the internal crypto API to make secure choices the easiest path and unsafe choices impossible or explicit. As a cryptographer I prioritize AEAD, nonce-safety, key opacity, and clear runtime guarantees.

Key design choices

• Secure defaults: AEAD-only (e.g., XChaCha20-Poly1305, AES-GCM-SIV where hardware available). No unauthenticated primitives exposed by default.
• Opaque types: Key, Nonce, Tag as language-level opaque or sealed types so callers cannot forge or inspect raw bytes accidentally. Construction only via library factories.
• Nonce management: Library-generated nonces by default (per-message random or monotonic counter tied to key + domain separation). Expose deterministic nonce APIs only with explicit, documented opt-in functions.
• Forced AEAD usage: Single encrypt/decrypt APIs that accept AAD and return ciphertext+tag as an opaque struct.
• Runtime asserts & misuse detection: Runtime checks for nonce reuse, key reuse across domains, and incorrect tag lengths with deterministic crash/fail-fast logging in dev builds.
• Easy wrappers & ergonomics: High-level helpers for common workloads (encryptString, encryptStream, envelope for key rotation) plus low-level primitives for audited teams.
• Polyglot considerations: Provide idiomatic bindings (e.g., typed classes in Java, struct wrappers in Rust, sealed classes in TypeScript) and clear FFI boundaries; encode versioned wire formats and strict canonical serialization.

Rationale & trade-offs

• Prevent developer error over performance micro-optimizations.
• Opaque types and library nonce generation remove human sources of nonce reuse.
• Runtime asserts catch protocol misuse early; opt-in escape hatches require security review.

This approach reduces accidental misuse while allowing expert users controlled flexibility.