# What is the difference between PKCS#5 padding and PKCS#7 padding

One runtime platform provides an API that supplies PKCS#5 padding for block cipher modes such as ECB and CBC. These modes have been defined for the triple DES, AES and Blowfish block ciphers. The other platform API only provides PKCS#7 padding.

Are PKCS#5 padding and PKCS#7 padding compatible?

-
Hopefully some people on Stackoverflow will find this Q/A, it gets asked a lot... –  owlstead Jul 4 '13 at 21:19

There is only one main difference between PKCS#5 and PKCS#7 padding is the block size. PKCS#5 padding is only defined for 8-byte block sizes. PKCS#7 padding would work for any block size from 2 to 255 bytes.

This is the definition of PKCS#5 padding (6.2):

The padding string PS shall consist of 8 - (||M|| mod 8) octets all having value 8 - (||M|| mod 8).

PKCS#7 is the same except that it allows block sizes up to 256 bytes in size (10.3 note 2):

For such algorithms, the method shall be to pad the input at the trailing end with k - (l mod k) octets all having value k - (l mod k), where l is the length of the input.

So fundamentally PKCS#5 padding is a subset of PKCS#7 padding for 8 byte block sizes. Hence, PKCS#5 padding can not be used for AES. PKCS#5 padding was only defined with (triple) DES operation in mind.

Most cryptographic libraries use either PKCS#5 or PKCS#7 to define the same padding mechanism. Officially PKCS#7 would of course be the only correct one if block sizes other than 8 are used within the calculation.

Note that both PKCS#5 and PKCS#7 are not standards for padding mechanisms. The padding part is only a small subset of the defined functionality (password based encryption or PBE, and the cryptograpic message syntax or CMS respectively).

-
any block size from 1: PKCS#7 does not appear to be very useful with block size of 1, and not all software can be trusted to support PKCS#7 with blocksize=1. Which one is correct up to 256 bytes or to 255 byte? To me it would appear $k < 256$, thus up to 255 bytes. –  user4982 Jan 5 at 21:32
@user4982: the definition of PKCS#7 padding for $k$-octet block cipher as "pad the input at the trailing end with $k-(l\bmod k)$ octets all having value $k-(l\bmod k)$, where $l$ is the length of the input" is not applicable to $k=256$ (notice that for $l$ multiple of $k$, it is prescribed octets with value $256$, which is wrong). A correct extension would be "pad the input at the trailing end with $k-(l\bmod k)$ octets all having value $(k-(l\bmod k))\bmod k$, where $l$ is the length of the input". –  fgrieu Jan 6 at 11:41
@user4982 blocksize=1 is not useful but possible. blocksize=1 only makes sense for stream ciphers, and stream ciphers do not need padding anyhow. I've explained that the 256 value is exclusive, but as current ciphers have normally a maximum of 256 bit (32 byte) blocks, the maximum is never reached anyway. For a more flexible (and IMHO better) padding mechanism, use bit padding (a single bit set to one, followed by all zero bits). –  owlstead Jan 6 at 18:28