Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 46 down vote accepted

The difference between the PKCS#5 and PKCS#7 padding mechanisms is the block size; PKCS#5 padding is defined for 8-byte block sizes, PKCS#7 padding would work for any block size from 1 to 255 bytes.

This is the definition of PKCS#5 padding (6.2) as defined in the RFC:

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

The RFC that contains the PKCS#7 standard is the same except that it allows block sizes up to 255 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.

Many cryptographic libraries use an identifier indicating PKCS#5 or PKCS#7 to define the same padding mechanism. The identifier should indicate PKCS#7 if block sizes other than 8 are used within the calculation. Some cryptographic libraries such as the SUN provider in Java indicate PKCS#5 where PKCS#7 should be used - "PKCS5Padding" should have been "PKCS7Padding". This is a legacy from the time that only 8 byte block ciphers such as (triple) DES symmetric cipher were available.

Note that neither PKCS#5 nor PKCS#7 is a standard created to describe a padding mechanism. The padding part is only a small subset of the defined functionality. PKCS#5 is a standard for Password Based Encryption or PBE, and PKCS#7 defines the Cryptographic Message Syntax or CMS.

share|improve this answer
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 '14 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 '14 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). – Maarten Bodewes Jan 6 '14 at 18:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.