Kleines Weihnachtsgeschenk von der DEC

[TurboMagic]

Zitat von Kas Ob.:

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.

Ok, I can fully understand this. People not properly implementing a standard are a nuisance
What about having two classes for this: one with random fill and one with zero fill for best compatibility?
Or would one variant (the one with random fill) be sufficient?

Zitat von Kas Ob.:

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.

Understood. I created a PKCS#5 class now wich is a 1:1 alias of the PCKS#7 class. Just a type definition.
Is that ok? I'll add this to the enumeration and treat it like PKCS#7.

[Kas Ob.]

Zitat von TurboMagic:

What about having two classes for this: one with random fill and one with zero fill for best compatibility?
Or would one variant (the one with random fill) be sufficient?

I prefer to either
1) leave with 0 fill, but without strict validation (checking against 0), as i mentioned it should not be used in real data trafficking or storing, so the danger of not checking its fill correctness make sense .. or
2) have two classes as you suggested, and i suggest to make sure to name the one with random as old or legacy, as it is really very rare to be using random fill in other libraries, and in contrary to its own original specification, which the cause of this mess.

Zitat von TurboMagic:

Understood. I created a PKCS#5 class now wich is a 1:1 alias of the PCKS#7 class. Just a type definition.
Is that ok? I'll add this to the enumeration and treat it like PKCS#7.

Absolutely OK, PKCS#5 padding should have been killed and never used since the dawn of computer cryptography.
I think it is, yes, unifying their implementation makes sense, the problem with PKCS#5 padding is the wrong implementation and naming in many libraries, they do use PKCS#7 padding under the name of PKCS#5.


And thank you and Christoph for your effort, work and contribution.

[TurboMagic]

We did some more work on this. Bear in mind that this is, while pushed to development branch, is not finished completely yet.
We still need to think about some of your stuff and unit tests need to be worked at as well, basing them most likely on your
data from this post.

=> stay tuned but don't hold your breath