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