Hello,
according to this stack exckange discussion you linked:
https://crypto.stackexchange.com/que...677d098ea2c5dd
ANSI X9.23 uses 0 as filler bytes instead of the padding length PKCS#7 uses.
If that is correct I wonder why your validity check method doesn't check for the #0
like the one for PKCS#7 checks for that specific padding byte.
I also wonder why you have a separate PKCS#5 implementation. As far as I understood so far (correct me if I'm wrong)
is PKCS#7 a superset of PKCS#5.
Well, to be honest i thought about this and here what logic echoed in my brain,
Lets look at the most accurate original definition of
ANSI X9.23,
from
https://www.ibm.com/docs/en/linux-on...block-chaining
Zitat:
The
ANSI X9.23 method always appends from 1 - 8 bytes to the plaintext before encipherment. The last appended byte is the count of the added bytes and is in the range of X'01' - X'08'. The standard defines that any other added bytes, or pad characters, be random.
also from
https://en.wikipedia.org/wiki/Padding_(cryptography)
Zitat:
In
ANSI X9.23, between 1 and 8 bytes are always added as padding. The block is padded with random bytes (although many implementations use 00) and the last byte of the block is set to the number of bytes added.[6]
PKCS#7 has concretely defined fill value unlike this one.
on other hand random fill can't be validated, also this padding schemes is old, very old and used many in many cases with both 0 fill and random, this exactly what rendered it unreliable to be used widely in securing traffic over wire, in fact it is not used and not recommended, these days as de facto is zero fill but yet not quit, as many php libraries (old and some are new) still use it as both zero fill and random fill, this what made me let remove the zero checking, and that is it just for legacy compatibility with older libraries from different platform,
Also as suggestion per best practice only 2 padding schemes are currently recommended, PKCS#7 and the unlimited length scheme "ISO/IEC 7816-4", both are validated and checked right.
As for PKCS#7 and PKCS#5 padding, you are right, and it is there for cosmetic, see PKCS#5 is old and was fixed at 8 bytes block size, so it even can't and shouldn't be used with AES !!, it designed for DES and 3DES...
i left it in case users of this library needed to be sure when they are in doubt and needed the name to be exist, again it is your call, also i relaxed the length checking as many libraries extended the length for it making it %100 copy of PKCS#7 padding without changing the name.