Kleines Weihnachtsgeschenk: DEC V6.00 verfügbar

[TurboMagic]

Hallo,

sozusagen als kleines Weihnachtsgeschenk gibt's ein neues Release V6.0 der DEC.
Somit gibt's nach 5 Jahren endlich wieder ein Release!
Zu finden ist es hier:

https://github.com/MHumm/DelphiEncry...eases/tag/V6.0

Was ist DEC?
DEC steht für Delphi Encryption Compendium,
eine Open Source Bibliothek mit diversen Kryptographie Algorithmen aus diesen Bereichen:

• Hash Funktionen
• Verschlüsselungsfunktionen
• Schlüsselableitungsfunktionen
• CRC
• Kryptographischer Pseudozufallszahlengenerator
• Formatkonvertierungsklassen

Was ist neu in V6.0 gegenüber der letzten veröffentlichten Version 5.2?
Eine Liste aller Neuigkeiten bietet das letzte Kapitel der im Projekt befindlichen
Dokumentation, daher hier nur das wichtigste:

• Unterstützung der neuesten Delphi Versionen ab D2009
• Cross Plattform fähig, wenn Verwendung von ASM abgeschaltet
  (siehe Conditional Defines in DECOptions.inc)
• Bisheriges schwer verständliches Testprogramm in Unit Tests umgewandelt
• Erhöhung des Testabdeckungsgrades
• Fehlerkorrekturen, z.B. beim XTEA Verschlüsselungsalgorithmus
• Umsetzung der neuesten Version des Whirlpool Hashes
• Korrektur des falsch benannten KDF2 Schlüsselableitungsalgorithmus.
  Eigentlich was der KDF1
• Umsetzung der KDF2 und KDF3 Algorithmen
• Änderung der Unit Struktur um modularer zu werden
• Demo Programme hinzugefügt, inkl. 2 FMX basierte Demos die auch
  in Google Play sind
• Hinzufügen einer > 40 seitigen englisch sprachigen Dokumentation
• Die meisten Methoden usw. haben jetzt auch XMLDOC Kommentare

War's das dann, oder gibt's Pläne für weitere Versionen?

Soweit es meine Zeit erlaubt (Mitstreiter gerne willkommen!) gibt's durchaus
Pläne für V6.1. Hier mal ein paar Ideen:

• Hinzufügen von SHA224, der fehlt nämlich noch
• Hinzufügen von SHA3
• Hinzufügen des GCM Blockverkettungsmodus
• Hinzufügen eines ersten Passwort Hashalgorithmus. Vermutlich BCrypt

So viel mal für heute

Grüße
TurboMagic

[jziersch]

Vielen Dank für eine derart leistungsfähige und dennoch übersichtliche Bibliothek.

Schöne Weihnachtstage,
Julian

[EdAdvokat]

Cipher_FMX wirft Exception und kann nicht erstellt werden.
Ich habe Dein Weihnachtsgeschenk mal ausprobiert und bin beim Programm Demos\Cipher_FMX als Win32-Application
auf einen Fehler gestoßen, den ich nach Vergleich mit der Vorversion, Stand 12.01.2020 (dabei insbesondere die Dateien DECCipher.pas
und MainForm) wie folgt in MainForm (Zeile 271-272) verändert habe:

Delphi-Quellcode:

procedure TMainForm.ComboBoxCipherAlgorithmChange(Sender: TObject);
var
  Context : TCipherContext;
begin
  Context := TDECCipher.ClassByName(
    ComboBoxCipherAlgorithm.Items[ComboBoxCipherAlgorithm.ItemIndex]).Context;

  StringGridContext.RowCount := 7;
  StringGridContext.Cells[0, 0] := 'Key size (bit)';
  StringGridContext.Cells[0, 1] := 'Block size (bit)';
  StringGridContext.Cells[0, 2] := 'Buffer size (bit)';
  StringGridContext.Cells[0, 3] := 'User size (bit)';
  StringGridContext.Cells[0, 4] := 'User save';
  StringGridContext.Cells[0, 5] := 'Cipher mode';
  StringGridContext.Cells[0, 6] := 'Cipher key';

  StringGridContext.Cells[1, 0] :=  (Context.KeySize*8).ToString;
  StringGridContext.Cells[1, 1] :=  (Context.BlockSize*8).ToString;
  StringGridContext.Cells[1, 2] :=  (Context.BufferSize*8).ToString;
  StringGridContext.Cells[1, 3] :=  (Context.AdditionalBufferSize*8).ToString; //  UserSize*8).ToString;
  StringGridContext.Cells[1, 4] :=  BoolToStr(Context.NeedsAdditionalBufferBackup, true);  //UserSave, true);

Das Programm konnte so kompiliert werden, jedoch überblicke ich nicht ob diese Veränderungen meinerseits so exakt sind.
Ich wollte lediglich darauf hinweisen, dass in der vorliegenden Form das Programm Cipher_FMX bei mir nicht kompiliert werden
konnte, da die Exception - userSize... und userSave nicht gefunden geworfen wurde.
Nachdem ich beim Vergleich von DECCipher.pas (alt und neu) festgestellt habe, dass aus userSize AdditionalBufferSize und aus
userSave NeedsAdditionalBufferBackup wurde, war ich mal so kühn und habe die o.g. Veränderung vorgenommen.
Schau doch mal ob da wirklich ein Fehler vorliegt, oder ob bei mir eine Irrung vorliegt.
(Delphi 10.2 prof)

[Alter Mann]

Hallo,

ich bekomme schon beim 'normalen' compilieren der DECChiper.pas Fehlermeldungen:
[DCC Fehler] DECCiphers.pas(977): E2003 Undeklarierter Bezeichner: 'FUser' .
Das wiederholt sich in den Zeilen : 1051, 2427, 2510, 4726 und 4805.

[TurboMagic]

Oha!
Da hab' ich wohl bei der Umbenennung zweier Felder neulich einen kleinen Bock geschossen und nicht
sauber alle Projekte angepasst. Sorry!

Ich versuche mal nacher die Zeit zu finden, das zu korrigieren.

Grüße
TurboMagic

[TurboMagic]

Ok, Feuer erneut frei!
Ich hoffe es passt jetzt so!

[DieDolly]

Hat DEC bei AES Decode und Encode keine EINFACHE Möglichkeit einen Progress-Callback einzubauen?
Anlass zu der Frage ist dieses Thema https://www.delphipraxis.net/206384-...ml#post1479406

Es ist meiner Meinung nach für nicht-programmierer viel zu kompliziert gemacht!
Ich bitte in 6.1 darum, dass man ganz normale CallBacks über eine Prozedur verwenden kann.

Ich habe DEC jahrelang gemieden, weil es viel zu kompliziert war. Aber 6.0 ist noch immer viel zu kompliziert, wenn man nicht mal "eben so" sowas simples wie einen CallBack einbauen kann.

Ich rechne fest damit, dass ich jetzt von echten Programmierern zusammengemault werde.

Wie ich mir einen CallBack vorstelle

Delphi-Quellcode:

// Eine Extra-Unit, ohne Form u.a. mit (beispielhaft)
function AESFileEncrypt(const FileName, Password: string): string;
var
 Cipher: TCipher_AES;
begin
 Cipher := TCipher_AES.Create;
 try
  Cipher.Init(Password, #1#2#3#4#5#6#7#64, 0);
  Cipher.Mode := cmCBCx;
  Cipher.EncodeFile(DateiIn, DateiOut, ProgressCallBack);
 finally
  Cipher.Free;
 end;
end;

procedure ProgressCallBack(parameter);
begin
 // tue etwas mit den Parametern)
end;

[himitsu]

Die 130 Zeilen der Copy von Code aus der System.pas kann man "etwas" Kürzen und durch Code ersetzen,
der immer "sicher" funktionieren wird, selbst wenn Embarcadero mal wieder das Interne der LongString-Typen ändern sollte.
(OK, ist selten passiert und die letzten 2 Mal waren um 2009/2010)

Delphi-Quellcode:

// DECUtilRawByteStringHelper.pas

procedure UniqueString(var Str: RawByteString); overload;
begin
  if StringRefCount(Str) <> 1 then
    SetLength(Str, Length(Str));
end;

Da diese Funktion nur einmal verwendet wird und der Code nun nur noch ein Zweizeiler ist, könnte man eigentlich auch gleich die ganze Unit loswerden und den Code direkt einsetzen.

Delphi-Quellcode:

// DECUtil.pas

procedure ProtectString(var Source: RawByteString);
begin
  if Length(Source) > 0 then
  begin
    // UniqueString(Source); cannot be called with a RawByteString as there is
    // no overload for it, so we need to call our own one.
    //DECUtilRawByteStringHelper.UniqueString(Source);
    if StringRefCount(Source) <> 1 then
      SetLength(Source, Length(Source));

    ProtectBuffer(Pointer(Source)^, Length(Source) * SizeOf(Source[Low(Source)]));
    Source := '';
  end;
end;

Was mich nach reichlicher Überlegung aber überrascht hat, ist der Denkfehler von Hagen,
denn das UniqueString ist hier absolut sinnlos, in den ProtectString-Funktionen.

Denn diese Funktion arbeitet nur bei RefCount = 1 korrekt, bzw. sie hat ausschließlich dort die geplante Wirkung.
Und die "geplante" Funktion ist das "sichere Löschen" des Speichers. (überschreiben mit einem Muster)

• mit RefCount kleiner 0 (genauer -1) ist es eine String-Konstante in schreibgeschütztem Speicher und die lässt sich sowieso nicht löschen
  • weiter siehe "RefCount ungleich größer 1"
• bei RefCount gleich 1 passt alles
  • es wird nicht kopiert, also der "richtige" Speicher wird überschrieben und anschließend freigegeben
• bei RefCount größer 1 gibt es mehrere Zeiger auf diesen String
  • da großer/ungleich 1, wird erstmal der ganze String kopiert (Unique in einen neuen Speicher, mit RefCount = 1)
  • dann wird "nur" der neue Speicher gelöscht/überschrieben, den es aber ohne das Kopieren sowieso nicht gegeben hätte
  • am Ende wird die neue Referenz+Speicher freigegeben
  • ABER zurück bleibt der originale String (mit/für die restlichen Referenzen), womit sich rein garnichts änderte und "effektiv" auch nicht gelöscht wurde

Delphi-Quellcode:

procedure ProtectString(var Source: RawByteString);  // auch bei String/UnicodeString, AnsiString und WideString
begin
  if (Source <> '') and (StringRefCount(Source) = 1) then
    ProtectBuffer(Pointer(Source)^, Length(Source) * SizeOf(Source[Low(Source)]));
  Source := '';
end;

Und statt Length(Source) * SizeOf(Source[Low(Source)]) könnte man auch Length(Source) * StringElementSize(Source) verwenden,
allerdings weiß ich nicht, wie es im FPC mit StringElementSize und StringRefCount aussieht.

Bzw. weiß ich garnicht, ob im FPC die LongStrings intern überhaupt gleich aufgebaut sind, wie aktuell im Delphi. (mit CodePage und CharSize ElementSize)
Diese beiden Felder wurden 2009 mit der Unicodeumstellung eingefügt. (aber egal ... wenn die Kopie entfent wurde, brauchen wir uns nicht mehr darum zu kümmern)

[TurboMagic]

Hallo,

danke für deine Analyse, auch wenn ich die noch nicht gaz verstehe.
Ja, wenn man diese Unit loswerden könnte wäre das natürlich gut.

Soweit ich dich verstehe erfüllt der derzeitige Code nicht den intendierten Zweck.
Nur wie müsste es denn wirklich aussehen um den Zweck zu erfüllen?
Das hab' ich noch nicht so ganz verstanden.

Ich würde auch einen Pull-Request akzeptieren, auch wenn ich mit Git ab und an
noch etwas auf Kriegsfuß stehe, aber irgendwie bekomme ich das dann schon integriert...

Grüße
TurboMagic

[TurboMagic]

Hallo,

so, auf den berühmt berüchtigten vielfältigen Wunsch eines einzelnen
hab' ich mal eine kleine VCL Demo für die Nutzung dieser Progress
Anzeige gemacht.

Dabei ist mir aufgefallen, dass der Methodenname im IDECProgress Interface
evtl. noch ein wenig blöde heißt. Der könnte sich also in Zukunft nochmal
ändern. Sorry! Außerdem sind da nicht alle Parameter im XMLDOC beschrieben,
auch das sollte sich in Zukunft ändern.

Im Anhang also die Demo.

Grüße
TurboMagic