1
$\begingroup$

I am a bit new to java crypto, lately, I was going through some articles regarding the use of AES/CTR/PKCS5Padding for encryption. I read that

The block size is a property of the used cipher algorithm. For AES it is always 16 bytes. So strictly speaking, PKCS5Padding cannot be used with AES since it is defined only for a block size of 8 bytes. I assume, AES/CBC/PKCS5Padding is interpreted as AES/CBC/PKCS7Padding internally.

So, Even if the data is more than 8 bytes (say 10 bytes), will this be padded upto the next block size of 32 bytes (AES Block size) or 16 bytes (PKCS5 block size) or will this not be padded at all?

Improve this question
$\endgroup$
1
  • 1
    $\begingroup$ The question has serious issues. "32 bytes (AES Block size)" should be "16 bytes (AES block size)"; "16 bytes (PKCS5 block size)" should be "8 bytes (PKCS#5 block size)"; and the example "10 bytes" is such that the two padding methods yield the same result, thus should be changed to something where the methods are not equivalent, like "2 bytes" or "18 bytes". Also, neither "more than 8 bits" nor "more than 8 bytes" accurately characterize when there is ambiguity. Perhaps, the question's title would best be: what padding is used in AES/CTR/PKCS5Padding? $\endgroup$
    – fgrieu ♦
    Feb 2 '17 at 8:13
6
$\begingroup$

PKCS#5 was initially written for block ciphers using 64-bit blocks, and up to and including PKCS#5v2.0 had no provision for larger ones. PKCS#5v2.1 remains littered with references to eight octets, including in padding.

The principle that PKCS#5 uses for 64-bit blocks padding is easily generalized to block ciphers with larger blocks (up to 255 octets per block), and that's what PKCS#7 padding is: for a message of $m$ octets ($8m$ bits) and a block cipher of $k$ octets ($8k$ bits), pad the message with $p=k-(m\bmod k)$ octets with value $p$. When $k=8$, that's precisely PKCS#5 padding.

AES is a 128-bit (16 octets) block cipher, thus (at least in CBC mode) is not amenable to PKCS#5 padding with 64-bit blocks. For this reason, PKCS#5 was revised and for AES-CBC-Pad PKCS#5v2.1 footnote 2 of section B.2.5 prescribes 128-bit padding, effectively that of PKCS#7.

The question's quote sticks to the 64-bit definition of padding of PKCS#5 before revision 2.1, and makes the simplest possible conjecture when it assumes that AES/CBC/PKCS5Padding really is internally AES/CBC/PKCS7Padding. Otherwise, it would be impossible to process some messages. For example, with 64-bit padding, the 2-octet message 0x41 0x42 would be padded to 8 octets as 0x41 0x42 0x06 0x06 0x06 0x06 0x06 0x06, and that can't be CBC-enciphered with a 16-octet block cipher; the padding used by AES/CBC/PKCS5Padding thus is 0x41 0x42 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E. And that's what PKCS#5v2.1 prescribes.

Another plausible conjecture is that AES/CTR/PKCS5Padding uses the same padding as AES/CBC/PKCS5Padding, and is internally AES/CTR/PKCS7Padding; but to be sure, we would need to look at the code or some test data, because CTR mode (contrary to CBC mode) does not require padding to block boundaries, and AES-CTR would also be compatible with no padding at all, or with strict PKCS#5 padding. According to this source, this varies across implementations, and it looks like the Sun Oracle Java official stance is that AES/CTR/PKCS5Padding is not supported, should raise an exception if used, and does so with few exceptions that are designated as bugs. Such important boring details are arguably off-topic.

Important note: the only good reason to use AES/CTR/PKCS5Padding is for interoperability with something that does. There is no need for padding in CTR mode, thus given the choice we should use AES/CTR/NoPadding (or perhaps AES/CBC/PKCS5Padding if we need that the ciphertext size in bytes is a multiple of 16, for some reason).

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ PKCS5 v1 was, and PBES1 on v2.1 p11 remains, limited to 64-bit, but in v2.1 PBES2 is extended to use AES (B.2.5 on p25) with CBC and the padding from RFC 5652, which is the current version of PKCS7. $\endgroup$
    – dave_thompson_085
    Apr 28 '20 at 3:01
  • 1
    $\begingroup$ Had an annoying java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding after testing my application on Linux. Everything worked just fine on Windows. Changed to AES/CTR/NoPadding and all was good. $\endgroup$
    – Avec
    Oct 14 at 12:07
  • 1
    $\begingroup$ @Avec: sure it fixes the error, but you loose interoperability with something that uses AES/CTR/PKCS5Padding. I added a final note. $\endgroup$
    – fgrieu ♦
    Oct 14 at 12:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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