Symmetric encryption is usually described as 'the same key encrypts and decrypts'. Give the definition an engineer should actually work from: what security property it provides, what it does not provide, and why a block cipher such as AES is not by itself an encryption scheme.
answer
- same key both directions, secrecy in the key only
- Kerckhoffs: rotate a key, you cannot rotate a design
- AES = keyed permutation on one 128-bit block, primitive not scheme
- key size bounds brute force; block size sets the birthday limit (64-bit -> 2^32)
- table-lookup AES vs CPU instructions vs ChaCha20 = three side-channel profiles
basics
~20 sOne secret shared by both sides; security rests on the key alone, never on hiding the algorithm. AES by itself is a keyed permutation on one fixed block, so a usable scheme adds length handling and per-message randomisation. It gives confidentiality only, not integrity or authenticity.
solid answer
~50 sSymmetric encryption means both parties hold the **same secret key**, and all security rests on that key staying secret. The algorithm is assumed public (Kerckhoffs's principle), because designs leak out of shipped binaries and, unlike keys, cannot be rotated afterwards. A block cipher like AES is a **primitive, not a scheme**: for a fixed key it is an invertible permutation on exactly one fixed-width block (128 bits for AES), so alone it can neither handle arbitrary-length messages nor produce different output for the same message twice. A scheme is the primitive plus a mode supplying length handling, per-message randomisation and, in modern practice, an integrity tag. Key size bounds brute force; **block size** is a different parameter, and it is the one that forced 64-bit-block ciphers out of bulk traffic. What symmetric encryption does **not** give: tamper detection, proof of who sent the message, replay protection, or anything at all once the key is reachable.
go deeper
Say it cleanly: one shared secret, security depends only on the key, the algorithm is public. Know that AES alone handles a single fixed-size block and that encryption gives secrecy, not tamper detection.
Separate primitive from scheme, and separate key size from block size — key size bounds brute force, block size sets the birthday limit that retired 64-bit-block ciphers. Name the four properties (confidentiality, integrity, authenticity, freshness) and which one encryption alone supplies.
Argue Kerckhoffs operationally (keys rotate, designs do not) and show you know implementations diverge: table-lookup AES leaks through cache timing, CPU cipher instructions are constant-time and much faster, ChaCha20 is constant-time in plain software. Tie key-volume limits to rekeying policy.
Frame the whole area as key custody, not algorithm choice: who holds the key, in which compromise domain, for how long, and what a single compromise costs. Set fleet-level rules — standard public algorithms, per-object keys wrapped by long-lived keys, CSPRNG-only key material, byte-budget rekeying, and profile choice driven by the deployment target.
## The model Symmetric encryption is the case where the same key is used in both directions: encrypt(K, plaintext) produces ciphertext, decrypt(K, ciphertext) recovers the plaintext. Both endpoints must already hold K before any protected traffic can flow. Every hard question in this area is a consequence of that one fact: the difficulty moves out of the mathematics and into who holds K, for how long, and inside which compromise domain. The mathematics is the part that reliably works. ## Security rests on the key, not the design Kerckhoffs's principle says the system must remain secure when everything except the key is public. This is an operational argument, not academic purity. An algorithm shipped inside software is recoverable by anyone with a disassembler, so its secrecy has a short and unknowable half-life. A design cannot be rotated once it leaks — you would have to replace every deployed endpoint — whereas a key can be rotated in minutes with no code change. And a design that nobody outside the team may review is a design nobody has attacked, which is absence of evidence rather than evidence of strength. "We also keep the algorithm secret" is therefore not an extra layer on top of review; in practice it substitutes for it. The invariant to work from: assume the attacker holds your binary, your protocol description and your ciphertext, and is missing only the key. ## Primitive versus scheme A block cipher such as AES is a primitive, not an encryption scheme: for a fixed key it is an invertible permutation on exactly one fixed-width block (128 bits for AES), so by itself it can neither process a message of arbitrary length nor produce different ciphertext for the same message twice. A usable scheme is that primitive plus a mode of operation, which supplies length handling, per-message randomisation and — in modern authenticated designs — an integrity tag; what a mode is and what each one guarantees is a separate topic and not derived here. ## Key size and block size buy different things Key size bounds exhaustive search. A 128-bit key means 2^128 candidate keys, which engineering effort does not reduce to something feasible. 256-bit keys are chosen for margin: multi-target settings where an attacker grinds many keys at once, and a hedge against future cryptanalysis that shaves bits off. Note the shape of the scaling — each extra key bit doubles the search space, so 256 bits is not "twice as strong" as 128, it is 2^128 times the work, and neither number is what actually fails in deployed systems. Block size is a separate and subtler parameter. Under a single key, ciphertext blocks begin to collide by the birthday bound after roughly 2^(n/2) blocks, where n is the block width, and each collision leaks a relation between the corresponding plaintexts. With a 128-bit block that threshold is around 2^64 blocks, far beyond any realistic data volume. With a legacy 64-bit block cipher it is around 2^32 blocks — tens of gigabytes on one key, a volume that long-lived connections genuinely reached. That is why 64-bit-block ciphers were retired for bulk traffic while their key sizes were still nominally adequate: the limit came from the block, not the key. The same arithmetic is why "rekey after N bytes" is a real design parameter rather than paranoia. ## Where implementations genuinely diverge "Strong cipher" is not one uniform thing, and three concrete cases show it. AES implemented in software with lookup tables leaks through CPU cache timing, because which table line is touched depends on secret key material and a co-resident process can measure that. AES executed with dedicated CPU instructions is constant-time by construction and roughly an order of magnitude faster. ChaCha20 is a stream-cipher design built only from additions, rotations and XORs, precisely so that a plain software implementation is naturally constant-time on hardware that has no cipher instructions. Same nominal security level, three different side-channel and performance profiles. The right choice is therefore a property of the deployment target — a claim you cannot even formulate if you treat "AES" as a single object. ## What it does not give you Confidentiality is one property among four. Integrity (was this modified?), authenticity (who produced it?) and freshness (is this a replay of something older?) are not supplied by encryption and must be added deliberately, which is why modern practice pairs confidentiality with an integrity tag in one operation. Encryption also says nothing about identity: anyone holding the key can produce ciphertext that decrypts, so a key shared by two parties cannot distinguish them, and a key shared by a fleet identifies nobody. That is the structural difference from public-key signatures, and the reason a shared symmetric key makes a poor authentication token. ## Key material Finally, the key must be full-entropy output of a cryptographically secure random generator. A key taken from a timestamp, a counter, a UUID or a password used directly has far fewer than its nominal bits of entropy: the attacker searches the generator's state or the password space, not the key space, so a 256-bit key derived naively from a six-character password is a six-character password. Passwords become keys only through a deliberate key-derivation function with a tuned work factor, and the cipher cannot compensate for entropy that was never there.
- Why is AES-256 not simply twice as secure as AES-128, and when would you still pick it?Each extra key bit doubles the search space, so 256 bits is 2^128 times more brute-force work, not twice as much. Both are already beyond exhaustive search, so the practical arguments for 256 are margin against future cryptanalysis, resistance in multi-target settings where an attacker attacks many keys at once, and compliance requirements. Neither size helps if the key is reachable, reused across purposes, or generated from weak randomness.
- What actually goes wrong if one key encrypts an enormous volume of traffic?Statistically, ciphertext blocks start colliding once the volume approaches the birthday bound implied by the block size — about 2^32 blocks for a 64-bit block, about 2^64 for a 128-bit one — and each collision leaks a relation between plaintexts. Operationally, one key protecting everything means one compromise exposes everything, and rotation requires re-encrypting the whole corpus. That is why systems use per-object keys wrapped by a longer-lived key, and why protocols rekey after a byte budget.
- A team wants to keep their cipher design secret as an additional layer. How do you respond?Point out that it is not additive: the design ships inside binaries anyone can disassemble, so its secrecy has an unknown half-life, and unlike a key it cannot be rotated when it leaks without replacing every endpoint. Worse, secrecy usually replaces external review, so the design has simply never been attacked. Keep the algorithm public and standard, and spend the secrecy budget entirely on the key.
The cipher is a lock cylinder, not a door. A cylinder alone is a component with a keyway; making it useful and safe needs a door, a frame, and a latch that tells you when it has been forced.
saying these in an interview costs you the question
- "We keep the algorithm secret too, so it's an extra layer" — obscurity substitutes for review, and a leaked design cannot be rotated the way a key can.
- "AES-256 is twice as strong as AES-128" — each bit doubles the search space, and key length is almost never the failure mode.
- "It's encrypted, so nobody can modify it or forge it" — confidentiality is not integrity, authenticity or freshness; those must be added deliberately.
- "AES is AES" — a table-lookup software implementation, a hardware-instruction implementation and ChaCha20 have very different side-channel and performance profiles.
- Deriving a key from a UUID, a timestamp or a raw password — the attacker searches that small space, not the nominal key space.