Ciphertext Stealing

How ciphertext stealing works

ciphertext stealing is a block-cipher mode technique that handles a short final block without padding by reusing bytes from the last full ciphertext block. The result is a ciphertext that matches the plaintext length, while still relying on the underlying block cipher for confidentiality.

The core idea is simple, but the block order is easy to mishandle. The penultimate and final blocks must be arranged exactly as the algorithm expects, because ciphertext stealing changes how the last two blocks are formed and recovered.

Why ciphertext stealing exists

Padding solves the “not a multiple of the block size” problem, but it also changes the output length and can introduce padding-specific handling in downstream systems. Ciphertext stealing avoids that by preserving the original plaintext length, which is useful when a format, protocol, or storage layout expects exact length preservation.

That design choice makes ciphertext stealing attractive in legacy and interoperability-sensitive environments. It can reduce format friction, but only if every implementation agrees on the same variant and block-processing rules. A mismatch between encryption and decryption logic can produce corrupted output even when the key is correct.

Implementation and interoperability concerns

The main implementation burden is not the block cipher itself, but the last-block choreography. Encryptors and decryptors must agree on byte ordering, block substitution, and the exact handling of the final partial block, or the ciphertext will not round-trip cleanly.

These details matter because ciphertext stealing is not one universally “obvious” encoding. Different documentation and libraries may describe closely related variants, and a team that copies pseudocode without checking the exact mode definition can create data that another system cannot read. For this reason, implementation notes and test vectors are often more important than the name of the mode alone.

Where it is used and what to verify

Ciphertext stealing is most relevant when length preservation matters more than simplicity, especially in systems that already depend on block-cipher-based encryption and cannot tolerate padding artifacts. It is a compatibility feature as much as a cryptographic one.

Before adopting it, teams should confirm that every component in the path supports the same variant, and that test cases include edge conditions such as a one-byte short final block. In practice, the safest validation is to encrypt and decrypt across every implementation that will touch the data, then compare the recovered plaintext byte for byte.

Risk and Threat Considerations

Ciphertext stealing itself does not create a new cryptographic weakness, but implementation errors can create real exposure. The most common risk is silent corruption, where data decrypts into the wrong final bytes, causing integrity failures, parsing errors, or application-level misbehaviour that may be hard to trace.

Failure mechanism: A library or integration layer mishandles the final two blocks, uses the wrong ciphertext-stealing variant, or truncates and reassembles bytes incorrectly, breaking reversibility even though the cipher and key are valid.

Impact: Systems may lose data integrity, fail interoperability tests, reject records, or process corrupted plaintext without an obvious encryption error, which can become a reliability or security problem if the data drives access, records, or transactions.

Practitioner Guidance

What to watch for: Treat ciphertext stealing as a mode that needs explicit compatibility testing, not as a drop-in padding substitute. If multiple libraries, platforms, or teams are involved, verify the exact variant and keep reference test vectors for the final-block cases.

Practitioner takeaway: The security of ciphertext stealing depends less on the idea itself than on whether every implementation handles the last block identically.

Related resources from NHI Mgmt Group

• How should security teams prevent a malicious npm package from stealing cloud credentials?
• What breaks when ransomware actors buy access instead of stealing it themselves?
• How can security teams reduce the impact of info-stealing malware?
• What do security teams get wrong about antivirus in credential-stealing campaigns?