Übrigens gilt diese Argumentation nicht nur für das Ende der Wurst sondern auch für den Anfang
Die gleiche Problematik hat man nämlich auch bei der Initialisierung der Cipher. Sprich welchen IV und wie berechnet er sich und welches Verfahren benutzt man um die übergebenen Passwörter in sichere Sessionkeys umzuwandeln.
Meine Taktik in diesem Fall war:
1.) die IVs sind fest vorgegeben bzw. werden fest berechnet. Es ist nämlich sowieso so das man entweder den IV per Zufall wählt und dann aber die eigentlich produzierte Nachricht noch um diese Bytes expandieren muß. Es bedingt also einen erhöhten Aufwand für den Anwender von Kryptographie in dessen Pre- und Postprocessing der Daten. Und dies alles ohne realem Sicherheitsgewinn da ja der IV unverschlüsselt übertragen wird.
Alternative ist es den IV fest vorzugeben, zb. alles 0xFF Bytes und für eine höhere Sicherheit extern die Nachricht am Anfang mit x Bytes Zufall vor der Verschlüsselung zu expandieren. Da intern ein Feedback existiert würden diese Zufallsbytes als verschlüsselt gespeicherter IV interagieren. Damit hätte man dasjenige IV-Schemata das schon bekannt ist, bei dem ein Zufalls-IV bei der Initialsierung verschlüsselt wird und im Feedback Register landet. Mit diesem Vorgehen ist es wieder so das
DEC eine autom. Vorgabe macht die aber ohne Probleme durch den Anwender mit bischen Aufwand durchaus verbessert werden kann. Und statt nun mit Blockgröße Zufallsbytes seine Nachricht zu expandieren könnte der Anwender auch zb. x * Blockgröße Zufallsbytes benutzen und so weit mehr Sicherheit erreichen als mit normaler IV Benutzung.
2.) Beim Keysetup ist die Sache wiederum anders gelagert. Hier entschied ich mich in den Ciphern kein Preprocessing der Schlüssel mehr zu benutzen. Im
DEC 3 war das der Fall aber die kryptographische Sicherheit wurde damit nicht inkrementiert, eher das Gegenteil es wurde die Verfahrensicherheit reduziert. Stattdessen wird im
DEC 5 sogar die Verfahrensicherheit inkeremeniert da nun wesentich striktere Prüfungen des Schlüssels greifen als im
DEC 3. Zulange Schlüssel werden zb. angemeckert.
Bei Schlüsseln ist es öfters so das sehr unterschiedliche Anforderungen existieren. Manchmal liegen die Schlüssel schon in nutzbarer konvertierter Form vor, also preprocessed, manchmal liegen sie einfach 1 zu 1 vor aber die Anforderungen sind ncht so hoch und wiederum ein anderes mal möchte der Anwender in diesem sensiblem Bereich die absolute Kontrolle und keinerlei Einmischung durch die Cipher selber.
Ergo wurde im
DEC 5 alles das ausgebaut was hilfreich für die Umwandlung von Schlüsseln in Sessionkeys ist und was auch kryptographisch Sinn macht und anerkannt ist. Dh. die Hash Funktionen wurden erweitert um sogenannte KDFs, Schlüsselableitungsfunktionen. Diese sind kryptographisch sicher und am sinnvollsten. Sie wurden dabei so eingebaut das sie in einem einzigen Funktionsaufruf benutzt werden können was die Verfahrenssicherheit drastisch inkrementiert, heist weniger Benutzerfehler durch den Programmierer. Beispiele für deren Benutzung gibts hier im Forum zur Genüge.
Gruß Hagen