All jobs / Cybersecurity

Cryptography interview questions

Cryptography questions a Cybersecurity can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. What is the difference between hashing, encryption and encoding, and when do you use each?

    The strongest answer: Hashing is one-way and used to verify, such as a password check; encryption is reversible with a key and used to keep data confidential; encoding such as base64 is only a format change and protects nothing

    Why it works: Exactly — and calling out encoding matters, because that is the confusion the question is testing for.

    • One-way, reversible, or neither.
    • Hash to verify; encrypt to protect.
    • Encryption needs a managed key.
    • Encoding is a format, not a control.

  2. How do you store a password in 2026?

    The strongest answer: A slow, salted password hash (Argon2 / bcrypt / scrypt) — not reversible encryption, not SHA-256 of the raw password, not plaintext “for support”

    Why it works: Exactly. Password hashes are one-way and slow. Encryption is for secrets you must read back.

    • Slow salted password hash.
    • Not reversible encryption.
    • Not a fast hash.
    • Never plaintext for support.

  3. When would you use symmetric encryption, when asymmetric, and why do real systems use both?

    The strongest answer: Symmetric is fast and fine for bulk data when both sides can hold the same key; asymmetric solves getting a key to someone you have never met and lets you verify a signature — so systems use asymmetric to agree a symmetric key and then encrypt the data with it

    Why it works: Right — that hybrid pattern is what the question is fishing for, and it is what a TLS session does.

    • Asymmetric distributes, symmetric carries.
    • Same key both sides: symmetric.
    • Key pair for strangers and signatures.
    • Hybrid is the normal design.

  4. A browser shows a certificate warning on an internal service, and a developer suggests telling everyone to click through it.

    What does a certificate actually prove, and what is the right fix here?

    The strongest answer: It binds a name to a public key, and it is trusted because an authority the client already trusts signed it — so the fix is a certificate from a trusted authority, or the internal authority distributed to the fleet, not training people to ignore warnings

    Why it works: Exactly — trust comes from the chain, and teaching people to dismiss warnings removes the only signal they have.

    • Certificates bind a name to a key.
    • Trust comes from the chain.
    • Fix the certificate, not the user.
    • Keep warnings meaningful.

  5. At a high level, what happens in a TLS handshake, and what does it give you besides encryption?

    The strongest answer: The two sides agree parameters, the server presents a certificate the client validates against its trust store and the name it asked for, and session keys are established — so you also get server identity and tamper detection on everything after that

    Why it works: Right — identity and integrity are the parts people forget, and both depend on the client actually validating the name.

    • Agree, authenticate, derive keys.
    • The certificate proves the name.
    • Integrity, not only secrecy.
    • Validation is the client’s job.

  6. A developer wants to invent a “small” encryption scheme for tokens. What do you say?

    The strongest answer: Use a boring library and a documented mode — homemade crypto is a finding with extra steps

    Why it works: Exactly. Boring crypto. Learning happens in a lab, not on session tokens.

    • Use a boring library.
    • Document the mode.
    • No homemade tokens.
    • Do not hide the scheme.

  7. An expired internal certificate took down a payment path, and the team wants a five-year certificate so it cannot happen again.

    What is your answer as the owner of the certificate authority?

    The strongest answer: No — a longer lifetime hides the real problem, which is that issuance and renewal are manual. I would automate issuance, shorten lifetimes, inventory every certificate with an owner, and alert long before expiry

    Why it works: Right — short lifetimes force the automation that makes expiry a non-event, and inventory is what makes rotation possible at all.

    • Automate issuance and renewal.
    • Short lifetimes force the automation.
    • Inventory every certificate and owner.
    • Rotate keys, not only dates.