Kleines Weihnachtsgeschenk: DEC V6.00 verfügbar

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