Mit DEC verschlüssel. Wie groß ist die Schlüssellänge?

[Luckie]

Ich nutze diesen Code, um eine Datei mit dem DEC zu verschlüsseln:

Delphi-Quellcode:

////////////////////////////////////////////////////////////////////////////////
// Comment   : Encodes a file
// Arguments : Filename, Folder, PW: String; FileHeader: TFileHeader;
//             hWnd: THandle
// Result    : Boolean

function TEncodeThread.EncodeFile(Filename, Folder, PW: string;
  FileHeader: TFileHeader; hWnd: THandle): Boolean;
var
  SrcStream: TStreamProgressAdapter;
  DestStream: TFileStream;
  Len: Integer;
  Buffer: Pointer;
begin
  result := False;
  // open source stream
  SrcStream := TStreamProgressAdapter.Create(TFileStream.Create(Filename, fmOpenRead or fmShareDenyNone), hWnd);
  if Assigned(SrcStream) then
  begin
    try
      // create destination stream
      DestStream := TFileStream.Create(IncludeTrailingPathDelimiter(Folder)+ ExtractFilename(Filename) + EXTENSION,
        fmCreate);
      if Assigned(DestStream) then
      begin
        try
          // write the head into the stream
          DestStream.Write(FileHeader, sizeof(TFileHeader));
          //  prepare vor encoding
          with DefCipherClass.Create(PW, nil) do
          begin
            Mode := cmCBC;
            InitKey(PW, nil);
            // alocate memory for the buffer
            GetMem(Buffer, 1024);
            try
              // as long as we have not reached the end of the source stream
              while (SrcStream.Position < SrcStream.Size) and (Terminated = False) do
              begin
                // how much to read
                if SrcStream.Size - SrcStream.Position > BlockSize then
                  Len := BlockSize
                else
                  Len := SrcStream.Size - SrcStream.Position;
                // read into the buffer
                SrcStream.ReadBuffer(Buffer^, Len);
                // encode the buffer
                EncodeBuffer(Buffer^, Buffer^, len);
                // write the buffer
                DestStream.WriteBuffer(Buffer^, Len);
              end;
            finally
              // clean up the buffer
              FreeMem(Buffer);
            end;
          end;
        finally
          // free the destination stream
          FreeAndNil(DestStream);
        end;
      end
      else // could not create the destination stream
      begin
        RaiseLastOSError();
        exit;
      end;
    finally
      // free the source stream
      FreeAndNil(SrcStream);
    end;
  end
  else // could not open the source stream
  begin
    RaiseLastOSError();
    exit;
  end;
  // we didn't exit the function early, everything went O.K.
  result := True;
end;

Wobei

Delphi-Quellcode:

  DefCipherClass: TCipherClass = TCipher_Rijndael;
  DefHashClass: THashClass = THash_SHA1;

Wie groß ist da jetzt eigentlich die Schlüssellänge?

[Alter Mann]

Hi,

ich hoffe das Du hier die Antwort findest: system.security.cryptography

[Luckie]

Äh, nein. Da hat mit dem DEC von Hagen nichts zu tun.

[OG Karotte]

Zitat:

Wie groß ist da jetzt eigentlich die Schlüssellänge?

Bei SHA1 160 Bit und
bei Rijndael:

Zitat:

Bei Rijndael handelt es sich um einen symmetrischen Algorithmus mit einer variablen Blockgröße von 128, 192 oder 256 Bit und einer variablen Schlüssellänge von 128, 192 oder 256 Bit.

Zitat aus'm I-Net müsste aber auch für DEC gelten.

[Luckie]

Zitat:

Zitat von OG Karotte

Zitat:

Bei Rijndael handelt es sich um einen symmetrischen Algorithmus mit einer variablen Blockgröße von 128, 192 oder 256 Bit und einer variablen Schlüssellänge von 128, 192 oder 256 Bit.

Genau das wurde ich per E-Mail gefargt:

Zitat:

Hallo, mit welcher Schlüssellänge verschlüsselt denn der von "FileCrypter" verwendete AES-Algorithmus? Mit 128 Bit, 192 Bit oder 256 Bit?
Oder anders gefragt: Welche der AES-Varianten AES-128, AES-192 und AES-256 verwendet das Programm "FileCrypter"?

Jetzt wüsste ich gerne, welche Variante eigentlich in dem Algorithmus verwendet wird bzw. wie ich da beeinflussen kann mit dem DEC.

[negaH]

DEC benutzt alle drei Schlüssellängen ;)

Abhängig von der Länge des Passwortes benutzt AES Rijndael 128/192 oder 256 Bits. Also im häufigsten Falle, also ohne Passwortpreprozessing, 128 Bit.
Die Sache ist ganz einfach: ein Passwort das nur 64 Bit effektiv lang ist wird mit AES a 256 Bit nicht sicherer. D.h. es macht keinen Sinn bei so einem Key mit mehr als AES 128 Bit zu arbeiten. Wenn das Passwort aber 192 Bit groß ist so sollte man klarerweise mit AES 192 arbeiten. Mit AES 128Bit würde man wertvolle Bits = Sicherheit des Passwortes "wegwerfen", mit AES 256Bit würde man aber kein bischen mehr an Sicherheit erlangen als mit AES 192 Bit. AES 256 wäre nur langsammer ;(

Ergo: DECs AES ermittelt über die Passwortlänge wie er intern arbeitet. Er rundet dabei immer auf, dh. Passwort mit 238 Bits würde AES 256 benutzen.
Beeinflussen kannst du dies indem du mit einer KDF einen Sesionkey mit definierter Länge erzeugst

Delphi-Quellcode:

SessionKey := THash_SHA1.KDFx(Salt, Password, Cipher.Context.KeySize, TFormat_COPY);

Dies würde dann aus dem zu kurzen Password, im Falle von AES, einen Sessionkey mit 256Bits erzeugen. Wenn das Passwort aber nur 32Bits groß ist macht es dies nur marginal sicherer.

Die Frage nach der benutzten Schlüsellänge im AES ist also am Ziel vorbei gestellt und eigentlich wenig sinnvoll. Die Gegenfrage sollte lauten: "Mit welchen Passwortlängen füttern Sie AES denn ?". Denn um AES 128Bit auszulasten müsste man ein Paswort der Länge 128 * 3.6 = 460 Bits / 8 = 58 ASCII Zeichen benutzen. Das benutzt heutzutage kein Mensch. Anders ausgedrückt: Diese Frage wurde gestellt weil sich der Anwender von den unprofessionellen Aussagen = Werbeversprechnungen Anderer in die Irre leiten lassen hat. Man sagt immer "unser AES arbeitet mit 256 Bits", schön, aber dann muß man auch Passwörter mit 115 Zeichen benutzen um die geforderte Sicherheit zu erlangen. Deshalb macht DEC dies eben abhängig vom Passwort und dann auch noch "overestimated", weil der Faktor 3.6 der Redundanz eines englischen/deutschen Passwortes garnicht berücksichtigt wird. Minimal eben 128 Bit und maximal 256 Bits.

Gruß Hagen

[Nikolas]

Da das jetzt geklärt ist, habe ich nur eine kleine Zwischenfrage:

Zitat:

Deshalb macht DEC dies eben abhängig vom Passwort und dann auch noch "overestimated", weil der Faktor 3.6 der Redundanz eines englischen/deutschen Passwortes garnicht berücksichtigt wird.

Verstehe ich das jetzt richtig, dass du hier von einem Wörterbuch ausgegangen bist und ausgerechnet hast, wie viele Buchstaben du von einem Wort brauchst um den Rest recht sicher raten zu können?

[negaH]

Nöö ;)

Es geht dabei um die Entropie in unserer Sprache im Vergleich zu der benutzten Codierung im ASCII Symbolraum. Ein ASCII benötigt für 256 Zeichen exakt 8 Bits pro Zeichen um das zu kodieren. Mit diesen Symbolsatz arbeiten wir in Computern. Aber wir benutzen in unseren Passwörtern nur eine geringe Anzahl von diesen Symbolen, dh. wir codieren unser Passwort nicht so optimal das es nicht weiter komprimierbar wäre. Eine verlustfreie Komprimierung ist immer ein Prozess bei dem Redundanzen entfernt werden, oder anders ausgedrückt die Entropie erhöht werden soll. Englische und Deutsche Wörter/Sätze entalten nur eine Entropie von ca. 3.6 Bit auf 8 Bit. Wir können solche Texte durchschnittlich um 55% komprimieren, einfach durch bloße Umkodierung im benutzten Symbolraum.

Ein Cipher benutzt aber den vollen Symbolraum des Passwortes, nur das unser Passwort nur 0.45 aus diesem Symbolraum real benutzt. Um das zu kompensieren müssen wir also exakt 2.2 mal längere Passwörter benutzen als wir Zeichen in unserem Cipher benutzen können. Beispiel: AES 128 Bit = 16 Symbole * 2.2 = 35 Zeichen Passwörter wären angebracht um die gleiche Sicherheit wie 128Bit binäre Zufallspasswörter zu erreichen. Da aber AES keine "Schlüsselkomprimierungsfunktion" benutzt können wie keine 35Zeichen = 35*8= 280Bit langen binären Paswörter benutzen. Maximal sind es 256 Bit = 32 Zeichen lange Passwörter die vergleichbar wären mit einem echten 115 Bit binärem Zufallspasswort. Also nochmal

AES 256 Bit = 32 Zeichen, 32 Zeichen Passwort entspräche in der Entropie einem 32 * 3.6 = 115 Bit binärem Zufalls Schlüssel. Ergo: werden die Passwörter ohne Preprozessing = Komprimierung der Entropie, benutzt so werden wir AES 256 Bit benutzen müssen und erreichen aber nur eine reale Sicherheit von 115 Bit Sicherheit. Da die meisten Tools Passwörter direkt mit AES benutzen, ja sogar fast alle, ist es logisch das man immer mit AES 256 verschlüsseln muß bei 32 Bytes Passwörtern aber nur real weniger als eine AES 128 Bit Verschlüselung an Sicherheit hat.

Es ist also enorm wichtig das das reale Passwort vorher in einen Sessionkey umgewandelt wird. Idel dazu sind KDFs -> Key Derivation Functions die aus Hash Algorithmen beruhen. Man kann dann ein zb. 72 Zeichen langes Passwort in einen 256 Bit langen binären Wert "komprimieren" (hashen). 72 Zeichen a 3.6 Bit / 8 Bit = 256 Bit. Die KDF entfernt quasi per Kompression, und Hashfunktionen sind Kompressorfunktionen, die Redundanzen im Passwort relativ gesehen zum benutzen Symbolraum des ASCII Zeichensatzes. Damit man also AES 256 wirklich sicher benutzen kann mit maximaler Sicherheit von 256 Bits MUSS man unbedingt vorher das Passwort in einen binären Sessionkey umwandeln und das Passwort muß 72 Zeichen enthalten. Macht man dies nicht, leider fast schon Standard, so kann man nur 32 Zeichen lange Passwörter benutzen. Man muß dann wirklich alle möglichen 256 Zeichen auch benutzen, was wir aber eben nicht tuen. Ergo entsteht eine reale Sicherheit von nur 115 Bits mit einem AES 256 Cipher.

Was ich damit im Grunde aussagen will ist das die Angabe "AES 256" rein garnichts aussagt und genauso sicher/unsicher sein kann wie ein AES 128 der korrekt benutzt wird.
Es wird also sehr oft dem Unkundigen mit Zahlenangaben imponiert (Werbung) ohne das es Relevanz hat.

Offline Brute Force Angriffe per Dictionaries/Rainbowtabellen beruhen exakt auf diesem Fakt. Ein zb. 6 Zeichen langes Passwort wäre vergleichbat mit einem 22 Bit langem Binärwert. Unser durch Brute Force Angriff zu durchsuchender Schlüsselraum beträgt also 2^22 = 4,2 Millionen Schlüssel. Das ist fast schon lächerlich wenig und zeigt auch das unser Online Banking schon fast lächerlich unsichere Schlüssellängen benutzt. Normal sollte man 128 Bit binäre Schlüssel benutzen um Brute Force ausschließen zu können. Einzigst der Fakt das nach 3 ungültigen Loginversuchen der Online Banking Server den Account sperrt verhindert solche Angriffe, wenn sie online durchgeführt werden. Sollte aber der Server hijacket sein und man kann eine offline Attacke auf die DB durchführen ist diese Sicherheitsstufe schon grob fahrlässig.

Gruß Hagen