Why does a ransomware encryptor cipher only a fraction of each file?

## The arithmetic that drives the choice Picture the target: shared storage holding hundreds of guest disks, tens of terabytes in total. To cipher every byte the encryptor must read all of it and write all of it back. That is bounded by the storage fabric, not by the processor - modern symmetric ciphering is hardware-accelerated and effectively free next to the input and output cost. Now put a clock on it. The operation becomes obvious the moment files stop opening. From that moment the operator is racing a human decision to disconnect things. If a full pass takes eight hours and the estate reacts in one, the operator finishes a fraction of the estate, gets a much weaker demand, and loses the window. Ciphering one tenth of the bytes turns eight hours into under one. That is the whole reason partial - often called intermittent - encryption exists. It is a deliberate operational optimisation by people who are competent, not a mistake by people who are not. ## Why a partly ciphered file is still useless The reason a tenth of the bytes buys nearly all of the denial is that data formats are not uniform. Their interpretability is concentrated: - A **guest disk image** begins with a partition table and filesystem superblocks; destroy those and the volume does not mount at all, whatever the remaining bytes contain. - A **compressed archive** or any deflate-style stream is a chain: corrupt an early region and everything after it decompresses to noise. - A **database file** is a set of pages with a header and allocation structures; ciphered pages scattered at a stride mean the engine refuses to open the file. - An **office document** is itself a compressed container with a directory at a known offset. So the encryptor puts its effort where the format's meaning lives, and treats the bulk payload bytes as not worth the input and output. ## What the trade actually accepts This is the part candidates usually miss, and it is what makes the question interesting. 1. **Plaintext survives.** Bytes that were never touched are still there. For unstructured content - plain text, some media, log-like files - carving out the untouched regions can return real, readable material. It gives fragments without names, ordering or completeness, so it is not recovery of a running system, but it is not nothing either. 2. **The crew inherits a correctness problem.** Their decryptor must reverse exactly the same chunk size and stride, per file, per version of their own payload. A bug means a paying victim gets nothing back, which damages the only thing the business model runs on - the belief that paying works. 3. **Denial is weaker for a few formats.** Where meaning is not concentrated, skipping bytes really does leave usable data. The operator takes all three because finishing the estate inside the window is worth more than perfect denial. ## Per-victim keying, and why it matters here The same trailer that records chunk size and stride usually carries the key material: a symmetric key generated **per victim** (often per file, itself sealed under a victim key), stored wrapped under the crew's public key. The operational consequence is the point to remember: material recovered from one victim frees that victim, not the others. Only the crew's private key - occasionally obtained through a seizure or a leak of the crew's own infrastructure - unlocks the whole population at once. So "a decryptor was published" is a claim that must be read carefully: for whom? ## How to answer this in an interview Lead with the constraint, not the cipher: "they are bounded by input and output across the fabric and by how long they have before someone disconnects things, so they cipher the regions that make a file interpretable and skip the rest. It costs them some recoverable content and it puts a correctness burden on their own decryptor, and they take that trade to finish the estate in one window." Then, if pushed on the leftovers, be precise: partial recovery of fragments is not recovery of a system.