wenn man den CipherMode cmCTSx/cmCTS8 benutzt kann man am Ende eine CMAC errechnen und abspeichern. Das ist vergleichbar mit den sich gerade in Standardisierung befindelichen Ciphermodis bei AES. cmCTSx/cmCTS8 sind prohibitär das ist richtig. Im Grunde sind es doppelt arbeitende CBC Modis auf Blockgröße oder Bytegröße Feedback. Sie arbeiten wie CBC indem sie die Daten mit dem Feedbackregister vor der Verschlüsselung des Blocks XOR verknüpfen. Nach der Verschlüsselung wird aber nun zusätzlich auch der verschlüsselte Datenblock mit dem Feedback Register XOR verknüpft. So entsteht eine Verknüpfung der Datenblöcke untereinander die 1. von Feedbackregister Startwert abhängt, 2. vom Passwort und dem daraus erzeugten Schlüsselstrom und 3. von den Daten der Nachricht selber da man ja das Verschlüsselungprodukt noch zusätzlich XOR Verknüpft. cmCTS? ist also fast eine Alles oder Nichts Verschlüsselung ohne Selbstsynchronsation. Ändert sich 1 Datenbit mitten in den verschlüsselten Daten so sind alle nachfolgenden Datenblöcke inklusive des aktuellen Datenblockes vernichtet, eg. nicht korrekt entschlüsselbar. Am Ende einer Verschlüselung/Entschlüsselung kann man mit Cipher.CalcMAC eine sogenannte Cipher-MAC errechnen und somit auf Datenintegrität testen. Wie oben angedeutet wird sich die so errechnet CMAC komplett unterscheiden wenn nur 1 Datenbit falsch übertragenm wurde. Ok, da die meisten Cipher mit zb. 8 Bytes Feedbackregster arbeiten ist diese CMAC auch meistens nur 64 Bit groß. Das Kollisionsrisiko im Vergleich zu eienr guten Hash-MAC ist also viel größer. Nutzt man aber zb. einen 16 Bytes Blockcipher so ist das identisch mit einer zb. MD5-HMAC. Aber mit dem Unterschied das diese CMAC Berechnung Performancetechnisch schon inklusive ist.
Stört man sich nicht daran das cmCTS? prohibitär ist und nicht selbstsynchronisierend so dürfte das eine gute Wahl sein, sowohl aus Sicherhsitsaspekten betrachtet wie auch aus Sicht der Performance. Aus kryptrographischer Sicht dürfte somit cmCTS? identisch zu den neueren Ciphermodis sein, eben nur mit dem Unterschied das
DEC diesen Mode schon seit Jahren anbietet und AES sich noch in der Findungsphase befindet. (ich weiß das du, Gammatester, da eine andere Meinung vertrittst
)
Ein weiterer Unterschied, prohibitär natürlich, besteht im Padding. Das neuste
DEC wechselt wenn es padden muß vom Blockorientierten Modus zum Byteorientierten Modus. Ich erachte dies für die sicherste Paddingmethode. Den Byteorientierten Modus, wie zb. cmCBC8,cmCTS8 usw. benutzt man schon seit langer Zeit um sehr kurze und hochsensible Daten zu verschlüsseln, sie sind also anerkannte Verfahren. Sie sind aber bei langen Nachrichten ineffizienter das sie ja zb. bei Blockgröße 16 einen Datenblock insgesamt 16 mal verschlüsseln. Nimt man nun einen anerkannten Blockmodus wie CBC und verschlüsselt den letzten zu kurz geratenen Datenblock im dazu vergleichbaren Byteorientierten Ciphermode so hat man eine gute Methode für ein Padding. Neben viele anderen Vorteilen ergibt sich der Vorteil das man Daten die kürzer sind als die Blockgröße des Ciphers autom. immer im 8Bit Feedbackmodus verschlsüselt, da dieser 1. Datenblock ja auch gleichzetig der zu paddende Datenblock ist. Somit benutzt dieses Paddingschemata auch bei sehr kurzen Datenmengen den sichersten Modus. In keinem der Fälle kommt es zu einer Datenexpansion bei der Verschlüsselung, was enorm von Vorteil ist. Zudem braucht man dann auch nicht mehr spezielle und komplexere Chiphermodis zu impolenetieren das das System meistens immer einen Blockorientierten und Byteorientierten Feedbackmodus anbieten kann.
Also, das was ich im
DEC implementiert habe hat meiner Meinung nach sehr wohl ein kryptographisch sauberes Fundament, nur mit dem Unterschied das
DEC sowas schon seit längerer Zeit anbietet und die neueren Standards längst noch nicht in der Praxis angekommen sind. Verfolgt man den AES Zertifizierungsablauf bei den Ciphermodis über längere teit so wird man feststellen das von den vielen vorgeschlagenen Ciphermodis sehr viele in kürzester Zeit als unsicher bewiesen wurden. Das Komen und Gehen in diesem Sektor ist nach meinem Gefühl viel stärker als bei der Auswahl geeigneter Verschlüsselungsalgorithmen, also beim AES Rijndael. Das suggeriert wenig Vertrauen.
Ich werde diese Modis noch einbauen, mit Sichereit, aber erst wenn diese neuen Modis in der Praxis auf breite Akzeptanz gestoßen sind. Das heist ganz im Besondern das ich eben nicht EAX einbauen werde solang nur spezielle Produkte diesen unterstützen, womöglich nur diejenigen Produkte die den EAX entwickelt und vorgeschlagen haben.
Gruß Hagen