Cryptography Fundamentals Questions

Clarify requirements & constraints

• Global low-latency service, high availability, privacy-preserving, must support offline verification and scale to millions of TLS connections/sec. Accept some stale info with bounded window.

High-level architecture

• Distributed fleet of regional Revocation Gateways (RGWs) that aggregate CRLs/OCSP from CAs, maintain caches, and expose internal OCSP/CRL APIs to application edges.
• Edge TLS terminators implement OCSP stapling and consult local RGW cache; fall back to stapled responses or cached OCSP/CRL.
• Central control plane for policy (revocation TTLs, hard-fail policies) and telemetry.

Components & responsibilities

• CRL fetchers: periodic delta fetch + full CRL; store in compressed index (serial → revocation time).
• OCSP responder aggregator: query CA responders on cache miss, validate signatures, store signed OCSP responses.
• Cache layer: in-memory LRU + persistent local store; index by cert serial/OCSP nonce + responder signature.
• Privacy module: strip client-identifying data when forwarding OCSP queries; use proxy querying to avoid leaking visited host -> CA mapping.
• Offline verification: include signed revocation timestamps in certificate transparency logs or use short-lived certs (preferred). Provide local verify tool that uses cached CRL deltas and last-known-good OCSP signatures.

Caching & freshness

• Honor CA NextUpdate/thisUpdate but enforce service-wide max-validity (e.g., 1 hour). Use TTLs, staleness window, and background refresh. Serve cached stapled OCSP while asynchronously refreshing.
• CRL deltas minimize bandwidth; bloom filters speed membership checks before full lookup.

OCSP stapling

• Primary mechanism to reduce latency and CA queries. Encourage short stapling lifetimes (minutes). Edge rotates and re-staples proactively.

Privacy

• Use RGWs as privacy proxies so clients do not contact external CAs. Support caching of OCSP responses per-host, avoid embedding client IP in upstream requests. For strict privacy, prefer short-lived certs to eliminate revocation checks.

Trade-offs

• Real-time checks: highest assurance, increased latency and CA/Network dependency; vulnerability to CA downtime. Adds global scaling burden.
• Cached/stapled: low latency, high availability, acceptable risk within TTL. Risk of window where revoked cert still accepted.
• Short-lived certs: shift complexity to issuance automation; virtually eliminate revocation need but operational cost.
• Offline verification: stronger auditability but may reject valid certs if cache stale.

Recommendations

• Use OCSP stapling + regional RGW cache as default, enforce short stapling TTLs, back with CRL delta for bulk checks and CT/audit logs. For highest-risk flows (admin panels, payment), enforce online check with hard-fail. Prefer short-lived certs where automation allows. Monitor hit/miss, latency, and CA availability; tune TTLs accordingly.

Situation & goal
Present a 12–36 month practical roadmap to prepare the enterprise for quantum threats to asymmetric crypto, achieving crypto-agility while minimizing operational disruption.

1. Inventory & telemetry (0–3 months)

• Automated discovery of keys/certs: PKI, HSMs, TPMs, SSH, TLS, S/MIME, code-signing, VPNs, cloud KMS, IoT devices.
• Tools: network scans, config management DB, CSP APIs, HSM vendor tools, endpoint agents.
• Output: asset registry with algorithm, key size, lifetime, owner, usage criticality, replacement complexity.

2. Risk prioritization (1–4 months)

• Classify by “harvest-now-decrypt-later” risk and business impact.
• Score factors: data retention period, exposure (public keys vs internal), regulatory sensitivity, replacement difficulty.
• Produce prioritized list: Tier 1 (certs protecting PII/IP & long-retention data), Tier 2 (internal auth), Tier 3 (non-sensitive).

3. Proofs-of-concept & hybrid testing (3–12 months)

• Select PQC algorithms (NIST standards: CRYSTALS-Kyber, CRYSTALS-Dilithium, etc.) and hybrid approaches.
• Testbed: CI pipelines, staging HSMs, TLS proxies, code-signing workflows.
• Validate interoperability, latency, key sizes, revocation flows, backup/restore with HSMs.
• Metrics: handshake time, CPU/memory, cert chain length, error rates.

4. Vendor & supply-chain readiness (3–12 months)

• Questionnaire + SLA check: PQC roadmap, firmware update mechanisms, HSM support, hybrid mode support, FIPS/NIST plans.
• Engage critical vendors for timelines; negotiate patch/update commitments.
• Plan mitigations for unsupported vendors (segmentation, compensating controls).

5. Migration planning & pilots (9–24 months)

• Phased migration: start with public-facing TLS, then internal auth, then code-signing and long-lived archives.
• Develop key rollover, dual-signature strategies, and automated orchestration (CI/CD, Vault, KMS).
• Run pilot for Tier 1 apps; rollback/recovery tested.

6. Governance, compliance & ops (0–ongoing)

• Update crypto policy, key lifecycles, incident playbooks.
• Map regulatory impacts (GDPR, HIPAA, sector-specific): document rationale for migration timeline, maintain audit trail.
• Training for Dev/Ops, runbooks for key compromise scenarios.

7. Monitoring & continuous review (ongoing)

• Monitor NIST approvals, standardization, and crypto incidents.
• Re-evaluate asset scores quarterly; track migration KPIs (percentage migrated, mean-time-to-rollover).

Why this works: focuses scarce resources on highest-risk assets, validates real-world interoperability with hybrid schemes, ensures vendor and compliance alignment, and builds automation for repeatable key lifecycle operations—delivering pragmatic, auditable crypto-agility before quantum risk becomes critical.

Overview

As a cybersecurity engineer I expect cryptographic hash functions to provide three core properties:

Preimage resistance

• Definition: Given h, infeasible to find m such that hash(m)=h.
• Why it matters: Protects password hashes—attackers can’t recover the original password from its hash.

Second‑preimage resistance

• Definition: Given m1, infeasible to find m2≠m1 with hash(m2)=hash(m1).
• Why it matters: Prevents forgery when replacing stored data (e.g., a signed document) with a different one that yields same hash.

Collision resistance

• Definition: Infeasible to find any pair m1≠m2 with equal hashes.
• Why it matters: Critical for digital signatures and content‑addressing; collisions can allow signature misuse or content spoofing.

Trade-offs: collision resistance is strongest; breaking collisions is easier than finding preimages for well‑designed hashes—choose modern hashes (SHA‑256/3/Blake2) and HMAC/salting for passwords.

Definition
An IV (initialization vector) and a nonce are values used to make encryption nondeterministic. IV is general term; nonce (number used once) emphasizes uniqueness per key. Both are public and not secret, but must meet mode-specific properties.

Roles (CBC vs GCM)

• CBC: IV must be unpredictable/random to prevent chosen-plaintext attacks; same IV + same plaintext leaks block patterns.
• GCM (AEAD): nonce must be unique for a given key (can be deterministic counter); reuse breaks authentication and can leak the AES-GCM keystream, allowing plaintext recovery and forgery.

Required properties

• Randomness/unpredictability: important for CBC and stream-cipher-like constructions.
• Uniqueness (no repeat): critical for GCM and CTR-like modes.

Consequences of reuse

• CBC with repeated IVs: reveals identical first-block XORs, enabling pattern leaks.
• GCM/CTR reuse: catastrophic — keystream reuse allows plaintext XORs and universal forgery.

Best practices

• Generate IVs with CSPRNG when randomness required; use monotonic counters or per-message incremented nonces when uniqueness suffices.
• Associate nonces/IVs with message IDs; include them in authenticated data or prepend to ciphertext.
• Never reuse nonce/IV for same key; rotate keys on wraparound.
• Log and audit nonce generation; derive nonces with deterministic KDFs (e.g., HKDF with per-record counter) when system needs reproducibility.
• Transmit IV/nonce in clear alongside ciphertext; store only as metadata and ensure backups preserve uniqueness constraints.

Brief thesis
Encrypt-then-MAC (symmetric cipher + HMAC) and AEAD (AES-GCM) both provide confidentiality+integrity, but differ across performance, streaming, error semantics, and implementation risk. As a Cybersecurity Engineer I choose based on threat model, operational constraints, and ecosystem support.

Performance & hardware acceleration

• AES-GCM is faster on modern CPUs with AES-NI and PCLMULQDQ (GHASH) — low latency and high throughput.
• HMAC+AES-CBC (or CTR) may be slower because HMAC (SHA-2) lacks universal hardware on all platforms; but on systems with SHA extensions HMAC can be competitive.
• For small messages AES-GCM’s single-pass combined primitive usually wins.

Streaming support

• Encrypt-then-MAC: easier to support streaming/ chunked processing — you can stream ciphertext and incrementally update HMAC.
• AES-GCM: supports incremental processing but GHASH requires careful handling of lengths and finalization; less natural for unbounded streams unless you use explicit chunk framing and rekeying.

Error handling

• AEAD (AES-GCM) returns a single auth-fail — clear, atomic. Rejection happens before plaintext release.
• Encrypt-then-MAC also cleanly rejects on MAC mismatch. However, implementations sometimes verify MAC after partially processing plaintext (bad), so ensure MAC checked before any use.

Implementation risks in distributed services

• Key management: both need secure key distribution; AEAD uses fewer keys (single key for crypto), reducing operational surface.
• Nonce/IV misuse: AES-GCM is catastrophic if IVs repeat (complete loss of authenticity/confidentiality). Systems must enforce unique nonces (per-key counters, deterministic derivation). Encrypt-then-MAC with CTR/CBC also requires IV care but repeated IVs typically less disastrous than GCM nonce reuse.
• Interop & downgrade: mixing libraries with different defaults (tag length, AAD handling) causes subtle vulnerabilities.
• Side channels & constant-time: HMAC implementations must be constant-time on comparisons; GCM GHASH has fewer timing pitfalls but still needs safe APIs.
• Recovery and replay: AEAD’s AAD lets you bind metadata (IDs, sequences) to ciphertext; with HMAC you can do same but must ensure consistent inclusion.

Recommendation
Prefer AEAD (AES-GCM or AES-GCM-SIV/ChaCha20-Poly1305) for most services due to performance and simpler API, but:

• Enforce strict nonce strategy (counters or key per message).
• Use library AEAD APIs (don't roll your own encrypt-then-MAC).
• For true streaming/long-lived streams use chunked encrypt-then-MAC with per-chunk keys/IVs or streaming AEAD constructions (e.g., TLS record layer, RFC 9126).
• Automate key rotation, telemetry for nonce reuse, and protocol tests to detect interoperability pitfalls.