VerschlüsselungsProgramm

[Rackergen2]

Merke: Am sichersten ist es, eine Datei zwei Mal zu kodieren... Dann kommt keiner ran... :zwinker:

[negaH]

Zitat:

Merke: Am sichersten ist es, eine Datei zwei Mal zu kodieren... Dann kommt keiner ran...

Merke: Am UN-sichersten ist es einen Text zweimal oder mehrfach zu verschlüsseln !!

Zb. eine RC4 Verschlüsselung mit gleichem Passwort ZWEIMAL auf sich selber angewendet, entschlüsselt den vorher verschüsselten Text wieder. Logisch, da die Entschlüsselung-Funktion die gleiche ist wie die der Verschlüsselung. Bei allen XOR- und Streamverschlüsselungen trifft diese Aussage zu.
Da man beweisen kann das eine Zweifachverschlüsselung mit gleichen Passwort bei Stromverschlüsselungen eine Entschlüsselung zur Folge hat, kann man eine logische Beweiskette auch für andere Verschlüsselungen aufbauen. Nämlich: es ist 100% wahrscheinlich das man mit gleichem Passwort bei zwemaliger Verschlüsselung wieder entschlüsselt. Es ist nun sehr wahrscheinlich das dies mit unterschiedlichen Paswörtern EBENFALLS zur teilweisen Entschlüsselung führt. Es ist nun ebenfalls wahrscheinlich das man mit einer mehrfachen Blockverschlüsselung mit unterschiedlichen Passwörtern denoch eine Teilentschlüsselung durchführt.

Alle Kryptoexperten warnen daher vor Mehrfachverschlüsselungen, weil deren Auswirkungen den theoretischen Krypto.Design-Kriterien widersprechen. D.h. die Sicherheit in der Kryptiographie entsteht dadurch das man exakt vorausberechen und beweisen kann das ein Verfahren sicher sein MUSS. Man plant also auf mathematischen Wege mit Hilfe von Formeln eine Verschlüsselung. Nun, bei der Mehrfachverschlüsselung kann man die Auswirkugen eben nicht mehr planen und somit reduziert sich immer die tatsächliche Sicherheit. Aus einem klaren JA/NEIN wird ein ICH WEIS NICHT GENAU.

Zudem, mit einer starken Verschlüsselung die beweisbar sicher ist, ist es überhaupt nicht mehr notwendig mehrfach zu verschlüsseln, wozu soll das gut sein ?
Man kann damit die Sicherheit NIEMALS erhöhen da die Sicherheit nur so groß sein kann wie das stärkste Glied der Kette. Wird also 1 mal mit 128 Bit Blowfish verschlüsselt + 1 mal 96Bit DES dann ist die theoretische Sicherheit denoch nur 128 Bit, eben Blowfish. Logisch, denn wenn ich 128 Bit Schlüssel knacken kann dann kann ich dies auch mit 96Bit Schlüsseln. Da man allerdings nur Blowfish und DES unabhängig voneinander entwickelt und mathematisch designed hat, erhöht sich nun das Risiko das DES die Stärke vom Blowfish reduziert enorm. Somit kann man sagen das die theoretisch anzunehmende Sicherheit der Blowfish/DES Kombination bei 128 - 96 = 32 Bit liegt.
Da aber bisher noch kein Mensch mathematisch korrekte Berechnungen über ein solche Kombination durchgeführt hat, ist im Gegensatz zu den Einzel-Algorithmen die praktische Sicherheit der Kombination beider absolut UNBEWIESEN und somit faktisch 0.

Merke: Die Sicherheit der Kryptographie entsteht ausschließlich nur durch die mathematische Beweisbarkeit der verwendeten Algorithmen. Somit produziert NICHT der Verschlüsselungsalgorithmus das Sicherheitsgefühl sondern NUR das Wissen um die verwendete Mathematik. Man muß also mathematisch beweisen das die Sicherheit vorhanden ist. Sollte dies NICHT bewiesen worden sein, so ist die effektive Sicherheit 0 und die phsychologische Sicherheit sogar -x Prozent.

Mehrfachverschlüsselungen wurden heutzutage nur im Zusammenhang mit EINEM spezifischen Algorithmus analysiert. Und dann auch nur um die Entschlüsselung oder die relative Stärke des Verfahrens als Einzelverfahren zu untersuchen. Somit gibt es im Grunde keinerlei praktische Untersuchungen ob eine Mehrfachverschlüsslung mit verschiednenen oder gleichen Verfahren mit verschiedenen oder gleichen Passwörtern tatsächlich sicher ist.

Da es keine mathematischen Beweise für deren Sicherheit gibt, folgt ergo: Sicherheit der Merhfachverschlüsselung muß mit 0% angegeben werden.


About Hash-Verschlüsselungen :

Mit Hash-Funktionen kann man auch verschlüsseln. Diese Anwendung der Hashs nennt man MDC's = Message Digest Cipher. Dabei wird die Hashfunktion in eine Funktion umgewandelt die aus einem Passwort = Startwert = Seed einen Schlüsselstrom erzeugt. Dabei wird der Hash vom Hash vom Hash vom .... vom Hash erzeugt. Alle Zwischenresultate ergeben dann unseren Schlüsselstrom. Dieser Schlüsselstrom wird nun mit einer XOR Operation mit den Daten verknüpft und fertig ist eine Stromverschlüsselung auf Basis einer Hashfunktion.
Allerdings: es besteht kein Grund das man solche Verfahren anwenden sollte. Eher das Gegenteil ist der Fall, man sollte sie nicht nutzen da:
1.) Stromverschlüsselungen als solches die häufigst gebrochenen Algorithmen sind, siehe Differentielle Kryptoanalyse.
2.) es bei MDC nachweislich bewiesene Schwachstellen gibt.
3.) Hashfunktion als Einweg-Funktionen für ganz andere Aufgaben mathematisch konziptioniert wurden
4.) es mathematisch bewiesene und exakt auf Verschlüsselungsaufgaben hin entwickelte Verfahren gibt, nämlich die stink normalen Verschlüsselungsalgortihmen.

Anders ausgedrückt: Wenn man beim Hausbau das Fundament aus Fundament-Beton baut und den Dachstuhl aus Holz dann könnte man zwar auch das Fundament aus Holz und den Dachstuhl aus Beton bauen, aber man sollte trotzdem das probate Mittel zur Erfüllung eines spezifischen Zweckes benutzen. Soll heisen: willst du verschlüsseln so nutze einen anerkannten Veraschlüsslungsalgorithmus, benötigtst du digitale Fingerabdrücke oder Einwegkryptographie so nutze eine anerkannte Hashfunktion.


About prohibitäre Verfahren:

Ein Verfahren kann niemals geheim gehalten werden, punkt. Schon garnicht wenn man dem Anwender das Verfahren als Software zur Verfügung stellt. Auch wenn es NICHT als Source vorliegt so stellt der binäre Code nichts anderes als die Source dar. Somit sollte man NIEMALS damit argumentieren das eine prohibitäres Verfahren eben dadurch sicherer wird weil keiner das Verfahren kennt. Dies ist unlogisch und nicht beweisbar.
Das Gegenteil muß der Fall sein: WENN ein veröffentliches und breitbandig analysiertes Verfahren als sicher beweisen wurde dann und nur dann ist es zum heutigen Zeitpunkt tatsächlich sicher.

Willst du also Bewertungen DEINES Verfahrens von anderen Leuten haben so veröffentliche bitte dein Verfahren + mathematischen Beweis + Komplexitätsanalyse + Referenzangaben auf die verwendeten Einzelkomponenten und deren Kreuzverweise in die Fachliteratur + funktionierenden Source + Testvektoren. Dann schreibe noch einen 6 stelligen monitären Betrag aus und eventuell erbarmt sich ein Experte um deine Vermutungen zu bestätigen.

Aus Anwendersicht sind dies alles Gründe dafür DEINEM Verfahren nicht 1 Sekunde Zeit zu schenken.

Es ist schon ein kräftiger Tritt in den Fettnapf wenn nach 2 Stunden schon Leute herausfinden das dein Verfahren darin besteht den Text zu spiegeln. Dies kann man schon nicht mehr als schlechten Scherz abtuen.

Gruß Hagen

[MaBuSE]

Zitat:

Zitat von negaH

... Dabei wird die Hashfunktion in eine Funktion umgewandelt die aus einem Passwort = Startwert = Seed einen Schlüsselstrom erzeugt. ... Alle Zwischenresultate ergeben dann unseren Schlüsselstrom. Dieser Schlüsselstrom wird nun mit einer XOR Operation mit den Daten verknüpft und fertig ist eine Stromverschlüsselung auf Basis einer Hashfunktion.
Allerdings: es besteht kein Grund das man solche Verfahren anwenden sollte. Eher das Gegenteil ist der Fall, man sollte sie nicht nutzen da:
1.) Stromverschlüsselungen als solches die häufigst gebrochenen Algorithmen sind, siehe Differentielle Kryptoanalyse. ...

Hallo Hagen,
sehr interessant Dein Artikel ;-)

Ich habe oft kleinere Programme, bei denen ich Daten verschlüsseln möchte. (z.B. temp. Dateien)
Die verschlüsselten Daten sind meist "unwichtig" und eine Entschlüsselung würde wenig Sinn machen.
Das mache ich nur um mir nicht in die Karten schauen zu lassen.

Ich verwende auch einen Schlüsselstrom, der mit einem Seed festgelegt wird.
(RandSeed := Startwert) Der Schlüsselstrom wird allerdings durch den Zufallsgenerator von Delphi zur Verfügung gestellt :mrgreen:

Ich habe mir eine kleine Funktion geschrieben, um nicht mit Kanonen auf Spatzen zu schießen.
(Für diesen Zweck reicht eine "einfache" Verschlüsselung aus. Es muss ja nicht immer eine 4096bit Schlüssellänge mit einem starken Algorithmus verwendet werden.)

Es kommt also immer auf den Verwendungszweck an.

ps: Falls Sich jemand für den Code interessiert:

Delphi-Quellcode:

// written by MaBuSE, member of delphipraxis.net
function myCoder(s: string; password: Integer; decode: Boolean):string;
var
  i, c, x: Integer;
begin
  if decode then x := -1 else x := 1;
  RandSeed := password;
  Result := '';
  for i := 1 to length(s) do
  begin
    c := ord(s[i]);
    if c in [32..122] then
    begin
      c := c+(x*Random(90));
      if (c<32) or (c>122) then c := c-(x*90);
    end;
    Result := Result + chr(c);
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  // von Edit2 nach Edit3 mit Passwort aus Edit1 verschlüsseln
  Edit3.Text := myCoder(Edit2.Text, StrToInt(Edit1.Text), False);

  // und wieder von Edit3 nach Edit4 entschlüsseln.
  Edit4.Text := myCoder(Edit3.Text, StrToInt(Edit1.Text), True);
end;

[negaH]

Schau mal, nachfolgender Code ist die RC4 Verschlüsselung. Sie gilt als sicher und ich will dir mal zeigen wieviel Aufwand sie im Source darstellt. Schnell wird ersichtlich, das im Gegensatz zu deiner sehr unsicheren Methode, eine starke Verschlüsselung NICHT zwangsläufig auch aufwendig sein muß.

Delphi-Quellcode:

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

procedure RC4Init(var RC4: TRC4Context; const Key: String);
var
  R,S,T,K: Byte;
  U,L: Integer;
begin
  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 RC4Code(var RC4: TRC4Context; const Source; var Dest; Count: Integer);
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;

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

Gruß Hagen

[MaBuSE]

Zitat:

Zitat von negaH

Schau mal, nachfolgender Code ist die RC4 Verschlüsselung. Sie gilt als sicher und ich will dir mal zeigen wieviel Aufwand sie im Source darstellt. Schnell wird ersichtlich, das im Gegensatz zu deiner sehr unsicheren Methode, eine starke Verschlüsselung NICHT zwangsläufig auch aufwendig sein muß.

Delphi-Quellcode:

...
procedure RC4Init(var RC4: TRC4Context; const Key: String);
...
procedure RC4Code(var RC4: TRC4Context; const Source; var Dest; Count: Integer);
...
procedure RC4Done(var RC4: TRC4Context);

:shock:

Das ist alles?
So einfach geht das?

Danke, das werd ich mal austesten.

Ich hatte überlegt, meinen kleinen "unsicheren" Algorithmus in die CodeBase zustellen.
Aber jetzt Denke ich, Du soltest Deinen "sicheren" Algorithmus dort veröffentlichen.
Ich habe mal nachgesehen, zu Verschlüsselung ist noch kein Code-Schnippsel zu finden.

Wird das so angewendet?

Delphi-Quellcode:

var 
  x: TRC4Context;
  str1, str2: string;
begin
  str1 := 'unverschlüsselt';
  RC4Init(x,'Passwort');
  RC4Code(x, str1, str2, Length(str1));
  Rc4Done(x);
  WriteLn('verschlüsselt: ', str2);
end;

Das gibt bei mir Fehlermeldungen.
Kannst Du ein kleines Beisp. posten.

Danke.

[MaBuSE]

Zitat:

Zitat von MaBuSE

Danke, das werd ich mal austesten.

Wird das so angewendet?

Delphi-Quellcode:

var 
  x: TRC4Context;
  str1, str2: string;
begin
  str1 := 'unverschlüsselt';
  RC4Init(x,'Passwort');
  RC4Code(x, str1, str2, Length(str1));
  Rc4Done(x);
  WriteLn('verschlüsselt: ', str2);
end;

Das gibt bei mir Fehlermeldungen.
Kannst Du ein kleines Beisp. posten.

Hurra, es klappt.
Mit untyperisierten Parametern hab ich noch nicht so viel gearbeitet. ;-)

Delphi-Quellcode:

var
  x: TRC4Context;
  str1, str2, str3: string;
begin
  str1 := 'unverschlüsselt';
  setLength(str2,length(str1));
  RC4Init(x,'Passwort');
  RC4Code(x, str1[1], str2[1], Length(str1)); // verschlüsseln
  setLength(str3,length(str2));
  RC4Code(x, str2[1], str3[1], Length(str2)); // entschlüsseln
  Rc4Done(x);
end;

Danke auch an maximov, der hat's mir hier gezeigt :zwinker:

[maximov]

Also entschlüsseln geht bei mir doch nicht!? Bei dir

//edit: Verdammt! geht doch...aber nicht mit deinem code (mabuse). So muss sein:

Delphi-Quellcode:

var 
  x: TRC4Context; 
  str1, str2, str3: string; 
begin 
  readLn(str1);
  setLength(str2,length(str1)); 
  writeLn('text: '+str1);
  
  RC4Init(x,'Passwort'); 
  RC4Code(x, str1[1], str2[1], Length(str1)); // verschlüsseln   
  Rc4Done(x);
  
  writeLn('coded: '+str2);
  setLength(str3,length(str2)); 

  RC4Init(x,'Passwort'); 
  RC4Code(x, str2[1], str3[1], Length(str2)); // entschlüsseln 
  Rc4Done(x);
   
  writeLn('encoded: '+str3);
  readLn;
end.

Super sache! danke.

[MaBuSE]

Zitat:

Zitat von maximov

Also entschlüsseln geht bei mir doch nicht!? Bei dir

//edit: Verdammt! geht doch...aber nicht mit deinem code (mabuse). So muss sein:

Stimmt, ich hatte es genau so wie Du habe aber den Code zusammengefasst, damit ich nicht so viel posten muß (außerdem hatte ich alles mit TEdit Feldern gemacht)

Das hätte ich mal besser nach dem zusammenfassen noch mal testen sollen :oops:

[negaH]

Für Strings einfach einen overload machen:

Delphi-Quellcode:

function RC4Code(var RC4: RC4Context; 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;

Zur Verwendung von Random:

Der in Delphi/Borland PASCAL verwendete Random Algorithmus ist seit Borland PASCAL 4.1 immer schon der selbe, also über 15 Jahre schon. Es handelt sich dabei um einen LCG = Linear Congruential Generator = Reste Generator. Diesen findet man sehr sehr häufig, eben auch in JAVA, C usw. usw. LCG's sind sehr gut erforscht, auch in der Kryptographie und es sind die UN-sichersten Verfahren überhaupt (mal abgesehen von noch einfacheren). Wenn nun noch nicht das zweite Problem wäre, nämlich das es nur ein 32 Bit Generator ist. Dadurch ist die Länge des effektiven Passwortes immer auf 32 Bit beschränkt. Ihr solltet euch einschlägige Fachliteratur suchen und dort mehr über den LCG, LFSR, CFR usw. nachlesen. Die LCG's, fast egal in welcher Bitgröße sind heutztage sehr wohl knackbar.

Die Verwendung von Random() in der Kryptographie scheint meiner Meinung nach die meist empfohlene und die schwachsinnigste Idee unter Delphi Programmierern zu sein. An jeder Ecke im WEB stößt man auf solche Vorschläge und immer wieder muß man dazu sagen das die schlichtweg falsch sind. Im gleichem Atemzuge wird dann meistens behauptet das dies ausreichend sicher wäre, ABER NIEMAND hat dies jemals bei diesen Vorschlägen tatsächlich bewiesen. Diese Aussagen sind demzufolge alle unbewiesen, und andererseits gibt es genügend Fachliteratur in denen Matematiker bewiesen haben das LCGs kryptographisch unsicher und sogar nur bedingt in der Statistik zu gebrauchen sind.
Mal ganz davon abgesehen das die Verwendung von Random(), und dessen Seed durch Überschreibung als Passwort zu gebrauchen, den Programabfluß der Gesamtanwendung zb. für Statistische Zufallsauswertungen absolut durcheinander bringt. Man sollte Random() zur Erzeugung von Zufall applikationsweit betrachten und ihn auch nur dafür benutzen.

Das wohl schlechteste Beispiel für die Anwendung von Random() ist diesen zur Erzeugung eines OTP = One Time Password's = Einmal Passwortes zu gebrauchen. Dieses große Passwort wird dann meistens per XOR mit der Nachricht verknüpft. Diese propagierte Anwendung von Random() in einer OTP Verschlüssleung ist wohl das widersinnigste was ich gesehen habe. Eine OTP Verschlüsselung gilt als die 100% sicherste Verschlüsselung die man kennt. Aber eben NUR wenn das verwendete Passwort aus echtem puren Zufall besteht. Durch die Verwendung von Random() degradiert man die sicherere OTP Verschlüsselung auf fast 0 Sicherheit !!


Gruß Hagen

[negaH]

Ganz im Gegensatz zu Random(), kann man aber RC4 so umbauen das er als Zufallsgenerator dient der sogar statistisch gesehen weit besser als Random() selber ist.

Delphi-Quellcode:

var
  RC4Random: TRC4Context;

procedure RC4Seed(const Seed: String); 
begin
  RC4Init(RC4Random, Seed);
end;

function RC4Random: Cardinal;
type
  TRC4Cast = record
    FirstSBOX: Cradinal;
  end;

begin
// verschlüssele die dynamsiche SBOX von RC4Random.D mit sich selber und gebe die 4 ersten Bytes
// als Zufallswert zurück !!
  RC4Code(RC4Random, RC4Random.D, RC4Random.D, SizeOf(RC4Random.D));
  Result := TRC4Cast(RC4Random).FirstSBOX;
end;

initialization
  RC4Seed('');
finalization
end.

Da die SBOX 256 * 8 = 2048 Bit groß ist und die kryptographische Funktion vom RC4 eben deshalb so sicher ist weil man bewiesen hat das JEDE mögliche Kombination bei einem spezifischen Passwort exakt nach 2^2048 Bits sich erst wiederholt, können wir davon ausgehen das die maximale Periode dieser Zufallsfunktion 2^2048 Bits beträgt. Dabei stellt der Seed = Passwort nur den Index in diesen 2^2048 Bit Langen Bitstrom dar. Bei Random() wäre die maximale Period nur 2^32 Bits.

Gruß Hagen

PS: nun wird auch ersichtlich das RC4 eine 2048 Bit sichere Verschlüsselung darstellt, mehr geht nicht.