Dateien verschlüsseln - aber wie?

[daniel-volk]

So,
ich hab hier mal die erste Beta meines Verschlüsselungsprogs CryptMaster.
Bis jetzt kann man nur Texte ver- und entschlüsseln, dafür aber - hoffentlich - sehr sicher!
Ich arbeite mit folgenden Mitteln:
DEC von Hagen (öffentliche Version)
Cipher: Rijndael
Hash: SHA1
Mode: CTS

Bevor der Klartext verschlüsselt wird, wird erst noch ein Zufallsstring der Länge "BufSize" vorne angehängt.
Anschließend wird beides verschlüsselt.
Nachdem alles verschlüsselt ist, wird noch der Original-Hashwert des Klartextes vorne angehängt und fertig.

Die Entschlüsselung geht genau umgekehrt.

Testet also bitte alle mal den CryptMaster und sagt mir, wie ihr das GUI etc findet!

@Hagen:
So, nun mal an den Experten:
Mein vorläufig verwendeter Code sieht so aus. Meiner Meinung nach sollte das zu einer maximalen Sicherheit führen, aber ich bin eben nur Amateur in Sachen Verschlüsselung.

Delphi-Quellcode:

const
  EXTENSION = '.cryptmaster';
  APPNAME = 'CryptMaster';
  APPVER = 'Beta 1';
  DefCipherClass : TCipherClass = TCipher_Rijndael;
  DefHashClass : THashClass = THash_SHA1;
  DefStringFormat = fmtMIME64;
  DefCipherMode = cmCTS;

implementation

{$R *.dfm}

// Function zum Generieren der Zufallswerte
function TFrmCipher.RandomString(Len: Integer): String;
begin 
  SetLength(Result, Len); 
  Rnd.Buffer(Result[1], Len);
end;

// function zum Verschlüsseln von Text
function TFrmCipher.EncodeString(Klartext, Passwort : string) : string;
var
  Hashstring : string;
begin
  with DefHashClass.Create(nil)
  do begin
      try
       HashString := CalcString(Klartext,nil,DefStringFormat);
      finally
       Free;
      end;
     end;
  with DefCipherClass.Create('',nil)
  do begin
      try
       Mode := DefCipherMode;
       HashClass := DefHashClass;
       InitKey(Passwort,nil);
       Result := CodeString(RandomString(BufSize)+Klartext,paEncode,DefStringFormat);
       Result := HashString+Result;
      finally
       Free;
      end;
     end;
end;

// String dekodieren | Result[1] (0,1) gibt an, ob es einen Fehler gab
function TFrmCipher.DecodeString(Ciphertext,Passwort : string):string;
var
  Hashlength : word;
  OldHash, NewHash : string;
begin
  with DefHashClass.Create(nil)
  do begin
       try
         Hashlength := length(CalcString(Ciphertext,nil,DefStringFormat));
       finally
         Free;
       end;
     end;
  OldHash := Copy(Ciphertext,1,Hashlength);
  Delete(Ciphertext,1,Hashlength);
  with DefCipherClass.Create('',nil)
  do begin
      try
       Mode := DefCipherMode;
       HashClass := DefHashClass;
       InitKey(Passwort,nil);
       Result := CodeString(Ciphertext,paDecode,DefStringFormat);
       Delete(Result,1,BufSize);
      finally
       Free;
      end;
     end;
  with DefHashClass.Create(nil)
  do begin
       try
         NewHash := CalcString(Result,nil,DefStringFormat);
       finally
         Free;
       end;
     end;
  If OldHash = NewHash
  then Result := '1'+Result
  else Result := '0'+Result;
end;

Wie bewertest du diesen Code?

Thx,
Daniel.

PS: @Hagen:
Würde es dir etwas ausmachen, wenn ich dir meinen fertigen Sourcecode (sofern er denn mal irgendwann fertig ist) demnächst zur Kontrolle zuschicke? Bevor ich das Ding mit der Definition "sehr sicher" - möchte nämlich mit die sicherste Freeware-Verschlüsselungssoftware schreiben - auf die Leute loslasse, hätte ich das schon gerne nochmal überprüft.

[negaH]

Zitat:

Nachdem alles verschlüsselt ist, wird noch der Original-Hashwert des Klartextes vorne angehängt und fertig.

Wie bewertest du diesen Code?

Nun diese Frage hätte ich so nicht gestellt an deiner Stelle, nun antworte ich auch offen.

1.) deine Einrückungen im Source sind Mist
2.) deine Zeilenumbrüche bei den "with do", "if thens" usw. sind Mist, die Befehle gehören in eine Zeile, nur ein "Begin end" Block wird ZWEI Zeichen eingerückt. Dafür gibt es die "Begin end" Blöcke.

3.) das Protokoll deiner Verschlüssung erlaubt Angriffe die nicht sein müssten.

In einem der vorherigen Postings nahm ich an das du die Message vorne mit Zufallsbytes expandierst, dann einen Hash darüber erzeugst in vor die Message hängst und dann alles verschlüsslst. Diese Annahme war ja bekanntlich falsch, hatte aber ihre Gründe.

Denn in deinem Verfahren ist der Hash unverschlüsselt und wird somit für den Angreifer lesbar.
Dieser macht nun folgendes bei zb. 8 Bytes kurzen Messages. Er erzeugt alle möglichen Zufallsbytes = 2^64 Kombinationen. Nun erzeugt er alle 2^64 möglichen Message Kombinationen und hat nun die Möglichkeit ein Dictionary zu allen Kurzen Passwörtern anzulegen. Nur anhand deines Hashes besteht nun die Möglichkeit die Message aus der Datenbank zu finden und das dazugehörige Passwort.

Die Kombinationsvielfalt von 2^64 ist viel zu gering. Erst ab 2^128 wird es unpraktikabel.
Du solltest tatsächlich den Hash mitveerschlüsseln da er sowieso erst relevant wird wenn die Message wieder entschlüsselt wird. Da der Hash aber in jedem Falle eine "Verknüpfung" zu den Daten hat, heist das auch wenn er sicher ist er denoch bestimmte Dictionary Angriffe ermöglicht wenn er nicht geschützt wird. Also: Hash + 128 Bit Zufall + Message verschlüsseln. Wäre der Hash eine verkürzte Prüfsumme, zB. 32 Bit, so könnte man diese auch unverschlüsselt speichern, warum ??
Das besondere eines Hashes ist es das die durch ihn erzeugten "Prüfsummen" mit enorm hoher Wahrscheinlichkeit exakt eine Nachricht identifizieren. (stimmt nur praktisch aber nicht theoretisch, aber egal). Eine 32 Bit Prüfsumme im Vergleich zu einem 128 Bit hash, würde demnach 2^(128 -32) = 2^96 mal mehr Prüfsummen erzeugen die zu jeweils verschiedenen Nachrichten trotzdem gleich wären. D.h. bei 2^128 verschiedenen Nachrichten a 128 Bit, erzeugt eine Hashfunktion exakt 2^128 verschiedne Prüfsummen, eine 32 Bit Prüfsumme würde aber für jede der 2^32 möglichen Prüfsummen jeweils 2^96 verschiedene Messages zulassen. Ein kurze Prüfsumme wäre demnach NICHT mehr eindeutigt und ein Angreifer hat nicht mehr die Chance auf grund der Prüfsumme eine eindeutige Nachricht zuzuordnen. Kryptographisch gesehen verkehrt sich das Verhältnis von BitSize zu Sicherheit aus ins Gegenteil.

Ich hoffe mal das man diesen komplizierten Ausführungen noch folgen konnte.

Gruß Hagen

[daniel-volk]

Doch doch,
ich konnte dir sehr gut folgen. Dann werde ich den Code mal so umstellen, dass der Hash-Wert mitverschlüsselt wird. Hier war das ja mit dem Random nicht schwer, aber wie mace ich das mit dem Random bei Files? Luckie hat ja schon seinen Code veröffentlicht, bei dem in den Files dann noch die Hash-Werte gespeichert werden. Aber eben auch im Header und somit inverschlüsselt! Ist das akzeptabel?
Files sind ja meist so lang, dass ein Hashwert nicht mehr viel Aufschluss geben kann, oder?

Und welche Funktion muss ich nutzen, um meinen Files vor dem Verschlüsseln noch Zufallsbytes hinzuzufügen? Ich werde als Grundlage für die Verschlüsselung wohl Luckies erste Veröffnetlichung nehmen.

Noch etwas zu AES-Verfahren im DEC:
1) Du sagtest mal, dass da ein Fehler sei. Beeinträchtigt der die Sicherheit oder wozu führt der?
2) Mit wieviel Bit arbeitet die AES-Verschlüsselung im DEC?

THX,
Daniel.

[daniel-volk]

Ein Mann, ein Wort...

Hier ist der veränderte Code:

Delphi-Quellcode:

const
  EXTENSION = '.cryptmaster';
  APPNAME = 'CryptMaster';
  APPVER = 'Beta 1';
  DefCipherClass : TCipherClass = TCipher_Rijndael;
  DefHashClass : THashClass = THash_SHA1;
  DefStringFormat = fmtMIME64;
  DefCipherMode = cmCTS;
  CipherTextBegin = '[BEGIN-CryptMaster-Message]';
  CipherTextEnd = '[CryptMaster-Message-END]';

implementation

{$R *.dfm}

// Function zum Generieren der Zufallswerte
function TFrmCipher.RandomString(Len: Integer): String;
begin
  SetLength(Result, Len);
  Rnd.Buffer(Result[1], Len);
end;

// function zum Verschlüsseln von Text
function TFrmCipher.EncodeString(Klartext, Passwort : string) : string;
var
  Hashstring : string;
begin
  with DefCipherClass.Create('',nil) do
    begin
      try
       Mode := DefCipherMode;
       HashClass := DefHashClass;
       InitKey(Passwort,nil);
       Klartext := RandomString(BufSize)+Klartext;
       with DefHashClass.Create(nil) do
         begin
           try
             Hashstring := CalcString(Klartext,nil,DefStringFormat);
           finally
             Free;
           end;
         end;
       Klartext := Hashstring+Klartext;
       Result := CodeString(Klartext,paEncode,DefStringFormat);
     finally
       Free;
     end;
   end;
  // Marker für den Ciphertext setzen
  Result := CipherTextBegin+Result+CipherTextEnd;
end;

// String dekodieren | Result[1] (0,1) gibt an, ob es einen Fehler gab
function TFrmCipher.DecodeString(Ciphertext,Passwort : string):string;
var
  Hashlength : word;
  OldHash, NewHash : string;
  RemBufSize : Int64;
begin
  // Marker für den Ciphertext entfernen
  Delete(Ciphertext,1,pos(CipherTextBegin,Ciphertext)+length(CipherTextBegin)-1);
  Delete(Ciphertext,pos(CipherTextEnd,Ciphertext),length(Ciphertext)-pos(CipherTextEnd,Ciphertext)+1);
  with DefHashClass.Create(nil) do
    begin
       try
         Hashlength := length(CalcString(Ciphertext,nil,DefStringFormat));
       finally
         Free;
       end;
     end;
  with DefCipherClass.Create('',nil) do
    begin
      try
       Mode := DefCipherMode;
       HashClass := DefHashClass;
       InitKey(Passwort,nil);
       Result := CodeString(Ciphertext,paDecode,DefStringFormat);
       RemBufSize := BufSize;
      finally
       Free;
      end;
     end;
  OldHash := Copy(Result,1,Hashlength);
  Delete(Result,1,Hashlength);
  with DefHashClass.Create(nil) do
    begin
       try
         NewHash := CalcString(Result,nil,DefStringFormat);
       finally
         Free;
       end;
     end;
  Delete(Result,1,RemBufSize);
  If OldHash = NewHash then Result := '1'+Result else Result := '0'+Result;
end;

MfG,
Daniel.

[daniel-volk]

Hi Hagen,

mir ist gerade etwas aufgefallen:
Auch Steganos 5 arbeitet mit AES und SHA1! Hab ich wohl 'ne gute Wahl getroffen.

Aber mal was Anderes dazu: Steganos verwendet doch Live-Encryption. Dabei werden die Daten immer nur beim Lesen entschlüsselt, was dann voraussetzt, dass auch immer nur einzelne Dateiteile gelesen werden.
Und das wiederum bedeutet doch, dass Steganos wahrscheinlich mit ECB oder so arbeitet, nicht aber mit CTS! Sie werden also auch keine Zufallsbytes anhängen, weil das dann nichts mehr bringt.

Wenn ich somit ohne Random arbeite (bei den Files) aber mit CTS, dann müssten Known-Plaintext-Angriffe bei mir doch immer noch schlechter durchzuführen sein, als bei Steganos, oder? Und das wiederum würde bedeuten, dass ich ruhig auf Random verzichten kann, denn Steganos wird ja wohl schon sicher genug sein!
Wenn ich jetzt ECB (oder wie das auch immer heißt) verwenden würde (ohne Random), würde das weniger Sicherheit bieten als CTS?

Wie kann ich eigentlich mit den DEC eine Datei wipen? Geht das mit dem Code:

Delphi-Quellcode:

with DefCipherClass.Create('',nil) do
begin
  Mode := mdCTS;
  HashClass := DefHashClass;
  InitKey('',nil);
  CodeFile(Filename,paWipe,nil);
  DeleteFile(Filename);
end;

Oder muss ich das irgendwie anders machen?

MfG,
Daniel.

[negaH]

Zitat:

Wenn ich somit ohne Random arbeite (bei den Files) aber mit CTS, dann müssten Known-Plaintext-Angriffe bei mir doch immer noch schlechter durchzuführen sein, als bei Steganos, oder? Und das wiederum würde bedeuten, dass ich ruhig auf Random verzichten kann, denn Steganos wird ja wohl schon sicher genug sein!
Wenn ich jetzt ECB (oder wie das auch immer heißt) verwenden würde (ohne Random), würde das weniger Sicherheit bieten als CTS?

Ich weiß nicht ob Steganos mit ECB arbeitet, kann es mir nur schwer vorstellen. Sollte es so sein dann hätten die Designer einen groben Fehler gemacht.
Der Zufallswert expandiert nur die Nachricht, es können also auch andere Ciphermodes angewendet werden die "seekable" sind. Ich glaube aber nicht das Steganos "wahlfreien" Zugriff bei der Entschlüsselung ermöglicht. So gut ist Steganos nun auch wieder nicht.

Es gibt Ciphermodes die genauso sicher wie CTS/CBC sind und dennoch wahlfreien Zugriff auf die Daten während der Entschlüsselung bieten. Z.b. der CTR=Counter Modus. Dabei wird jeder Block der Verschlüsselung durchnummeriert. Intern wird ein zB. 64/128 Bit Zähler mitgeführt, als IV sozusagen, und die Nummer des Blockes draufaddiert. Nun hat man den IV berechnet der zu dem Block gehört. Da der Counter sich so von Block zu Block immer erhöht hat jeder Block seinen eigenen Counter, ist aber NICHT abhänig von vorherigen Blöcken. Dieser CTR Mode ist ein Vorschlag bei der AES Auswahl der zukünftigen Standard Ciphermodes. Der Startcounter beim CTR sollte nur einmal verwendet werden !

Ich persönlich würde dennoch mit CTS arbeiten, da er durch seine Eigenschaften eine Alles oder Nichts Entschlüsselung ermöglicht. Dies ist das algorithmisch gesehen höchste Maß an Sicherheit.
Auch der CTS ermöglicht eine Live-Ver-/Entschlüsselung, aber eben nur sequentiell vom ersten Block zum letzten Block der Message.

Allerdings ist CTS in keinster Weise ein Standardmodus, sondern ein von mir entwickelter "Doppel-Feedback" Modus. D.h. meine Änderungen sind so gemacht das sie einen CBC Modus erweitern um einen "Doppelt-CBC-Modus" zu bekommen. Wenn also der CBC Modus als sicher gilt so muß es auch der CTS Modus sein. CBC ist ein sehr anerkannter Standardmodus. Diese "Design" Philosophie musste ich benutzen damit CTS sicher bleibt/wird, denn ich selber habe nicht die Resourcen um effektiv zu beweisen das CTS wirklich sicher ist.

Was macht CTS ?
CBC verknüpft per XOR das Feedbackregister mit den Datenblock der verschlüsselt werden soll. Danach wird der Datenblock verschlüsselt und ins Feedbackregister kopiert.
CTS macht das gleiche, aber statt Kopieren wird das Feedbackregister wiederum XOR verknüpft mit dem nun verschlüsselten Datenblock.
Das Feedbackregister enthält am Schluß im CTS Modus die XOR Verknüpfungen der Daten vor Verschlüsseung mit der XOR Verknüpfung der Daten nach der Verschlüsselung ALLER Datenblöcke.
Im CBC Modus enthält das Feedbackregister am Schluß den letzten verschlüsselten Datenblock.

Hier erkennt man die Eigenschaft der "Error-Propagation" des CTS Modus, denn das letzte Feedbackregister ist sozusagen die XOR Summe aller Blöcke + deren Verschlüsseltes Produkt in verschlüsselter Form. Eine einzigste Fehlerbit-Änderung würde damit vollständig die nachfolgenden Blöcke zerstören.

Die Gegenüebrstellung der Modis sieht so aus:

Zitat:

IV = initialization Vector
c() = verschlüsslungsfunktion eines Blockes
Cx = Ciphertext des x. Blockes, die verschl. Message besteht aus C1...Cx
Dx = Plaintext des x. Datenblockes, die Message besteht aus D1..Dx
F = Feedbackregister

CBC-Modus

C0 = IV
C1 = c(C0 xor D1)
C2 = c(C1 xor D2)
C3 = c(C2 xor D3)
C4 = c(C3 xor D4)

CTS-Modus

C0 = IV
C1 = c(C0 xor D1)
C2 = c(C0 xor C1 xor D2)
C3 = c(C0 xor C1 xor C2 xor D3)
C4 = c(C0 xor C1 xor C2 xor C3 xor D4)

verkürzt und intern in meinen Ciphern benutzt siehts so aus:

F = IV
C1 = c(F xor D1); F = F xor C1; // F == C0 xor C1
C2 = c(F xor D2); F = F xor C2; // F == C0 xor C1 xor C2
C3 = c(F xor D3); F = F xor C3; // F == C0 xor C1 xor C2 xor C3
C4 = c(F xor D4); F = F xor C4; // F == C0 xor C1 xor C2 xor C3 xor C4

F = Cipher-Message-Authentication-Code

CBC-Mode

F = IV
C1 = c(F xor D1); F = C1;
C2 = c(F xor D2); F = C2;
C3 = c(F xor D3); F = C3;
C4 = c(F xor D4); F = C4;

F = letzter verschlüsselter Block

vollständige Formel für C3 ist:

CTS-Mode

C3 = c(IV xor D3 xor c(IV xor D2 xor c(IV xor D1)) xor c(IV xor D1))

CBC-Mode

C3 = c(c(c(IV xor D1) xor D2) xor D3)

Man sieht sehr schön um wie vieles stärker der CTS Modus sein muß, obwohl nur eine einzigste Operation verändert wurde. Statt F = Cx, eben F = F xor Cx !

Im CBC Mode wird nur der 1. Datenblock mit dem Zufalls-IV verknüpft.
Im CTS Mode werden ALLE Datenblöcke mit dem IV verknüpft.
Im CBC Mode wird nur der vorherige verschlüsselte Block mit dem aktuellen Block verknüpft.
Im CTS Mode werden ALLE vorherigen verschlüsselten Blöcke mit dem aktuellen Block verknüpft.

Wie gesagt ich meine das ich NICHT der absolute Kryptoguru bin und nicht die Fähigkeiten besitze um sagen zu können das meine Analysen was taugen. Jeder sollte sich selber ein Bild über CTS machen, und darüber selber nachdenken ob CTS nun besser als CBC ist. Ich persönlich bin davon überzeugt das er um vielfaches besser ist als CBC.

Gruß Hagen

[daniel-volk]

@ Hagen:

Erst einmal danke für deine sehr anschaulichen Formeln!
Aber meine (eigentlich recht guten da Mathe-Leistungskurs und Informatik) mathematischen Kenntnisse lassen mich doch etwas an CTS zweifeln.
Ich CBC wird jeweils auch der Cipherblock des vorherigen Datenblockes "mitgenommen".
Dieser enthält nun wiederum Infos über den davor usw.
Es ist somit klar, dass auch bei CBC die Infos des ersten Blockes bis zum Schluss - wenn auch nur geringfügig - mitgetragen werden.

Im CTS-Modus erfolgt dieses Mittragen sehr viel intensiver, und gerade dass führt zu meinem Zweifel:
Erst einmal ein kurzes Beispiel dazu:

Wenn ich 13 xor 55 xor 255 xor 3 xor 54 rechne, dann kommt da 240 raus.
Rechne ich jetzt 240 xor 13, dann gibt das 253 und das ist wiederum = 55 xor 255 xor 3 xor 54 .

Soll heißen:
Wenn ich bei einer noch so langen XOR-Rechnung einen Wert zweimal einbeziehe, dann wird er eliminiert. Wird auch hierdurch klar: Y xor Y = 0 bzw: Y xor Y xor X = X

Der Random-Block, der ja nun der erste ist, befindet sich nun im Feedbackregister und wird somit auf den Block 2 angewendet. Das Ergebnis davon gelangt jetzt wieder in abgewandelter Form in das Feedbackregister: ==> Im Feedbackregister befindet sich indirekt der Random-Block 0 zweimal!
Somit hat er eventuell auf Block 3 keine Auswirkung mehr! Lediglich in Block 4 wäre wieder eine Auswirkung gegeben, da hier der Random-Block 0 dreimal vorkäme.

Diese Problematik solltest du mal genauer untersuchen.
Ich will jetzt nicht unbedingt behaupten, dass CTS unsicherer ist als CBC, aber auch beim Gegenteil bin ich skeptisch!
Denk immer dran: Bei der Modifikation von Ciphern etc kann sehr schnell etwas schief gehen! Ein XOR zu viel und alles ist kaputt - obwohl es im ersten Moment sicher aussieht...

Was für ein Fehler ist eigentlich in Rijndael im DEC?
Kann ich den irgendwie manuell beheben? Das sind doch sicher nur ein oder zwei Zeilen?!
THX,
Daniel.

[negaH]

Zitat:

Im CTS-Modus erfolgt dieses Mittragen sehr viel intensiver, und gerade dass führt zu meinem Zweifel:
Erst einmal ein kurzes Beispiel dazu:

Wenn ich 13 xor 55 xor 255 xor 3 xor 54 rechne, dann kommt da 240 raus.
Rechne ich jetzt 240 xor 13, dann gibt das 253 und das ist wiederum = 55 xor 255 xor 3 xor 54 .

Soll heißen:
Wenn ich bei einer noch so langen XOR-Rechnung einen Wert zweimal einbeziehe, dann wird er eliminiert. Wird auch hierdurch klar: Y xor Y = 0 bzw: Y xor Y xor X = X

Der Random-Block, der ja nun der erste ist, befindet sich nun im Feedbackregister und wird somit auf den Block 2 angewendet. Das Ergebnis davon gelangt jetzt wieder in abgewandelter Form in das Feedbackregister: ==> Im Feedbackregister befindet sich indirekt der Random-Block 0 zweimal!
Somit hat er eventuell auf Block 3 keine Auswirkung mehr! Lediglich in Block 4 wäre wieder eine Auswirkung gegeben, da hier der Random-Block 0 dreimal vorkäme.

Schau dir's nochmal genauer an, denn deine Annahmen stimmen so nicht.
Beim CTS Modus wird ja immer nur mit den Verschlüsselten Vorgängerblöcken XOR verknüpft. Wäre c(), der Verschlüsslungscode, eine einfache XOR Verschlüsselung dann würde deine Annahme stimmen. Aber im gleichem Maße wäre dann CBC erst recht unsicher. Da aber c() bei heutigen Blockverschlüsslungen eben nur durch e(), dem Entschlüsslungscode, invertierbar ist, können deine Annahmen nicht stimmen.

Beim CBC Modus wird nur der 1. Block verknüpft mit dem IV. Da dieser IV natürlich Einfluß auf den nächsten Wert im Feedback-register hat, wird er indirekt mit durchgeschliffen. Allerdings im CTS Modus passiert das Gleiche plus das der IV mit jedem Block verknüpft wird.

Deshalb meinte ich ja das der CTS Modus sozusagen ein "doppelter" CBC Modus ist. Genau genommen ist er ein "x Block facher" CBC Modus. Je mehr Blöcke verschlüsselt werden im CTS Modus destomehr ist der nachfolgende Block abhänig von allen Vorgängerblöcken. Der letzte Block ist das Produkt aller Vorgängerblöcke + IV's + Passwort + Verschlüsselungsfuntion c(). Der letzte Wert im Feedbackregister ist somit absolut abhängig vom IV + Palintext + CipherText + Passwort + c().
Wie gesagt, schau dir die Formeln ganz genau an, und analysiere sie erstmal richtig. Dann wirst du sehen was ich meine. Der CTS Modus wurde mit vielen Cryptogurus in sci.crypt besprochen und analysiert.

Zitat:

Was für ein Fehler ist eigentlich in Rijndael im DEC?
Kann ich den irgendwie manuell beheben? Das sind doch sicher nur ein oder zwei Zeilen?!

Sorry, nicht in Rijndael ist der Fehler sondern in Twofish.

Gruß Hagen

[daniel-volk]

Zitat:

Der CTS Modus wurde mit vielen Cryptogurus in sci.crypt besprochen und analysiert.

Achso, na dann ist ja alles OK.

Frage mich nur immer noch, warum er dann nicht längst öffentlich anerkannt ist wie CBC. Auf diese Möglichkeit hätte doch schon viel früher jemand kommen können.
Egal. Mal sehen, welchen Mode ich verwende. Entweder CTS oder CBC. CBC hätte wahrscheinlich den Vorteil, dass er von der Öffentlichkeit eher anerkannt wird und die Leuts somit mehr Vertrauen in mein Prog hätten - auch wenn CTS im Endeffekt vielleicht sicherer wäre.

Mal seh'n, werd schon 'ne Lösung finden.

MfG,
Daniel.

PS: Meine Zweifel rührten nicht daher, dass ich dir nicht zutraue sowas zu erfinden, sondern eher daher, dass ich CTS für recht ungeprüft hielt und slbst schon oft darüber verwundert war (bei meinen eigenen Kryptversuchen) welche "Wunder der Mathematik" da plötzlich auftauchen.

[negaH]

Zitat:

Frage mich nur immer noch, warum er dann nicht längst öffentlich anerkannt ist wie CBC. Auf diese Möglichkeit hätte doch schon viel früher jemand kommen können.

Oh, ein ähnlicher CTS als solches wurde vor einem Jahr in den AES Auswahlprozess für Standard Ciphermodes aufgenommen. Betrachtet man CTS mal auf Byte-Ebene so stellt man fest das es CFB Modis gibt die wie CTS arbeiten. Es ist also nicht unbekannt im eigentlichen Sinne, sondern es wurden anderen Ciphermodis den Vorrang gegeben weil sie meistens effizienter sind. Erst seit 1-2 Jahren bemüht man sich auch die Ciphermodis der Blockcipher genauer und gezielter zu entwickeln. Bis dato wurden die Ciphermodis im allgemeinen NICHT als Sicherheitsrelevant eingestuft. Diese Annahme hat sich als falsch erwiesen, weil eben die Sicherheitanforderungen gestiegen sind.

Ich persönlich habe CTS so entwickelt weil der Austausch der Feedback-Zuweiseung Operation so enorm einfach durch eine XOR Operation möglich war. Statt Move() eben XOR(). Es gibt mittlerweile noch einen Counter-CTS Modus.

Zitat:

PS: Meine Zweifel rührten nicht daher, dass ich dir nicht zutraue sowas zu erfinden, sondern eher daher, dass ich CTS für recht ungeprüft hielt und slbst schon oft darüber verwundert war (bei meinen eigenen Kryptversuchen) welche "Wunder der Mathematik" da plötzlich auftauchen

Diese Herangehensweise ist absolut korrekt und richtig. Aber Neuentwicklungen werden gemacht damit sie ältere Fehler beseitigen. Würde man nur an altem hängen so würden sich bessere Neuentwicklungen nicht durchsetzen. Zudem, es gibt genügend Beispiele bei denen die heutigen Cryptogurus selber Fehler eingestehen, und trotzdem sind deren Verfahren Standards geworden. Um es mal anders auszudrücken: Krypto-Standards sind Mittel in einem elektronischen Krieg der zwischen den beteiligten und Patenthaltenden Firmen geführt wird. Die Entwickler/Professoren/Doktoren und Experten dieser Firmen/Universitäten sind nur Mittel zum Zweck. Deshalb setzen sich auch immer wieder Standard's durch die eben nicht gut sind.

Gruß Hagen