Cryptography Concepts
The primitives a developer must choose between — hashing, symmetric and asymmetric encryption, cipher modes, signatures, randomness, password storage and TLS — and the reasoning behind each choice. Interviewers ask at the concept level because the common failures are picking the wrong primitive, not calling it incorrectly.
part ofApplication security & secure codingoverview, primer and where to startread it →on this pageshowhide
explore
- Cryptographic Hashing5 questions
- Symmetric Encryption4 questions
- Asymmetric Encryption5 questions
- Cipher Modes & Authenticated Encryption5 questions
- Digital Signatures4 questions
- Secure Randomness5 questions
- Password Storage4 questions
- Transport Layer Security5 questions
- Computer Scienceskillanchors this topic
- AI Engineerrole
- AI Red Teamingrole
- API Designskill
- Android Developerrole
- Backend Developerrole
- Blockchain Developerrole
- Cyber Security Expertrole
- Data Engineerrole
- DevOps / SRE Engineerrole
- DevSecOps Engineerrole
- Frontend Developerrole
- Full Stack Developerrole
- GraphQLskill
- Java Backend Developerrole
- Java SDETrole
- Kotlin Backend Developerrole
- Machine Learning Engineerrole
- QA Engineerrole
- Software Architectrole
- iOS Developerrole
questions
page 2 of 2Symmetric ciphers such as AES encrypt bulk data orders of magnitude faster per byte than public-key operations such as an RSA private-key operation or an elliptic-curve key-agreement step. Derive where that gap comes from in terms of what each primitive actually computes, and then compare the three topologies by which a shared symmetric key can get into place — an interactive key-agreement handshake, store-and-forward per-message key wrapping, and a key-management service that returns a data key both in usable and in protected form — saying what each one assumes about liveness and trust.
basics
~20 sSymmetric ciphers are a few cheap CPU-level rounds over a fixed block, so cost is linear in bytes; public-key work is big-number modular exponentiation or curve point multiplication, costly per operation. Cost being per operation, key establishment picks a topology: interactive agreement (live peer, forward secrecy), per-message wrapping (no interaction), or a custodian-issued data key (online trusted service).
TLS clients typically ship with a store of well over a hundred certificate authorities. Explain the security property that follows from that, why revocation is the weak part of the model, and what a system can do when 'any public CA' is too broad a trust set.
basics
~20 sTrust is a disjunction: any trusted authority - or anyone who compromises or coerces one - can vouch for any name, so you inherit the weakest. Revocation soft-fails, so short-lived certificates replace it; narrow trust with private CAs or pinning, and detect mis-issuance through public issuance logs.
Why are older TLS/SSL versions and cipher suites removed rather than left enabled for compatibility? Explain downgrade attacks and how a negotiated protocol defends its own negotiation.
basics
~20 sA negotiated protocol is only as strong as the weakest option it will accept, because an active attacker steers negotiation. Authenticating the whole handshake transcript stops edits to the negotiation, but only refusing an option removes a weakness both peers genuinely support.
A value produced by a non-cryptographic pseudo-random generator never throws, never looks wrong, and passes every test. Suppose someone recovers that generator's internal state from a handful of observed outputs: what do they gain, and in particular what happens to the values the system issued *before* the compromise? Then rank the controls that prevent this class of defect rather than detect it afterwards, and say why each rung is weaker than the one above it.
basics
~20 sAn ordinary generator's state update is invertible, so a recovered state yields the sequence forwards and backwards: values issued in the past are exposed too. Prevent structurally — one minting facility, then a closed list of approved sources. Post-hashing, lint and monitoring only weaken from there.
Leadership asks you to encrypt all sensitive data with symmetric encryption. Since the application must hold the key in order to use the data, explain what threats this actually removes, what it does not, and how you would decide where the encryption boundaries go.
basics
~20 sIt converts a data problem into a key-custody problem. It removes readers who get bytes without keys - backups, replicas, stolen media, low-privilege accounts, dumps. It removes nothing from an attacker inside the process that legitimately decrypts.
You are designing the on-disk format for encrypting many records with a symmetric key. Walk through the decisions — nonce strategy, what belongs in the associated data, how many records one key may protect — and say what an authenticated mode still does not protect against.
basics
~20 sStore a versioned header — format version, key id, nonce — and authenticate all of it plus the record's identity as associated data. Bound messages per key so nonces cannot collide. An authenticated mode still misses replay, rollback, record deletion, length leakage and key ambiguity.
Your product claims that its signed audit records are non-repudiable evidence. What has to be true operationally for that claim to hold, and where do real systems usually fail it?
basics
~20 sNon-repudiation is a system property, not an algorithm property. It needs exclusive key control by the party being bound, a trustworthy key-to-identity binding, trusted time so revocation has meaning, an append-only store the signer cannot rewrite, and someone who actually verifies.
showing 31–37 of 37