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