Kleines Weihnachtsgeschenk von der DEC

[Kas Ob.]

Zitat von TurboMagic:

About the test data used in your sample run: do you have any URLs for the srouce
of those? I'm asking because I had already learned years ago that some of the
test data in DEC (a project which I inherited btw.) was not 100% correct and thus
masked 1 or 2 bugs in DEC. I tried to find the original/official test data for the
hash algorithms then at least and was only partially successfull. But I "implemented"
what I found as original test data.

Alas, there is no test vector for these simple padding !, i made the tests above to check data integrity for different case, and to use BlockSize and MinLength in useful way.

As for the implementation, it is in the scattered few links in the sources above, well.. along with this too
https://en.wikipedia.org/wiki/Padding_(cryptography)

ISO(s) standards are strictly to paid access, but the description for padding is easy enough to implement.

As for test vectors, i have similar when i implement Gimli cipher block https://gimli.cr.yp.to/spec.html
and ended up with 3 versions, one published by the author, and another submitted to NIST competition LightWeight Cryptography
https://csrc.nist.gov/Projects/Lightweight-Cryptography
but in second round there was different version of these vectors

Here an answer from one of the authors
https://crypto.stackexchange.com/que...for-gimli-hash

And the reason was the permutation is the same as it should not be changed, but the difference and the confliction in the last step after perform the rounds and on padding and bit locking, the original was locking different bit, while NIST prefer their own bit locking
and here how it look like

Delphi-Quellcode:

procedure Gimli_PadThenSqueeze(GimliContext: PlcGimliState; Last: Integer); //inline;
begin
  // enable one of these padding schemes
  // 1)  padding with xor'ing $1F at last byte and $80 at the end of block
  {GimliContext^.Bytes[Last] := GimliContext^.Bytes[Last] xor $1F;
  GimliContext^.Bytes[GIMLI_RATE - 1] := GimliContext^.Bytes[GIMLI_RATE - 1] xor $80;}
  //  2)  padding with xor'ing 1 at the last of text with 1 at the last byte of the state
  GimliContext^.Bytes[Last] := GimliContext^.Bytes[Last] xor $1;
  GimliContext^.Bytes[GIMLI_STATE_LAST_BYTE] := GimliContext^.Bytes[GIMLI_STATE_LAST_BYTE] xor $1;
  //  3) //// removed and should not be used

  GimliPermute(GimliContext^);
end;

So i think your problem is something similar to this bit locking, SHA1 and SHA256 doesn't have these and this is great weakness for them.

[Rollo62]

TL;DR;

What just jump into my eye is this, cant this be written more efficient?

Delphi-Quellcode:

class function TDECPaddingCommon.CalculatePaddingLength(DataLength, BlockSize, MinLength: Integer): Integer;
begin
  if (MinLength < 0) or (DataLength < 0) or (BlockSize < 0) or (MinLength or BlockSize = 0) then
  begin
  ...

like so

Delphi-Quellcode:

class function TDECPaddingCommon.CalculatePaddingLength(DataLength, BlockSize, MinLength: Integer): Integer;
begin
  if (MinLength <= 0) or (DataLength <= 0) or (BlockSize <= 0) then
  begin
  ...

Not sure is there is any hidden math trick behind that logic, have not thought too deep into it ...

[TurboMagic]

Hello,

thanks for all these contributions!

1. I'm currently changing the code a bit so it will have PKCS#7 and ANSI X9.23. As they are
quite similar I'll introduce another abstract class from which these two will inherit.

2. I already had some conversation with Christoph about the submission and he rates it as
high quality but will only have time to look at it somewhen next week. So don't be disappointed
when you don't hear much (except for my implementation I'll finish and push tonight) from us.
We value that! Oh and I'll add the necessary calls in TDECCipherFormats so somewhen tonight
we at least can choose between PKCS#7 and ANSI X9.23. The other one will follow as soon as we
find the time (unfortunately there are some other things in other projects to do as well...)

3. About the more efficient code: yep, we have to think this through and if there's no math catch
somewhere we'll implement it that way.

4. And later on I need to update the documentation once again.

[TurboMagic]

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.

[Kas Ob.]

Zitat von TurboMagic:

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.

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

[Kas Ob.]

Zitat von Rollo62:

TL;DR;

What just jump into my eye is this, cant this be written more efficient?

Delphi-Quellcode:

class function TDECPaddingCommon.CalculatePaddingLength(DataLength, BlockSize, MinLength: Integer): Integer;
begin
  if (MinLength < 0) or (DataLength < 0) or (BlockSize < 0) or (MinLength or BlockSize = 0) then
  begin
  ...

like so

Delphi-Quellcode:

class function TDECPaddingCommon.CalculatePaddingLength(DataLength, BlockSize, MinLength: Integer): Integer;
begin
  if (MinLength <= 0) or (DataLength <= 0) or (BlockSize <= 0) then
  begin
  ...

Not sure is there is any hidden math trick behind that logic, have not thought too deep into it ...

Simple, none of these can be negative but all can be zero, with only one condition that MinLength and BlockSize can't be zero at the same time.