Kleines Weihnachtsgeschenk von der DEC

[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.