What is ANSI X.923 padding standard? 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?
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:


the padding X.923 does not exist, it is just X9.23 with the dot at the wrong location;
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.