3
$\begingroup$

Wikipedia defines ANSI X.923 padding as follows:

In ANSI X.923 bytes filled with zeros are padded and the last byte defines the padding boundaries or the number of padded bytes.

Example: In the following example the block size is 8 bytes, and padding is required for 4 bytes (in hexadecimal format)

... | DD DD DD DD DD DD DD DD | DD DD DD DD 00 00 00 04 |

So far so good.

Java Bouncycastle provider supports X932Padding, but it does it differently; instead of filling the unused bytes with zeros it fills them with random bytes.

I've got interested and started to search for ANSI X.923 official standard in internet and did not find it; instead I've found ANSI X9.23 description, and it says The standard defines that any other added bytes, or pad characters, be random.

So Bouncycastle implementation follows ANSI X9.23.

The question is : does the ANSI X.923 standard as it is defined in Wikipedia really exist?

Improve this question
$\endgroup$
  • $\begingroup$ Could you give me a link to a pdf file of ANSI X9.23 Standard? I need it, But I didn't find it on the internet. $\endgroup$ – Land Jul 14 '20 at 11:44
4
$\begingroup$

IBM described the exact padding with random bytes as in your message as ANSI X9.23.

ANSI X9.23 is a withdrawn standard called "X9.23-1988 (Financial Institution Encryption of Wholesale Financial Messages" from ASC X9 (Accredited Standards Committee X9) which is part of ANSI (American National Standards Institute).

It's very old, it may be that you could only order a paper version before it was withdrawn.

That means that:

  1. the padding X.923 does not exist, it is just X9.23 with the dot at the wrong location;
  2. the padding does exist and the Bouncy Castle padding generated during encryption is correct.

Bouncy Castle also allows you to not specify a random number generator in which case zero valued bytes are used instead. You can do this by not calling the init method, or by calling it with null instead of a SecureRandom instance. That's not an option that I see anywhere mentioned for this standard.

The X9.23 padding on Wikipedia is a relatively new addition by an author with just an IP address. My guess is that the author simply used the Bouncy Castle provider and specified "X923PADDING" which (incorrectly) doesn't call the init method and therefore generates zero bytes. And the name lacks the dot, of course.

Notes:

  • Obviously you should not use this padding for new protocols; in general you should try and avoid block cipher modes that require padding all together.
  • You should make sure that the padding byte has a value between 1 and the block size. Especially in languages with pointer arithmatic / unbounded arrays accepting values such as negative values for unpadding can be pretty dangerous.
  • Ciphertext should of course be authenticated before it is being deciphered and - where required - unpadded.
Improve this answer
$\endgroup$
  • 1
    $\begingroup$ IBM Knowledge Center defines ANSI X9.23 as padding with random bytes + count, see here or here. $\endgroup$ – kludg Aug 22 '18 at 19:36
  • $\begingroup$ OK, right. So there are two steps that need to be taken. 1. Wikipedia needs to be edited and 2. somebody should write to the dev list of Bouncy Castle and warn them that this padding is used incorrectly. If you want to do any of these let me know, I don't want to steal your thunder :) $\endgroup$ – Maarten Bodewes♦ Aug 22 '18 at 20:23
  • $\begingroup$ Adjusted answer, looked up Bouncy implementation. $\endgroup$ – Maarten Bodewes♦ Aug 22 '18 at 20:31
  • $\begingroup$ No, I'm not going to edit Wikipedia or write to Bouncycastle devs. I just found this X932 story weird; it looks like the original X9.32 defines indeterministic filling with random bytes, but somehow it became later deterministic filling with zero bytes, without any official document; and I've seen crypto libraries that require zero filling for decrypting X9.32 padding. Of course it is all legacy staff but it is strange. $\endgroup$ – kludg Aug 22 '18 at 20:51
  • $\begingroup$ @kludg There is a lot of copy pasting going on between crypto libraries. This is especially true when the standard documents cannot be easily retrieved, such as in (old) ANSI standards or ISO/IEC standards. I'm very much against these kind of payed standards anyway. Being in a standardization committee should bring enough benefit by itself; they should be sponsored commercially. $\endgroup$ – Maarten Bodewes♦ Aug 22 '18 at 20:56

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.