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

[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 von TurboMagic:

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
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!