Dateien verschlüsseln

[St.Pauli]

Hi, ich suche ne einfache Komponente oder Source, die ich einbinden kann, um die Dateien von meinem Programm zu ver-/entschlüsseln...
Die ver-/entschlüsselung muss nicht aufwändig sein, und ich müsste es einfach aufrufen können (ver-/entschlüssel('Hallo.txt')...).

Kennt jemand so eine Komponente, oder kann jemand so ne Source posten?

PS: ist das hier richtig? :gruebel:

[PierreB]

Willst du nur Text verschlüsseln ?

Für Text gibt es einige (sehr unsichere) Verschlüsselungen wie ROT-13 oder Caesar. Such mal im Forum danach.

[idontwantaname]

wie wärs mit xor ??

Delphi-Quellcode:

function XORCrypt(Password,InputFilePath,OutputFilePath:String):Boolean;
var aktChar: Integer;
   InputFile, OutputFile: File of Byte;
   Buffer:Byte;
begin
  Result := False;

  try
    aktChar := 1;

    AssignFile(InputFile,InputFilePath);
    Reset(InputFile);

    AssignFile(OutputFile,OutputFilePath);
    Rewrite(OutputFile);

    while not Eof(InputFile) do
    begin
      if(aktChar > Length(Password)) then aktChar := 1;
      Read(InputFile,Buffer);
      Buffer := Buffer xor ord(Password[aktChar]);
      Write(OutputFile,Buffer);
      Inc(aktChar);
      Application.ProcessMessages;
    end;
  finally
    CloseFile(InputFile);
    CloseFile(OutputFile);

    Result := True;
  end;
end;

[3_of_8]

Das ganze kann man auch noch mit +einwert oder -einwert kombinieren. Man kann es auch mit einem Passwort machen, wenn man weiß wie. Falls Interesse besteht, erkläre ich es gern.

[idontwantaname]

Zitat:

Zitat von 3_of_8

Man kann es auch mit einem Passwort machen, wenn man weiß wie.

was meinst du damit ??
hast du soetwas wie den code, den ich oben gepostet hab, im sinne ??

[St.Pauli]

@ idontwantaname: [..]XORCrypt(Password,[..]

Wofür? :gruebel:

[DP-Maintenance]

Dieses Thema wurde von "Sharky" von "Windows API / MS.NET Framework API" nach "Object-Pascal / Delphi-Language" verschoben.
Das ist eigentlich alles Standard und hat nichts mit der API zu tun ;-)

[idontwantaname]

da kannst du ein passwort nehmen, bzw. musst, z.B. "affe", mit dem wird dann die datei verschlüsselt, du kannst aba auch in folgender zeile:

Delphi-Quellcode:

Buffer := Buffer xor ord(Password[aktChar]);

das ord(Password[aktChar]) mit einem wert zwischen 0..255 austauschen, die sicherheit ist jedoch dabei nicht allzu groß, da wenn man diesen wert weiß, die datei entschlüsseln kann ;)

[St.Pauli]

OK, Thannks @ all! :thumb:

Edit: Habs jetzt mal getestet, und kann nur sagen: :cyclops: :cyclops: GEIL!
Nach sowas hatte ich schon lange gesucht

[supermuckl]

nimm halt die komponente dcpcrypt.. damit kannste auch twofish, blowfish, rindajel, des usw verwenden

auch mit 5 zeilen dateien(streams) und text ver/entschlüsseln und zwar sicher

[Matze]

Zitat:

Zitat von St.Pauli

Edit: Habs jetzt mal getestet, und kann nur sagen: :cyclops: :cyclops: GEIL!
Nach sowas hatte ich schon lange gesucht

ABer sicher ist das überhaupt nicht.

Falls du etwas wirklich sicheres suchst, benutze das DEC, dec hagen reddmann.

[idontwantaname]

Zitat:

Zitat von Matze

ABer sicher ist das überhaupt nicht.

wie würdest du denn die datei entschlüsseln, wenn diese mit meiner funktion verschlüsselt wurde ?? (also, mir passwort)
denn ich denke, das ist gar nicht so leicht bzw. unmöglich !

[Matze]

Zitat:

Zitat von idontwantaname

wie würdest du denn die datei entschlüsseln, wenn diese mit meiner funktion verschlüsselt wurde ?? (also, mir passwort)
denn ich denke, das ist gar nicht so leicht bzw. unmöglich !

unmöglich ganz sicher nicht. Ich kenne mich da nicht gut aus, aber ohne allzu große Probleme kann man das knacken.

Nachtrag: Lies dir das hier mal durch.

[negaH]

Benutzt hier irgend jemand die Suche ?
oder schaut mal in der CodeLib rein ?

http://www.delphipraxis.net/internal...830&highlight=

ist eine sehr kompakte Unit die aber denoch sehr sichere Verschlüsselungen erlaubt.

Nochwas zum Aberglaube das XOR-Verschlüsselungen gleichbedeutend mit unsicherer Verschlüsselungen sind. Das ist schlichtweg falsch. Die XOR Operation als Operation innerhalb einer Verschlüsselung ist mathematisch gesehen absolut perfekt. Sie kippt/verändert ein Bit mit exakt 50% Wahrscheinlichkeit in einer Domain die aus 50%,50% -> eg. 0,1 Werten besteht. Sogesehen ist XOR als Operation eine der besten Möglichkeiten in der Verschlüsselung.

Was aber dabei wichtig ist ist die Frage mit WAS wird denn die Nachricht XOR verschlüsselt ? Und genau das ist der Punkt in dem die meisten XOR Verschlüsselungen, so wie die obige, absolut unsicher sind. Die meisten verchlüsseln XOR mit viel zu kurzen Schlüsseln und wiederholen stückchenweise immer den selben Schlüsseltext. Man nennt dies Schlüsselstrom, ein kontinuierlicher Strom von Bytes der von einem Initialschlüssel abhängig ist und mit der Nachricht XOR verknüpft wird. Ergo: ist dieser Strom von schlechter Qualität so wird das Ganze absolut unsicher. Hier mal eine Einstufung verschiedener Schlüsselströme:

1.) der sicherste ist der OTP basierend auf einem absolut zufälligem Schlüsselstrom. Nur das ist ein echter One Time Pad (es gibt nämlich viele andere Algorithmen die die Buchstaben OTP schamlos mißbrauchen).
Der Schlüssel beim OTP ist gleich dem Passwort, und dieses besteht komplett aus Zufallsdaten die nicht zb. durch Delphi Random erzeugt wurden. Dieser Schlüssel ist damit exakt so groß die die Nachticht selber und darf niemals wieder ein zweites mal benutzt werden.
Diese Form der Verschlüsselung ist die absolut sicherste Verschlüsselung, denn sie eben exakt auf Grund der mathematischen Eigenschaften der XOR Operation + dem Zufallspasswort mathematisch beweisbar sicher. Es ist mathematisch bewiesen wurden das es keinen Algorithmus geben kann der noch sicherer als ein solcher OTP ist. Begründung: bei einem OTP mit unbekanntem Passwort ist aus Sicht des Angreifers JEDE Nachrichtenkombination mit gleicher Länge zur Originalnachricht exakt gleichwahrscheinlich eine korrekte Lösung, ergo: nur mit dem absolut korrekten Schlüssel kann man exakt die originale Nachricht restaurieren. Die Verschlüsselungs-dichte ist also maximal, d.h. exakt gleich der Schlüssellänge und damit gleich der Nachrichtenlänge.

2.) die starken Verschlüsselungen, eben solche wie in den einschlägigen Standards und alle die im DEC integriert sind. Das sind schon wesentlich komplexere Verfahren. Essentiell geht es immer darum aus einem kurzen Passwort einen Strom von Bytes zu erzeugen der nicht vorhersagbar ist wenn man dieses Passwort nicht besitzt. Nicht vorhersagbar bezieht sich aber immer auf die entsprechenden Schranken. Das bedeutet im Idealfalle das man ein solches Verfahren nur knacken kann wenn man alle möglichen Schlüsselkombinationen durchprobieren muß. Ergo: die Schlüssellänge in Bits bestimmt die Gesamt-Maximal-Sicherheit des Systemes. Im besten Falle ist der Algorithmus so gut das er mit einem Zufallspasswort das die gleiche länge wie die Nachricht selber hat den in Punkt 1.) besprochenen idealem OTP entspräche. Kann man dies mathematisch beweisen so ist der Algorithmus definitiv sicher. Da im Normalfall aber das Passwort eben nicht die Länge der Nachricht hat und eben nicht per reinem Zufall gewählt wurde kann auch ein solcher starker Algorithmus niemals mathematisch 100% sicher sein. Die effektiven Schlüssellänge und die Qualtität des Schlüssels bestimmt dann als Alleiniges die Sicherheit. Jede Mehrfachbenutzung des gleichen Passwortes reduziert somit auch die Gesamtsicherheit aller vorherig verschlüsselten Nachrichten umd den Faktor 2. Logisch da das aus der Definition der 100%'tig sicheren Verschlüsselung, obiger Punkt 1.) OTP, ersichtlich wird.

3.) XOR Verschlüsselungen die solche Funktionen wie Delphi's Random() als Schlüsselstrom benutzen. Delphis Random ist ein LCG=Linear Congruential Generator und mit seinen 32Bit viel zu kurz. LCG's sind an sich schon schlechte Pseudozufallsgeneratoren und in der Kryptographie verpönt, weil sie eben knackbar sind.

4.) XOR Verschlüsselungen die das Passwort direkt als Schlüsselstrom benutzen. Das ist wohl die übelste und unsicherste Form überhaupt. Der obige Algo. ist ein solcher. Ich schicke dir eine Nachricht die in weiten Teilen nur aus Nullen=$00 besteht und du schickst mir das verschlüsselte Resultat zurück. In dieser Nachricht kann ich in 1 zu 1 Form dein benutztes Passwort ablesen. Somit entsteht folgende Situation:

Du glaubst das dein Verfahren sicher ist und verlässt dich darauf. Ich weis das dein Verfahren unsicher ist und nutze das aus um dich zu schädigen.

Wenn man garnicht verschlüsselt so beträgt die Sicherheit exakt 0 Prozent. Wenn man mit solchen Verfahren wie oben verschlüsselt beträgt die Sicherheit exakt -100 %, in Worten: minus hundert Prozent. Denn du glaubst es ist sicher und ich weis das es unsicher ist. Während du dich also 100'prozentig in Sicherheit wähnst habe ich deine Daten mit 100% Wahrschenlichkeit schon längst geknackt. Übrig bleibt wweit eniger als 0 Prozent Sicherheit, sozusagen 100% Un-Sicherheit.

Fazit: obigen Algorithmus zu benutzen grenzt an Sabotage, denn er ist unsicherer als garnicht zu verschlüsseln. Denn wenn ich man nicht verschlüsselt weis man das es unsicher sein [b]muß[/]. Benutzt man obigen Algorithmus dann wähnt man sich sicher obwohl es definitiv unsicher ist. Es sollte logischerweise wohl jedem von euch einleuchtend sein das dies gefährlicher ist als garnicht zu verschlüsseln.

Gruß Hagen

[idontwantaname]

okay, okay, ich gebe mich geschlagen, ihr habt gewonnen :duck:

Zitat:

Zitat von negaH

Fazit: obigen Algorithmus zu benutzen grenzt an Sabotage, denn er ist unsicherer als garnicht zu verschlüsseln. Denn wenn ich man nicht verschlüsselt weis man das es unsicher sein muß. Benutzt man obigen Algorithmus dann wähnt man sich sicher obwohl es definitiv unsicher ist. Es sollte logischerweise wohl jedem von euch einleuchtend sein das dies gefährlicher ist als garnicht zu verschlüsseln.

also, wenn man obigen - unsicheren - algorhytmus zur verschlüsselung benutzt, dann soll das unsicherer sein, als das man die daten unverschlüsselt lässt ... :roll:

[Sharky]

Zitat:

Zitat von idontwantaname

... dann soll das unsicherer sein, als das man die daten unverschlüsselt lässt ...

Ja!

Denn dann weisst Du das jeder an die Daten kommt. Wenn Du sie unsicher verschlüsselst dann glaubst Du das keiner an die Daten kommt.

Mann kann das ganze auch ganz extrem sagen:
Jeder Algorithmus denn DU nicht als sicher beweisen kannst muss von Dir als unsicher eingestuft werden.

(Uff.. daraus folgt ja das ich das DEC als unsicher einstufen muss *g*)

[Robert Marquardt]

Nicht zu vergessen die Turbopower Lockbox. http://www.sf.net/projects/tplockbox

[idontwantaname]

Zitat:

Zitat von Sharky

Zitat:

Zitat von idontwantaname

... dann soll das unsicherer sein, als das man die daten unverschlüsselt lässt ...

Ja!

Denn dann weisst Du das jeder an die Daten kommt. Wenn Du sie unsicher verschlüsselst dann glaubst Du das keiner an die Daten kommt.

Mann kann das ganze auch ganz extrem sagen:
Jeder Algorithmus denn DU nicht als sicher beweisen kannst muss von Dir als unsicher eingestuft werden.

(Uff.. daraus folgt ja das ich das DEC als unsicher einstufen muss *g*)

schon klar, trotzdem denke ich, das jemand, der einen text vor sich hat, den inhalt leichter erfährt, als wenn jener den gleichen text mit einer unsicheren verschlüsslungsmethode (wenn auch nur ROT13) vorsich hat

[negaH]

Zitat:

schon klar, trotzdem denke ich, das jemand, der einen text vor sich hat, den inhalt leichter erfährt, als wenn jener den gleichen text mit einer unsicheren verschlüsslungsmethode (wenn auch nur ROT13) vorsich hat

Ich glaube du willst es nicht begreifen. Du postest hier einen Source Code und behauptest das es eine Verschlüsselung ist. Ein naiver Programmierer nimmt deinen Code und baut ihn in seine Anwendung ein weil er denkt das das eine simple und gute Verschlüselung ist. Diese Software verkauft er an ein Unternehmen das sich natürlich auf die Aussagen zur Sicherheit des Programmieres verlässt. Alle glauben ihre Daten wären sicher und keiner aus sie selber könnten sie lesen. Falsch gedacht denn dein Code ist absolut unsicher. Nun tätigt die Firma eine geheime und wertvoll Transaktion und natürlich denkt der Verantwortliche ads seine Daten mit deinem Algorithmus sicher wären vor Spionage. Sein Konkurrent hat aber hier in die DP geschaut und weis das es eben nicht sicher ist. Er entschlüsslt die Nachrichten seines Konkurrenten, ermfährt so das dieser im Kostenvoranschlag mit 2 Mio Euro rechnet und schwups macht er ein Gegenangebot mit 1.7 Mio Euro. Der Kunde der deinen Algo. benutzt verliert also Geld. Ergo: statt den fast sicheren 2 Mio Euro hat er garnichts, er muß Leute kündigen und zahlt nen Berg Schulden ab.

Hätte er aber in vollem Bewusstsein das seine Konkurrenten ihn ausspionieren komplett auf die Verschlüsselung verzichtet so hätte er erst garnicht den Fehler gemacht ein Angebot zu schreiben das 2 Mio hoch ist. Stattdessen eben gleich auf 1.5 Mio runter damit keiner seiner Konkurrenten den Auftrag bekommt.

Fazit: Analytisch betrachtet bedeutet also keine Verschlüsselung ebenfalls eine Art von Sicherheit, denn ich weis mit Gewissheit das es unsicher sein muß und kann andere Maßnahmen ergreifen. Die größte Unsicherheit ist somit der Punkt wenn man nur vertrauen kann, nur glauben kann und es eben nicht definitiv weis ob was sicher oder unsicher ist.

Wie gesagt, test es doch einfach aus. Erzeuge eine Datei die aus lauter $00 besteht und verschlüssel sie mit einem Passwort. Danach öffnest du diese mit einem HEX Editor undschaust sie dir genau an.

Gruß Hagen

[St.Pauli]

Zitat:

Zitat von negaH

Ein naiver Programmierer nimmt deinen Code und baut ihn in seine Anwendung ein weil er denkt das das eine simple und gute Verschlüselung ist.

Ich hoffe du hast damit nicht mich gemeint :wink:

Zitat:

Zitat von negaH

Du postest hier einen Source Code und behauptest das es eine Verschlüsselung ist. Ein naiver Programmierer nimmt deinen Code und baut ihn in seine Anwendung ein weil er denkt das das eine simple und gute Verschlüselung ist. Diese Software verkauft er an ein Unternehmen das sich natürlich auf die Aussagen zur Sicherheit des Programmieres verlässt.

Was meinen Teil betrifft, hätte ich vieleicht das Thema anders nennen sollen. Eigentlich brauchte ich keine hochsichere Verschlüsselung, sondern nur etwas, was mir einfach meine Optionen "verändert" aka auf den ersten Blick unleserlich macht^^. Das wenn ein PC-Normalo vieleicht mal die Optionen öffnet, er nicht erkennen kann, was Sache ist, oder sogar die Optionen über Editor ändern kann^^.

Deswegen kam mir auch der Code von idontwantaname super gelegen, einfach aufrufbar!

[idontwantaname]

ich habe bereits zugegeben, dass es sich um eine unsichere verschlüsselung handelt !

noch was zu meiner verschlüsselung:
würde sie soetwas sicherer machen, also, wenn ich mit dem folgendem code aus dem passwort einen key erstellt ??
ich meine aber nur etwas sicherer, nicht ganz sicher
KeySize sollte der größe der datei entsprechen

Delphi-Quellcode:

function XOR_KeyGen( const Password : String ; const KeySize : Integer ) : String;
var
  PassSum : Integer;
  Loop    : Integer;
  Key     : String;
begin
  PassSum := 0;
  for Loop := 1 to Length( Password ) do
    Inc( PassSum , Ord( Password[Loop] ) );

  Randomize;
  RandSeed := PassSum;

  Key := '';
  for Loop := 1 to KeySize do
    Key := Key + IntToStr( Random(10) );

  Result := Key;
end;

[negaH]

Jain, es würde leicht sicherer weil es komplexer ist. Auf der Stufe der verschiedenen Schlüsselströme wäre es Punkt 3.) und die Gefahr das man aus der Nachricht selber den Schlüssel extrahieren kann ist ein kleines bischen geringer. Aber im Grunde für einen Profi absolut kein Hindernis, weil eben Random() mit 32Bit zur kurz ist und der Algo., ein LCG, ein direkt reversibler Algo. ist, man kann ihn also "zurückrechnen".
Die effektive Schlüsselgröße wird also reduziert. Angenommen man benutzt 16 Bytes = 128Bit Schlüssel so würde dieser durch die Anwendungvon Random() auf 32 Bit verkürzt.

Ich sage es mal so:

Es gehört ne Menge Mathematik dazu um Verschlüsselungsalgorithmen entwickeln zu können. Dabei darf man niemals, so wie wir als Programmierer vorgehen, nach der Methode Trial&Error verfahren. Hinter den meisten anerkannten Algorithmen stehen ganz abstrakte mathematische Formeln. Wir als Laien würden in diesen Formeln niemals vermuten das sie einen Verschlüsselungsalgorithmus ergeben.

Ich beschäftige mich nun seit über 5 Jahren mit der Materie, und ehrlich gesagt würde ich mir es auch heute noch nicht zutrauen einen wirklich guten Verschlüsselungsalgorithmus zu bauen.
Deshalb empfehle ich immer: nehmt einen anerkannten Algorithmus, es gibt wirklich sehr sehr einfache wie RC4, Blowfish etc. pp. und baut ihn wenn überhaupt nötig an eure Erfordernisse um.

Auch wenn es nur zum "unleserlich" machen von Daten geht, die Arbeit macht man dann nur einmalig. Oder eben gleich hier in der CodeLib die RCx Sourcen nehmen, immerhin poste ich das hier nicht ohne Sinn.

Ich habe mir mit der Zeit verschiedene Design-Kriterien zur Beurteilung geschaffen. Sie sind mein persönlicher Maßstab, basieren damit nur teilweise auf wissenschaftlichen Grundlagen und teilweise auf meinem Bauch-Gefühl:

1.) ist der Algo. schön kurz ? Verständlichkeit/programtechnische Schlichtheit=gut
2.) benutzt er druchgängig 32Bit Operationen ? Geschwindigkeit=gut
3.) setzt er alle Schlüsselbits gleichmäßig verteilt in seinen internen Status um ? Schlüsselbits sind sehr wertvoll, kein Bit an Information darf verloren gehen und sollte direkt die Ausgaben des Algos. beeinflussen. Sicherheit=gut
4.) woher stammt der Algo. ? hat ihn ein Programmierer oder ein Professor entwickelt ? ist er ein militärischer oä.Standard ? Vertrauenswürdigkeit/Fachkenntnisse=gut
5.) ist es eine vollkommen symmetrische Konstruktion oder eher eine bijektive symmetrische Konstruktion ? es gibt symmetrische Cipher die jeweils unterschiedliche Formeln zur Ver- und Entschlüsselung benötigen, siehe auch IDEA oder hier in der CodeLib meine Abwandlung des RC5 Ciphers = RCx. zahlentheoretische Komplexität=gut
6.) benutzt er komplexere Operationen ? sprich Multiplikation, modulare Divisionen, fortlaufende Zähler, Transpositionen, Lookuptables == SBOX algorithmische Komplexität=gut
7.) wie sieht das Key-Sheduling aus ? -> heist wie arbeitet der Algo. im Schlüsselsetup den Schlüssel in seinen internen Status ein. Benutzt er direkt den Schlüssel = schlecht, benutzt er ausreichend große interne Speicher = besser. angepasste Schlüsselaufbereitung=gut
8.) Welcher Klasse von Algo. gehört er an ? ist es eine Stromverschlüsselung oder eine Blockverschlüsselung ? Algorithmenklasse=modern, Stromverschlüsselungen sollte man vermeiden.
9.) wie groß ist die Verarbeitungsbreite intern ? 128 Bit's sollten es mindestens sein Berechnungskomplexität=je höher je besser, aber mehr als 256 Bits sind schon wieder schlecht Warum sollen 1024 Bits schlechter als 128 Bits sein ? Ein sich sicherer Kryptograph muß abwägen zwischen Berechnungskomplexität, resultierender Sicherheit, praktischen Notwendigkeiten und dem Machbaren. Mein Bauchgefühl sagt mir bei Algos. die sehr lange Schlüssel benutzen können/müssen das sich der Entwickler nicht sicher war, er also meinte lieber mit fetten Kannonen geschossen als zu wenig Geschütze aufgefahren zu haben. Ein guter Entwickler der weis was er macht legt die Berechnungskomplexität aber beweisbar so knapp wie möglich fest, damit sein Algorithmus auch schnell und ausreichend einfach bleibt und denoch sicher ist.
10.) ist die Portierbarkeit gegeben ? je portierbarer=umso besser Unter Portierbarkeit versteht man nicht nur Windows PC und Linux Rechner, sondern auch kryptographische Hardware wie SmartCards, MCUs, CPLD's und FPGA's, ebenso alle anderen exotischen Rechenmachinen bis hin zum einfachsten Kopfrechnen oder Rechnen auf dem Papier. Ein Algo. der sowohl als auch auf all das portierbar ist und denoch sicher bleibt ist schwer zu designen. Hat ein Entwickler aber offensichtlich das ebenfalls im Design berücksichtig dann ist er erfahren und mit Bedacht vorgegangen. Auch dies ist wiederum ein Vertrauenskriterium=Fachwissen vorhanden
11.) sind fundierte wissenschaftliche Abhandlungen und Kryptoanalysen fremder Kryptographen vorhanden ? Wissenschaftlichkeit/Verifizierbarkeit/Anerkannt=gut

All dies sind einfache Maßstäbe, einige sind Bauchentscheidungen, und die meisten haben rein garnichts mit fundierter Kryptoanalyse zu tun. Möchte man also definitiv einen Algo. einstufen so reichen obige Kriterien nicht aus, das dürfte wohl klar sein. Aber wir als Programmierer und ungebildete Mathematiker können eine wissenschaftliche Abhandlung über einen Verschlüsselungsalgortihmus bei weitem nicht begreifen (auf alle Fälle nicht einfach so aus dem Stand heraus ohne Vorbildung). Ergo sind solche Abhandlung aus unserer Sicht zwar schön und gut aber im Grunde sinnlos und nicht aussagekräftig für uns. Deshalb meine Vorgehensweise mehr auf allgmeingültige Maßstäbe zusetzen.

Gruß Hagen

[negaH]

Delphi-Quellcode:

function XOR_KeyGen( const Password : String ; const KeySize : Integer ) : String; 
var 
  PassSum : Integer; 
  Loop    : Integer; 
  Key     : String; 
begin 
// 1.)
  PassSum := 0; 
  for Loop := 1 to Length( Password ) do 
    Inc( PassSum , Ord( Password[Loop] ) ); 

// 2.)
  Randomize; 
// 3.)
  RandSeed := PassSum; 

// 4.)
  Key := ''; 
  for Loop := 1 to KeySize do 
    Key := Key + IntToStr( Random(10) ); 

  Result := Key; 
end;

So nun zur Analyse deines Keysetups:

bei 1.) reduzierst du die Komplexität des übergeben Schlüssels auf 32 Bit. Angenommen man übergibt einen Schlüssel von 128 Bit länge dann wäre es 1 aus 2^128 möglichen Schlüsseln. Bei Punkt 2.) steht in PassSum=32Bit nur noch 1 aus 2^32 möglichen PassSum Werten drinnen. Ergo: es gehen wertvolle Schlüsselinformationen verloren und die effektive Sicherheit beträgt nur 32 Bit.

bei 2.) rufst du unnötiger weise Randomize() auf obwohl bei 3.) RandSeed := PassSum gesetzt wird. Das gibt mir zwei wichtige Hinweise: Du hast keine Ahnung von Programmierung, ergo kein fundiertes Fachwissen oder du arbeitest schlampig und hast vergessen deinen Testcode zu entfernen. Beides reduziert mein Vertrauen in deine Arbeit auf Null. Sorry das ich das so hart und deutlich sagen muß, aber es ist leider nun mal fakt. Und du kannst nichts lernen wenn man keine ehrliche Kritik übt. Nehme mein Aussagen also sportlich und nicht persönlich, bitte ;)

bei 4.) setzt du nun noch einen drauf. Zuerst hast du die Schlüsselkomplexität künstlich reduziert und dann expandierst du virtuell wieder die Schlüssellänge damit es nach mehr aussieht. Solche Vorgehensweisen werden üblicherweise immer dann benutzt wenn der Entwickler des Algorithmus absichtlich die Sicherheit reduzieren will oder muß. "Muss" auf Grund von Exportbestimmungen oder weil er für verschiedene Organsitationen arbeitet die kein Interesse an echter Sicherheit für uns haben. Man könnte sowas Sabotage nennen, oder Unterminierung der realen Sicherheit. Denn lange Schlüssel bedeuten nicht zwangsläufig mehr Sicherheit.

Die effektive Komplexität des so erzeugten Schlüssel ist maximal 32 Bit groß. Also selbst wenn du mit KeySize = 1024 = 8192 Bits arbeitest so kannst du durch die Benutzung von Random()->RandSeed nur maximal 2^32 verschiedene Schlüssel aus einer Menge von 2^8192 real möglichen Schlüssel erzeugen. Ergo: aus einem verfügbaren Schlüsselraum von 2^8192 Schlüsseln werden maximal nur 2^32 mögliche Schlüssel benutzt. Man verschenkt also 2^(8192-32) = 2^8160 Schlüssel Kombinationen. Je größer nun KeySize wird desto schlimmer wird dieses Mißverhältnis.

Gruß Hagen

[DXler]

@alle:

Ich gebe auch mal meinen "Senf" dazu: meiner Meinung nach ist eine Verschlüsselung mit Hilfe eines Paßwortes sicher, denn der Angreifer weiß ja nicht, welches Paßwort genutzt wurde.

Zu dem Beispiel von negaH:

Wenn jemand tatsächlich das verschlüsselte Angebot in die Hände bekommt kann er zwar durch ausprobieren versuchen den Schlüssel zu finden, aber er hat ein "Problem": welches Verschlüsselungsverfahren wurde benutzt?

Ich kenne mich mit Verschlüsselungsverfahren zwar nicht aus, aber mir erscheint es logisch, das in der verschlüsselten Nachricht KEIN Hinweis steht, mit welchem Verfahren verschlüsselt wurde. Also muß der Angreifer erstmal sämtliche Verfahren durchprobieren, bis er das richtige gefunden hat. Wobei das natürlich voraussetzt, das er neben dem richtigem Verfahren auch einen Anhaltspunkt bezüglich Schlüssel hat. Hinzu kommt noch, das er wissen muß, was für einen Dokumenttyp er vor sich hat => PDF-Datei, Bild, Word-Dokument usw.

Wenn jetzt wirklich der Beispielcode aus dem Posting benutzt wurde, muß der Angreifer diesen erstmal finden! Damit will ich sagen: zuerst muß erstmal der Gedanke kommen hier im Forum nach einem Verschlüsselungsverfahren zu suchen...

Ich glaube kaum das es jemanden gibt der hier im Forum gezielt danach sucht, wenn er ein Verfahren knacken will und mit den üblichen Verschlüsselungsverfahren nicht weiter kommt.

Außerdem bin ich davon überzeugt, das eine komplexe Verschlüsselung u. U. einfach zu entschlüsseln ist. Das heißt: wenn ich z. B. eine komplexe mathematische Formel habe, ist es u. U. möglich diese so zu vereinfachen, das am Ende das gleiche Ergebnis dabei herauskommt.

Eins muß man sich immer vor Augen führen: eine sichere bzw. perfekte Verschlüsselung gibt es nicht, denn sie wurde von Menschen entwickelt. Und es ist eine unumstößliche Tatsache das wir Menschen nicht perfekt sind...


Zum Schluß möchte ich allerdings eine "Herausforderung" an die Krypto-Experten hier im Board aussprechen: wer schafft es die angehängte Datei zu entschlüsseln?

Da es meiner Meinung nach unmöglich sein wird die Datei zu entschlüsseln, gebe ich ein paar Hinweise die das Ganze ein bißchen vereinfachen sollen.


Hilfen:

- die Datei ist nicht gepackt,
- es ist eine Textdatei,
- kein bekanntes Verfahren wurde angewendet (zumindest weiß ich nicht, das es das schon gibt),
- das Verfahren basiert auf einer Paßwortverschlüsselung,
- das Paßwort hat eine Länge von 12 Zeichen

Viel Spaß beim Probieren! :-D :wink:

[uschi]

jo jetzt sagen die "experten" nix mehr.


merkwürdig.

[SubData]

[OT]
Ich liebe Threads in denen Hagen postet... Da lernt man was und kann sich auch nochn bissi amüsieren :>
[/OT]

[DXler]

So.... 28 Tage sind vergangen und keiner hat die Herausforderung für sich klar entscheiden können.

Und was zeigt uns das?

1) die von mir gewählte Verschlüsselung ist als sicher "einzustufen", :wink:
2) das Interesse am "Entschlüsseln" ist auch nicht besonders groß (zumindest hier im Forum),

Also kann man (nach der "Wichtigkeitspriorität" geordnet) seine Daten durchaus mit einem "unsicheren" Verfahren verschlüsseln, da das Forum hier wohl nicht als "Verschlüsselungs-Suchfeld" in Betracht kommt, denn sonst wären bestimmt einige darauf gekommen mich zu fragen, ob ich u. U. das eine oder andere Verfahren (leicht oder stark abgeändert) benutzt hätte.

Da solche Anfragen ausblieben, kann ich davon ausgehen, das hier im Forum nicht intensiv danach gesucht wurde!

Ebenso zeigt mir die Anzahl der Downloads, das das Interesse an so einer Herausforderung nicht wirklich groß ist.


Damit wäre für mich persönlich dieses Thema "abgehakt".

[negaH]

Zitat:

1) die von mir gewählte Verschlüsselung ist als sicher "einzustufen",
2) das Interesse am "Entschlüsseln" ist auch nicht besonders groß (zumindest hier im Forum),

1) falsch
2) falsch

Es sagt uns nur das bisher keiner das Interesse hatte sehr wichtige Daten mit deinem Verfahren zu verschlüsseln und 2. das bisher noch keiner die Notwendigkeit hatte Daten die mit deinem Verfahren verschlüsselt wurden zu knacken und 3. sagt uns das, daß schon mehr als 100 Hacker insgeheim die Daten von Millionen von Kunden, die ihre Daten mit deinem Verfahren gesichert hatten, geknackt haben und natürlich werden sich diese Hacker hüten dir das auf die Nase zu binden. Unsichere Verfahren werden immer im Geheimen geknackt, das Gefährliche an solchen Verfahren ist es eben das ein Codebreaker der ein Verfahren geknackt hat im Grunde nie ein Interesse hat das an die Öffentlichkeit zu bringen. Um so wichtiger wird es das DU der Welt exakt beweisen kannst das dein Verfahren auch sicher ist.

Wenn du willst das dein Verfahren als sicher eingestuft wird dann hast du die verdammte Pflicht und Schuldigkeit uns hieb- und stichfest zu beweisen das DEIN Verfahren sicher ist. Nicht wir oder andere Experten sind dafür verantwortlich. Das keine allzugroße Resonanz auf dein Posting erfolgte wird also eher daran liegen das keiner deinem Verfahren traut.

Gruß Hagen

[MrKnogge]

Zitat:

Zitat von DXler

die von mir gewählte Verschlüsselung ist als sicher "einzustufen"

Du solltest aber auch beachten, dass der böhse Unbekannte wahrscheinlich nicht nur deine "verschlüsselte" Datei hat, sondern eben auch noch dein Programm und einen Hex-Editor :wink:

[mimi]

und was würdet ihr zu so einenm verfahren sagen:
du hast eine datei zerlegst sie in gruppen und zwar soviele gruppen wie der user angeben hat beispiel:

der user möchte 20 gruppen anlegen diese 20(mit unterschliedlichen längen) gruppen werden z.b. mit einer xor verschlüsslung verschlüsselt und es werden verschiende passwörter erzeug wobei die gruppenzahl der init wert von random ist. d.h. wenn du gruppe 1 entschlüsseln möchtes musst du erstmal die länge wissen.
beispiel:
Das Programm legt die Gruppe 1 und und die ist 20 byte groß und die nächste gruppe ist 19 byte groß.

und soweiter. dann währe z.b. so ein password dekbar:
5,20,30,20,10,100,200

wobei zwischen den komas die längen sind.

wie lange braucht man um eine datei mit diesem verfarhren zu entschlüsseln.....
weil es gibt ja 10000000000000000 möglichkeiten.
wisst ihr wie ich das meine ?
(ich habe dieses verfahre noch nicht geschrieben)

[MrKnogge]

Dann probier es doch einfach mal aus, nur kann man bei dir leider dann sein passwort nicht selber wählen, das passwort sieht zu dem noch "verdächtig" aus, und zuletzt: was will der Benutzer dann mit bsp. 20 Dateien ?
Wenn er sie per E-Mail verschicken möchte, wünsche ich ihm viel spass.
Gut. Er kann alle Dateien markieren und anschl Drag&Drop, aber freuen würd ich mich darüber trotzdem nicht.

Bitte les nochmeil deinen Beitrag durch, ich sehe da noch ein paar ungereimtheiten,
erst sagst du der user gibt an wieviele gruppen erstellt werden sollen, dann sagst
du dass die gruppenanzahl per random festgelegt wird.

Zitat:

Zitat von mimi

wenn du gruppe 1 entschlüsseln möchtes musst du erstmal die länge wissen

Wenn du die einzelne Gruppe in einer Datei hast, dürfte das nicht allzuschwer sein,
du müsstest schon alle Dateien wieder zusammenfügen.

Eine weitere unklarheit, du schreibst das für die xor verschlüsselung der einzelnen blöcke verschiedene passörter erzeugt werden, aber diese passwörter benötigt du auch für die entschlüsselung, soll sich der Benutzer 20 passwörter merken ?

Und last but not least:
Du hast eine Datei, von sagen wir 100 MB teilst sie in 20 gruppen auf:
dann müsste der böhse unbekannte also eigentlich "nur" 20 5MB große Stückchen
kracken.

gruss

[DXler]

@negaH:

Zitat:

Es sagt uns nur das bisher keiner das Interesse hatte sehr wichtige Daten mit deinem Verfahren zu verschlüsseln

Das ist klar, denn das Verfahren wurde erst vor kurzem entwickelt bzw. dahingehend weiterentwickelt, das es einsetzbar ist!

Zitat:

und 2. das bisher noch keiner die Notwendigkeit hatte Daten die mit deinem Verfahren verschlüsselt wurden zu knacken

Richtig! Begründung: s. oben

Zitat:

und 3. sagt uns das, daß schon mehr als 100 Hacker insgeheim die Daten von Millionen von Kunden, die ihre Daten mit deinem Verfahren gesichert hatten, geknackt haben und natürlich werden sich diese Hacker hüten dir das auf die Nase zu binden.

Diese Aussage trifft wohl nicht zu => s. ganz oben :wink:

Zitat:

Unsichere Verfahren werden immer im Geheimen geknackt, das Gefährliche an solchen Verfahren ist es eben das ein Codebreaker der ein Verfahren geknackt hat im Grunde nie ein Interesse hat das an die Öffentlichkeit zu bringen. Um so wichtiger wird es das DU der Welt exakt beweisen kannst das dein Verfahren auch sicher ist.

hmmm.... Ok. Die Frage ist nur: wie soll ich den Beweis erbringen? Mehr als eine verschlüsselte Datei veröffentlichen kann ich ja wohl kaum oder?

Zitat:

Wenn du willst das dein Verfahren als sicher eingestuft wird dann hast du die verdammte Pflicht und Schuldigkeit uns hieb- und stichfest zu beweisen das DEIN Verfahren sicher ist.

s. oben

Zitat:

Nicht wir oder andere Experten sind dafür verantwortlich. Das keine allzugroße Resonanz auf dein Posting erfolgte wird also eher daran liegen das keiner deinem Verfahren traut.

Wohl ehr daran, das es noch nicht bekannt ist! :wink:


@MrKnogge:

Zitat:

Du solltest aber auch beachten, dass der böhse Unbekannte wahrscheinlich nicht nur deine "verschlüsselte" Datei hat, sondern eben auch noch dein Programm und einen Hex-Editor

Das kann er ruhig haben! Nützen wird es ihm aber bestimmt nichts. Da bin ich mir SEHR sicher.

[MrKnogge]

Zitat:

Zitat von DXler

hmmm.... Ok. Die Frage ist nur: wie soll ich den Beweis erbringen? Mehr als eine verschlüsselte Datei veröffentlichen kann ich ja wohl kaum oder?

Doch, veröffentlich erstmal dein verschlüsselungstool, später dann den quellcode.
Wenn es einem Hacker nicht gelingt deine Datei zu kracken, selbst wenn er das Verschlüsselungsverfahren kennt, dann ist es ein sicheres Verfahren.

[edit]Habe das quote versehentlich verunstaltet[/edit]

[Gina]

Hallo,

da hier grad so schön über die Sicherheit von Verschlüsselungsalgorithmen diskutiert wird... Mir brennt da schon seit einiger Zeit eine Frage auf dem Herzen ;)

Es geht um das OpenSource-Produkt TrueCrypt.

Dieses bietet eine Container- oder Festplattenverschlüsselung an. Man kann zwischen verschiedenen Algorithmen wählen. Der Key wird vom Programm generiert unter Nutzung einiger "zufälliger" Gegebenheiten (Mausbewegung, Tastendrücke Netzwerklast... etc.) Das scheint alles ganz supi zu sein.

Nehmen wir mal an, ich wähle AES 256 Bit. Das ist ein anerkannter Algorithmus, zu dem ich auch großes Vertrauen habe. Aber...

Der Key, der generiert wird, wird im Header abgelegt. Auch der Algorithmus und weitere Informationen. Also alles, was nötig ist, um den Containerinhalt zu entschlüsseln. Der Header ist mittels eines selbst zu wählenden Passwortes verschlüsselt. Wie genau, das hab ich bisher nicht verstanden. Das Passwort selbst ist ebenfalls (indirekt) im Header abgelegt. Wenn das richtige Passwort eingegeben wurde, dann steht im Header der ASCI-String "TRUE". Eine Rolle dabei spielt auch noch der zu wählende Hash-Algorithmus (SHA1 oder RIPEMD-160). Die Iteration ist fest 2000.

Die Sicherheit der Verschlüsselung ist also nicht die Sicherheit von AES, sonder m.E. "nur" die Sicherheit der Header-Verschlüsselung...

Die Dokumentation zu TrueCrypt findet man hier. Ab Seite 31 stehen die technischen Details.

@Hagen:
Ich würde mich riesig freuen, wenn du vielleicht mal Zeit hast und dir das Verfahren mal anschauen könntest. Deine Meinung ist mir sehr wichtig ;) Mein Bauch sagt mir, dass es unsicher ist. Aber vielleicht täusche ich mich auch, da ich die Headerverschlüsselung nicht verstanden habe. Im TrueCrypt-Forum konnte mir sie auch keiner erläutern...

Falls also jemand mir erklären könnte, was mit dem Header passiert, wäre das total supi... :kiss:

Tausend Dank, liebe Grüße, Gina.

[mimi]

ich meinte es eigetnlich anders:
du hast eine datei in diese datei werden z.b. Gruppen erstellt die du a: per random feslegen kannst(anzahl und lenge) und b: manuell festlegen kannst.

z.b. könntes du z.b. die einzelden gruppene einfach mischen und dann würde es warscheinlich zeit brauchen bis der richtige text raußkommt. Verstanden ?
du hast z.b. 20 Gruppen diese werden in einer einzigsten datei gespeichert(in der qulldatei) und sehen z.b. so aus:
12345,12445252,5425677,2452524,546677,84626,
das , ist nur vorstellen gedacht jetzt in wirklichkeit soll es ohne , gehen

[MrKnogge]

aber wenn du anzahl und länge per random festlegst, dann musst du diese ja speichern (was dieses verfahren aber sinnlos macht) oder der user muss sie beim nächsten mal zum entschlüsseln per hand eingeben was ich für wirklich umständlich halten würde.

[mimi]

es würde ja reichen wenn der start wert einmal festgelegt wird und zwar könnte der sich aus der Gruppenanzahl + Längen ergeben(irgenwie...).
du als anwender sollst dir nur mekren:wieviele gruppen und welche anzahl haben sie z.b. so:

10=5,9,3,5,....

das heißt jetzt:
die gruppen anzahl ist 10
Gruppe 1:= hat eine länge von 5
Gruppe 2:= hat eine länge von 9 und soweiter.
aber warscheinlich ist dieses verfarhen sehr einfach zu knacken... aber für ebend schnell dürfe es reichen

[DXler]

MrKnogge:

Zitat:

Doch, veröffentlich erstmal dein verschlüsselungstool, später dann den quellcode.
Wenn es einem Hacker nicht gelingt deine Datei zu kracken, selbst wenn er das Verschlüsselungsverfahren kennt, dann ist es ein sicheres Verfahren.

Das Programm kann ich veröffentlichen (nach Absprache). Der Quellcode bzw. die Verschlüsselungstechnik ist nicht öffentlich zugänglich, da ich als "Mitentwickler" zwar einiges darüber weiß, aber die Rechte an dem Verfahren nicht mir gehören.

Die liegen bei der neXt generation Software und die möchte, verständlicherweise, das Verfahren kommerziell nutzen.

[negaH]

Hi Gina,

ich habe mal die Doku vom TrueCrypt reingezogen. Das sieht sehr gut aus, bzw. anders ausgedrückt ich habe selten eine Software gesehen die so detailiert auf die eigenen Schematas eingeht. Teilweise meine ich das die Programmierer von TrueCrypt sogar versucht haben viel zu viel Sicherheit zu implementieren. Zb 2 Punkte sind mir aufgefallen:

1.) Der Header enthält keine Infos über die benutzten Algorithmen. Selbst TrueCrypt muß mit einem Trial&Error Verfahren den Header mit jedem möglichen Algo. entschlüsseln um den richtigen zu finden. Das halte ich für üebrtrieben, und verhindert eine Brute Force Attacke nur sehr wenig. Angenommen wie bei True Crypt gibt es 8 verschiedene Algos. Bei einer Schlüssellänge von 256 Bits wären das dann statt 2^256 Kombinationen eben 2^256 * 8 = 2^260 Kombinationen. Also nicht so viel ausschlaggebend mehr.

2.) TrueCrypt benutzt kaskadierte Verschlüsselungen. D.h. es verschlüsselt die Daten zb. bis zu 3 Mal nacheinander mit 3 verschiedenen Ciphern und 3 verschiedenen Passwörtern. Allgmein sagen die Experten das man dies auf keinen Falle machen sollte. Man sollte sich also auf einen einzigsten Algo., wie AES, alleine beschränken. Die Auswirkungen einer Mehrfachverschlüsselung sind bei weitem noch nicht tiefgreifend erforscht.

Ansonsten lässt die Doku nur Gutes vermuten. Sie halten sich an annerkannte Standardalogs. aus dem PKCS# Standard. Und zum Glück nur an die Version 5. denn die neueren Versionen vom PKCS# sind buggy. Desweiteren stellen sie sicher das bestimmte sensitive Speicherbereiche besonders geschützt werden, sehr gut. Auch die Algorithmen-Auswahl gefällt mir sehr gut: AES, Serpent, Tripple DES, Blowfish CAST5, SHA und RipeMD sind alles gute Algos. Sie könnten die "Bedienungssicherheit" noch erhöhen wenn sie sich auf AES + SHA alleine beschränkt hätten. Ein sehr gutes Zeichen ist die Verwendung von "Key-Derivation-Functions", sprich zb. den HMAC's um aus den Passwörtern sichere Sessionkeys zu erzeugen.

Gruß Hagen

[Gina]

Hi Hagen,

vielen lieben Dank für deine Antwort. :kiss: Auch wenn mich deine Worte sehr beruhigen ;), möchte ich es gerne etwas genauer wissen... :oops:

Heißt das, der Header wird mit PKCS#5 verschlüsselt?

Und wozu wird SHA1 oder RIPEMD-160 benutzt? Und dieser Zufallswert (Salt), der in den ersten Bytes abgeöegt ist? Normalerweise würde man doch damit ein Passwort verschlüsseln um es zu speichern. Das wird doch aber nicht getan. (oder?) Verschlüsseln damit geht ja nicht, da die beiden Algos ja nicht umkehrbar sind... :gruebel:

Und was genau passiert bei dieser Key-Derivation-Function?

Fragen über Fragen...

Tausend Dank, Gina.