Kleines Weihnachtsgeschenk von der DEC

[TurboMagic]

Hallo,

so, Weihnachten naht mit großen Schritten und ich hab's endlich mal wieder geschafft was an der DEC
(Delphi Encryption Compendium) zu machen, u.a. getrieben durch einen Beitrag unseres Schweizer MVP Kollegen Christoph.

Das "Geschenk" ist noch im Development Zweig hier:
https://github.com/MHumm/DelphiEncry...ee/development

Was ist es?

• Unterstützung des PKCS#7 Paddings bei den Verschlüsselungsalgorithmen (das schließt auch PKCS#5 ein)
• Erweiterte Cipher_FMX Demo
• Erweiterte VCL Progress Demo
• TFormat_UTF8 und TFormat_UTF16 (letzteres ist nur ein Alias für TFormat_BigEndian16)
• In anderen Pull Requests beigesteuerte Fehlerkorrekturen z. B. in TDECCipher.DecodeRawByteString

Die Doku wurde auch gleich erweitert.
Achtung: es ist bekannt, dass derzeit nicht alle Unit Tests fehlerfrei durchlaufen.
Das betrifft jedoch nur den GCM und den Keccak Algorithmus.Ursachen muss ich noch suchen. Beim Keccak
liegt es an irgendwelchen Stringverarbeitungen und der Fehler ist im Unit Test, sehr wahrscheinlich nicht im Algorithmus,
da andere Tests für diesen bestanden werden.

Was ich noch super fände wäre, wenn mal jemand der FPC installiert hat prüft, ob das
auch unter FPC noch alles compiliert.

So, jetzt aber frohe Weihnachten und einen guten Rutsch ins Jahr 2025!

[Kas Ob.]

Happy holidays to you too and too everyone !

Nice and thank you for work and contribution!

One very small thing i saw here
https://github.com/MHumm/DelphiEncry...as#L1451-L1453
This should be exception raised in consistent with the used style and coding, if the length is 0 this PKCS7 padding is absent and broken.


on side note: these exception in general, not only in PKCS7 or any specific unit
raise EDECCipherException.Create('xxxxxxxxxx'); Can affect performance due to code for string handling inserted by the compiler, although using TBytes itself does that too, so the following is not so important performance wise in this case per se, but..
replacing these calls with something centralized would be contain the usage of the strings and open the door for localization or at least just translating, it is cosmetic suggestion mostly.
example
as procedure DECExceptionRaise(DECEXCEPT_CIPHER_PADDING_PKCS7_INVALID;...); And this could be applied to other exception across the library to make it useful, see these
https://github.com/MHumm/DelphiEncry...Modes.pas#L483

Delphi-Quellcode:

resourcestring
  sInvalidMessageLength = 'Message length for mode %0:s must be a multiple of %1:d bytes';
  sInvalidBlockSize     = 'Block size must be %0:d bit for selected mode %1:s';
  sInvalidModeForMethod = 'Invalid mode for this method. Mode must be %0:s';

.....
procedure TDECCipherModes.SetDataToAuthenticate(const Value: TBytes);
begin
  if (FMode = cmGCM) then
    FGCM.DataToAuthenticate := Value
  else
    raise EDECCipherException.CreateResFmt(@sInvalidModeForMethod, ['cmGCM']);
end;

[Kas Ob.]

More thinking about this RemovePKCS7Padding i have a suggestion, and i am really sorry that i am doing this here not on GitHub

Refactor RemovePKCS7Padding where it could be split into a new public function HasValidPKCS7 return boolean and RemovePKCS7Padding can call it, this is more useful.

[Christoph Schneider]

I agree, in case of empty chiffre we should throw an exception.

To your second proposal. What is the workflow? Do you really have a chiffre where you dont know, if PKCS#7 padding was added or not?
The problem is from my point of view, if we would offer such check method, we run decrypt two times, one in this check and one after it for getting the result. Than an option for a facultative padding would be better but result in a more complex interface.

[Kas Ob.]

Zitat von Christoph Schneider:

To your second proposal. What is the workflow? Do you really have a chiffre where you dont know, if PKCS#7 padding was added or not?

No, i don't have specific logic where we are in doubt if there is a PKCS7 padding or not, this should not be the case.

Zitat von Christoph Schneider:

The problem is from my point of view, if we would offer such check method, we run decrypt two times, one in this check and one after it for getting the result. Than an option for a facultative padding would be better but result in a more complex interface.

My suggestion is small cosmetic, the refactor i suggested is based on the fact PKCS7 padding is used in few other places not just symmetric encryption or in PKCS7 CMS itself, this padding is the most used in asymmetric encryption and signing, also it is de facto the most used data padding scheme in general, so extracting the check for validity will be helpful, instead of repeating that loop, we can have a tidy small check for validity and correctness, .... well naming could be better like HasValidPKCS7Padding (i missed typed it as HasValidPKCS7).

[Kas Ob.]

One more thing i missed up there,
Signing and hashing in many case does need padding and in this case we don't need to extract, we need the correctness check only.
Have a look at this question and answers
https://crypto.stackexchange.com/que...y-need-padding

Fun stuff