Cryptography interview questions

For practical purposes, no. AES-128 already needs about 2^128 work to brute-force — utterly infeasible — so AES-256 doesn't make you meaningfully safer against brute force; it mainly adds margin (e.g. post-quantum headroom, compliance). Both are standardized and unbroken. Your mode (GCM), nonce handling, and key management matter far more than 128 vs 256. 'AES-256 is twice as secure' is the misconception.

No. You can't compare raw key length across different algorithm families. Because of how each one's underlying math hardens, a 256-bit elliptic-curve key gives roughly the same security as a 3072-bit RSA key — about 128-bit strength, per NIST. Bigger isn't simply stronger: ECC reaches equivalent strength with far smaller keys, which is why modern systems prefer it. Within a single algorithm, longer keys do help, up to a point.

You don't — cryptographic hashes are one-way functions with no inverse. 'Cracking' a hash means guessing candidate inputs, hashing each, and comparing (dictionary, brute force, rainbow tables), which is exactly why slow salted hashes are used for passwords. There is no key that 'decrypts' a hash. If something can be decrypted it was encrypted, not hashed — and Base64 is reversible encoding, not hashing.

Not necessarily. Double-encrypting with the same algorithm doesn't simply double security — the classic result is that 2DES adds only about one bit of effective strength because of meet-in-the-middle attacks, which is why 3DES exists. More importantly, hand-rolled multi-layer schemes tend to introduce implementation bugs that weaken the whole thing. Use one well-vetted authenticated cipher (AES-GCM) with sound key management instead of stacking crypto.

No. TLS/HTTPS secures data in transit between client and server; once received, the data is decrypted and handled in plaintext by the app, then stored however the database is configured. Protecting data at rest is a separate concern — disk/column encryption, a KMS, and access control. Conflating 'we use HTTPS' with 'our stored data is encrypted' is a common and dangerous misconception.

No. A salt is a unique, random value stored right alongside the hash; its job is to make identical passwords hash differently and to defeat precomputed rainbow tables — not to stay secret. It's fine if an attacker who steals the database also gets the salts. What actually protects passwords is a slow, salted hash (bcrypt, scrypt, Argon2). A separate, optional secret 'pepper' is a different concept.

Password storage needs a deliberately slow, salted, memory-hard hash — bcrypt, scrypt, or Argon2 — so cracking stolen hashes is expensive and rainbow tables don't apply. A fast hash like SHA-256 is trivially brute-forced at scale; reversible encryption means one key compromise exposes every password at once; and plaintext is indefensible no matter how locked down the database is. Choose Argon2id (or bcrypt) with a tuned work factor and a unique per-user salt.

SSLv3, TLS 1.0, and RC4 are broken or deprecated and enable downgrade and decryption attacks, so disable them and require TLS 1.2 or 1.3 with strong, forward-secret cipher suites — accepting the rare loss of very old clients. Leaving them on for compatibility keeps the weakness exploitable. Adding a second certificate or switching to a self-signed one doesn't remove the weak protocols, and self-signed certs harm trust without fixing the cryptography.

`alg: none` lets anyone craft a valid-looking unsigned token and impersonate any user — a full authentication bypass, not a minor finding. Fix it by allow-listing the expected algorithms server-side and always verifying the signature with the right key; never trust the token's own alg header to pick the verification method. Longer expiry or moving where the token is stored does nothing about forged, unsigned tokens. This is critical and exploitable, so document is not a fix.

Encryption at rest defends exactly one threat — physical or disk theft — and does nothing against a compromised application, stolen credentials, or sniffed traffic, because the database decrypts transparently for any authorized query. A sound design also requires TLS in transit, strong authentication and authorization, and proper key management with separation of duties. Doubling the at-rest encryption adds cost without changing the threat model, and encrypting only the backups leaves the live data and its access paths exposed.

If the key lives with the ciphertext, anyone who steals the database gets both, so the encryption protects nothing — it is a lock with the key taped to it. Keys must be managed in a dedicated KMS or HSM, separated from the data, with strict access control, rotation, and separation of duties. Hashing the key makes it one-way and useless for decryption, and storing extra copies in the same place just multiplies the exposure rather than reducing it.

Manual renewals fail, so engineer the problem away with automated ACME renewal plus expiry monitoring that alerts days in advance. A calendar reminder is the manual process that already failed once. A long-lived self-signed cert breaks public trust and violates modern lifetime limits (CAs cap validity at ~398 days, dropping further). Disabling TLS trades an availability blip for a catastrophic confidentiality and integrity loss.

Encryption in transit (TLS) protects data moving over the network from eavesdropping and tampering; enforce TLS everywhere and reject plaintext. Encryption at rest protects stored data on disks and backups, typically via KMS-managed keys using envelope encryption. Both are baseline controls, but neither stops an authorized-but-malicious request — the service decrypts transparently for valid callers — so access control still matters most.

RSA is an asymmetric algorithm used to encrypt data or create digital signatures using a key pair. Diffie-Hellman is a key-agreement protocol that lets two parties derive a shared secret over a public channel without ever transmitting it. They solve different problems: RSA proves identity and can wrap keys; DH negotiates a session key — and its ephemeral variant gives forward secrecy.

A digital signature is the hash of a message transformed with the signer's private key. The verifier recomputes the hash, applies the signer's public key, and checks they match. Because only the signer holds the private key, a valid signature proves the message came from them (authenticity), wasn't altered (integrity), and that they can't credibly deny it (non-repudiation).

HMAC is a keyed message authentication code: it hashes the message together with a secret key using a nested construction (inner and outer hash with key-derived pads). It proves both integrity (the message wasn't altered) and authenticity (it came from someone holding the key). A plain hash proves neither, since anyone can recompute it; HMAC also resists length-extension attacks.

Store passwords using a deliberately slow, salted, adaptive password-hashing function — bcrypt, scrypt, or Argon2 — never a fast general-purpose hash like SHA-256 or MD5. Fast hashes are built for speed, so attackers with GPUs can test billions of guesses per second against a leaked database. Slow hashes have a tunable work factor (and memory cost) that makes each guess expensive, keeping brute force impractical even after a breach.

Perfect Forward Secrecy (PFS) means each session derives a unique key from an ephemeral key exchange that is thrown away afterward. If an attacker later steals the server's long-term private key, they still cannot decrypt previously captured traffic, because that key was never used to derive the session keys. It's achieved with ephemeral Diffie-Hellman (DHE/ECDHE).

The client builds a chain from the server (leaf) certificate up through one or more intermediate CAs to a root CA in its trust store. It verifies each certificate's signature using the next issuer's public key, checks validity dates, name/hostname match, key usage, and revocation (CRL/OCSP). Trust terminates at a self-signed root that is pre-trusted; the chain is valid only if every link checks out.

A salt is a unique, random value generated per user and combined with the password before hashing. It ensures identical passwords produce different hashes and makes precomputed attacks like rainbow tables useless, since the attacker would need a separate table per salt. Salts are stored alongside the hash. A pepper is an additional secret value, the same for all users, kept separately (e.g., in app config or an HSM) so a database leak alone isn't enough.

TOTP (Time-based One-Time Password) combines a shared secret, established at enrollment, with the current time divided into fixed windows (usually 30 seconds). It runs HMAC over the time-step counter with the secret, then truncates the result to a 6-digit code. Both the app and server hold the same secret and clock, so they independently compute the same code — no network call needed. The code rotates each window.

Client and server agree on a shared secret in a single round trip using ephemeral Diffie-Hellman (ECDHE). The ClientHello carries the supported groups and a key share; the server replies with its key share and certificate, both sides derive the same keys, and application data flows immediately — with forward secrecy by default.

The CIA triad is the three core goals of information security: confidentiality (only authorized parties can read data), integrity (data isn't altered without authorization), and availability (authorized users can access systems when needed). Almost every control maps to one or more of these.

Encoding (like Base64) is a reversible format change with no secret — not security. Encryption is reversible with a key and protects confidentiality. Hashing is a one-way function producing a fixed-length digest, used for integrity checks and password storage, and cannot be reversed back to the input.

Symmetric encryption uses a single shared secret key for both encryption and decryption and is fast, but both parties must already share the key. Asymmetric uses a public/private key pair, solving the key-distribution problem but more slowly. Real protocols like TLS use asymmetric crypto to exchange a symmetric key, then switch to symmetric for the bulk data.

Compress first, then encrypt. Good encryption produces output that is statistically indistinguishable from random, so ciphertext has no patterns left to compress — compressing afterward is pointless. The important caveat: compressing secret and attacker-controlled data together before encryption can leak information through ciphertext length, which is exactly the CRIME and BREACH attacks.

Encoding transforms data into another format for compatibility and is fully reversible by anyone with no key (e.g. Base64, URL encoding) — it provides no confidentiality. Encryption is reversible only with a key and is what provides confidentiality. Hashing is a one-way function: you cannot recover the input from the output, which is why it suits integrity checks and password storage (with a salt and slow KDF).

HTTPS is not a protocol of its own — it is plain HTTP running inside an encrypted TLS tunnel. SSL is the old name: SSL 2.0/3.0 are the deprecated, insecure predecessors of TLS, which superseded them (TLS 1.0 through 1.3). When people say 'SSL certificate' or 'SSL', they almost always actually mean TLS.

Because they are fast. MD5 and SHA-256 are designed for speed, which is exactly wrong for passwords: an attacker who steals the hashes can compute billions of guesses per second on a GPU. The fix is a deliberately slow, memory-hard key-derivation function — bcrypt, scrypt, or Argon2 — combined with a per-user salt and a tunable work factor.

Phishing-resistant MFA means the second factor can't be replayed against the real site even if the user is tricked. FIDO2/WebAuthn passkeys achieve this with origin-bound public-key cryptography: the authenticator signs a challenge tied to the real site's domain, so a credential captured by a lookalike or attacker-in-the-middle site is useless. TOTP codes and push prompts are still phishable because they can be relayed in real time.

First identify the hash format (hashid or context), then run hashcat or John with the correct mode against a wordlist like rockyou, applying rules to mutate candidates. Use the right format flag (NTLM, sha512crypt, NetNTLMv2, etc.) so the tool hashes guesses the same way the target did.

Any authenticated domain user can request a Kerberos service ticket (TGS) for any account with an SPN. That ticket is encrypted with the service account's NTLM password hash, so you extract it and crack the password offline — no privileged access needed to start, and it's near-silent.

Encryption is reversible — with the key you get the plaintext back; it protects confidentiality. Hashing is a one-way function producing a fixed-size digest you cannot reverse; it verifies integrity and identity. Passwords should be hashed with a slow, salted algorithm like bcrypt or Argon2, never encrypted.

Symmetric encryption uses one shared key for both encrypt and decrypt — it's fast but the key must be shared securely. Asymmetric encryption uses a public/private key pair, solving key distribution but slowly. Real systems use asymmetric crypto to exchange a symmetric session key, then use the fast symmetric cipher for bulk data.

A PKI is the system of CAs, certificates, and policies that binds public keys to identities. To validate a server cert a client builds a chain to a trusted root, verifies each signature, checks validity dates and the hostname, confirms key usage, and checks revocation via CRL or OCSP.

Never store passwords in plaintext or reversibly encrypted, and never with fast general-purpose hashes like MD5 or SHA-256. Use a slow, memory-hard password hashing function — Argon2id (preferred) or bcrypt — with a unique random salt per password and a tuned work factor, so an attacker who steals the database cannot feasibly crack the hashes.