Dateien verschlüsseln

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

[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",
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 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

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