Padding (cryptography)

Why padding is used

There are two main reasons for padding. First, many block ciphers operate on fixed-size blocks (for example, 128 bits). If the message length is not a multiple of the block size, the last block must be filled. Second, messages often contain predictable headers, footers, or formats (e.g., greetings, file headers). Padding can add entropy that makes known-plaintext patterns less useful to an attacker and can obscure exact message lengths.

Common padding schemes

• PKCS#7 / PKCS#5: pads with N bytes each equal to the value N, so the receiver can remove N bytes unambiguously.
• Zero padding: fill with zero bytes; simple but ambiguous if the original data can legitimately end with zeros.
• ANSI X.923: zeros followed by a final byte containing the length of padding.
• ISO/IEC 7816‑4: a 0x80 byte then zeros to the block boundary.
• OAEP and PKCS#1: randomized padding for public‑key encryption (RSA) that provides semantic security and resists direct decryption without the private key.

Risks and notable attacks

Incorrect handling of padding can create severe vulnerabilities. Padding oracle attacks exploit differences in error responses (or timing) when systems validate padding before decrypting or authenticating a message. Such flaws can let an attacker decrypt ciphertexts or forge messages without knowing the key. Likewise, flaws in public‑key padding schemes have led to adaptive attacks unless randomized padding (e.g., OAEP) is used.

Best practices

To avoid padding-related weaknesses, modern systems prefer authenticated encryption modes (AEAD) that combine encryption and integrity so padding is validated only after authenticity checks succeed. Implementations should perform padding checks in constant time and avoid exposing different error messages. Where possible, use well-specified, widely reviewed padding algorithms and libraries rather than rolling custom schemes.

For an introduction and further technical references, see cryptography reference.