6
$\begingroup$

I am assuming none of these padding algorithms are "the best"... But what are the advantages and disadvantages of using them? PKCS7 is certainly the most commonly used one, but I am interested in seeing what the others offer.

$\endgroup$
  • 1
    $\begingroup$ I made my own since none of them worked well for ciphers with larger block sizes, like Threefish. groups.google.com/forum/#!topic/sci.crypt/oXhg6hvWdcs $\endgroup$ – Richie Frame Dec 18 '15 at 1:30
  • $\begingroup$ Hm. This looks good. The current system I am using padding for isn't actually a larger block size... But I may well work with a larger block size in the future, so thanks. $\endgroup$ – trevorKirkby Dec 19 '15 at 16:26
7
$\begingroup$

ANSI x.923 padding and the padding used within PKCS#7 are functionally equivalent. The last byte of the padding stream is the length of the padding stream. The difference is the value of the other bytes, which are all 0x00 in ANSI, and all the identical to the last byte in PKCS#7.

f4 93 d6.00 00 00 00 00 00 00 00 00 00 00 00 0d    ANSI X.923
f4 93 d6.0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d    RSA PKCS#7

Neither has a large advantage over the other, except that a zero padded message can be "fixed" to ANSI padding by simply changing the last byte in many cases.

I do not believe that either one requires official verification of the padding bytes preceding the last byte to verify that they are correct per the standard, meaning the same algorithm can decode either scheme by simply looking at the last byte. The same algorithm will also decode ISO 10126 padding.
If used in an unauthenticated scheme, the bytes should be checked for correctness, since some attacker advantage could be achieved through their manipulation. Verification is done with bitwise OR against those bytes, which then must either equal 0x00 for ANSI or the length byte for PKCS#7 padding.
Both only support up to 255 bytes of padding.
PKCS is by RSA for RSA products and algorithms, and ANSI is a generic common standard by committee with the goal of interoperability.

ISO/IEC 7816-4 is a different story. It is more flexible and can technically support an unlimited length of padding bytes, however removal of the padding can be more computationally intensive. ISO/IEC 7816-4 padding places a single 0x80 byte after the message, then pads the rest with 0x00.
The padding scheme is also known as bit padding, as it simply places a single 1 bit after the plaintext, followed by 0 valued bits up to the block size; it therefore works for bit oriented protocols as well.

f4 93 d6.80 00 00 00 00 00 00 00 00 00 00 00 00    ISO/IEC 7816-4

By specification you must start at the end and work backwards, checking every byte until you hit 0x80. If you hit something other than 0x80 or 0x00 the message is assumed to be incorrectly decoded. With a small block size this is quite fast.
ISO/IEC 7816 contain the ISO/IEC standards for electronic ID cards like smart cards. Systems that use the standard have mandatory padding for encrypted data.

I have also seen what I called "rainbow" padding, which looked to be a hybrid of ANSI and PKCS7. The last byte was the amount of padding bytes, and the preceding bytes were that value decrementing until the message boundary:

f4 93 d6.01 02 03 04 05 06 07 08 09 0a 0b 0c 0d    ???

I have never seen it described by a specific name, but it may be removable by an ANSI/PKCS remover if the remover only takes the last byte into account.

As you mentioned, none of these padding schemes are perfect. Only IEC 7816 can support block sizes of 256-bits and larger, and ANSI and PKCS7 can be unpadded by a common algorithm.

$\endgroup$
  • 1
    $\begingroup$ I know what is described here as ISO/IEC 7816(-4) padding under the name ISO/IEC 9797-1 padding method 3. It is in the 1999 (first published) edition of ISO/IEC 9797-1, and is more general as it is defined for bitstrings (with bytestrings giving what's described here); when it started to appear in ISO/IEC 7816-4 starting with the draft of the second edition, in 2000. Not coincidentally, ISO/IEC 7816-4 (2nd and 3rd edition) make reference to ISO/IEC 9797-1 for MACs, which is where it uses padding. $\endgroup$ – fgrieu Dec 18 '15 at 8:16
  • $\begingroup$ The 0x80 padding is a special case of bit padding. The obvious extension allows messages with any bit lengths. What's wrong with it when block size is large (your comment on the question)? $\endgroup$ – otus Dec 18 '15 at 10:52
  • $\begingroup$ @otus I do not like the procedure of either working backwards from the end to find a single bit or working from the start and making note of the last bit, when I can look at the very end and be told precisely where to go. $\endgroup$ – Richie Frame Dec 18 '15 at 19:09
  • $\begingroup$ My main peeve is "If used in an unauthenticated scheme, the bytes should be checked for correctness". Everybody here knows that verifying the padding in unauthenticated schemes opens up the cipher mode for padding oracle attacks. You either do not require authentication or you don't; if you require authentication, then you do not acquire it by verification of padding. $\endgroup$ – Maarten Bodewes Dec 19 '15 at 12:12
  • 1
    $\begingroup$ @someone-or-other see ISO 10126 padding, which is no longer recommended. It can give a substantial attacker advantage because they can change the random bytes to whatever they want, and the padding will still be correct. $\endgroup$ – Richie Frame Dec 20 '15 at 4:10

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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