![]() |
AW: Gute Nachricht des Tages: DEC V6.4 wurde veröffentlicht
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. |
AW: Gute Nachricht des Tages: DEC V6.4 wurde veröffentlicht
Hallo Norbert
ich nehme an du hast Vorkenntnisse in diesem Bereich. Wenn Nein, dann findest du ![]() U.a. bei NIST findest du das ![]() 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 ![]() 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 ![]() |
AW: Gute Nachricht des Tages: DEC V6.4 wurde veröffentlicht
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? |
AW: Gute Nachricht des Tages: DEC V6.4 wurde veröffentlicht
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 |
AW: Gute Nachricht des Tages: DEC V6.4 wurde veröffentlicht
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. |
AW: Gute Nachricht des Tages: DEC V6.4 wurde veröffentlicht
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 |
AW: Gute Nachricht des Tages: DEC V6.4 wurde veröffentlicht
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 |
AW: Gute Nachricht des Tages: DEC V6.4 wurde veröffentlicht
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. |
AW: Gute Nachricht des Tages: DEC V6.4 wurde veröffentlicht
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 |
AW: Gute Nachricht des Tages: DEC V6.4 wurde veröffentlicht
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 |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:20 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz