Rijndael-Entschlüsselung

[negaH]

ok,

IV = binascii.unhexlify('FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FF')
IV_Cipher = AES.new(Key,AES.MODE_ECB)
IV = IV_Cipher.encrypt(IV)

zeige mal zu deinen Testvektoren noch den IV nach IV_Cipher.Encrypt() als HEX String. Bisher konnte ich nichts reproduzieren. Ich brauch also diesen verschlüsselten IV als HEX String.

Gruß Hagen

EDIT: und sende mal die Vektoren für sowas wie Obj.Encrypt('Teststring'); statt über die Dateien zu arbeiten. Du hast dort noch ein Preprozessing drinnen das einen String im MIME64 bearbeitet, aus einer Datei liest usw. und bei deinen obigen Testvektoren sind am Schluß immer die zeichen $0D + $0A das sind Carrige Return und Linefeed Steuercodes die in einem sinnvollem Testvektor nichts zu suchen haben.

[negaH]

Davon abgesehen stimmt mit deinen Testvektoren sowieso irgendwas nicht.

Code:

696D6C5666374861645137307A6C466C
516E6F2F73736937614A616C734E4C76
5830636751345930544E5432
--334C4C6752306256646C652F77735A3246704B6E5A654F6C6E686E2F586E4C4C4A6E3D3D0D0A^

Entschlüsselt 1:
CCF: [url]http://rapidshare.com/files/[/url] -- 58141435/voy402.part1.rar

------------------------------------------------------------------------------

Verschlüsselt 2:
696D6C5666374861645137307A6C466C
516E6F2F73736937614A616C734E4C76
5830636751345930544E5432
 --- 304434714341456B506573524D424B4930497A7A57357A3D0D0A

Entschlüsselt 2:
CCF: [url]http://rapidshare.com/files/[/url] --- 91891665/D2SC.rar

Wenn man bei beiden HEX Vektoren mal die Anzahl der sich dahinter verbergenden Zeichen zusammenzält die in beiden gleich snd so komme ich auf 44 Zeichen die gleich sind. Logisch das wir gleiches Passwort ohne Zufallssalt benutzen und die gleichen Daten verschlüsseln (übrigens kryptographisch unsicher !!) falls das Passwort immer gleich ist.

Nun zählen wir mal die Zeichen in deinem angeblichen String der verschlüsewlt wurde. Ich komme 33 Zeichen. Also WO zum Teufel sind die restlichen 11 Zeichen hin ? Vor deinem String "CCF:...." müssen noch 11 andere Zeichen sein, anders kann ich es mir nicht erklären. Nungut, denken wir uns mal das dieser String vor der Verschlüselung mit MIM Base 64 formatiert wurde, was ansich ja bescheuert wäre (kryptographisch betrachtet). Wenn wir einen 33 Zeichen-String in MIME64 umwandeln dann wird das Resulat im Verhältnis 3 zu 4 größer sein. Nun, 33*4/3 == ? ja 44.

Edit: anders ausgedrückt, deine Testvektoren sind für den Popo und repräsentieren nicht die Daten der eigentlichen Verschlüsselung.

[negaH]

So, du bist mir'ne Nuss

Delphi-Quellcode:

function CCFDecrypt(const CCF: Binary; const Password: Binary): Binary;
begin
  with TCipher_Rijndael.Create do
  try
    Mode := cmCFB8;
    Init(Password);
    Result := DecodeBinary(CCF, TFormat_MIME64);
  finally
    Free;
  end;
end;

function CCFEncrypt(const CCF: Binary; const Password: Binary): Binary;
begin
  with TCipher_Rijndael.Create do
  try
    Mode := cmCFB8;
    Init(Password);
    Result := EncodeBinary(CCF, TFormat_MIME64);
  finally
    Free;
  end;
end;

procedure Test;
var
  Password, Data: Binary;
begin
  Password := TFormat_HEX.Decode('8C35192D964DC3182C6F84F3252239EB4A320D2500000000');

  Data := CCFEncrypt('CCF: http://rapidshare.com/files/58141435/voy402.part1.rar', Password);

  WriteLn('MIME64 : ', Data);
  WriteLn('HEX    : ', TFormat_HEX.Encode(Data));

  Data := CCFDecrypt(Data, Password);

  WriteLn('Data   : ', Data);

end;

raus kommt dann

Code:

MIME64 : imlVf7HadQ70zlFlQno/ssi7aJalsNLvX0cgQ4Y0TNT23LLgR0bVdle/wsZ2FpKnZeOlnhn/XnLLJg==
HEX    : 696D6C5666374861645137307A6C466C516E6F2F73736937614A616C734E4C765830636751345930544E54323
         34C4C6752306256646C652F77735A3246704B6E5A654F6C6E686E2F586E4C4C4A673D3D
Data   : CCF: [url]http://rapidshare.com/files/58141435/voy402.part1.rar[/url]

Wie du siehst brauscht du im DEC nur die richtigen Parameter einstellen und ohne Probleme funktioniert alles. Man sollte eben wissen WAS man da eigentlich als Datenformat so macht und gleich die richtigen Testvektoren liefern.

So das kostet dich ein Bier und da ich keines trinke könntest du uns an deiner fertigen Anwendung, RapidShare Tool, partizipieren lassen.

Gruß Hagen

EDIT: ach übrigens ich hoffe das es positiv auffällt mit wie wenig Sourcezeilen man das Gleiche in Delphi machen kann was im PHP umständlich geht
EDIT: kryptographisch betrachtet ist diese Methode Dateien zu schützen unsicher, falls das Passwort nicht jedesmal neu per Zufall gewählt wird !

[q3fuba]

Erstmal muss ich sagen *respeckt* !

aber jetzt habe ich noch folgendes problem:

mein test quelltext:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  MIME64, DataList: TStringList;
  MeinHexString, Password: string;
  i: integer;
begin

  Password := TFormat_HEX.Decode(Edit1.Text);
  MeinHexString:=Edit2.Text;

  MIME64 := TStringList.Create;
  DataList := TStringList.Create;
  MIME64.Text:=TFormat_HEX.Decode(MeinHexString);

  for i:=0 to MIME64.Count-1 do
  begin
    DataList.Append(CCFDecrypt(MIME64[i], Password));
  end;
  MIME64.SaveToFile('MIME64.txt');
  DataList.SaveToFile('Decrypted.txt');

in Edit1 steht mein Passwort in HEX:

Code:

8C35192D964DC3182C6F84F3252239EB4A320D2500000000

in Edit2 steht mein Verschlüsselter Text in HEX:

Code:

696D6C5666374861645137307A6C466C516E6F2F73736937614A616C734E4C765830636751345930544E5432304434714341456
B506573524D424B4930497A7A57357A3D0D0A387447614C6C6B4F3652643148314558386B414F55664B47494E486E4F346C6F37
6C4A31777233516E7867315234455571724D3752596F2F324F3335376B2B2F5A7639304E715976425456390D0A

Welcher entschlüsselt sein soll:

Code:

CCF: [url]http://rapidshare.com/files/91891665/D2SC.rar[/url]
CCF: [url]http://rapidshare.com/files/72806508/Forum_Tools.rar[/url]

aber raus kommt nur die erste zeile wie sie sein soll.
Denn es sieht dann so aus:

Code:

CCF: [url]http://rapidshare.com/files/91891665/D2SC.rar[/url]
;ÂZÔ˜zùÓ-,í^[rdshare.com/files/72806508/Forum_Tools.rar

Der text der zweiten zeile wird verstümmelt
Auch wenn ich 10 zeilen haben, wird nur die erste zeile richtig enschlüsselt


Also, bis zu dem punkt:
MIME64.Text:=TFormat_HEX.Decode(MeinHexString); stimmt noch alles, da bekomm ich 2 zeilen raus, welche ich dann jeweils einzelln decrypten müsste

Das kommt raus wenn ich "MeinHexString" decodiere

Code:

imlVf7HadQ70zlFlQno/ssi7aJalsNLvX0cgQ4Y0TNT20D4qCAEkPesRMBKI0IzzW5z=
8tGaLlkO6Rd1H1EX8kAOUfKGINHnO4lo7lJ1wr3Qnxg1R4EUqrM7RYo/2O357k+/Zv90NqYvBTV9

und das stimmt 100% mit dem überei, was mir das python script auch ausgiebt (habe ich getestet)

nur dann mach Phyton das:

Code:

base64.b64decode(zeile1)
obj.decrypt(zeile1)

base64.b64decode(zeile2)
obj.decrypt(zeile2)

also jede zeile einzelln decrypten

was wiederum für mich in delphi das ergeben würde:

Delphi-Quellcode:

  for i:=0 to MIME64.Count-1 do
  begin
    DataList.Append(CCFDecrypt(MIME64[i], Password));
  end;

mache ich das aber so, dann komm das raus:

Code:

CCF: [url]http://rapidshare.com/files/91891665/D2SC.rar[/url]
;ÂZÔ˜zùÓ-,í^[rdshare.com/files/72806508/Forum_Tools.rar

warum stimmt dann nur die erste zeile, aber die weiteren nicht?

[edit=Phoenix]Die lange Zeile umgebrochen wegen Layout. Mfg, Phoenix[/edit]

[negaH]

Weißt du was der PHP Code macht, wie er funktioniert ?

Als Hinweis: wie oft wird der Cipher erzeugt und mit einem Password gefüttert im Vergleich zu der Anzahl der Datenzeilen die man entschlüsselt ?

Delphi-Quellcode:

  with TCipher_Rijndael.Create do
  try
    Mode := cmCFB8;
    Init(TFormat_HEX.Decode('8C35192D964DC3182C6F84F3252239EB4A320D2500000000'));

    WriteLn(DecodeBinary('imlVf7HadQ70zlFlQno/ssi7aJalsNLvX0cgQ4Y0TNT20D4qCAEkPesRMBKI0IzzW5z=', TFormat_MIME64));
    WriteLn(DecodeBinary('8tGaLlkO6Rd1H1EX8kAOUfKGINHnO4lo7lJ1wr3Qnxg1R4EUqrM7RYo/2O357k+/Zv90NqYvBTV9', TFormat_MIME64));
  finally
    Free;
  end;

Delphi-Quellcode:

procedure CCFLoadFiles(AItems: Strings; const AFileName: String; const APassword: Binary);
var
  I: Integer;
begin
  AItems.BeginUpdate;
  try
    AItems.LoadFromFile(AFileName);
    AItems.Text := TFormat_HEX.Decode(AItems.Text);
    with TCipher_Rijndael.Create do
    try
      Mode := cmCFB8;
      Init(APassword);
      for I := 0 to AItems.Count -1 do
        AItems[I] := DecodeBinary(AItems[I], TFormat_MIME64);
    finally
      Free;
    end;
  finally
    AItems.EndUpdate;
  end;
end;

procedure TForm1.ButtonClick(Sender: TObject);
begin
  if OpenDialog1.Execute then
    CCFLoadFiles(ListBox1.Items, OpenDialog1.FileName, TFormat_HEX.Decode('8C35192D964DC3182C6F84F3252239EB4A320D2500000000'));
end;

Warum RapidShare das so verschlüsselt ist unklar. Man hätte

1.) mit einem Salt arbeiten müssen
2.) alle unverschlüsselten Zeilen als eine Zeile in einem Rutsch verschlüsseln können und dieses Resultat in einem Rutsch in MIME64 und dann nochmal in HEX umwandeln können.
3.) die Zusätzliche Umwandlung in HEX eines MIME64 String ist für den Popo und expandiert die Datenmenge nur unnötig. Es sei denn das DU diese HEX-Umwandlung eingebaut hast und in Wahrheit Rapidshare in seinen Dateien nur einfach zeilenweise MIME64 formatierte Strings enthalten. Das würde dieses ständige Umwandeln von HEX nach MIME64 erklären. Sollte das der Fall sein dann ändere oben Source um in

Delphi-Quellcode:

procedure CCFLoadFiles(AItems: Strings; const AFileName: String; const APassword: Binary);
var
  I: Integer;
begin
  AItems.BeginUpdate;
  try
    AItems.LoadFromFile(AFileName);
//    AItems.Text := TFormat_HEX.Decode(AItems.Text);
    with TCipher_Rijndael.Create do
    try
      Mode := cmCFB8;
      Init(APassword);
      for I := 0 to AItems.Count -1 do
        AItems[I] := DecodeBinary(AItems[I], TFormat_MIME64);
    finally
      Free;
    end;
  finally
    AItems.EndUpdate;
  end;
end;

Gruß Hagen

EDIT: erkläre uns doch mal was das eigentlich werden soll, ich möchte ungern unwissentlich in eine Straftat verwickelt werden. Davon abgesehen habe ich deine Arbeit gemacht und meine das alle hier im Forum interessierten Leute auch was davon haben sollten.

EDIT: übrigens sieht man sehr schön an Hand deiner fehlerhaften Resultate wie sich der Cipher sauber selbstsynchronisert. In deinem Output ist der 1. Datenblock a 16 Bytes der 2. Zeile zerstört. Aber alle nachfolgenden Datenblöcke sind wieder richtig. Das ist die Selbstsynchronisierung des Ciphers. Der 1. Datenblock ist deshalb falsch weil des interne Feedback-Register des Ciphers, 16 Bytes, neu mit einem Password initlaisiert wurde und nicht der letzte Wert aus der vorherigen 1. Zeile weiterbenutzt wurde. Da wir immer das gleiche Passwort benutzen, für jede Zeile separat, werden alle Datenblöcke nach dem 1. Datenblock wieder korrekt entschlüsselt. Für einen erfahrenen Laien ist also an Hand deines fehlerhaften Outputs sofort ersichtlich wo der Fehler im Source liegt, man erkennt sofort das der 1. Datenblock=16 Bytes falsch sind und stellt autom. die Vermutung auf das die Daten an einem Stück verschlüsselt wurden, auch ohne das PHP Script gesehen zu haben.

[negaH]

So nach kurzer Recherche weiß ich nun worum es geht. Mit nachfolgendem Code kann man RapidShare Containter Dateien mit Endung .RSDF entschlüsseln. So wie ich das interpretiere benutzt Rapidshare dabei zwar eine starke AES Verschlüsselung aber im Grunde vollkommen falsch. Ein Beispiel wie man es nicht machen sollte.

1.) das Passwort scheint hardcoded zu sein, kein Wunder das Cracker dieses schnell gefunden haben.
2.) das Passwort wird nicht mit einem Zufallssalt und einer KDF (Schlüsselableitungsfunktion) in einen pseudozufälligen Sessionkey umgewandelt, naja ist bei einem hardcoded Passwort auch sinnfällig.
Punkte 1. und 2. und die Tatsache das jeder Rapidshare Link immer mit 'CCIF: http://rapidshare....'' anfdangen haben die Konsequenz, das im verschlüsseltenm Resultat immer die gleichen Bytefolgen zu sehen sind. Man kann also als Angreifer, mit dem Wissen das die Dateien immer gleich anfangen, sehr schnell erkennen das ein hardcoded Passwort ohne Preprocessing des Passwortes benutzt wurde. Dazu muß man nur ein par dieser RSDF Dateien analysieren.
3.) das eigentliche Datenformat ist kompliziert und ineffizient. Man hat binäre Daten die man zeilenweise verschlüsselt und in MIME64 umwandelt obwohl sie am Stück mit einem Cipher Objekt verschlüsselt werden. Man kann also nicht beliebig eine dieser Zeile entschlüsseln ohne alle vorherigen Zeilen zu entschlüsseln. Ergo macht es auch keinen Sinn die einzelnen Zeilen separat und denoch abhängig voneinander zu verschlüsseln und in MIME64 umzuwandeln. Man hätte auch gleich die Daten in einem Rutsch verschlüsseln können. Dies wäre weit effizienter (schätze mal das dahinter ein PHP Script bei RapidShare steckt ) Die zusätzliche Umwandlung dieser Daten in das HEX Format ergibt technologisch betrachtet keinen Nutzen. Das INet kann ohne Probleme MIME64 formatierte Daten übertragen. Problematisch könnten nur die Zeilenumbrüche innerhalb dieses MIME64 String sein, wahrscheinlich auch der Grund für die Konvertierung in das HEX Format. Nur ist es eben so das diese zusätzlichen Zeilenumbrüche erst dadurch entstanden sind weil man sinnloser weise die einzelnen Dateinamen eben zeilenweise verschlüsselt und in MIME64 umgewandelt hat. Dieses ineffektive Datenformat ist also entstanden weil der Programmierer schon am Anfang einen konzeptionellen Fehler gemacht hat.
An Hand dieses Datenformates kann ein Angreifer gut erkennen das in einer RSDF Datei X Links gespeichert wurden, denn es gibt X Zeilen getrennt durch Zeilenumbrüche. Nun muß man nur noch ein RSDF File anlegen in dem mehrmals ein Link auf exakt die gleiche Datei gespeichert wurde. Analysiert man dieses verschlüsselte RSDF File so gäbe es zwei Möglichkeiten. Jede der Zeilen im File besteht aus exakt dem gleichen MIME64 String oder die Strings unterscheiden sich zeilenweise. Träfe erster Fall zu so würden wir wissen das jede Zeile mit neuem Passwort und Cipher Objekt verschlüsselt wurde, also so wie es der OP gemacht hat. Träfe der zweite Fall zu dann wissen wir das zeileweise verschlüsselt wurde aber mit nur einem einmalig initialiserten Cipher Objekt, so wie es auch der Fall ist. Also allein an Hand einer beeinflussbaren RapidShare Container Datei können wir enorm viele Informationen erlangen wie was verschlüsselt wurde. Der nächste und finale Schritt ist es den verwendeten Cipher samt Mode usw. und das hardcoded Passwort per Reverse Engineering der Download Software zu knacken, wir wissen ja nun wonach wir suchen müssen.
Das verwendete Dateiformat lässt also viel zu viele Informationen nach aussen dringen die es einem Angreifer leicht machen es zu knacken. Das Dateiformat ist also eine kryptographische Unsicherheit.

Delphi-Quellcode:

procedure RSDFLoadFiles(AItems: TStrings; const AFileName: String);
const
  Password = #$8C#$35#$19#$2D#$96#$4D#$C3#$18#$2C#$6F#$84#$F3#$25#$22#$39#$EB#$4A#$32#$0D#$25#$00#$00#$00#$00;

  function DoCleanup(const Value: String): String;
  begin
    Result := System.Copy(Value, Pos('HTTP', AnsiUpperCase(Value)), MaxInt);
  end;

var
  I: Integer;
begin
  AItems.BeginUpdate;
  try
    AItems.LoadFromFile(AFileName);
    AItems.Text := TFormat_HEX.Decode(AItems.Text);
    with TCipher_Rijndael.Create do
    try
      Mode := cmCFB8;
      Init(Password);
      for I := 0 to AItems.Count -1 do
        AItems[I] := DoCleanup(DecodeBinary(AItems[I], TFormat_MIME64));
    finally
      Free;
    end;
  finally
    AItems.EndUpdate;
  end;
end;

Damit das funktioniert müsst ihr in DECFmt.pas folgendes ändern:

Delphi-Quellcode:

class function TFormat_HEX.DoDecode(const Value; Size: Integer): Binary;
var
  S: PChar;
  D: PByte;
  T: PChar;
  I,P: Integer;
  HasIdent: Boolean;
begin
  Result := '';
  if Size <= 0 then Exit;
  SetLength(Result, Size div 2 +1);
  T := CharTable;
  D := PByte(Result);
  S := PChar(@Value);
  I := 0;
  HasIdent := False;
  while Size > 0 do
  begin
    P := TableFind(S^, T, 18);
    if P < 0 then P := TableFind(UpCase(S^), T, MaxInt);
    if P < 0 then
      raise EDECException.CreateFmt(sInvalidStringFormat, [DECClassname(Self)]);
    Inc(S);
    if P >= 0 then
      if P > 16 then
      begin
        if not HasIdent and (P < 18) then
        begin
          HasIdent := True;
          I := 0;
          D := PByte(Result);
        end;
      end else
      begin
        if Odd(I) then
        begin
          D^ := D^ or P;
          Inc(D);
        end else D^ := P shl 4;
        Inc(I);
      end;
    Dec(Size);
  end;
  SetLength(Result, PChar(D) - PChar(Result));
end;

Der HEX String in einer RSDF Datei enthält am Ende ein '/n' bzw. eben ein #13#10 -> Carrige Return + Linefeed. Meine originale HEX Konvertierungsfunktion hat diese Steuerzeichen nicht rausgefiltert. Logisch betrachtet ein Fehler im DEC.

Gruß Hagen

[negaH]

Ach und nochwas

Der Cipher wird im CFB8 Modus betrieben. Das ist quasi ein Blockcipher der in einen Streamcipher umgewandelt wird. Das besondere daran ist das nun der AES ausgehend vom Passwort nur einen Schlüsselstrom aus Bytes erzeugt. Dieser Schlüselstrom wird dann mit den Daten XOR verknüpft. Das ist unsicher !!
Denn nun machen wir einfach mal folgendes Experiment. Wir legen eine Rapidshare Account an und lassen ein Containerfile erzeugen das möglichst viele Links enthält. Alle Links in der gleichen Reihenfolge. Dann nehmen wir unsere Rapidshare Datei ent-HEX'en sie, und ent'MIME64 sie und verknüpfen beide Daten per XOR. Nun haben wir den Schlüsselstrom extrahiert. Da das Passwort hardcoded und unveränderlich ist, da der IV nicht per Zufall gewählt wurde und auch kein Zufallssalt eingebaut wurde, können wir diesen Schlüsselstom driekt benutzen um alle Rapidshare Dateien zu entschlüsseln. Also ohne das Passwort noch den AES Cipheralgortihmus zu kennen knacken wir alle Rapidshare Dateien. Naja, kryptographisch betrachtet also nicht besser als eine XOR Verschlüsslung oder sonstwas billiges.

Merke:
- Passwörter immer per Salt umwandeln
- Daten nach Möglichkeit randomisieren am Anfang
- nach Möglichkeit immer alle Daten am Stück verschlüsseln
- niemals ein hardcoded Passwort benutzen
- einen Blockcipher am besten in einem Ciphermode betreiben der auch wirklich blockweise die Daten verschlüsselt und nicht wie einen Streamcipher benutzen.

Gruß Hagen

[q3fuba]

Oh mann...
Das hätte ich in nem jahr alleine nicht hinbekommen

Ich denke aber auch, dass die rsdf files nur soweit "verschlüsselt" sind, damit die nicht jeder lesen kann, was wiederum eigentlich voll für'n hugo ist, aber naja dafür kann ich leider nichts

Zitat:

Der HEX String in einer RSDF Datei enthält am Ende ein '/n' bzw. eben ein #13#10 -> Carrige Return + Linefeed. Meine originale HEX Konvertierungsfunktion hat diese Steuerzeichen nicht rausgefiltert. Logisch betrachtet ein Fehler im DEC.

naja, wer rechnet den mit sowas?
soll ja ne Delphi decrypting unit sein, nicht eine von php abgeleitet.

Aber allgemein gesehen, weil ich ja von crypting und co NICHT annähernd soviel ahnung habe wie du, muss ich sagen, *respeckt*!

Mein programm sollte ja eigentlich nur die links aus der rsdf rausfiltern und dann in ne list / datei lesbar wieder abspeichern.

Zitat:

Der Cipher wird im CFB8 Modus betrieben. Das ist quasi ein Blockcipher der in einen Streamcipher umgewandelt wird. Das besondere daran ist das nun der AES ausgehend vom Passwort nur einen Schlüsselstrom aus Bytes erzeugt. Dieser Schlüselstrom wird dann mit den Daten XOR verknüpft. Das ist unsicher !!

Aber trotzdem hat es leute wie mich, davon abgehalten, den code "einfach" zu decrypten.
Naja wenn man nicht allzuviel ahnung hat, ist das auch nicht schwer und genau darum geht es ihnen denke ich.


Aber egal, ich habe das kleine tool, welches ich eigentlich machen wollte man angefügt.
Natürlich habe ich auch dich darin erwähnt!

Sag mir was du davon hälst

[negaH]

Ausführbare Dateien werde ich mir nicht anschauen, verständlich oder Ich möchte dir damit keine bösen Absichten unterstellen sondern nur meinen Rechner sauber halten.

EDIT: ich schrieb

Zitat:

Der Cipher wird im CFB8 Modus betrieben. Das ist quasi ein Blockcipher der in einen Streamcipher umgewandelt wird. Das besondere daran ist das nun der AES ausgehend vom Passwort nur einen Schlüsselstrom aus Bytes erzeugt. Dieser Schlüselstrom wird dann mit den Daten XOR verknüpft. Das ist unsicher !!

Ist natürlich falsch und bezieht sich auf dem OFB8 -> Output Feedback Modus und nicht CFB8 -> Cipher Feedback Modus. Der CFB8 ist im Gegensatz zum OFB8 auch abhängig vom Datenstrom der verschlüsselt wird. Das hat zur Konsequenz das man nicht auf einfache Weise einen Schlüsselstrom zu einem unbekannten Passwort nur mit Hilfe der unverschlüsselten und verschlüsselten Daten extrahieren kann. Beim OFB8 geht das aber, deshalb muß man beim OFB auch immer das Passwort oder IV randomisieren.

Gruß Hagen

http://de.wikipedia.org/wiki/Respekt

[q3fuba]

Zitat:

Ausführbare Dateien werde ich mir nicht anschauen, verständlich oder Smile Ich möchte dir damit keine bösen Absichten unterstellen sondern nur meinen Rechner sauber halten.

jo, ist verständlich.

Zitat:

http://de.wikipedia.org/wiki/Respekt

grml, da verschreibt man sich mal und wird gleich belehrt

aber mal was anderes...
Wo/wie sollte ich beim Crypting anfangen?
Weil ich bin ja in dem gebiet ja ne null und würde mich da gerne mal weiterentwickeln
Was muss ich verstehen usw...

Hast da irgendwelche infos für mich?