Gute Nachricht des Tages: DEC V6.4 wurde veröffentlicht

[TurboMagic]

Hallo,

soeben wurde V6.4 von DEC (Delphi Encryption Compendium) veröffentlicht:
https://github.com/MHumm/DelphiEncry...eases/tag/V6.4

Was ist neu?

• Bugfixes
• Layout Verbesserung der FMX Hash Demo
• Teilweise überarbeitete Dokumentation
• GCM (Galois Counter Mode) Blockverkettungsmodus fpr 128 Bit Verschlüsslungsalgorithmen hinzugefügt

Viel Spaß beim Benutzen
TurboMagic

[EdAdvokat]

Bisher hat wohl noch niemand DEC 6.4 ausprobiert, jedenfalls sehe ich keine Rückmeldungen. Ich habe extra etwas gewartet mit meiner Nachfrage.
So richte ich meine Frage an Markus.

Ich also DEC 6.4 installiert und zunächst die Demoprogramme kompiliert. Das ging soweit gut.
FMX Hash klappt soweit.
Doch mit FMX Cipher habe ich so meine Probleme:

Folgende Einstellung:
TCipher_AES (und mit den anderen TCipher_Algorithmen dann ebenfalls probiert...)
input: TFormat_Copy
output: TFormat_Copy
Key: 4727595189464286
IV: BDC9FC6D0E82
Filler: 12355124
Modus CBC (und die anderen probiert) gleiches Ergebnis

Gebe einen Plantext ein und enc. erhalte ich die Fehlermeldung: Input is not an valid HexL Format
obwohl Input TFormatCopy eingestellt ist.
Wechsele ich den Algorithmus erhalte ich bei jeder neuen Wahl den Fehler: Invalid chipher algorithmus selected
for block chaining mode. für alle eingestellten TCipher_Algorithmen.
All diese komischen Meldungen hatte ich bei den Vorversionen nicht.
Wo liegt der Fehler oder mache ich da was falsch?

[Michael II]

Du beziehst dich auf \Demos\Cipher_FMX.

Wahrscheinlich liegt es daran, dass in deinem InitVektor Grossbuchstaben vorkommen und im Programm steht "lower case" (wieso nur lower zugelassen werden weiss ich nicht).

Wenn ich deinen Test Case übernehme, aber den Wert für den InitVektor "klein schreibe", dann wird keine Fehlermeldung ausgegeben.

Löst dies dein Problem?

M hält einen Vortrag an der EKON und hat wohl gerade andere Prioritäten ;-).

[EdAdvokat]

Danke Michael II aber auch das löst mein Problem nicht.
Hast Du mit dem Demo-Programm in DEC 6.4 keine Probleme? Ich erhalte erneut die Meldung Input ist nicht HexL-Format auch wenn ich als Input TFormat_Copy und als output-Format
TFormat_HexL eingebe. Es hat sich nichts geändert.

[Michael II]

Hallo EdAdvokat

ich habe definitiv 6.4 drauf - im \readme-md steht "The current version 6.4 is compatible...".
Wenn ich deine Werte (inkl. deinem grossen FillerByte) eingebe, aber wie erwähnt den Wert des InitVektors - wie im Programm verlangt wird - klein schreibe (also bdc9fc6d0e82), für Plain Text "Dies ist ein Test" eingebe, danach Encrypt klicke, dann lautet der CipherText 66ff24a48159ee09a2c034b667b0ae05e5 (TFormatHexL).

Gruss
M

(In der nächsten Version wird TM den Demoprogrammen hoffentlich doch ein Save/Load Menu verpassen (damit ist einer meiner Wünsche nun öffentlich - das soll aber keinerlei Druck... ;-)). Das wäre definitiv praktisch. Dann könntest du wie bei den NIST Testfällen einfach rasch deinen Testfall als File an mich oder wen auch immer weitergeben. Falls ich noch einmal was testen soll: Ich habe dir meine eMail Adresse per PN gesendet.)

[TurboMagic]

Hallo,

danke Michael, für deine Unterstützung!
Ja, heute ist Vortrag!

Zu der Demo: diese wurde tatsächlich für 6.4 noch ein wenig
geändert. Die testdaten weshalb ich das geändert habe wurden
danach bestanden und warum es bei deinen Daten Fehler Spucken
soll ist mir noch nicht klar auch nicht warum es bei Michael
funktioniert und bei dir nicht.

Falls ihr nicht Unterschiede im Eingeben eurer Daten findet
muss ich wohl in den nächsten Tagen, sobald ich wieder zuhause
bin, nachschauen.

Einen Speichern Button werde ich eher nicht einbauen, da das
unter Mobile immer nerviger wird (vgl. Scoped Storeage ab
Android 10). Aber einen "Kopieren in die Zwischenablage"
Button könnte ich mir vorstellen.

Grüße

TurboMagic

[EdAdvokat]

Nochmals Danke Michael II.
Ich habe nunmehr DEC 6.4 völlig neu installiert und Cipher_FMX ausprobiert.
Ich erhalte tatsächlich nun auch Dein Ergebnis: 66ff24a48159ee09a2c034b667b0ae05e5. Auch funktionieren nun alle Ein- und Umstellungen ohne Fehlermeldung. Sogar der neue Modus
GCM kann genutzt werden. Da war wohl der Hund drin? Habe zwar keinen Hund, doch woran es gelegen haben kann konnte ich bislang noch nicht feststellen, zumal das Programm ordnungsgemäß kompiliert werden konnte.
Jetzt ist die Welt also wieder rund und ich danke Euch nochmals. Nun kann ich mein bisheriges Projekt wieder auf einen neuen Stand bringen.

[Michael II]

Hallo EdAdvokat,

Dankeschön fürs Melden.

Da zeigte vielleicht noch was auf alten Code und nicht auf den neuen - fehlt nur noch was Gebrauchtes ;-).

[freimatz]

deleted

[TurboMagic]

Hallo,

so, nach dem der Vortrag rum ist und glaube ich ganz ordentlich lief (der Raum war jedenfalls
soweit mit Zuhörern gefüllt also dürfte Interesse da gewesen sein) mal noch meine Frage:

Welche Version war denn installiert, bevor du's ganz neu installiert hast?
Evtl. eine aus dem Entwichlungs Zweig? Evtl. von kurz vor dem Release der V6.4?
Ich hatte da nämlich noch Last-Minute Bugs in der Cipher FMX Demo gefixt.
Das würde es jedenfalls erklären.

Die gefixte Version habe ich auch erfolgreich mit einem der Original GCM Testvektoren vom
NIST getestet. Das war am Ende meine "Hürde" die ich vor der Veröffentlichung des Release
nehmen wollte.

Grüße
TurboMagic

[EdAdvokat]

Hallo TurboMagic
Also zu Deiner Frage: Ich habe DEC 6.4 in einem neuen Verzeichnis entpackt, Demo/Cipher_FMX aufgerufen und dann den
Source-Path von DEC 6.4 hinzugefügt, da ich erst einmal sehen wollte, ob das auch funktioniert. Dann kompiliert und
Cipher_FMX.exe ließ sich aufrufen, jedoch mit den beschiebenen Fehlern.
Nach dem Hinweis habe ich DEC 6.4 völlig neu installiert (Source im Delphi-Path) und ohne das Hinzufügen des Source-Path
in die .dpr aufgerufen danach lief es.
Was die Ursachen für die Fehler waren, kann ich nicht sagen. Es war tatsächlich nur der neue Quellcode von DEC 6.4 ohne eigene
Zusätze.

Nun, da wir schon dabei sind, eine Frage: Der Modus GCM läßt sich einstellen und ich erhalte auch im Feld
Calculated authentication value einen Hashwert, der sicher zur Autorisierung des gesendeten Plantextes dienen soll.
Wofür sind die Felder Autenticated data und Expected authentication result? Wo finde ich dazu eine nähere
Erklärung. Ich denke es sollte für die Prüfung der Autorisierung dienen. Wie geht das konkret?
Meine Versuche, den Chiffretext mit dem Hash-Wert der Autorisierung zu vergleichen führten stets dazu, dass keine Übereinstimmung gemeldet wurde
Ich will mich heute nochmals mit dem Programm beschäftigen, nachdem ich es gestern von FMX auf VCL "konvertiert"
habe.

[Michael II]

Hallo Norbert

ich nehme an du hast Vorkenntnisse in diesem Bereich. Wenn Nein, dann findest du hier eine Grobübersicht.

U.a. bei NIST findest du das Originalpaper von MCGrew und Viega zum GCM Mode. Die "mathematische Sprache" im Paper ist erfrischend einfach gehalten. Am Ende des Papers findest du viele Testfälle; sogar Zwischenresultate sind aufgeführt.

Wie du schreibst dient der "authentication tag" als Signatur für die in 128 Bit Blöcke zerlegte (im Original [und meistens] mit AES) verschlüsselte Nachricht.

Wenn du eine verschlüsselte Nachricht erhältst, dann erhältst du über irgend einen Weg auch einen "authentication tag". Du berechnest nun aus der Nachricht den "authentication tag" und vergleichst diesen mit jenem, den du erhalten hast. Du akzeptierst die Nachricht, wenn die beiden Werte übereinstimmen.

Tipp: Bei NIST findest du über 40'000 Testfälle; mit diesen kannst du eigene Anpassungen am Code testen.

Wenn ich dich richtig verstehe, dann schreibst du dass von dir zuvor chiffrierte Nachrichten beim Dechiffrieren wegen falschem "authentication tag" verworfen werden. Das wäre natürlich nicht gut. Hast du ein Beispiel (inkl. Angabe OS)? Kannst auch per PN; das ist sicher nix von allgemeinem Interesse. Du findest auch hier oder bei mormot Code zum Gegenchecken.

[EdAdvokat]

Hallo Michael II
in einer PN habe ich die Einzelheiten mitgeteilt.
Allgemein sei gesagt, dass ich mit AES und Modus GCM eine Nachricht verschlüsselt habe und dazu einen Authentication value
erhalte.
Den chiffre Text und auch meinen Authentions Value übermittele ich dem Empfänger.
Der dechiffriert des chiffre Text und vergleicht den dabei generierten Autentions Value mit dem, den er von mir
erhalten hat. Stimmen beide überein alles i.o und der Plantext wurde nicht verändert.
Stimmen diese beiden Aut...value nicht überein, dann war "Mallory" zwischen Bob und Alice. Wirklich blod - oder?

Meine Frage: wozu sind die beiden edit-Felder im Cipher_FMX: autenticated data und expected authentication result?
Was muss da eingegeben werden?

[TurboMagic]

Hallo,

so, zurück von der EKON und mal ein paar Minuten Zeit:
Ich wunrdere mich immer wieder wozu der Inhalt des "docs" Ordners der DEC Distribution
dieser Distribution beigepackt wurde.

Könnte es sein, dass sich der Autor dieser PDFs dort drinnen evtl. was dabei gedacht hat?
Man könnte beispielsweise Kapitel 3.4.6.6 lesen und dem Autor des DOkumentes via
Delphipraxis mitteilen, ob dieser Inhalt verständlich ist...

Grüße
TurboMagic

[EdAdvokat]

Bei der Durchsicht der Doks bin ich bei der Suche nach GCM, Authentication u.ä auf diesen Unterpunkt "Using the cipher algorithms"
nicht gestoßen, Sorry, denn dort hätte ich Infos zu meinem Problem nicht erwartet.
Doch vielleicht liegt es ja an mir, dass ich zu b... bin, das zu finden und zu begreifen.
Trotzdem glaube ich den Sinn des Ganzen verstanden zu haben und daher führte ich diverse Prüfungen durch, bei denen ich festgestellt
habe, dass nach enc und Übertragung des chiffretextes und des vom Absender generierten Autentications value an den Empfänger dieser
dann vom Empfänger in Expected authentication result eingegeben wird, danach dec ausgeführt wird. Es gibt keine Meldung! Also kein
Fehler und das bedeutet also, dass alles in Ordnung ist? Ich habe erwartet, dass mir an dieser Stelle ein explizites OK gegeben wird.
Was bedeutet : "Rufen Sie nach dem Entschlüsseln unbedingt Done auf, damit dies funktioniert!" ?

Zum Feld DatatoAuthenticate habe ich folgenden Eintragung übersetzt mit Deep gelesen: "Wenn die Datenauthentifizierung des GCM-Modus
verwendet werden soll, werden die zu authentifizierenden Daten vor Beginn der Ver- oder Entschlüsselung in diese TBytes-Eigenschaft
eingetragen. Auch wenn sie leer bleibt, wird ein Authentifizierungswert berechnet, der nur auf den zu verschlüsselnden Daten basiert.
Die Festlegung von zu authentifizierenden Daten, ohne dass Mode auf einen der verfügbaren authentifizierten Modi eingestellt ist,
führt zu einer EDECCipherException!"
Das habe ich nicht verstanden. Was soll in dieses editfeld eingetragen werden?

Und ja lieber Autor diese Eintragungen sind nicht verständlich. Jedenfalls für mich nicht.
Hätte nicht ein einfacher Vergleich der Aut...value vom Absender mit der vom Empfänger mit einem klaren Ok oder falsch auch gereicht?
Wenn Du schon eine gesondert Pdf zu den Änderungen erstellst, dann wäre doch auch ein expliziter Hinweis auf die versteckte Stelle im
Kap. 3.4.6.6 möglich gewesen. Da steht lediglich "Added support for the GCM (Galois Counter Mode) block chaining mode." und "Added GCM
specific fields to Cipher FMX demo"

Ich denke noch immer, dass die Fragen nach den editfeldern in DEC-Demo Cipher_FMX angemessen waren und gezeigt haben, dass noch
Erklärungsbedarf auch für einfache Geister besteht.

[TurboMagic]

Hallo,

habe jetzt verstanden, dass du wohl kein Englisch kannst und drum die Anleitung etwas problematisch für dich ist.
Versuche heute Abend Zeit für etwas Erklärung zu finden. Bitte ein wenig Geduld.

Grüße

TurboMagic

[TurboMagic]

Hallo,

jetzt eine kurze Erklärung:
GCM liefert in jedem Fall einen Authentifizierungswert zurück. Das ist CalculatedAuthenticationResult.
Wenn keine Daten in DataToAuthenticate übergeben wurden, basiert der nur auf den zu verschlüsselten
oder verschlüsselten Daten.

Wurde aber ein Wert an DataToAuthenticate übergeben wird das mit in die Berechznung einbezogen.
Man muss in dem Fall dem Empfänger natürlich auch diesen Wert übergeben, damit er das selbe Rechenergebnis
bekommen kann.

Damit: AuthenticationResultBitLength gibt man noch an wie lange diesere Authentifizierungswert in Bit
sein soll. Im Prinzip kann man jede beliebige Länge angeben, besser ist es aber einen der in diesem Array
drin enthaltenen Werte zu benutzen: GetStandardAuthenticationTagBitLengths

Warum? Naja, weil das die vom NIST definierten Standardwerte sind, die auch von den Testvektoren vom NIST
in unseren Unit Tests benutzt werden...

Wenn der berechnete Authentifizierungswert nicht ExpectedAuthenticationResult entspricht wird eine
Exception ausgelöst. Die entschlüsselten Daten werden aber nicht verworfen, auch wenn die dann nicht
vertrauenswürdig sind. Muss dann jeder selber entscheiden was noch ok ist.

Und ja: die Demo könnte im Gutfall eine "OK-Meldung" anzeigen. Nehme es auf die ToDo Liste.

Reicht das jetzt zum Verständnis?

Grüße
TurboMagic

[EdAdvokat]

Zunächst möchte ich feststellen, dass ich mit meinen Wortmeldungen nicht als Nörgler oder Miesmacher verstanden werden will.
Mitunter drängte sich mir der Eindruck auf, ich würde nerven. Sicher ist das der Sache weniger dienlich.

Sicher hast Du bemerkt, dass mich das Thema DEC durchaus interessiert und ich gemäß meinen bescheidenen Möglichkeiten eine Unterstützung
leisten möchte.
Und ja, ich habe in der Schulzeit/Studium Russisch mit einer Sprachkundigenprüfung bestanden Franzöisch 4 Jahre gelernt und mir
Englisch selbst angeeignet. Sicher durchaus verbesserungswürdig, doch das verstehende Lesen klappt schon recht gut. Dass ich kein Englisch kann stimmt
so nicht, doch egal.
Da ich jedoch den für sehr kompliziert gehaltenen englischen Text in der Dok möglichst genau übersetzt bekommen haben wollte, habe ich die
Hilfe von Deepl in Anspruch genommen aber auch damit den wirklichen Sinn nicht verstanden.
Ich kann nicht einschätzen, ob nur ich diese Doc für etwas zu kompliziert formuliert sehe, doch an bestimmten Stellen half sie mir nicht weiter.

Hast Du mal die verwendeten recht langen und komplizierten Bezeichnungen im Programm mit den von Dir in der Doc aufgeführten verglichen?

Im Programm (Property/Methode) nicht Labels!
Authenticated data
Excepted autentication result
Calculated authentication value
Length calculated value (bit)

In der Doc:
DataToAuthenticate
ExpectedAuthehticationResult sind beide gleich
CalculatedAuthenticationResult
AuthenticationResultBitLength

Der besseren Verständlichkeit dienend wäre in der Doc weniger die Auflistung der Methoden/Porperties als eher die Bezeichnungen der Editfelder/
Label gewesen, um damit die exakte Funktionalität erkennen zu können.

Du schreibst : GCM liefert in jedem Fall einen Authentifizierungswert zurück. Das ist CalculatedAuthenticationResult.

Im Programm erscheint tatsächlich im Edit-Feld Calculated authentication value der Authentifizierungswert (value nicht result).

weiter: Wenn keine Daten in DataToAuthenticate übergeben wurden, basiert der nur auf den zu verschlüsselten oder verschlüsselten Daten.

Was könnte also praktisch in das editfeld Authenticated data eingegeben werden? Den Text, den ich übermitteln will, wurde in Plan text eingetragen.
Ich habe überhaupt keine Vorstellungen dazu, was da rein sollte und dass müsste dann auch in hex sein.
Hierzu hätte ich gern eine Erklärung.

weiter schreibst Du: Wurde aber ein Wert an DataToAuthenticate übergeben wird das mit in die Berechznung einbezogen.
Man muss in dem Fall dem Empfänger natürlich auch diesen Wert übergeben, damit er das selbe Rechenergebnis bekommen kann.

Ich habe mal probeweise einen beliebigen hex-Wert in das editfeld Authenticated data eingetragen und dann verschlüsselt.
Daraufhin erhalte ich einen anderen Calculated authentication value. Den würde ich also dem Empfänger mitteilen.
Dein Doc-Text könnte dahingehend mißverstanden werden (...auch diesen Wert...), dass neben dem Calculated authentication value noch ein weiterer
Wert übermittelt wird.
Wird aber wohl nicht. Nur ein anderer resultierender Wert gemäß der Berechung für den Text und den ominösen Anhang.

weiter: Wenn der berechnete Authentifizierungswert nicht ExpectedAuthenticationResult entspricht wird eine Exception ausgelöst.

Das bedeutet also der Empfänger trägt vor der Dechiffrierung in das editfeld Excepted autentication result den vom Absender erhaltenen Auth...Wert
ein und im Zuge der Dechiffrierung erkennt er aktuell nur bei Nichtübereinstimmung des Originaltextes mit dem dechiffrierten Text durch eine
Exception dass was nicht gestimmt hat. Hier habe ich bei meinen Versuchen bei Übereinstimmung stets eine ok-Meldung erwartet. Die Exceptions habe ich stets auch erhalten
wenn es nicht gestimmt hat.

[TurboMagic]

Hallo,

keine Panik! Ich sehe dich nicht als Nörgler. Es ist nur gerade ein wenig viel los auch bei DEC...
Das mit dem Englisch hatte einfach so auf mich gewirkt. Aber das ist ok. Ich kann kein Russisch und
mein Französisch ist naja, vorhanden aber nicht gut.

Zurück zum Thema:

1. Ich werde die Doku nach falsch geschriebenen GCM Properties durchforsten. Ich hab' da auch
die blöde Angewohnheit, dass sich meine FInger immer bei Authentication vertippen...

2. Die Doku hangelt sich NICHT an den Demos entlang, sondern an den Klassen mit deren Methoden,
Properties usw. Demos können manchmal Dinge auslassen wenn das sonst für die allgemeinen Fälle
zu verwirrend würde. Auch meine Freizeit ist leider begrenzt.

3. Das Demo Programm werde ich so abändern, dass es bei korrekter Authentifizierung eine OK
Meldung anzeigt. War vorhin leider nicht in 5 min. umzusetzen, sondern braucht eine interne
Zustandsvariable...

4. Das mit dem DataToAuthenticate kannst du dir wie eine art zusätzlichen Schlüssel vorstellen.
Wenn der Empfänger das richtige CalculatedAuthenticationResult erhalten will und der Absender
DataToAuthenticate benutzt hat, muss der Empfänger dort den selben Wert wie der Absender eintragen.

Ich hoffe das hilft etwas weiter. Deomo ist evtl. gleich nacher im Development Branch, Doku braucht
eher noch ein wenig...

Grüße
TurboMagic

[TurboMagic]

Hallo,

der Development Branch enthält nun ein verbessertes Demo Programm:

1. Erfolgsmeldung wenn Authentication Wert stimmt.

2. Eingabe eines Filler Bytes beim GCM ist nicht mehr nötig, da es
da scheinbar keinen Effekt hat. Das EIngabefeld wird in dem Fall aber
auf '00' gesetzt, weil der Init AUfruf halt was braucht...
Sonst muss ich muss ich nochmehr Verzweigungen einbauen und dann ist's
irgendwann keine einfache Demo mehr...

Grüße

TurboMagic

[Michael II]

Zitat:

Zitat von TurboMagic (Beitrag 1497441)

Eingabe eines Filler Bytes beim GCM ist nicht mehr nötig, da es
da scheinbar keinen Effekt hat.

Nur kurz zu "kein FB für AES bei GCM":

Bei GCM wird AES nicht auf die Nachricht angewendet: Mittels AES wird solange ein (von Key, IV und einem Zähler abhängiger) "zufälliger" Bitstrom erzeugt bis die Länge des Bitstroms die Länge der zu verschlüsselnden Nachricht erreicht oder überschritten hat. Bei diesem Prozess ist das Argument (für die Funktion AES) durch IV und Zähler immer bereits 16 Bytes lang definiert und muss damit nicht "aufgefüllt" werden.

Beispiel: Länge der Nachricht : 24 Bytes
Nach zwei Mal AES ist der Bitstrom mit 32 Bytes lang genug.

Nachricht und Bitstrom werden nun miteinander "verxort". => Die Nachricht ist verschlüsselt.

In unserem Beispiel: Die letzten 8 Bytes des Bitstroms werden nicht benötigt.

[ Danach wird die Nachricht via Operationen im Galois Körper GF(2^128) signiert. Beim Signieren wird genau einmal AES aufgerufen - auch hier ist das 16 Byte Argument definiert und muss nicht aufgefüllt werden. ]

[Gandalf2265]

Noch mal ein Wort zum DEC-Vortrag von Markus bei der EKON:

Ich fand den Vortrag gut und interessant :-D
Mein Verständnis für die ganze Funktionalität hat sich deutlich verbessert und ich ziehe den Hut vor der vielen Arbeit, die du in die Bibliothek steckst.

Gruß
Thorsten

[TurboMagic]

Danke!
Zur Zeit ist eine Bugfix Version 6.4.1 in Entwicklung.
Details entweder im Entwicklungszweig oder in den Issued auf GitHub.
Zeitplan? Keiner! ;-)