Dateien verschlüsseln

[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