Sicherheit von RC4

[Luckie]

Ich benutze teilweise diese RC4 Implementation von hagen:

Delphi-Quellcode:

{************************************************************}
{                                                            }
{                              RC4                           }
{                                                            }
{             Copyright (c) 2004 Hagen Reddmann              }
{                                                            }
{                                                            }
{************************************************************}


unit RC4;

interface


type
  PByteArray = ^TByteArray;
  TByteArray = array[0..32767] of Byte;

type 
  TRC4Context = record
    D: array[Byte] of Byte;
    I,J: Byte;
  end;

procedure RC4Init(var RC4: TRC4Context; const Key: String);
procedure RC4Done(var RC4: TRC4Context);
procedure RC4Code(var RC4: TRC4Context; const Source; var Dest; Count: Integer); overload;
function RC4Code(var RC4: TRC4Context; const Value: String): String; overload;
function RC4Code(const Value, Password: String): String; overload;

implementation


procedure RC4Init(var RC4: TRC4Context; const Key: String);
var
  R,S,T,K: Byte;
  U,L: Integer;
begin
{$R-}
{$Q-}
  L := Length(Key);
  with RC4 do
  begin
    I := 0;
    J := 0;
    for S := 0 to 255 do D[S] := S;
    R := 0;
    U := 0;
    for S := 0 to 255 do
    begin
      if U < L then K := PByteArray(Key)[U] else K := 0;
      Inc(U);
      if U >= L then U := 0;

      Inc(R, D[S] + K);
      T    := D[S];
      D[S] := D[R];
      D[R] := T;
    end;
  end;
end;

procedure RC4Done(var RC4: TRC4Context);
begin
  FillChar(RC4, SizeOf(RC4), 0);
end;

procedure RC4Code(var RC4: TRC4Context; const Source; var Dest; Count: Integer); overload;
var
  S: Integer;
  T: Byte;
begin
  with RC4 do
    for S := 0 to Count -1 do
    begin
      Inc(I);
      T := D[I];
      Inc(J, T);
      D[I] := D[J];
      D[J] := T;
      Inc(T, D[I]);
      TByteArray(Dest)[S] := TByteArray(Source)[S] xor D[T];
    end;
end;

function RC4Code(var RC4: TRC4Context; const Value: String): String; overload;
var
  Count: Integer;
begin
  Count := Length(Value);
  SetLength(Result, Count);
  RC4Code(RC4, Value[1], Result[1], Count);
end;

function RC4Code(const Value, Password: String): String; overload;
var
  RC4: TRC4Context;
begin
  RC4Init(RC4, Password);
  try
    Result := RC4Code(RC4, Value);
  finally
    RC4Done(RC4);
  end;
end;

end.

Mit wie viel Bit wird da verschlüsselt und wie sicher ist diese Verschlüsselung in vergleich zu anderen Verschlüsselungen?

[mkinzler]

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

[Luckie]

Also sehr sicher oder wie darf ich den Wikipedia Text verstehen? Aber mit wie viel Bit wird verschlüsselt? 256?

[mkinzler]

Die darauf basierende Standars DES und WEP sind nicht gerade für ihre Sicherheit bekannt

[phXql]

Da waren aber konzeptionelle Schnitzer drin.

Zitat:

Im WEP wurde der einmalige Schlüssel durch einfaches Zusammensetzen eines festen geheimen Schlüssels und eines Session Key bestimmt. In diesem Fall ist es jedoch möglich den festen geheimen Schlüssel abzuleiten. Falls der Schlüssel mit einer Hash-Funktion quasi zufällig gewählt wird, kann der RC4 aber weiterhin als sicher betrachtet werden.

[negaH]

Wenn du es sicher haben möchtest dann wähle AES oder andere anerkannte Blockverschlüsselungen. RC4 ist sicherer als viel der Hobby-XOR-Verfahren und im Gegensatz zu deren Implementierungen auch noch sehr einfach und effizient. Das war auch der Grund warum ich den RC4/RCx hier gepostet hatte, als bessere Alternative zu den einfachen XOR-Hobby-Algos.

Will man aber echte Kryptographie machen dann nimm AES und Konsorten.

Der Wiki-Artikel beschreibt es sehr schön:

1.) RC4 müsste mit einem zufälligen Einmalpasswort arbeiten
2.) RC4 ist ein Streamcipher und enthält somit kein Feedback der Datenblöcke untereinander, somit sind spezielle Angriffe möglich. Deshalb habe ich auch RCx hier gepostet der dieses Problem teilweise beseitigt

Gruß Hagen

[Luckie]

Ich hatte RC4 gewählt, weil der Code ohne großem Overhead auskommt. Er bietet als eine höhere Sicherheit, wie eine einfache XOR-Verschlüsselung, kommt an die Sicherheit von AES aber nicht dran. Man kann also sagen RC4 bietet einen erhöhten rudimentären Schutz ohne richtig sicher zu sein. Kann man das so sagen?

Spielt dabei die länge des Passwortes eine Rolle? Ich benutze ihn mit einem acht stelligen Passwort, bestehen aus Groß- und Kleinbuchstaben und Ziffern.

[negaH]

Ja, die Länge des Passwortes, bzw. dessen Qualität, bestimmt die Sicherheit. Auch das Präprocessing des Passwortes spielt eine Rolle.

1.) benutze RCx statt RC4
2.) wandele das Passwort mit Hilfe einer Hashfunktion und Zufall in einen Sessionkey um. Der Zufallssalt muß dann natürlich mit an die daten drangehangen werden
3.) benutze gute Passwörter. Ein 8 Zeichenkey ist im Grunde unsicher. Er sollte 128 Bit haben mit bester Entropie. Also nur Buchstaben/Ziffern wären 36 Symbole aus einem Set von 256 möglichen. Ein solches Passwort sollte also aus 128 / 8 * 256 / 36 = 113 Zeichen bestehen damit es vergleichbar zu einem 128 Bit binärem und zufälligem Schlüssel ist. Das zeigt sehr schön das Ungleichgewicht zwischen heutzutage benutzten sicheren Algorithmen zum durch Menschen gewähltem Passwort. Ergo: RC4 sollte mit deinem kurzen Passwort ausreichend sein ;)

Durch die Expansion des Passwortes mit Zufall und deren Umwandlung per Hashfunktion in einen Sessionkey hat man zwei wichtige Punkte verbessert
1.) die Hashfunktion schützt das Passwort falls man per Kryptoanalyse die verschlüsselten Daten geknackt hat
2.) durch den Zufallswert entstehen somit immer pseudozufällige Sessionkeys die bewirken das ein und die selbe Nachricht immer anders verschlüsselt wird. Damit fallen viele Kryptoanalyseangriffe flach, Choosen PlainText, Differentielle Analyse usw.

Warum wählst du nicht DEC ? Benutzt du nur AES_Rijndael und zb. SHA1 dann werden auch nur diese Algos. in deine EXE eingelinkt. Der Overhead dürfte nicht so gewaltig sein und am Ende hast du es auf einfache Weise auch sicher.

Gruß Hagen

[Luckie]

Konkrete Fragen: Wenn ich das Passwort mit MD5 hashe, dann ist es 32-Bit groß, das heißt der Salt müsste 128 - 32 Bit groß sein. Wie erzeugt man so einen Salt?

Was ist RCx? Hast du dazu eine Implementation zur Hand, die du posten könntest?

Ein 113 Zeichen langes Passwort ist wohl eher unrealistich.

Die Größe der Exe spielt natürlich heutzutage keine große Rolle mehr, trotzdem wollte ich einen unnötigen Overhead vermeiden. Ich werde mal gucken, was für einen Overhead das DEc verursacht. so bald aber die Unit Classes eingebunden wird, ist es eigentlich schon überflüssig auf den Rest der VCL zu verzichten.

[negaH]

MD5 erzeugt einen 128 Bit Output == 16 Bytes !!
Ergo ist es die beste Wahl den Password-Salt ebenfalls exakt 128 Bit groß zu machen. Mehr an Saltbits lohnen nicht da sie keine höhere Sicherheit im Gesamtsystem mit dem MD5 ergeben, weniger Saltbits würden den Salt zum Angriffsziel einer Attacke machen da deren Sicherheit geringer als die der des MD5 ist, also exakt 128 Bit sind am besten. Wichtig ist das auch dieser Zufall auf sichere Weise erzeugt wurde. Das bedeutet du kannst mit der RCxRandomString() Funktion solchen sicheren Zufall erzeugen wenn der Seed für diesen RNG "unpredictable" also unvorhersagbar für den Angreifer ist. Das könnten zb. Maus/Keyboard Eingaben eines Menschen sein, oder man erzeugt über den Temporary Internet Files Ordner eine Hashprüfsumme der darin enthaltenen Dateien, oder man holt sich aus dem INet von speziellen Servern erzeugten Zufall aus Atomaren Zerfalls-RNGs (ist sehr einfaches Protokoll).
Als Hash Algorithmus benutzt man eine KDF->Key Derivation Function -> Schlüsselableitungsfunktion. Schau mal im DEC bei THash.KDF1() und THash.KDFx(). Die KDF1 ist nach IEEE Standard implementiert, die KDFx ist von mir entwickelt und sollte besser sein. Also einfach nur Salt + Password hashen geht zwar auch wird aber nicht empfohlen. Eine KDF geht da besser vor weil sie

1.) den Hash sequientiell mehrmach nacheinander berechnet
2.) in jeder Teilberechnung imer nur einen Teil des Hashoutputs in das Resultat einrechnet
3.) der Output exakt auf die Länge an benötigten Schlüsselbits für den Cipher berechnet wird

Man zieht also zb. 1000 mal den Hash vom Hash vom Hash... vom Salt+Password und errechnet aus den teilberechnungen das Resultat. Das bedeutet ein Angreifer muß ebenfalls pro Brute Force Atacke 1000 mal den Hash anwerfen -> ergo Komplexitätssteigerung des Angriffes um Faktor x1000.
Punkt 3.) oben ist ebenfalls wichtig. Mit einer KDF erzeugt man also aus einem beliebigen Password+Salt (Salt minimal so lang wie Password) einen Output der exakt so groß ist wie das größt möglich verwendbare Password der Verschlüsselung. Man erzeugt also exakt so viel Schlüsselbits wie der Cipher benötigt.

In DEC ist das alles sehr einfach:

Delphi-Quellcode:

Salt := RandomBinary(16);
with TCipher_Rijndael.Create do
try
  Mode := cmCBC8;
  Init(THash_SHA1.KDFx(Password, Salt, Context.KeySize));
  Result := TFormat_HEX.Encode(Salt) + EncodeBinary('Deine Daten hier', TFormat_HEX);
finally
  Free;
end;

RCx in der CodeLib -> http://www.delphipraxis.net/internal...=353886#353886

Gruß Hagen