Cryptography Fundamentals Questions

Overview / approach
Start by scoping library entry points, supported algorithms, and default configurations. Combine targeted static analysis to find API misuse patterns with dynamic testing and test-vectors to validate cryptographic correctness and runtime weaknesses.

Static analysis & patterns

• Use CodeQL and Semgrep rules for misuse patterns: ECB mode usage, fixed IVs/nonce reuse, low-iteration PBKDF2/scrypt defaults, disabling authentication (AES-GCM tag checks), insecure RNG calls (rand(), /dev/urandom misuse).
• Run language-specific linters: clang-tidy/cppcheck for C/C++; Bandit for Python; SpotBugs for Java. Search for deprecated APIs (OpenSSL older APIs, insecure Java Cipher.getInstance("AES")).

Dynamic testing & fuzzing

• Use Wycheproof and NIST test vectors (KATs) to validate correctness and detect padding oracle behavior.
• Perform API-level fuzzing (AFL/LibFuzzer or OSS-Fuzz) focused on serialization/deserialization, malformed ciphertexts, boundary sizes.
• Runtime tools: AddressSanitizer, MemorySanitizer, Valgrind for memory issues; strace/systrace to spot entropy sources; dynamic instrumentation to detect timing leaks.
• Create adversarial test-cases: nonce reuse, truncated tags, manipulated associated data to detect authentication bypasses and padding oracles.

Test vectors

• Wycheproof suites for hybrid and symmetric modes.
• NIST AES/GCM/KWP vectors and RFC test vectors for HKDF, HMAC.
• Custom Known Answer Tests covering IV/nonce reuse, predictable IVs, small iteration counts.

Prioritization of findings

• Rank by exploitability and exposure:
  1. Critical: remote-exploitable cryptographic bypasses (padding/oracle, MAC verification bypass), broken RNGs, predictable keys — immediate remediation.
  2. High: insecure defaults (ECB, no auth), low KDF iterations — schedule urgent fixes and config changes.
  3. Medium: API surface that could be misused (ambiguous defaults) — add hardening, safer APIs, deprecations.
  4. Low: code-style or minor memory inefficiencies.
• Use risk = likelihood * impact, factor in ease of exploitation (local vs remote), attacker prerequisites, and affected consumers.

Remediation & mitigation

• Prefer secure-by-default changes: safe defaults, require explicit opt-in for weaker modes, deprecate unsafe functions.
• Add KATs and fuzz harnesses to CI (Wycheproof + OSS-Fuzz).
• Patch, back-port notes, and provide migration guidance and semantic versioning for breaking safe-default changes.
• Track with SLAs: immediate hotfix for critical, 30-day for high, documented roadmap for medium.

Outcome evidence
Deliverable: prioritized findings list, PoC exploits for critical issues, test-suite added to CI, and developer guidance for secure API usage and migration.

Definition — what authenticated encryption is
Authenticated encryption (AE/AEAD) provides confidentiality plus integrity and authenticity in one primitive: it ensures ciphertexts decrypt only if they are unmodified and from an authorized sender. AEAD modes (e.g., GCM, CCM) combine encryption and a message authentication tag.

Why encrypt-then-MAC / AEAD is preferred

• Guarantees integrity before decryption, preventing processing of tampered ciphertexts.
• Prevents malleability attacks (attackers modifying ciphertext to alter plaintext).
• AEAD implementations are standardized and avoid common misuse of separate primitives.

Concrete attack when authentication is omitted

• AES‑CBC without a MAC is malleable. An attacker flipping bits in a ciphertext block causes predictable flips in the corresponding plaintext block. Example: a payment message "amount=100" can be altered in transit to "amount=900" by flipping ciphertext bits, letting attacker change balances without knowing the key. Padding-oracle attacks are another realistic consequence when integrity is missing.

As an analyst I prioritize AEAD or encrypt-then-MAC to stop these attack classes and simplify detection/monitoring (validate tags before processing).

Situation overview (one line)
An attacker exfiltrated DB backups encrypted with a symmetric key kept in app config—key compromise likely; I’d act immediately to contain, assess exposure, remediate, and harden.

Immediate containment

• Revoke access: disable credentials, service accounts, and app instances that use the compromised key.
• Isolate affected systems and stop further exfiltration (network ACLs, firewall rules).
• Preserve evidence: snapshot affected hosts, collect memory, config files, logs; set forensic hold.
• Notify incident response lead, legal, and execs per IR plan.

Forensic steps

• Triage logs (SIEM, application, DB, cloud storage) to timeline exfiltration and actor IOCs.
• Determine key usage: which backups and systems used that key; identify all key instances.
• Analyze attack vector: how config was accessed (code repo, deployment pipeline, host compromise).
• Verify backup integrity and count of exfiltrated artifacts; check for lateral movement.

Short-term remediation (key rotation & re-encryption)

• Generate new keys in HSM/KMS; do not store keys in app config.
• Rotate keys: retire compromised key, mark as revoked in KMS, maintain chain for audit.
• Re-encrypt backups and live DB at rest using new KMS-backed key; prioritize most sensitive datasets.
• Rotate credentials and secrets for services and users that had access.
• Validate restorations from newly encrypted backups in isolated environment.

Long-term prevention

• Move keys to managed KMS/HSM; enforce envelope encryption and access policies.
• Eliminate secrets in plaintext: use secret management (Vault), CI/CD secrets injection, and least privilege.
• Implement key rotation automation, secret scanning in repos, and strong logging/alerting for key access.
• Harden hosts (EDR), patching, MFA for service accounts, and regular backup access reviews.
• Conduct tabletop exercises, update IR playbooks, and provide dev/security training on secure key management.

I’d document all steps, preserve chain of custody for legal, and run a post-incident review to measure effectiveness (time-to-detect, time-to-contain) and close gaps.

Definition — Forward Secrecy vs Perfect Forward Secrecy

• Forward secrecy (FS): compromise of a server’s long‑term private key does not allow an attacker to decrypt past recorded sessions.
• Perfect forward secrecy (PFS): commonly used interchangeably with FS; emphasizes that session keys are independent and ephemeral so past sessions stay safe even if long‑term keys are later exposed.

How DH / ECDHE provide FS in TLS

• DH/ECDHE perform an ephemeral Diffie‑Hellman key agreement each session: server and client generate fresh ephemeral private/public pairs and derive a shared session key that is never sent over the wire.
• In TLS the server authenticates the exchange by signing the ephemeral public value with its long‑term certificate key (so authentication ≠ key derivation).
• Because the session key is derived from ephemeral secrets that are discarded after use, possession of the server’s long‑term private key alone cannot recover past session keys.

Practical limitations — what FS protects against

• Protects recorded traffic from future compromise of the server’s certificate private key.
• Mitigates mass passive collection attacks where adversary records TLS traffic hoping to decrypt later.

What FS does NOT protect against

• Compromise of endpoints (client or server) at the time of the session — if an endpoint leaks the session key or plaintext, traffic is lost.
• Compromise of ephemeral private material for a specific session (e.g., if an attacker obtains the server’s ephemeral private key, that session is broken).
• Weaknesses in TLS session resumption: session tickets or PSK reuse tied to long‑term keys can defeat FS if ticket keys are compromised.
• Active MITM during the handshake if attacker can spoof or obtain signing keys or subvert CA trust.
• Metadata leakage (SNI, IPs, timing).

Operational notes for an InfoSec analyst

• Ensure servers use ECDHE ciphersuites and disable RSA key‑exchange.
• Rotate and protect session ticket keys; monitor for endpoint compromise.
• Audit TLS configuration and certificate/key handling to preserve PFS guarantees.

Recommended key lengths (practical guidance)

• AES (symmetric): AES-128 (acceptable, ~128-bit security), AES-256 for high-value or long-lived data.
• RSA (classical PKI): 2048-bit minimum today; 3072-bit recommended for ~2030+ protection; 4096-bit when long-term confidentiality (decades) is required.
• Elliptic curve (ECDSA/ECDH): secp256r1 / curve P-256 (≈128-bit security) is standard; use P-384 (≈192-bit) for higher assurance/longevity.

Why key length matters

• Key length maps to security level (work factor against brute-force or best known attacks).
• Longer keys increase cost to break; for ECC, smaller sizes give equivalent security to much larger RSA.
• Quantum threats: Grover’s algorithm halves symmetric security (so AES-128 → effective 64 bits), while Shor’s algorithm would break RSA/ECC — motivates post-quantum planning.

Operational considerations

• Performance: AES-256 slightly slower than AES-128; RSA cost grows rapidly with size (handshake/CPU); ECC gives faster ops and smaller certs. Prefer ECC for constrained devices and high-throughput systems.
• Lifespan & migration: Align key lengths with expected data lifetime and certificate validity. For long-retained secrets choose stronger keys and plan migration paths (cert rollover, algorithm upgrades).
• Compatibility: Ensure client/server, HSMs, and tooling support chosen curves/sizes.
• Key management: Stronger keys require secure generation, storage (HSMs), rotation policies, and monitoring for cryptographic incidents.

As an analyst, maintain an inventory of crypto assets, enforce organizational baseline (e.g., AES-256 for sensitive data, RSA ≥3072 for new keys or prefer ECC P-256+), and draft migration and incident playbooks for algorithm compromise or quantum-era transition.