Problem mit Umstellung DEC 3 nach DEC 5.2

[Twigeater]

Hallo!

War bisher nur gelegentlicher Beobachter eures Forums, jetzt hab ich da aber ein Problem bei dessen Lösung mir vielleicht hier jemand helfen kann.

Wir verwenden bisher DEC 3 zur Verschlüsselung (Details s.u.) von nicht wirklich kritischen Informationen und möchten nun auf 5.2 umstellen (alles noch in D7). Vorgabe ist das die bereits verschlüsselten Dateien weiterhin lesbar sein müssen und auch neu codierte in alten Programmen funktionieren. Das hat auch mit den diversen Hinweisen in diesem Forum gut funktioniert, insbesondere 'Umstellung DEC 3.0 auf 5.2' war sehr hilfreich. Danke schon mal dafür.

Nun hab ich meine Unit Tests (Verschlüsseln mit 3+5 und Ergebnis in HEX vergleichen) erweitert und das hat ein Problem aufgedeckt, das ich vorher nicht gesehen hatte. Haben die Eingangsdaten eine bestimmte Größe ist das Ergebnis ziwschen 3+5 unterschiedlich. Das tritt zum ersten mal auf wenn die Daten zwischen 138 und 143 Bytes lang sind und wiederholt sich ab da dann in einem Muster das ich noch nicht erkenne. Dazwischen funktioniert aber alles wunderbar. Das paarweise Ver-/Entschlüsseln innerhalb jeder Version funktioniert unabhängig von der Länge immer einwandfrei.

Wäre toll wenn jemand eine Idee hätte.

Matthias


Hier der Code aus 3 (etwas vereinfacht):

Delphi-Quellcode:

function Decode(const aSomeText : AnsiString) : string;
var 
  cipher : TCipher_Blowfish;
  b      : string;
begin
  cipher := TCipher_Blowfish.Create('abcedefghijk', nil);

  try
    b := cipher.DecodeString(aSomeText);
    result := TStringFormat_HEX.StrTo(PChar(b), length(b));
  finally
    cipher.Free();
  end;
end;

Hier meine Anpassung an 5.2 (etwas vereinfacht):

Delphi-Quellcode:

function Decode(const aSomeText : AnsiString) : string;
var
  cipher   : TCipher_Blowfish;
  I        : Integer;
  hash     : THash_RipeMD256;
  IVector  : Binary;
  password : Binary;
  b        : Binary;
begin
  cipher := TCipher_Blowfish.Create();
  cipher.Mode := cmCTSx;

  hash := THash_RipeMD256.Create;
  try
    hash.Init;
    password := 'abcedefghijk';
    hash.Calc(password[1], length(password));
    hash.Done;

    I := hash.DigestSize;
    if I > cipher.Context.KeySize then I := cipher.Context.KeySize; {generaly will truncate to large Keys}

    cipher.Init(Hash.Digest^, I, IVector[1], 0);

    b := cipher.DecodeBinary(aSomeText);

    result := TFormat_HEX.Encode(b[1], length(b));
  finally
    cipher.Free();
    hash.Free();
  end; 
end;

[Assertor]

Hi Twigeater,

Zitat von Twigeater:

War bisher nur gelegentlicher Beobachter eures Forums, jetzt hab ich da aber ein Problem bei dessen Lösung mir vielleicht hier jemand helfen kann.

Erstmal ein verspätetes herzlich Willkommen im Forum!

Zitat von Twigeater:

Das hat auch mit den diversen Hinweisen in diesem Forum gut funktioniert, insbesondere 'Umstellung DEC 3.0 auf 5.2' war sehr hilfreich. Danke schon mal dafür.

Das freut zu hören!

Zitat von Twigeater:

Nun hab ich meine Unit Tests (Verschlüsseln mit 3+5 und Ergebnis in HEX vergleichen) erweitert und das hat ein Problem aufgedeckt, das ich vorher nicht gesehen hatte. Haben die Eingangsdaten eine bestimmte Größe ist das Ergebnis ziwschen 3+5 unterschiedlich. Das tritt zum ersten mal auf wenn die Daten zwischen 138 und 143 Bytes lang sind und wiederholt sich ab da dann in einem Muster das ich noch nicht erkenne. Dazwischen funktioniert aber alles wunderbar. Das paarweise Ver-/Entschlüsseln innerhalb jeder Version funktioniert unabhängig von der Länge immer einwandfrei.

Ich kann leider nicht viel zur DEC3 sagen, aber ich vermute mal daß hier ein entsprechende Änderung beim Padding der Eingangsdaten vorliegt (hab ich im anderen Thread ja auch schon geschrieben).

Ich verstehe jetzt aber noch nicht ganz, was Du machen möchtest. Du verschlüsselst im Unit Test mit DEC3 und danach mit DEC5 und vergleichst die Ergebnisse (hierbei wäre das Problem wahrscheinlich klar: Unterschiedliches Padding)? Wie schaut so ein unterschiedliches Ergebnis denn beispielsweise aus?

Gruß Assertor

[Twigeater]

Hallo!

Wollte gerade auch meine neuesten Erkenntnisse los werden, aber zuerst mal zu deinen Fragen:

Situation ist das wir seit vielen Jahren und bis heute mit 3.2 gearbeitet haben. Deshalb ist es einfach so das es viele verschlüsselte Dateien gibt, die auch nach einer Umstellung lesbar sein müssen. Vor der Umstellung habe ich deshalb UnitTests gemacht mit denen ich prüfen kann ob alles was wir mit 3 gemacht haben, auch wieder mit 5.2 geht. Durch Anpassung einiger Unit-/Klassennamen kann ich beide Version direkt vergleichen.

Der einfachste Testfall den ich jetzt habe ist der Input '12' der in 3 zu '4459' wird, in 5.2 zu '44BC' (mit dem Code oben).

Deine Vermutung mit dem Padding ist (soweit ich das verstehe) auch meine Erkenntnis. Nach einigen Untersuchung der internen Variablen zeigte sich das es zu Unterschieden kommt wenn die Eingangsdaten nicht Vielfaches der Blockgröße sind. Der Fall wir in 5.2 beim Cipher Mode 'cmCTSx' mit Padding bedacht, was in 3 anders war.

Nachdem ich alle Dinge bei mir durchgetestet habe, habe ich dann irgendwann mal testweise in der Unit 'DECCipher' von 5.2 in der Prozedur 'DecodeCTSx' den Aufruf bei 'if Size > 0 then' von 'DecodeCFS8' durch 'DecodeCFSx' ersetzt, was dann wieder das 3er Verhalten brachte. Ist aber nichts was ich so lassen will, zeigt mir aber das wohl dort die Ursache der Inkompatibilät liegt.

Da das ganze aber nicht mein Fachgebiet ist bin ich mir nicht sicher ob die Schlussfolgerung richtig ist und ob und wenn ja wie ich das ganze ohne Änderung an der Bibliothek hin bekomme.

Matthias

[Assertor]

Hi,

Zitat von Twigeater:

Deine Vermutung mit dem Padding ist (soweit ich das verstehe) auch meine Erkenntnis. Nach einigen Untersuchung der internen Variablen zeigte sich das es zu Unterschieden kommt wenn die Eingangsdaten nicht Vielfaches der Blockgröße sind. Der Fall wir in 5.2 beim Cipher Mode 'cmCTSx' mit Padding bedacht, was in 3 anders war.

Nachdem ich alle Dinge bei mir durchgetestet habe, habe ich dann irgendwann mal testweise in der Unit 'DECCipher' von 5.2 in der Prozedur 'DecodeCTSx' den Aufruf bei 'if Size > 0 then' von 'DecodeCFS8' durch 'DecodeCFSx' ersetzt, was dann wieder das 3er Verhalten brachte. Ist aber nichts was ich so lassen will, zeigt mir aber das wohl dort die Ursache der Inkompatibilät liegt.

Ja, ist absolut nachvollziehbar bisher.

Zitat von Twigeater:

Da das ganze aber nicht mein Fachgebiet ist bin ich mir nicht sicher ob die Schlussfolgerung richtig ist und ob und wenn ja wie ich das ganze ohne Änderung an der Bibliothek hin bekomme.

Na, die Schlussfolgerung ist schon richtig. Aber ohne Änderung an der Datei kannst Du das wohl nicht umsetzen. Ich hab den Source gerade nicht hier, glaube aber nicht, daß diese Funktionen in der Basisklasse virtuell sind. Da die DEC5 eine vollständige Neukonzeption der alten DEC war und Hagen Strukturänderungen, Verbesserungen und Fixes vorgenommen hat, sind diese Stellenweise inkompatibel. Das ist unvermeidbar gewesen.

Wie im anderen Thread angedeutet, würde ich den Weg wählen, die Daten zu konvertieren (DEC3 -> DEC5), anstatt die DEC 5.x "umzumodeln" um mit der DEC 3 kompatibel zu sein. In Produktivsoftware ließe sich dies durch Update/Servicereleases lösen (oder z.B. ein externe DLL, die für die DEC3-Daten da ist wenn Ihr auf D2009 umstellt). Den Rest dann per Prefix o.ä.

Ich hoffe die Anregungen helfen Dir trotzdem etwas weiter. Empfehlung zur Sourceanpassung der DEC 5.2 für diesen Sonderfall möchte ich nicht geben, auch wenn Dein o.g. Vorgehen scheinbar richtig ist. Die Auswirkungen könnten weitreichender sein und mögliche Risiken enthalten, die dann unter Umständen von vielen Nutzern leider so genutzt würden.

Gruß Assertor

[Twigeater]

Hallo!

Ich gebe dir absolut Recht. Die Änderung war ausschließlich um zu sehen ob meine Schlussfolgerung soweit richtig war. Hagens Werk ist so genial das ich das auch nur äußerst ungern gemacht habe und das niemals in einer produktiv Version machen würde.

Was wir nun machen werden muss ich mal ausdiskutieren. Ändern der vorhandenen, verschlüsselten Dateien ist sehr, sehr schwierig. Mal sehen...

Auf jeden Fall vielen Dank. Du warst eine große Hilfe.

Matthias

[negaH]

Letzendlich zählt das Ziel und die Deadline. Ich finde ein ummotscheln in solchen Fällen als gerechtferigt.

Das Problem liegt im Padding. DEC 3.x benutzt ein "Cipher Text Stealing" dh. es wird der Cipher Text des Feedback Registers benutzt um den letzten unvollständigen Datenblock aufzufüllen. Nun, damals vor 5-7 jahren war das anerkannte Praktik in der Kyptographie. Heute, mit DEC 5 ist man schlauer und weiß das es zwar nicht zwangsläufig kryptographisch unsicher ist aber das es bessere Alternativen gibt. In DEC 5 wird der Ciphermode für den letzten unvollständigen Datenblock von Blockgröße auf Bytegröße umgeschaltet. Und das ist auch rchtig so nach meiner Ansicht. Denn stellen wir uns mal vor wir benutzen einen festen IV=Initvector, also mit bekanntem Inhalt. Nun möchten wir zb. Passwörter verschlüssen. Diese sind kürzer als die zb. 8 oder 16 Bytes Blockgröße des Ciphers. Beim Cipher Text Stealing greift also schon beim ersten Datenblock das Cipher Text Stealing. Das bedeutet das dort in die Berechnungen der extern bekannte IV mit eingerechnet wird. Sowas ermöglicht Angriffe. Beim DEC 5 würde dieser erste und zugleich auch letzte Datenblock statt mit 8/16 Bytes truncated in einem 1 Bytes Feedback Modus vollständig verschlüsselt. Das ist wesentich sicherer da ein Feedbackmodus mit 1 Byte eben Daten die auf 8 Bit Grenzen ausgerichtet sind ohne Padding verschlüsseln kann.
Normalerweise ist es bei "anerkannten" Libraries sogar der Fall das der Anwender dieser Libraries, also wir, uns selber um das Padding kümmern müssten. Dh. in solchen Libs ist es üblich garkein automatisches Padding anzubieten. So ein Vorgehen einer Lib kam aber fürs DEC nicht in Frage da dessen Anwender eben keine Kryptoprofis sind. Ich war also beim DEC in einer Zwickmühle bei der Entscheidung wie mache ich es richtig, und ich musste die Entscheidung welches Padding final benutzt wird für diese Anwender treffen oder aber alle möglichen Paddingschematas in advance schon ins DEC integrieren. Das ist aber unmöglich da es viele davon gibt und imer neuere neu erfunden werden. Ergo: die Lösung ab DEC 5 mit dem Umschalten in einen höherauflösenden schon vorhandenen Ciphermode. Das lässt folgende Alternativ offen:
Der Programmierer verschlüselt mit DEC 5 und zb. cmCTSx erstmal die Nachricht soweit wie sie ganze Cipherblöcke enthält. Die restlichen Bytes kleiner Cipher Blockgröße muß er nun manuell verschlüsseln. Dazu baut er im Falle des DEC 3 einfach das Ciphertext Stealing nach.
Es ist also so das wenn die Nachricht exakt ein Mehrfaches der Blockgröße ist DEC nie irgendein Padding anwendet. Wenn der Anwedner also vor der Verschlüsselung seine Nachticht von Hand mit einem x-beliebigen Paddingverfahren schon gepaddet hat dann greift die Verschlüsselung vom DEC nicht ein. Ergo: mit DEC kann man jedes beliebige Padding extern benutzen, macht man es nicht so greift transparent und automatisch das DEC Padding Schemata.

Kryptographisch könnte man den "Beweis" pro DEC 5's Vorgehen so formulieren:

1.) Ciphermode = Blockmode wird als insich sicher angenommen für Daten mit Merhfaches an Blockgröße Datenlänge
2.) Ciphermode = Bytemode wird als insich sicher angenommen für Daten mit Mehrfaches an Bytegröße Datenlänge
ergo:
Kombination aus beiden muß sicher sein.

Gegen das Padding spricht also vieles da dort bekannte Daten nach bekanntem Muster zusätzlich, quasi von Außen und bekannt für Angreifer mit in die Berechnungen der letzten gepaddeten Datenblöcke einfließen. Ganz im Gegensatz zur gewählten Methode im DEC 5.
Zudem unterstützen fast alle Libs sowohl den Block- wie auch Byteorientierte Ciphermodis. Mit DEC 5's Vorgehen steigt also die Kompatibilität ohne Sicherheitseinbusen solange die implementierten Ciphermodis kompatibel sind. Man verschärft also nicht das Problem der unterschiedlichen Paddingverfahren sondern würde es mit diesem Vorgehen sogar beseitigen. Deswegen habe ich mich entschieden im DEC 5 eine solche Inkompatibilität zum DEC 3 absichtlich in Kauf zu nehmen.

Gruß Hagen

[negaH]

Ü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

[Twigeater]

Hallo Hagen!

Es zeigt wieder das sich die Welt zum Glück noch weiter dreht und wir alle immer klüger werden (hoffentlich).

Änderungen in Standarbibliotheken mag ich überhaupt nicht weil man sich ab da an scheut Updates einzuspielen, was gerade bei deiner Lib fatal sein könnte.

Danke und frohes Schaffen

Matthias

[negaH]

Danke für das Kompliment also ich meine das du das DEC als "Standardbibliothek" bezeichnest.

Um DEC3 kompatibel zu werden solltest du sowieso dessen Padding Schemata extern realisieren. Die Modifizierung vom DEC5 wie oben vorgeschlagen ist sowieso nicht korrekt. Testen kannst du dies am besten wenn du Nachrichten mit weniger als 8 oder 16 Bytes verwendest, also kleiner Cipher.BufferSize. Im Grunde kopierst du für den letzten Datenblock einfach Bytes aus dem Feedback Register, des in diesem Falle den IV enthält.

Empfehlen würde ich dir dem Vorschlag eine Konvertierung zu benutzen zu folgen. Das DEC5 Padding erachte ich als für viel sicherer. Für die Verschlüsselung von Passwörtern würde ich sowieso immer einen 8Bit Ciphermode empfehlen, aber nicht jeden !

Gruß Hagen

[Assertor]

Hi Hagen,

schön von Dir hier zu lesen! Danke für die Hintergrundinformationen zu dem Thema - zum Glück lag ich ja bezüglich des Paddings nicht daneben

Gruß Assertor