Skip to main content

Cryptography

Premium

Cryptography shows up in almost every security engineering interview because it protects data across systems, networks, and workloads. This lesson teaches you to describe encryption, hashing, digital signatures, and key management in simple, accurate terms that demonstrate practical judgment.

Security engineers are expected to:

  • Explain fundamental concepts like encryption, hashing, and signatures.
  • Apply encryption correctly to data in transit, data at rest, and data in use.
  • Recognize common implementation mistakes and propose realistic fixes.

What to expect

Typical interview prompts include:

  • “What is the difference between hashing and encryption?”
  • “How would you encrypt sensitive data in a production database?”
  • “You’re building a system that encrypts files uploaded by users. How would you design it?”

Expect a mix of quiz-style and scenario-based questions on cryptography.

Concepts

These are the essential building blocks you must be able to explain clearly:

Symmetric encryption

  • Uses a single shared key for both encryption and decryption.
  • Example: Encrypting database contents with AES.
  • Why it matters: Fast and ideal for protecting large volumes of data.

Asymmetric encryption

  • Uses a public/private key pair.
  • Example: Exchanging session keys during a TLS handshake.
  • Why it matters: Enables secure key exchange and identity verification.

Hashing

  • One-way transformation for integrity or password storage.
  • Example: Hashing passwords with bcrypt or Argon2.
  • Why it matters: Ensures that stored secrets cannot be reversed even if leaked.

Digital signatures

  • Prove integrity and authenticity.
  • Example: Signing software releases or JWT tokens.
  • Why it matters: Prevents tampering and impersonation.

Key management

  • Creating, storing, rotating, and controlling access to keys.
  • Example: AWS KMS, HashiCorp Vault, or hardware security modules (HSMs).
  • Why it matters: Encryption is only as strong as your ability to protect the keys.

Data protection across environments

Interviewers often ask where and how you apply encryption. Use this table to frame your answers:

ContextGoalExample control
Data in transitPrevent interception or tampering.TLS, HTTPS, VPNs.
Data at restPrevent unauthorized access to stored data.AES encryption, key management policies.
Data in useProtect data during computation.Hardware-backed encryption (SGX, Nitro Enclaves).

This helps you show that you’re thinking about the full lifecycle of data, not just one point in time.

Design risks

These are the cryptography failures interviewers expect you to recognize. The table shows what the risk is and how engineers solve it in real systems.

RiskDescriptionMitigation
Hardcoded keysKeys stored in code or config files.Use managed key vaults or environment-based retrieval.
Weak or custom algorithmsNon-standard or outdated ciphers.Use modern, vetted algorithms (AES-256, RSA-2048).
No rotation policyStatic keys never replaced.Rotate keys periodically and after compromise.
Improper key sharingDevelopers or systems share keys manually.Assign least privilege and enforce IAM-based access.
Poor randomizationPredictable initialization vectors or seeds.Use cryptographically secure random generators.

Recognizing these mistakes makes you sound like someone who has actually reviewed production systems, not just read documentation.

Tradeoffs

Cryptography is not free. Interviewers want to see that you understand:

  • Latency: Encryption and decryption introduce overhead.
  • Storage cost: Ciphertext and signatures may increase data size.
  • Operational complexity: Key rotation, KMS permissions, and auditing require process discipline.

Mentioning these shows maturity and real-world awareness.

How to answer

Use a clear three-step approach for any cryptography question:

  1. Clarify: What type of data and environment are we protecting?
  2. Explain: What mechanism or framework applies and why?
  3. Evaluate: What operational challenges or tradeoffs exist?

Prompt: “How would you encrypt sensitive data in a production database?”

Strong answer: “I’d encrypt sensitive columns using AES with keys managed by a KMS. The database would store ciphertext only, and keys would be rotated regularly with access restricted to the application layer. This minimizes exposure if the database is compromised.”

Next Lesson