Ciphertext stealing is a block cipher mode technique that lets encryption handle plaintext lengths that are not exact multiples of the block size without adding padding bytes. It rearranges the final blocks so the ciphertext stays the same length as the plaintext, which matters when padding behaviour must not leak metadata.
How ciphertext stealing preserves exact message length
ciphertext stealing is used with block ciphers when the final plaintext chunk is shorter than a full block. Instead of adding padding, the mode borrows bytes from the previous ciphertext block so the output length still matches the input length exactly. The important idea is not a new cipher, but a specific way of handling the last two blocks.
The mechanism only matters at the tail end of an encryption run. Earlier blocks are processed normally, then the final full block and the short remainder are rearranged so the short block can be represented without padding bytes. That is why ciphertext stealing is often discussed alongside block cipher modes, block alignment, and padding-sensitive protocols.
For practitioners, the main benefit is that it avoids padding metadata and the operational complexity that comes with it. In environments where ciphertext length should not reveal whether padding was added, or where a consumer expects a length-preserving encrypted record, ciphertext stealing can be a practical alternative to padding-based modes.
What changes in the last two blocks
The final two blocks are the entire trick. The penultimate ciphertext block is partially “stolen” to make room for the last partial plaintext block, and the resulting ciphertext is emitted in a swapped or rearranged form that still decrypts correctly. The details vary by mode family, but the goal is always the same: preserve plaintext length while keeping block-cipher structure intact.
This means ciphertext stealing is not a generic property of all block ciphers. It is an implementation technique layered on top of a block cipher mode, and the exact byte movements matter. If you are implementing or reviewing it, the question is whether the mode’s final-block handling is specified precisely and consistently on both encryption and decryption sides.
That precision is why cryptography references matter here. A general overview of block cipher modes and padding behaviour is easier to understand when paired with a broader cryptography reference such as Cryptography Basics Guide. It helps place ciphertext stealing in the larger set of choices around block ciphers, AEAD, padding, and length handling.
Where ciphertext stealing helps, and where it can mislead
Ciphertext stealing is useful when exact-length output is operationally desirable, but it does not magically add integrity or authentication. It solves a formatting problem, not a trust problem. If the surrounding design needs tamper detection, replay resistance, or authenticated encryption, ciphertext stealing alone does not supply those properties.
It also introduces implementation sensitivity. A mismatch in how the final blocks are arranged can break interoperability or cause decryption errors that only appear on non-aligned messages. The logic is easy to get wrong in custom code, especially if one side assumes padding and the other assumes ciphertext stealing.
For a broader control perspective, use established cryptographic guidance rather than ad hoc implementation. The NIST guidance on key and cipher handling, together with the NIST cryptography reference material, gives teams a safer baseline for deciding when to use a padding-free mode and how to verify that the implementation matches the intended specification.
Risk and Threat Considerations
Ciphertext stealing reduces one kind of leakage by avoiding padding, but it can still create risk if teams assume it provides security properties it does not. The biggest operational failure is confusing length-preserving encryption with authenticated encryption, then exposing systems to silent tampering or brittle interop bugs.
Failure mechanism: Implementations mis-handle the swapped final blocks, or teams deploy ciphertext stealing where the system actually needs integrity protection, replay resistance, or strict protocol interoperability.
Impact: Decryption failures, inconsistent behavior across systems, and a false sense of protection can follow. In the worst case, attackers can still manipulate ciphertext unless a separate integrity mechanism is present.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Ciphertext stealing is a cryptographic mode detail that belongs in key and cipher handling decisions. |
| Recommendation — Apply key-lifecycle guidance when selecting and verifying the cipher mode used for length-preserving encryption. | ||
| NIST SP 800-53 Rev 5 | SC-13 — Cryptographic Protection | Ciphertext stealing is a cryptographic protection mechanism used to preserve confidentiality without padding. |
| Recommendation — Use cryptographic protection controls to specify and validate the exact mode and its final-block behavior. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of Cryptography | The topic concerns choosing and implementing a cryptographic method correctly and consistently. |
| Recommendation — Define approved cryptographic methods and verify implementations match the intended mode specification. | ||
Practitioner Guidance
What to verify: Confirm that both encryption and decryption implementations use the same ciphertext stealing variant and agree on final-block handling. This is especially important when one component is a library or appliance and another is custom code.
Decision rule: If you need confidentiality only and length preservation matters, ciphertext stealing may fit. If you need authenticity as well, treat ciphertext stealing as incomplete on its own and pair it with an integrity-protecting design rather than assuming the mode covers that gap.
What practitioners underestimate: The hard part is usually not the math, but the integration boundary. Final-block edge cases, protocol expectations, and interoperability tests are where ciphertext stealing most often fails in practice.
Practitioner takeaway: Use ciphertext stealing as a length-handling technique, not as a security shortcut, and validate the final-block behavior with the same care you would apply to any cryptographic boundary.