1
$\begingroup$

I just designed my own padding function and came up with a potential problem that could harm the security of encryption. After I fixed that flaw, I found out that the PKCS7 standard padding should be also vulnerable to a known-plaintext attack. Please correct me if I am wrong at any point.

PKCS7 is filling each padded byte with the number of total bytes padded. Every time, at least one byte of padding is appended, in the worst case an entire block. When I am operating a cipher in the electronic code book mode, the last block could be easily guessed for a known-plaintext attack. (In 1 out of 16 [block size] cases, instantly) Example padding is shown below.

53 65 63 72 65 74 20 74 65 78 74 2e --> 53 65 63 72 65 74 20 74 65 78 74 2e 04 04 04 04

I figure that filling up all the padded bytes with random nonsense and the last byte with the number of padded bytes would be far more secure. Why isn't that the case in such a widely distributed padding standard? Isn't the example below more secure?

53 65 63 72 65 74 20 74 65 78 74 2e --> 53 65 63 72 65 74 20 74 65 78 74 2e 5a 2c 12 04

Thanks in advance.

$\endgroup$
6
  • 1
    $\begingroup$ Forger padding, use PRF-based modes like CTR, and never forget that CBC is IND-CPA secure like CTR mode. So no attack is feasible. CPA = Chosen Plaintext Attack $\endgroup$
    – kelalaka
    Commented Feb 2, 2022 at 22:57
  • 1
    $\begingroup$ Thanks for the reply, but if I specifically used ECB then there should be a security risk or not? For example, in standard implementations in Java for ECB with AES you can only select PKCS5 as padding algorithm which has the same weakness. I wonder why this is implemented by default, even though it introduces a security risk (independent of ECB itself). $\endgroup$
    – Luqus
    Commented Feb 3, 2022 at 12:25
  • $\begingroup$ Have you considered adding some form of MAC/HMAC? That helps with padding security. $\endgroup$
    – Paul Uszak
    Commented Feb 3, 2022 at 13:35
  • 1
    $\begingroup$ If you are using ECB, you are already on the wrong path. ECB there exists for backward compatibility and for those who know what they are doing. YOu can use ECB/nopadding and apply your padding. Your padding only helps you if you have only one block that can eliminate equality, if you have more than 1 blocks, that doesn't help at all. $\endgroup$
    – kelalaka
    Commented Feb 3, 2022 at 18:37
  • $\begingroup$ I am clear about the many downsides of ECB, don't worry. But imagine a situation in that you would be forced to use ECB for whatever reason. Also, I know about the NoPadding in Java, but you don't have to implement Padding yourself when using the only implemented padding PKCS5. Why isn't there another standard implementation? $\endgroup$
    – Luqus
    Commented Feb 3, 2022 at 21:02

1 Answer 1

2
$\begingroup$

I figure that filling up all the padded bytes with random nonsense and the last byte with the number of padded bytes would be far more secure. Why isn't that the case in such a widely distributed padding standard? Isn't the example below more secure?

53 65 63 72 65 74 20 74 65 78 74 2e --> 53 65 63 72 65 74 20 74 65 78 74 2e 5a 2c 12 04

This is basically known as ISO 10126 padding, compatible with ANSI X9.23 padding.

First of all, it should be noted that padding oracle attacks are only part of a wider set of plaintext oracle attacks. So if the decrypted plaintext can generate any error, the same issues can be present when the system is trying to apply the plaintext. For instance, it's very easy to create a plaintext oracle attack using errors of an XML decoder. Even easier: if the plaintext blocks consists of padding from the left hand side, then obviously it would also fail to a padding oracle attack.

Secondly a ciphertext will now be accepted (i.e. not generate a padding error) 1 time out of 256 / 8 = 32 times (final byte is valued 01 to 08) instead of about once in 256 times (final byte is valued 01 or the final bytes are valued 02 02 etc.). This precludes using the padding for message integrity / authenticity.

Thirdly you've mitigated the padding oracle attack, but you haven't entirely eliminated it. The final byte will still needs to be evaluated after all. We consider a cipher broken if anything can be learned from the original plaintext.

Finally you haven't eliminated the padding overhead.


If you assume overhead anyway then you might as well add an authentication tag, created by using a MAC or authenticated cipher. This is the reason why we're not very interested in the padding properties. We can use a mode that doesn't require padding, add the authentication tag and have a cipher mode with better security properties, while keeping message expansion limited.

$\endgroup$
1
  • 1
    $\begingroup$ Fun fact, I found that paper while I was showing that XML encryption without XML signature generation is not a good idea. And even if you use XML sig you have to pay very careful attention. $\endgroup$
    – Maarten Bodewes
    Commented Feb 4, 2022 at 19:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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