Cryptography and Encryption Fundamentals Questions

Comprehensive understanding of modern cryptography and encryption principles used to build secure systems. Candidates should be able to explain the differences between symmetric and asymmetric encryption, appropriate use cases for each, and common algorithms by full name such as Advanced Encryption Standard and Data Encryption Standard for symmetric ciphers and Rivest Shamir Adleman and elliptic curve based algorithms such as Elliptic Curve Digital Signature Algorithm and Elliptic Curve Diffie Hellman for public key operations. Describe hybrid encryption patterns in which asymmetric cryptography is used to protect a symmetric session key, and discuss block cipher modes of operation including cipher block chaining and authenticated encryption modes such as Galois Counter Mode, as well as the role of initialization vectors and nonces. Cover hash functions and integrity checks with properties such as collision resistance and preimage resistance, message authentication codes, authenticated encryption, and digital signatures for authentication and nonrepudiation. Include high level Public Key Infrastructure concepts including certificates and certificate authorities and how certificates are used to establish trust, together with foundational Transport Layer Security and Secure Sockets Layer principles without requiring deep certificate lifecycle management knowledge. Emphasize key management and operational concerns including secure key generation, secure storage, rotation and compromise handling, randomness and entropy sources, recommended key lengths and algorithm lifecycle considerations, and performance and scalability trade offs. Be prepared to discuss common implementation pitfalls and failures such as weak key sizes, poor random number generation, improper key reuse, and lack of authenticated encryption, plus threat models and practical applications including encrypting data at rest and in transit, secure channels, and signing and verification. Avoid deep mathematical proofs unless specifically requested, but be ready to reason about practical trade offs, algorithm selection, and secure implementation patterns.

HardTechnical

52 practiced

Provide a detailed analysis comparing RSA and elliptic curve cryptography (ECC) for large-scale TLS termination where millions of handshakes occur daily. Address CPU and memory cost per handshake, signature verification versus generation costs, key and certificate sizes, hardware acceleration impact, caching strategies, and long-term maintainability.

Sample Answer

**Summary recommendation**Use ECC (X25519 for KEX + P-256 or Ed25519/ECDSA for signatures) as the default for large-scale TLS termination. ECC offers much lower CPU, memory, and bandwidth per handshake and easier horizontal scale; keep RSA (2048/3072) as fallback only for legacy clients and plan for algorithm-agility and post-quantum migration.

**CPU & memory cost per handshake**- ECC: key exchange (X25519) and signature ops are compact; typical CPU time per handshake is a few hundred microseconds on modern x86 for X25519 + ECDSA/Ed25519. RAM impact is minimal (smaller ephemeral key material).- RSA: RSA key-exchange (RSA-KEM, obsolete) is rarely used; RSA-based certificate signatures (2048/3072) require larger bignum ops and more cache pressure — CPU per handshake is noticeably higher and increases with key size.- Net effect: for millions/day, ECC reduces aggregate CPU by 2–5x vs RSA certificates at equivalent security levels.

**Signature verification vs generation costs**- Server-side signing matters: in TLS 1.3 the server signs handshake messages per handshake (ephemeral). Signature generation cost is therefore on the server.- ECDSA/Ed25519/X25519: signature generation and verification are both efficient; Ed25519 signing is extremely fast and deterministic; verification is also cheap and benefits clients.- RSA: with CRT private key operations are fast but memory/cache heavy; verification (public exponent e often 65537) is very cheap for clients. For servers doing many signatures, RSA signing can be slower than Ed25519/ECDSA for equivalent security at higher RSA sizes.- Practical: ECC gives better per-handshake signing CPU for high volume TLS termination.

**Key and certificate sizes**- RSA-2048 certs ~2–3× larger than ECDSA P-256/Ed25519; signatures are larger (RSA sig ~256 bytes vs ECDSA ~64 bytes, Ed25519 64 bytes).- Smaller certs reduce network I/O and memory footprint in TLS stacks and caches — important at scale.

**Hardware acceleration impact**- HSMs / TPMs: offload private key ops (RSA or ECC) reduces CPU but adds latency and throughput limits (choose HSM with sufficient ops/sec).- Intel QAT / AES-NI: QAT accelerates asymmetric ops and symmetric crypto; ECC benefits strongly from hardware that supports curve ops (FPGA/QAT). TLS offload/load balancers with TLS ASICs often support large numbers of ECC handshakes more efficiently than RSA.- Trade-off: HSMs give security/legal benefits (key custody) but can be throughput bottlenecks; use batching, local ephemeral keys, or hybrid models (HSM-protected long-term keys, ephemeral locally generated keys signed less frequently).

**Caching & optimization strategies**- Always use TLS 1.3: smaller handshake, removes RSA key-exchange, favors ephemeral Diffie-Hellman (X25519).- Session resumption: use session tickets and 0-RTT (careful with replay) to avoid full handshake traffic.- Connection pooling / keep-alive: reduce handshake frequency per client.- OCSP stapling and SCT stapling: avoid per-client OCSP fetches.- Certificate and session caches: size for peak load; smaller ECC certs mean more entries fit in cache.- Offload verification for inbound traffic to dedicated worker pools or accelerator chips; separate cryptographic worker threads to avoid blocking network threads.

**Long-term maintainability**- Algorithm agility: implement and test multiple signature/KEX algorithms and config flags; log metrics per algorithm to detect failures.- Library choices: use well-maintained TLS stacks (BoringSSL, OpenSSL recent versions) with Ed25519/X25519 support and constant-time implementations.- Key rotation & incident response: shorter-lived certs, automated issuance (ACME) and rotation reduce blast radius.- Post-quantum readiness: ECC and RSA are both broken by large quantum adversaries — plan hybrid approaches (classical + PQC) and phased rollouts; use a reverse-proxy design that allows swapping crypto without touching backend services.- Operational aspects: monitor handshake CPU, latency, TLS errors; benchmark hardware accelerators under realistic loads; test fallback paths for legacy clients.

**Conclusion**For millions of daily handshakes prioritize ECC (X25519 + Ed25519/P-256), TLS 1.3, session resumption and hardware offload where appropriate. This minimizes CPU, memory and bandwidth, simplifies caching, and scales more predictably. Maintain algorithm agility and plan a PQC migration path to stay resilient long-term.

EasyTechnical

72 practiced

Explain key derivation functions (KDFs) such as PBKDF2 and HKDF. Describe appropriate use cases for each (password stretching vs deriving multiple keys), the roles of salt and iteration/memory cost, and how to safely derive multiple cryptographic keys from a single secret.

HardTechnical

58 practiced

Describe timing and other side-channel attacks relevant to cryptographic operations (for example on HMAC verification or ECDSA signing). Outline a layered mitigation strategy including constant-time implementations, blinding techniques, hardware mitigations, compiler/runtime considerations, and testing approaches to reduce leakage.

EasyTechnical

109 practiced

Describe the core properties of cryptographic hash functions: preimage resistance, second-preimage resistance, and collision resistance. Give brief examples of why each property matters in systems such as password storage, digital signatures, and content-addressing.

HardTechnical

71 practiced

Your organization still relies on SHA-1 in legacy components including certificate signatures and internal git repositories. Create a phased migration plan to stronger hashes (SHA-256 or better) that minimizes downtime, covers certificate replacement and repository migration, addresses interoperability with older clients, and verifies successful migration.

Sample Answer

**Overview & Goals**Reduce risk from SHA-1 by migrating to SHA-256+ with minimal downtime, preserve interoperability for legacy clients during transition, validate cryptographic and operational integrity, and provide rollback paths.

**Phased Plan**1. Inventory & Risk Triage (2–4 weeks)- Discover all SHA-1 uses: CA/intermediate certs, end-entity certs, git repos, signed artifacts, build systems, config files.- Prioritize by exposure and criticality (public-facing certs, CI/CD signing, root/intermediate CAs).

2. Preparation (2–6 weeks)- Stand up new PKI capability supporting SHA-256/SHA-384 (HSM config, key sizes RSA-3072/4096 or ECDSA P-256/P-384).- Update Git server support (GPG commit/tag signatures, server-side hooks) and git client guidance.- Create migration playbooks and test environments; communicate schedule to stakeholders.

3. Certificate Migration (rolling, 4–12 weeks)- Issue new intermediates signed with SHA-256 from existing root if root cannot change; where possible create new root signed by secure method.- Cross-signing: have new intermediates cross-signed by old root to support legacy chains.- Gradually reissue end-entity certs during normal renewal windows; for critical systems, schedule brief maintenance windows.- Revoke old certs after validating chain acceptance.

4. Git Repositories & Artifact Signing (4–8 weeks)- Enable server-side verification for SHA-256-signed commits/tags; support dual-signing: maintain SHA-1 signatures for legacy clients while creating SHA-256 signatures.- Migrate CI/CD to produce SHA-256 signatures and timestamped signatures; convert repository Git objects if necessary using git-filter-repo only after full client readiness.

5. Interoperability Strategy- Implement dual-signing and cross-signed chains; maintain legacy roots/intermediates in trust stores only until deprecation date.- Publish compatibility matrix and provide updated client packages and configuration snippets for older OS/clients; provide fallback proxies for protocol translation if unavoidable.

6. Verification & Validation- Automated tests: chain validation across OS versions, commit/tag verification, package signature checks, and end-to-end CI/CD pipelines.- Monitoring: certificate transparency logs, CRL/OCSP checks, git integrity checksums.- KPIs: percentage of certs migrated, percent of repos accepting SHA-256 signatures, incidents post-migration.

7. Cutover & Decommission (2–6 weeks)- Announce final deprecation date; after threshold reached, revoke old intermediates and remove SHA-1 trust entries.- Run post-mortem and update documentation.

**Rollback & Risk Controls**- Maintain old chain for cross-signing during transition; staged revocation; backup keys in HSM and tested rollback playbooks.

**Why this works**Phased, prioritized approach limits blast radius, dual-signing and cross-signing preserve interoperability, automation ensures repeatability, and verification closes the loop on security and operational readiness.

Unlock Full Question Bank

Get access to hundreds of Cryptography and Encryption Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.