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:

Delphi-Quellcode:

[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, :shock:
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

Delphi-Quellcode:

Length(Source) * SizeOf(Source[Low(Source)])

könnte man auch

Delphi-Quellcode:

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

[EdAdvokat]

ich habe vor Jahren mal mit Dateien aus einem fernen Land experimentiert und glaube es lohnt sich durchaus.
Anbei der Hinweis auf die Fly-Utils zum Thema AES-Files u.a.m.
https://sourceforge.net/projects/fly...urce=directory

Der Blogger Dennies Chang http://firemonkeylessons.blogspot.com/2017/
hält durchaus interessante Themen bereit. Es lohnt sich durchaus da mal rein zu schauen.
Mit Deepl ist das Übersetzen der fernen Zeichen kein großes Problem. (dies war keine Werbung)

[TurboMagic]

Danke für den Link.
Muss ich mal schauen ob das was nützliches drin ist.

[EdAdvokat]

wenn Du beim Prüfen und Vergleichen bist, solltest Du sicher auch hier mal vorbeischauen:
http://www.cnpack.org/showdetail.php?id=864&lang=en
Hier sind div. Chiffrieralgorithmen und div. Hash-Funktionen enthalten. Interessant sind auch die
asymetrischen Chiffrierverfahren RSA, Diffie-Hellman, ECC, also die Verwendung von eliptischen Kurven für
die asymetrische Chiffrierung.Dazu gibt es auch sehr interessante youtube-Videos von bekannten Kryptologieprof., die
DEC, AES und auch die Verwendung von eliptischen Kurven in der Chiffrierung erklären. Dazu braucht man jedoch
einen klaren Kopf und Geduld, doch es lohnt sich durchaus.
Auch das Rechnen mit großen Zahlen (big numbers) ist in diesem Zusammenhang recht interessant auch wenn es
hierzu weitere Autoren gibt.
Jedenfalls sind die cn-Tools ein Bereicherung zum Thema Chiffrierung/Hash-Funktionen.
Ich habe damit auch erfolgreich experimentiert und einige Programme dazu geschrieben. So ganz für mich allein.
Möglicherweise bieten diese Tools Anregungen und Wege auch für das DEC-Projekt.
Hier würde ich mir wünschen, dass auch asymetrische Algorithmen künftig aufgenommen werden.

[himitsu]

Die paar Pullrequests sind gleich von mir, falls sich wer wundert.

[TurboMagic]

Welche Pull Requests?
Hab' noch keine gesehen. Oder galt das nicht mir?

[himitsu]

Hatte mich noch entschieden was anders zu machen bin grade fast fertig ... heut abend oder morgen früh. :oops:

* hab die Projektoptionen (Ausgabepfade und Suchpfade angepasst)
* die Platformen aufgefüllt > DEC60.dproj kann nun für Win32/Win64/Linux/Android/iOS/OSX kompilieren
* * Linux probiere ich die nächsten Tage zu kompilieren, OSX/iOS kann nicht, aber für den iOSSimulator kompiliert es
* ein erstes Billigbuildscript (CMD) erstellt, dass alle Delphi-Versionen (wenn installiert) und sämtliche Platform/Configs compiliert
* * Compilieren für Freepascal/Lazarus fehlt noch
* * müsste ich mal auf Powershell oder Finalbuilder (Standard) umstellen (IDE-Pfade aus Registry auslesen geht in CMD nicht so gut)



* und hab (ebenfalls) probehalber an den OnProgress rumgepfuscht, aber auch wenn der Code so in Delphi und bestimmt auch FreePascal geht
sieht es doof aus und ich würde mal schauen (noch ein zweiter Versuch/Branch) die Überladungen in einen impliziten Cast via Record-Operatoren zu verlegen ... aber noch k.A. wie das dann in FreePascal aussähe

[TurboMagic]

Na da bin ich ja mal gespannt...
Die anderen Plattformen fehlen, weil ich die nicht installiert habe,
da ich die nicht nutze. Aber wir können's gerne unter denen auch testen.

Es stellt sich auch die Frage, ob's wirklich mit dem C++ Builder auch
funktioniert.

Was mich aber auch interessiert sind deine Anmerkungen zu dem ProtectString
Zeugs...

[himitsu]

C++Builder kann ich nicht testen,
aber der kann die Units (DCU) einbinden, welche von Delphi kompiliert wurden. (wenn ich das richtig verstanden hab)
(schade, dass man nicht andersrum im Delphi auch .C und .H vom C++ rein bekommt, außer mühevoll über eine PAS+OBJ)

Code:

### Delphi 21.0 ###

OK     Source\DEC60.dproj   : Win32 Debug
OK     Source\DEC60.dproj   : Win32 Release
OK     Source\DEC60.dproj   : Win64 Debug
OK     Source\DEC60.dproj   : Win64 Release
FAIL   Source\DEC60.dproj   : Linux64 Debug
FAIL   Source\DEC60.dproj   : Linux64 Release
OK     Source\DEC60.dproj   : Android Debug
OK     Source\DEC60.dproj   : Android Release
OK     Source\DEC60.dproj   : Android64 Debug
OK     Source\DEC60.dproj   : Android64 Release
FAIL   Source\DEC60.dproj   : iOSDevice64 Debug
FAIL   Source\DEC60.dproj   : iOSDevice64 Release
OK     Source\DEC60.dproj   : iOSSimulator Debug
OK     Source\DEC60.dproj   : iOSSimulator Release
FAIL   Source\DEC60.dproj   : OSX32 Debug
FAIL   Source\DEC60.dproj   : OSX32 Release
FAIL   Source\DEC60.dproj   : OSX64 Debug
FAIL   Source\DEC60.dproj   : OSX64 Release

OK     Unit Tests\DECDUnitTestSuite.dproj   : Win32 Debug
FAIL   Unit Tests\DECDUnitTestSuite.dproj   : Win32 GUI
FAIL   Unit Tests\DECDUnitTestSuite.dproj   : Win32 MobileGUI
FAIL   Unit Tests\DECDUnitTestSuite.dproj   : Win32 TestInsight
FAIL   Unit Tests\DECDUnitXTestSuite.dproj   : Win32 Debug
FAIL   Unit Tests\DECDUnitXTestSuite.dproj   : Win32 Console

OK     Demos\Cipher_Console\Cipher_Console.dproj   :
OK     Demos\Cipher_FMX\Cipher_FMX.dproj   :
OK     Demos\CryptoWorkbench_VCL\CryptoWorkbench_VCL.dproj   :
OK     Demos\Format_Console\Format_Console.dproj   :
OK     Demos\Hash_Console\Hash_Console.dproj   :
OK     Demos\Hash_FMX\Hash_FMX.dproj   :
OK     Demos\Progress_VCL\Progress_VCL.dproj   :
OK     Demos\Random_Console\Random_Console.dproj   :

RUN:3       DECDUnitTestSuite.exe   : Win32 Console
RUN:0       DECDUnitTestSuite.exe   : Win32 Debug
RUN:9009    DECDUnitXTestSuite.exe   : Win32 Debug
RUN:3       DECDUnitXTestSuite.exe   : Win32 GUI

Die FAIL bei iOS/OSX kommen, weil's hier nicht installiert ist.

Und DECDUnitTestSuite.exe (Win32/Debug) läuft auch ohne Fehler durch.

DUnitX bekomm ich nicht kompiliert (weiß grad nicht warum, aber mir reichte erstmal, wenn ein Test läuft)
und ich hab zwar unter "Debug" ein paar neue Configs angelegt, mit den $DEFINEs der Projekte, wo man z.B. zwischen VCL-GUI und Console wechseln kann. (hab da aber auch noch nicht nachgesehn, warum es nicht kompiliert ... einwas läuft, also das was es bisher gab, und der Rest hat Zeit)

Zitat:

Was mich aber auch interessiert sind deine Anmerkungen zu dem ProtectString

Wenn ich es richtig sehe, dann sind "eigentlich" alle Funktionen für RawByteString sinnlos,
da RawByteString ein AnsiString ist alles von/für ihn von den ANSI-Funktionen behandelt wird.
ABER, im NextGen iOS/Android gibt es "öffentlich" keinen Typen "AnsiString" (war eine echt beschissene Idee seitens Embarcadero), so daß es dort viel Spaß damit gibt.

Im Windows könnten also alles ala ProtectString für RawByteString weg, aber im Mobile braucht man es dann doch wieder.



Ich wollte es erstmal hinbekommen, dass man "alles" kompilieren kann, um bei tieferen Änderungen es auch möglichst überall testen zu können.

[himitsu]

Zitat:

Zitat von TurboMagic

Übrigens: DEC ist jetzt als DEC Lite ohne die Ciphers in GetIt verfügbar.
Die Ciphers sind wegen US Exportregularien ein Problem.

OMG, sogar im GetIt. :shock:
https://getitnow.embarcadero.com/DECLite-6.0/

Zitat:

Tags: Hash, Cipher, CRC, AES, Twofish, Blowfish, DES, 3DES, XTEA, TEA, SHA1, SHA256, RIPE MD160, Skipjack

Ein Fehler?

Pass nur auf, wegen der Namensrechte, nicht dass man es mit der Lampenfirma verwechselt. (in Google ist unser DECLite noch nicht oben gelistet)
Nur noch ein Logo mit angebissenem Apfel dazu und es ist perfeckt. :thumb:


Wie ist das eigentlich mit GitHub?
Jedesmal wenn sich jemand die Webseite an anguckt, geht das schwere DEC über dutzende Grenzen/Kontinente.

Wann is'n die Europa Cloud denn fertig? (Gaia-X, welche aber vorwiegend von Ammies geführt sein wird :roll:)
Ach Mist, dort ist man nun ja auch nicht mehr vor dem Gesetz sicher.
Heise: EU-Regierungen planen Verbot sicherer Verschlüsselung

Von Delphi gibt es auch die GSA Versionen (ohne die böse russische Spionagesoftware)
ID 30898, GSA accounts RAD Studio, Delphi, C++Builder 10.3.3 ISO (delphicbuilder10_3_3_gsa7899_nt)
ID 30896, RAD Studio, Delphi, C++Builder 10.3.3 ISO (delphicbuilder10_3_3_7899_nt)
aber ich finde dort keinen Unterschied.
:duck:

[himitsu]

So, ich denk mal das passt jetzt.

• Ausgabepfade noch bissl angepasst (die Demos landen unabhängig von der DelphiVersion und Config im selben Verzeichnis ... Eine reicht ja)

Auch die ConsolenVersionen der UnitsTests compilieren und laufen.

• DUnitX: TestInsight ist nicht installiert
  error F2613: Unit 'TestInsight.DUnitX' nicht gefunden.
• und bei der DUnitX-GUI fehlt auch mir eine Unit
  error E1026: Datei nicht gefunden: 'DUNitX.Loggers.GUIX.fmx'
• und es gibt ein paar "Veraltet"-Warnungen in den Tests für DUnitX (beim DUnit ist es ruhig)
  warning W1000: Symbol 'CheckEquals' ist veraltet: 'Use DUnitX.Assert class'

Code:

### Delphi 21.0 ###

OK     Source\DEC60.dproj   : Win32 Debug
OK     Source\DEC60.dproj   : Win32 Release
OK     Source\DEC60.dproj   : Win64 Debug
OK     Source\DEC60.dproj   : Win64 Release
FAIL   Source\DEC60.dproj   : Linux64 Debug
FAIL   Source\DEC60.dproj   : Linux64 Release
OK     Source\DEC60.dproj   : Android Debug
OK     Source\DEC60.dproj   : Android Release
OK     Source\DEC60.dproj   : Android64 Debug
OK     Source\DEC60.dproj   : Android64 Release
FAIL   Source\DEC60.dproj   : iOSDevice64 Debug
FAIL   Source\DEC60.dproj   : iOSDevice64 Release
OK     Source\DEC60.dproj   : iOSSimulator Debug
OK     Source\DEC60.dproj   : iOSSimulator Release
FAIL   Source\DEC60.dproj   : OSX32 Debug
FAIL   Source\DEC60.dproj   : OSX32 Release
FAIL   Source\DEC60.dproj   : OSX64 Debug
FAIL   Source\DEC60.dproj   : OSX64 Release

OK     Unit Tests\DECDUnitTestSuite.dproj   : Win32 Debug
OK     Unit Tests\DECDUnitTestSuite.dproj   : Win32 Console
OK     Unit Tests\DECDUnitXTestSuite.dproj   : Win32 Debug
FAIL   Unit Tests\DECDUnitXTestSuite.dproj   : Win32 GUI
OK     Unit Tests\DECDUnitXTestSuite.dproj   : Win32 MobileGUI
FAIL   Unit Tests\DECDUnitXTestSuite.dproj   : Win32 TestInsight

OK     Demos\Cipher_Console\Cipher_Console.dproj   :
OK     Demos\Cipher_FMX\Cipher_FMX.dproj   :
OK     Demos\CryptoWorkbench_VCL\CryptoWorkbench_VCL.dproj   :
OK     Demos\Format_Console\Format_Console.dproj   :
OK     Demos\Hash_Console\Hash_Console.dproj   :
OK     Demos\Hash_FMX\Hash_FMX.dproj   :
OK     Demos\Progress_VCL\Progress_VCL.dproj   :
OK     Demos\Random_Console\Random_Console.dproj   :

RUN:0       DECDUnitTestSuite.exe   : Win32 Console
RUN:0       DECDUnitTestSuite.exe   : Win32 Debug
RUN:0       DECDUnitXTestSuite.exe   : Win32 Debug
RUN:9009    DECDUnitXTestSuite.exe   : Win32 GUI

Was soll mir im Log des DUnitX das "1 Fehler" sagen?
Egal, es läuft ja :angle2:
[EDIT] Ach, das kam aus dem Eingabe-/CopyBuffer ... dort versteckt sich ein ReadLn. :stupid: [/EDIT]

Code:

### 21.0 Win32 Debug # DECDUnitXTestSuite.exe
**********************************************************************
*        DUnitX - (c) 2015-2018 Vincent Parrett & Contributors       *
*                                                                    *
*        License - http://www.apache.org/licenses/LICENSE-2.0        *
**********************************************************************

DUnitX - [DECDUnitXTestSuite.exe] - Starting Tests.

.........................................................................................................................................................
.........................................................................................................................................................
.........................................................................................................................................................
.........................................................................................................................................................
.........................................................................................................................................................
.........................................................................................................................................................
.........................................................................................................................................................
.........................................................................................................................................................
.........................................................................................................................................................
...................................................................................

Tests Found   : 730
Tests Ignored : 0
Tests Passed  : 730
Tests Leaked  : 0
Tests Failed  : 0
Tests Errored : 0
Done.. press <Enter> key to quit.    1 Fehler

[EdAdvokat]

ich habe an der VCL-Progress-Demo von TurboMagic ein wenig herumgebastelt, so dass die zu ver- oder zu entschlüsselden Dateien
ausgewählt und geladen werden können. Auch die Eingabe des Passwortes und Wahl des Betriebsmodus läßt sich einstellen.
Alles keine wirklichen Leistungen.
Dabei trat bei mir die Frage auf, warum ist diese DEC-AES Version nur mit der Schlüssellänge 128 bit vorgesehen.
Aus der Länge des Passwortes (16 Stellen) habe ich auf AES 128 getippt.
Gibt es auch eine Möglichkeit der Auswahl von AES 196 bit bzw. AES 256 bit? Sicher reicht AES 128 für einfache Zwecke aus,
doch wäre es nicht schlecht auch die anderen Schlüssellängen aufzunehmen.
Ich habe in den von mir zurückliegend erstellten AES-Versionen eine etwas ausführliche Hilfe/Info aufgenommen, in der
die Betriebsmodi, die Wahl der Schlüssellänge usw. beschrieben werden. Da es diesbezüglich doch hier und da Fragen gibt.
Ich habe also einfach mal so eine Hilfe/Info in deutsch mit aufgenommen.
Sicher wäre dazu rein optisch ein popup-Menü besser. Es ist lediglich eine "Vor-Alpha-Version" nur so zum Probieren.
Doch alles zu seiner Zeit.

Ich habe mal meine bescheidenen Versuche beigefügt.

[TurboMagic]

Hallo,

danke schon mal für deinen Beitrag, auch wenn ich noch keine Zeit hatte den zu begutachten.
Mich hält noch himitzus Pull Request beschäftigt.

Wenn ich mir den Quellcode von DEC's AES so ansehe, dann ermittelt er die Anzahl der
Runden anhand der Schlüssellänge. So beschreibt es auch der DE Wikipediaartikel zum AES.
Dadurch kommt man mit einer AES-Klasse aus und die Bittigkeit ergibt sich automatisch aus
der benutzten Schlüssllänge.

Also wenn man ein längeres Passwort angibt, erhält man auch eine höhere Verschlüsselungssicherheit.
Ich hoffe das jetzt richtig verstanden zu haben.

Das Demo Programm war übrigens bewußt minimalistisch gestrickt um möglichst wenig von der eigentlich
zu demonstrierenden Fortschrittsanzeige abzulenken. Natürlich dürfte deine Fassung für eine schnelle
Anwendung als Verschlüsselungsprogramm nützlicher sein. Muss ich mir bei Gelegenheit mal anschauen.

Grüße und frohe Weihnachten
TurboMagic

[generic]

Zitat:

Zitat von TurboMagic (Beitrag 1479037)

• Hinzufügen des GCM Blockverkettungsmodus
• Hinzufügen eines ersten Passwort Hashalgorithmus. Vermutlich BCrypt

Danke TurboMagic für dein Einsatz an der DEC.

Upvote für:
GCM wäre schön. Mehr Performance wegen möglicher Parallelisierung und etwas sicherer als CBC wegen der Padding-Attack in CBC.

[himitsu]

Joar, so kleine MiniDemos zu einem spezifischen Problem sind manchmal ganz nett.
Entweder um eine bestimmte Sache zu demonstrieren.
Aber natürlich kann auch eine "umfassendere" Demo für ein "grundsätzliche" Ver-/EnschlüsselungsBeispielprogram mit aufgenommen werden.

Schau dir mal dagegen die CryptoWorkbench-Demo an.
Das ist eine angefangene MegaDemo, wo als "gennerelle" Funktionsübersicht "alles" rein kann.
(ich denk mal als FMX wäre sie noch besser, damit man sie auch auf einem Handy ausprobieren kann ... die GUI ist ja per se egal)

[TurboMagic]

Naja, die Crypto Workbench war eigentlich etwas anders gedacht udn für die Hashes und
Ciphers gibt's ja schon FMX basierte Demos. Da braucht's nicht unbedingt eine Mega Demo.
Ich würd' mal vorerst die Workbench killen. Es gibt genügend andere Baustellen.