VerschlüsselungsProgramm

[devnull]

Hi,
ich hab jetzt doch mal, angeregt von anderen Tools ein eigenes Programm geproggt.
Dies ist jedoch nur eine Demo-Version, bei der es euch erlaubt ist
> EINFACHE TEXTE
> MAXIMAL 1000 ZEICHEN
zu kodieren.

:firejump: Naja, über keine Kritik würde ich mich freun.

devnull

[Matze]

Naja, der Text wird einfach umgedreht. ;)

Aus "Hallo du da" wird "ad ud ollaH".

Ob das sehr sicher ist ;)

[Gregor]

ja etwas nicht sicher :)

[Ultimator]

Nein, ich würde sogar sagen: "Gar nicht sicher" ;-)

[flomei]

har har... Ich könnte ein Anti-Programm schreiben... :twisted: ;)

Texte umdrehen ist aber wirklich kein bisschen sicher... :roll:

MfG Florian :hi:

[Filou]

Hallo!

Du könntest folgende Verschlüsserlungs-Algorythmen verwenden
- Caeser-Verlschlüsserlung (Bsp: aus "abc" wird "bcd")
- md5
- RSA


Tschau!

[Filou]

Zu md5 könnten dir folgende Artikel helfen:
http://www.delphipraxis.net/internal...&highlight=md5
http://www.delphipraxis.net/internal...&highlight=md5
cu

[edit=sakura] Links, nicht Suche... Mfg, sakura[/edit]

[Luckie]

Mit MD5 verschlüsseln? :gruebel: Das musst du mir mal zeigen.

[alcaeus]

Zitat:

Zitat von Luckie

Mit MD5 verschlüsseln? :gruebel: Das musst du mir mal zeigen.

Soviel ich weiß brauchst du nur in den phpBB-Sourcen nachsehen, phpBB verschlüsselt AFAIK das User-Passwort mit MD5.

Greetz
alcaeus

[fkerber]

Hi!
Das Problem an MD5: Oneway.
Man kann zwar Passwörter damit verschlüsseln, kann dann aber die Eingabe nur auch verschlüsseln und dann die verschlüsselten vergleichen, entschlüsseln geht nicht.

Ciao fkerber

[StefanDP]

Es ist definitiv nicht möglich, etwas mit md5 zu verschlüsseln und später wieder zu entschlüsseln!
(md5 ist eine "einbahnstraßen-verschlüsselung")

passwörter werden mit md5 verschlüsselt, gerade WEIL man sie nicht entschlüsseln kann

stefan

[atreju2oo0]

Hierbei dürfte der Trick auch darin liegen das der MD5 String
mit dem in der Datenbank gespeicherten verglichen wird und es
somit nicht zu einer Entschlüsselung kommt.
Deshalb kriegt man bei vergessenem Passwort auch so gut wie nie
das eigene PW zugeschickt sondern ein Neues.

[edit] na das war wohl nix... zu spät :drunken: [edit]

[phXql]

das haben die meisten MOD-verschlüsselungen so ansich, dass man sie nich mehr entschlüsseln kann :mrgreen:

[devnull]

HEY LEUTZ,

DAS WAR EIN WITZ

:zwinker:

[phXql]

dann wars aber kein guter ;)

[TeronG]

Zitat:

Zitat von devnull

DAS WAR EIN WITZ

:zwinker:

hihi .. DAS hätte ich jetzt aber auch gesagt! :wink: :mrgreen:

[Kernel32.DLL]

Muahahaha!

Cooler Witz, echt!

Muahahaha!

//Das war ein Witz... :roll:

[gekmihesg]

also ich habe mich belustigt gefühlt....

[Rackergen2]

Mal ne dämliche Frage: Was ist bei dir der Unterschied zwischen kodieren ud dekodieren? :zwinker:

[supermuckl]

lol der war gut :D

[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.

[Luckie]

Ich bekomme hier immer einen Integer Overflow:

Delphi-Quellcode:

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);  // <== hier!!!
      T    := D[S];
      D[S] := D[R];
      D[R] := T;
    end;
  end;
end;

Anwendung:

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);

Delphi Version: D6 Personal.

[negaH]

Logisch, das ist die Funktion im RC4 Algorithmus, eben eine Modulo 256 Operation. In diesem Sinne ist in meinem Code alles in Ordnung und der Code setzt absichtlich auf das Verhalten das bei der Addition eines Bytes +x beim Überlauf eine modulo 256 Operation impliziert ausgeführt wird.
Allerdings, ich gebe dir Recht das dies einem klar definierten Verhalten eines Sources ohne Fehler widerspricht.

Man könnte es so umschreiben:

Delphi-Quellcode:

R := (R + D[S] + K) mod 256;

wobei dann aber der Compiler ineffizienteren Code erzeugen muß da er das Zwischenresultat von "R + D[S] + K" nicht mehr im Bereich Byte sondern Word oder sogar Integer durchführen muß. Desweiteren muß dann das Zwischenresultat mit $FF maskiert werden, eben modulo 256. Dies ist wiederum ein zusätzlicher Maschinenbefehl.

Sogesehen habe ich so programmiert das ohne Überlaufprüfungen der Compiler den "effizientesten" Code erzeugen muß. Der gemeldete Überlauffehler ist also für die korrekte Funktionsweise des Algorithmus irrelevant. (ein fehlerhafter Fehler :) )

Gruß hagen

[Luckie]

Und wie bekommt man so was dann zu laufen? :gruebel:

[negaH]

Compileroptionen->Bereichsüberprüfung->aus.

Oder im Source mit dedingter Compilierung.

Delphi-Quellcode:

{$IFOPT R+}
  {$DEFINE INSUFFICIENT}
{$ENDIF}

{$IFOPT Q+}
  {$DEFINE INSUFFICIENT}
{$ENDIF}

{$IFDEF INSUFFICIENT}
  {$R-, Q-}
{$ENDIF}


function RC4Code().. bla bla



{$IFDEF INSUFFICIENT}
  {$R+, Q+}
  {$UNDEF INSUFFICIENT}
{$ENDIF}

Oder direkt in der betroffenen Prozedure, da $R/$Q eben nur lokal gültig sind:

Delphi-Quellcode:

procedure RC4Code();
begin
  {$R-, Q-}
  

... bla bla.

end;

Allerdings musste ich feststellen das dies nur abhängig von der Delphi Version funktioniert !!
D.h. in bestimmten Delphi Version werden diese Compilerswitches einfach ignoriert.

Gruß Hagen

[negaH]

Die Bereichsüberprüfung, bzw. eben das Rangechecking, sollte man NUR zur Entwicklugszeit aktivieren. In den Finalen Versionen sollte man IMMER ohne Debug/Überlaufprüfungen etc. compilieren.

Da in den meisten Fällen der Rangcheck immer nur dort anschlägt wo man es NICHT möchte aber fast NIEMALS dort anschlägt wo es sinnvoll wäre deaktiviere ich dies Überprüfung in meinen Sourcen von vornherein.

Überläufe selber sind Designtechnische Probleme, d.h. sie können nicht entstehen wenn der Programmierer die richtigen Algorithmen und Datentypen von vornhinein korrekt wählt.

Enstehen diese in meinen Sourcen denoch dann kann ich mit 99.99%'tiger Sicherheit dafon ausgehen das sie erwünscht sind, eben Datentypenabhängige Modulo Operationen.
Bei der Entwicklung vom DEC mit seinen viele verschiedenen Algorithmen die fast ALLE mit solchen 2^(2^x) Modulo-Operationen arbeiten, hatte ich anfangs mit vielen Supportmails zu kämpfen. Ich baute dann eine eigene INCLUDE VER.INC die standardmäßig folgende Switches setzt:

Delphi-Quellcode:

{$A+,B-,E-,F-,G+,H+,I-,J+,K-,N+,P+,Q-,R-,S-,T-,V+,W-,X+,Y-,G+}

{$IFDEF VER80}  { Delphi 1.0     }
  {$DEFINE VER_D1}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER90}  { Delphi 2.0     }
  {$DEFINE VER_D2}
  {$DEFINE VER_D2H}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER100} {Borland Delphi 3.0 }
  {$DEFINE VER_D3}
  {$DEFINE VER_D3H}
  {$DEFINE VER_D2H}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER120} {Borland Delphi 4.0 }
  {$DEFINE VER_D4}
  {$DEFINE VER_D4H}
  {$DEFINE VER_D3H}
  {$DEFINE VER_D2H}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER130} {Borland Delphi 5.0 }
  {$DEFINE VER_D5}
  {$DEFINE VER_D5H}
  {$DEFINE VER_D4H}
  {$DEFINE VER_D3H}
  {$DEFINE VER_D2H}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER140} {Borland Delphi 6.0 }
  {$DEFINE VER_D6}
  {$DEFINE VER_D6H}
  {$DEFINE VER_D5H}
  {$DEFINE VER_D4H}
  {$DEFINE VER_D3H}
  {$DEFINE VER_D2H}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER150} {Borland Delphi 7.0 }
  {$DEFINE VER_D7}
  {$DEFINE VER_D7H}
  {$DEFINE VER_D6H}
  {$DEFINE VER_D5H}
  {$DEFINE VER_D4H}
  {$DEFINE VER_D3H}
  {$DEFINE VER_D2H}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER93}  { Borland C++Builder 1.0 }
  {$DEFINE VER_BCB1}
  {$DEFINE VER_BCB1H}
{$ENDIF}

{$IFDEF VER110} { Borland C++Builder 3.0 }
  {$DEFINE VER_BCB3}
  {$DEFINE VER_BCB3H}
  {$DEFINE VER_BCB1H}
{$ENDIF}

{$IFDEF VER125}
  {$DEFINE VER_BCB4}
  {$DEFINE VER_BCB4H}
  {$DEFINE VER_BCB3H}
  {$DEFINE VER_BCB1H}
{$ENDIF}

{$IFNDEF VER80}           { Delphi 1.0     }
 {$IFNDEF VER90}          { Delphi 2.0     }
  {$IFNDEF VER93}         { C++Builder 1.0 }
    {$DEFINE VER_D3H}     { Delphi 3.0 or higher }
    {$IFNDEF VER100}
      {$DEFINE VER_BCB3H} { C++Builder 3.0 or higher }
      {$IFNDEF VER110}
        {$DEFINE VER_D4H} { Delphi 4.0 or higher }
        {$IFNDEF VER120}
           {$DEFINE VER_D5H}
           {$IFNDEF VER130}
              {$DEFINE VER_D6H}
              {$IFNDEF VER140}
                 {$DEFINE VER_D7H}
              {$ENDIF}
           {$ENDIF}
        {$ENDIF}
      {$ENDIF}
    {$ENDIF}
  {$ENDIF}
 {$ENDIF}
{$ENDIF}

{$IFDEF VER_D7H}
  {$A4} 
  {$WARN UNSAFE_TYPE OFF}
  {$WARN UNSAFE_CODE OFF}
  {$WARN UNSAFE_CAST OFF}
{$ENDIF}

Mit {$I VER.INC} wird dann gleich hinter UNIT XYZ; diese Versions Include eingebunden. Dies hat eben auch den Vorteil das man viel einfacher die verschiedenen Delphi/BCB Compiler erkennen kann.

Delphi-Quellcode:

unit XYZ;

{$I VER.INC}

interface

uses SysUtils;


implementation

const
{$IFDEF VER_D1}
  M1 = 'Delphi Version 1.0';
{$ENDIF}
{$IFDEF VER_D2}
  M1 = 'Delphi Version 2.0';
{$ENDIF}
{$IFDEF VER_D3}
  M1 = 'Delphi Version 3.0';
{$ENDIF}
{$IFDEF VER_D4}
  M1 = 'Delphi Version 4.0';
{$ENDIF}
{$IFDEF VER_D5}
  M1 = 'Delphi Version 5.0';
{$ENDIF}
{$IFDEF VER_D6}
  M1 = 'Delphi Version 6.0';
{$ENDIF}
{$IFDEF VER_D7}
  M1 = 'Delphi Version 7.0';
{$ENDIF}
{$IFDEF VER_D2}
  M1 = 'Delphi Version 2.0';
{$ENDIF}
{$IFDEF VER_D3}
  M1 = 'Delphi Version 3.0';
{$ENDIF}
{$IFDEF VER_D4}
  M1 = 'Delphi Version 4.0';
{$ENDIF}
{$IFDEF VER_D5}
  M1 = 'Delphi Version 5.0';
{$ENDIF}

initialization

  ShowMessage(M1);

{$IFDEF VER_D3H}
  ShowMessage('Delphi Version 3.0 oder höher');
{$ENDIF}  

{$IFNDEF VER_D6H}
  ShowMessage('mindestens Delphi 6.0 wird benötigt'); 
{$ENDIF}
end.

Gruß Hagen

[Luckie]

Hm, ach so ja gut. So ganz sauber finde ich das persönlich aber nicht, denn die Idee hatte ich auch schon gehabt.

[negaH]

Hm, das hängt davon ab: ist der Source nicht sauber an den Compiler angepasst oder ist der Compiler in seinen Fähigkeiten nicht korrekt an die Möglichkeiten der Hardware angepasst.

Ich persönlich habe nun seit BP 4.1 miterleben können wie unsicherer und ungenauer die Überlauf-Prüfung im Compiler wurde. Von Version zu Version entstanden in der Überlaufprüfung immer mehr Lücken und andererseits schlug diese Überprüfung immer häufiger dort an wo sie es nicht sollte.

Nungut, man kann den Source wie oben geschrieben abändern um ihn wieder 100%'tig konform zu machen, oder aber man benutzt die Compilerswitches dafür wozu sie eigentlich auch da sind, und deaktiviert die Überprüfungen, WENN man weiß was man tut :)

Gruß Hagen

[Rackergen2]

Zitat:

Zitat von 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 !!

Das war ein Witz, der sich speziell auf diesen "Verschlüsselungs"-Algorithmus bezogen hat...

[negaH]

Tja und wieder ein Witz, Joke oder so. Hier im Forum hatten wir es erst mit solchen coolen Witzen ;)

Gruß hagen

[dizzy]

[ot]muss ich jetzt mal los werden...
Ich finds immer wieder zum schießen mit euch! So im Umgang sind hier wirklich alle immer sehr nett und die meisten haben auch ganz schön den Schalk im Nacken :thuimb:. Eine richtig schön lockere Schmunzel-Atmosphäre!
Postet aber jemand mal ein scherzhaft gemeintes Programm, so hagelt es ernsthafte Verbesserungsvorschläge noch und nöcher :lol: --- die Helf-Disziplin hier ist einfach die beste *g*. Sehr löblich an sich, nur geht so einem scherzhaften Proggie da gewaltig der Witz verloren... was irgendwie ja auch schon wieder spassig ist.
Informatiker haben halt sehr viel Humor, aber der erstreckt sich wohl oft nicht bis in ihr Fachgebiet :)
[/ot]

ps: Das ist keine Kritik, sondern eine mich amüsierende Feststellung. (Ist ja auch nicht immer leicht ein so gemeintes Scherzprogramm von Programmen die ein schlechter Scherz sind zu unterscheiden ;))

n8i,
dizzy