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

[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