[HaBo]

hackerboy

Anzeige

hi leute,

bin neu in diesem Forum und habe sogleich eine Frage:

Wie programmiere ich mir einen Algorithmus zum Verschlüsseln von dateien?
Er sollte ziemlich knacksicher sein.

Habe schon gegooglet aber irgendwie bin ich bin ich nicht fündig geworden.
Könnt ihr mir weiterhelfen?


Vielen dank schon mal im Vorraus.

:::Lük:::

Wenn du das Ganze als Übung ansiehst solltest du das hier lesen: http://de.wikipedia.org/wiki/Verschl%C3%BCsselung

Wenn dir die Sicherheit des Algos wichtig ist dann schau dir das hier an bzw. verwende gleich TrueCrypt: http://de.wikipedia.org/wiki/Advance...ption_Standard

Janus

Weißt du überhaupt, was ein Algorithmus ist? Wie stehen deine Noten in Mathe?

Es gibt außerdem keine 100%igen "knacksicheren" Algorithmen. Brute Force hilft immer.

Außerdem find ich deinen Nick scheiße. Sorry, is so ^^ Fühl dich jetzt nicht beleidigt, aber "Hackerboy" hört sich schon kindisch an :-)

vv4yn3

Dieses Verfahren ist nicht zu knacken, unabhängig von der zu Verfügung stehenden Zeit und Rechenleistung: Einmalschlüssel-Verfahren

Dafür halt etwas umständlicher bei der Benutzung als andere Verfahren.

menace

schaue dir den Source von ncrypt[1] zum Beispiel an. Alternativ kannst du Bibliotheken wie crypto++ oder openssl oder cryptlib verwenden. Selber einen Algorithmus zu erstellen, darüber solltest du nicht nachdenken, denn das kannst du nicht (in dem Fall würdest du einfach nicht fragen, entschuldigung, aber so ist es)

Ich empfehle AES, Twofish, Serpent oder falls mal ausgefallener Cast oder XTEA

Heinzelotto

ich hasse es, solche demotivierenden Aussagen zu hören.

Ich an deiner Stelle würde nicht gleich (falls es denn als Übungsaufgabe gedacht ist) versuchen, einen der heutigen häufig hochkomplexen algorithmen zu implementieren, sondern stattdessen vielleicht erstmal mit nem einfachen anzufangen, z.B. Caesar, vignere...

menace

Ich hasse sowas ja auch und es tut mir ja leid für ihn. Aber immer noch besser, er weiss die Wahrheit, als dass er keinen "knacksicheren" Algorithmus entwirft, sich auf den verlässt und dann voll in die Scheisse fällt.
Und sichere kryptographische Algorithmen zu entwerfen (geschweige dann auch noch zu implementieren), ich glaub das können weit weniger, als Linuxtreiber zu programmieren.
Ich bin garantiert der letzte, der Neulinge demotivieren will. Aber wenn ihr Algorithmus dann geknackt wird, sind sie sicher noch schlechter drauf.

:::Lük:::

Danke!
Das kam mir auch sofort in den Sinn als ich menaces Post gelesen habe. Evtl. bedenkt man mal, dass die Leute die Algorithmen wie AES, Blowfish etc. entwickelt haben auch nur Menschen sind.
Mit so einer Einstellung kommt man nie weit.

Das errinert mich ein bischen an mich vor 3 Jahren: Ich wollte unbedingt ein Spiel programmieren, hatte aber null Ahnung davon, wie soetwas gehen sollte.
Damals habe ich auf den (freundlichen) Rat eines Forums hin mit kleineren Projekten angefangen und sehe mich heute durchaus in der Position eine kleinere 3D-Anwendung realisieren zu können (mittlerweile haben sich meine Interessen verschoben).

Also @hackerboy: Deinem Post nach lässt sich tatsächlich erahnen, dass du noch nicht viel Erfahrung hast. Leih dir erstmal ein Buch über Programmierung vllt. sogar schon für 3D-Programmierung (Stichwort DirectX) und arbeite dich dort etwas ein; glaub mir, wenn du dich wirklich dafür interessierst, dann wirst du früher oder später was erreichen. Welches Buch dafür am besten geeignet ist und welches nicht, dazu gibt es hier tausende treads.

Und wer weiß, vllt. halten wir in Zukunft irgendwan mal unknackbare Verschlüßelungssoftware von Hackerboy in den Händen

menace

Diese Menschen machen aber schon über 20-30 Jahre zum Teil Mathematik (Rivest, Shamir, Schneier, Adleman, Cramer Shoup). Und zum Bauen von guten Algorithmen braucht man nunmal extrem gute Mathematikkenntnisse. Wenns als Übungsaufgabe gemeint ist, okay, aber nicht wenns wirklich produktiv angewandt werden soll.
Man, es gibt ja noch nichtmal nen Leitfaden, nach dem man bei kryptoAlgorithmen vorgehen kann. Ich mein das nicht böse, aber bleibt bitte mal auf dem Teppich.
Soll der KryptoAlgorithmus *gut* und *sicher* sein? Wenn nein, dann helfe ich gerne und gebe soweit ich kann auch designtipps. alles andere ist einfach sinnlos.

ausserdem ist es keine schande, vorhanden libraries zu benutzen oder vorhandene algorithmen zu implementieren.
Die Aussage "das sind auch nur Menschen" ist, als würdest du eine Konkorde mit einer Doppeldeckermaschine vergleichen, mit der du über den Pazifik fliegen willst.

:::Lük:::

Natürlich ändert meine Ausgage nichts daran, dass es verdammt schwer ist, soetwas zu implementieren; ich wollte damit sagen das es nicht unmöglich ist wie du es beschrieben hast, sondern durchaus einen Versuch bei dem man seine Erfahrungen macht, wert ist.

menace

Ich habe nichts gegen Versuche, ich hab selber genügend experimentiert. Nur sollte man sich dann auch von erfahreneren Leuten sagen lassen, dass es ziemlich sicher in die Hose geht. Denn man kann die Sicherheit der Chiffre meist noch nicht mal einschätzen (es gibt im übrigen ausser dem reduzieren des angriffsaufwands noch keine möglichkeit die sicherheit von (v.a. symmetrischen) kryptoalgorithmen zu messen)

und mit unmöglich meine ich das wie mit dem 6er im Lotto und gleichzeitig vom blitz getroffen werden. Kann schon passieren. aber halt sehr sehr unwahrscheinlich

Ich wiederhole: die Erfahrungen die man beim Implementieren macht, sagen auch nichts über die Sicherheit aus. Ausser man lässt Statistiktests drüberlaufen, dann weiss man aber auch schon wieder mehr wo und wie man anpacken muss.

Gnome

Implementieren kann das jeder Hansel, das iszt ja nicht die Herausforderung. Aber einen Algorithmus zu schreiben, der sicher ist ist ein ganz anderes paar Schuhe. Um einen fertigen Algorithmus zu implementieren braucht man nur grundkenntnisse der genutzten Sprache. Um den Algorithmus zu verstehen braucht man in den meisten Fällen mehr oder weniger gute Mathematikkenntnisse (und vor allem welche weit abseits der Schulmathematik). Um einen eigenen Algorithmus zu entwickeln und dessen Sicherheit abschätzen/beweisen zu können braucht man _wirklich_ viel Ahnung von Mathematik und sollte vermutlich die populärsten bereits existierenden Algorithmen verstehen.

Und was anderes hat menace auch nie gesagt:

Einen existierenden Algorithmus zu implementieren dürfte auch für einsteiger relativ schnell möglich sein.

Elderan

Hallo,
jeder kann einen Algorithmus entwerfen, den er selber nicht knacken kann. Aussagen muss dies aber noch gar nichts.

Unmöglich nicht, in der Kryptographie lernt man aber relativ wenig durch try and error. Gut, die simpelsten Algorithmen kann man evt. noch selber knacken, aber dann hört es schon auf. Und wirklich viel Erfahrung erhält man durchs selber entwickeln von Algorithmen auch nicht, bzgl. was evt. die Sicherheit von zukünftigen Algorithmen betrifft lernt man nicht viel.


Das ist nicht so nicht ganz war.
Es gibt bestimmte Design-Kriterien die man durchaus überprüfen kann, und sofern der Algo. diese erfüllt, man schon einen Hinweis auf einen vermutlich starken Algorithmus hat.

Hier man die kurze Anleitung für Blockalgorithmen:

Das simpelste ist noch das Random Oracle Model, welches man auch sehr gut überprüfen kann.
Man gibt in seinen Algorithmus verschiedene Eingaben, die absolut nicht zufällig sind, und hinten raus müssen scheinbar zufällige Daten kommen.
Ein Beispiel ist, man gibt aufsteigende Zahlen (z.B. 0 bis 1 Mio.) bei einem festen Key ein, und die Ausgabe muss zufällig aussehen.
Dann kann man das gleiche mit dem Key machen, man nimmt einen fest Klartext (z.B. 0000...) und arbeitet dann mit aufsteigenen Keys (fängt bei 000.. an, dann 00...01 usw.).
Der Geheimtext muss wieder zufällig aussehen.

Hier ist das größte Problem wie man zufall feststellt. Es gibt eine FIPS-Testbatterie für Zufallsgeneratoren, welche in verschiedenen Tests ermittelt, ob die Zufallszahlen gut sind. Hat man diese erstmal implementiert (oder verwendet eine bereits fertige) lassen sich Algorithmen in dem Punkt schonmal sehr gut testen. Ansonsten hat CrypTool diese FIPS-Testbatterie auch implementiert, also zur Not mit Copy-Paste arbeiten.

Fast alle Algorithmen die von absoluten Neulingen geschrieben werden (auch fast alle alten), fallen hier schon durch.

Möchte man also selber einen Algorithmus entfernen, ist das erste Ziel erstmal diesen primitiven Test zu überstehen. Dann ist man aber schon so ziehmlich ans Ende angekommen, was man als Anfänger machen kann.


Andere Designkriterien die man noch überprüfen kann:
Full Diffusion: Nach wieviele Runden hängen alle Ausgabebits von allen Eingabebits ab, so dass wenn sich 1 Eingabebit ändert, sich im Schnitt 50% der Ausgabebits verändern.
Bei AES erreiche ich nach 2 Rounden schon full diffusion, d.h., alle Ausgabebits hängen von allen Eingabebits vorher ab. Wenn ich also 2 Rounden hinzufüge (4 Runden AES, statt 2) habe ich ein "full diffusion" Schritt mehr. Habe ich dann z.B. 14 Runden (AES mit 256 Bit Key), macht dies 7 full diffusion Schritte für mehr, Seite 29. Solch ein Algorithmus ist i.d.R. stärker als ein Algorithmus, welcher nur ein 'full diffusion' Schritt vorweisen kann.

Dies führt aus schon zum nächsten Punkt:
Differentielle und lineare Kryptoanalyse: Es lassen sich Abhänigkeiten zwischen Ein- und Ausgabe ausnutzen, um so an Informationen über den Key zu gelangen.
Man gibt z.B. zwei Eingaben ein, die sich nur im 1. Bit unterscheiden (also 01101...01 und 01101..00) und nun lässt sich ermitteln, mit welcher Wahrscheinlichkeit sich bestimmte Ausgabebits verändern, z.B. kann das ändern des 1. Bits dazu führen, dass dadurch mit einer Wahrscheinlichkeit von 1/32 die Ausgabebits 4 und 6 in einer bestimmten Art und Weise verändert werden.
Hat man diese Wahrscheinlichkeiten erstmal berechnet, lässt sich daraus auch ein Wert ableiten, wieviele gewählte Klartexte man benötigt, um an den Key zu gelangen.
Bei guten Algorithmen kann es schon vorkommen, dass man 2^100 gewählte Klartexte benötigt, um diese per differentielle Kryptoanalyse zu knacken, da die Abhänigkeiten zwischen Eingabebits und Ausgabebits verschwindend gering ist.


Diesen Wert zu ermitteln ist aber schon sehr sehr schwierig und lässt sich nicht mal eben so erledigen.
Einen Algorithmus der stark gegen differentielle/lineare Analyse zu finden, ist ebenso schwierig und man sollte z.B. sehr behutsam bei der Wahl der S-Boxes vorgehen. Diese S-Boxes sind meistens nicht einfach zufällig gewählt, sondern speziell so gewählt, dass diese Robust gegen diese Angriffe sind.

Aber allein um differentielle/lineare Kryptoanalyse zu verstehen und wirklich einfache Algorithmen dies bezüglich zu analysien, bedarf es unheimlich viel an Know-How, insbesonders mathematisches.


Aber ansonsten stimmt es, was Menace sagte, die Sicherheit von Algorithmen lässt sich nur relativ schwer bestimmen.
Der übliche Schritt ist zu gucken, ob dieser sicher genug ist gegen die bisher bekannten Angriffe. Was mit neuen Angriffen ist, kann keiner sagen.
Als die differentielle/lineare Kryptoanalyse endeckt wurde (~1990), stellte sich herraus, dass die S-Boxen von DES extrem gut gewählt waren und DES sehr stark gegen diese Angriffe ist (dan der S-Boxen).
Hätte von 30 Jahren die NSA nicht an den S-Boxen rumgespielt (vermutlich kannten die damals diese Angriffe bereits), könnte es gut sein, dass DES sich vergleichsweise schlecht gegen differentielle/lineare Kryptoanalyse geschlagen hätte.

Ansonsten kann man noch die Rundenzahl reduzieren und schauen, wieviele Runden man mit heutigen Attacken knacken kann.
Daraus lässt sich auch etwas über die Sicherheit sagen. Schafft man es z.B. 9 von 10 Runden zu knacken, reicht schon ein Fortschritt in der Kryptoanalyse, um den Angriff auf alle 10 Runden auszudehen.
Ein Algorithmus, bei den man evt. nur 9 von 32 Runden knacken kann, verspricht mehr Sicherheit.



Naja, kommt drauf an. Oftmals denkt man, man hätte diesen verstanden.
Warum verwendet man S-Boxen? Ganz klar, ist doch das gleiche Prinzip wie bei der monoalphabetischen Substitution!

Die wirklich relevanten Fragen stellt man sich nicht. Man nimmt die S-Boxen so hin, bietet mehr Sicherheit, dass versteht jeder, aber das wirklich Intressante ist, warum die S-Boxen speziell mit diesen Einträgen?
Oft denkt man, diese seien zufällig gewählt, und man kommt gar nicht auf die Idee dies weiter zu hinterfragen, aber in die S-Boxen wurden meistens sehr sehr viel Zeit investiert um so den Algorithmus sicher gegen verschiedene Attacken zu machen.
Zufällige (feste) S-Boxen sind da unpraktisch.


Wie bereits am Anfang des Posts:
Jeder kann einen Algorithmus entwerfen, den er selber nicht knacken kann.


Selbst wenn ein Bruce Schneier einen Algorithmus in heimarbeit entwickelt, würde dieser nicht als sicher gelten.
Erst wenn dieser von verschiedenen Experten auf der ganzen Welt intensiv überprüft wird, erst dann wird dieser als sicher bezeichnet.
Die sichersten Algorithmen sind immer noch die, die an meisten Aufmerksamkeit bekommen, also z.B. AES.


Aber ansonsten stimmt es, möchte recht Tief in die Materie einsteigen, braucht man sehr gute Mathekenntnisse und wird vermutlich nicht um einige (Uni) Mathemodule rumkommen.
Hat man dieses nicht, stehen die Chancen, einen halbwegs guten Algorithmus zu entwerfen, der nicht zu 99% von anderen akgekupfert wurde, nahzu null.



@Threadsteller:
Wenn du dir Algorithmen angucken willst, eignen sich XTEA und Blowfish recht gut für den Anfang. Auch AES ist gar nicht so schwer zu implementieren, wenn man eine gute (nicht so mathematisch gehaltene) Anleitung hat.
Einen selbstgeschriebenen Algorithmus wirklich zu verwenden hat keinen Sinn, der lässt sich vermutlich innerhalb von Sekunden brechen.
Möchte man Tiefer in die Materie einsteigen, kommt man um Bücher nicht herum. Anders als in der Programmierung bringt Try and Error relativ wenig bis gar nicht, das meiste muss man sich anlesen.
Gute Bücher sind von 'Abenteuer Kryptologie von Reinhard Wobst' und 'Angewandte Kryptographie von Bruce Schneier', es gibt noch viele andere gute.
Zuerst muss man viele Grundbegriffe lernen, bis man halbwegs die Funktionsweise von moderneren Algorithmen versteht, und damit ist nicht einmal das Hinterfragen von bestimmten Sachen, warum die Sbox so und nicht anders, gemeint.



Edit:
Warum dieser Random Oracle Test:
Ein Algorithmus welches diesen Test (Random Oracle) durchfällt, ist auch nicht gut geschützt gegen lineare/differentielle Kryptoanalyse. D.h., wenn ein Algorithmus gegen diese Attacken robust ist, wird es auch den Random Oracle Test (den oben beschrieben Test mit dem Random Oracle) bestehen.

Etwas leichter verständlich kann man sich die Wichtigkeit dieser Eigenschaft eines Algorithmus an folgendem Betriebsmodus machen:
Es gibt den sogenannten Counter-Mode, dabei wird zuerst 0..01, dann 0..02, 0..03 usw. verschlüsselt, also eine aufsteigende Nummer.
Die Ausgabe des Algorithmus wird als Key-Stream für eine Stromchiffre verwendet, sprich, der Geheimtext ist dann Klartext XOR Key-Stream.
Wie bekannt, muss der Key-Stream wirklich zufällig aussehen, ansonsten ist die Verschlüsselung nicht sicher.
Würde bei einem Algorithmus die Änderung des letzten Bytes nur eine Änderung des letzten Bytes im Geheimtext zufolge haben, heißt dies ja, dass bei der aufsteigenden Nummer die ersten Geheimtextbytes immer die gleichen sind, nur das letzte Geheimtextbyte würde sich verändern, durch die aufsteigende Nummer. Das Brechen des Algorithmus wäre ein Kinderspiel.


Was kann man daraus also schließen:
Wenn man vor hat, einen Algorithmus zu entfernen und nicht der Experte ist um die diffusion zu berechnen, kann man sich mit dem Test recht gut behelfen.
Die FIPS-Testbatterie (oder ähnliche Test) hat man schnell geschrieben, diese füttert man dann mit verschiedenen generierten Geheimtext und schaut was so rauskommt.
Man kann z.B. aufsteigende Nummer + fester Key, fester Plaintext + aufsteigener Key, Bits nach Links/Rechts wandern lassern, 00 00 (Hex), 01 01, 02 02... FF FF + festen Key verschlüsseln und jedes mal muss der Geheimtext die FIPS-Testbatterie bestehen. Hat man dies richtig implementiert, lässt sich das alles schön automatisieren.

Hat man erstmal einen Algorithmus gefunden, der diesen Test übersteht, kann man versuchen zu ermitteln, wie viele Runden dieser dafür benötigt.
AES braucht z.B. nur 2 Runden (zumindest wenn man nur den Klartext variiert) hat aber 10 bis 14 Runden, also 5-7 'full diffusion' Stufen.
Wenn der selbstgeschriebene Algorithmus das Ergebnis nach z.B. 8 Runden hat (bei 7 also nicht mehr), sollte man schon mehr als 8 Runden verwenden (z.B. 24) oder durch Verbesserungen versuchen, diese Zahl zu drücken, so dass der Algorithmus den Test schon nach 6 oder 4 Runden besteht (2 Runden sind schon extrem gut, andere gute Algorithmen schaffen es z.B. nach 4 Runden).

Vielleicht kann man auch schonmal anfangen, und versuchen seinen Algorithmus mit einer reduzierten Anzahl an Runden zu knacken.
Schaffe ich den Algorithmus zu knacken, wenn dieser evt. nur 2 Runden hat? Kann ich das auf 3 oder 4 Runden ausdehen? Lässt sich dies evt. irgendwie automatisieren? Wenn ja, kann ich den Aufwand für X Runden schätzen lassen?
Hört sich zwar recht einfach an, ist aber sehr schwierig und selbst bei leichten Algorithmen kann man wirklich schnell verzweifeln.


Aber Achtung: Nur weil der Algorithmus diesen Test besteht, sagt dies noch nichts über die Sicherheit aus (siehe z.B. hier). Es bedeutet nur, dass der Algorithmus wahrscheinlich nicht trivialerweise durch statistische Tests wie z.B. poly-/monoalphabetische Substitution geknackt werden kann.
Aber alle weiteren Tests sind deutlich komplexer und schwer zu überprüfen. Evt. kann man sich etwas in die lineare/differentielle Kryptoanalyse einlesen und schon mal schauen, ob es Auffälligkeiten in den verwendeten S-Boxen gibt, für viel mehr reicht es aber nicht. Tutorial für Fortgeschrittene in lineare/differentielle Kryptoanalyse

Vermutlich wird man auch schon Probleme haben, seinen Algorithmus zu knacken, wenn dieser nur 1 Runde hat. Wie gesagt, man muss sich wirklich intensiv in das Thema einlesen, nur durch Versuchen wird das nichts.

hackerboy

ok habe verstanden.
ich kann etwas HTML und einen Namensgenerator in C++ schreiben. Aber das wird mir wohl kaum was bringen.
Muss ich um einen Algorithmus programieren zu können eine 1 in Mathe haben und C++ komplett können? Wenn ja dann könnte ich es gleich vergessen denn ich kann C++ nur minimal, und habe eine 4 in Mathe.
OK: Was brauch ich alles an Software um einen kleinen Algorithmus zu programmieren?


Vielen Dank im Vorraus.

Mfg


Benjamin.

lightsaver

du musst eine programmiersprache nicht ins kleinste detail können, um solch einen algorithmus umzusetzen, das mathematische verständis für einen sicheren verschlüsselungsalgo ist viel wichtiger.

und allgemein zum programmieren:

überlege dir, was du machen willst und wo du das verwenden willst. dann überlegst du dir, welche sprache dazu gut passen könnte. danach noch eine entwicklungsumgebung dafür besorgen (teilweise reicht auch einfach notepad und ein compiler) und dann einfach programmieren.

leicht zu erlernen ist z.b. c#, gerade da du ja scheinbar einige (wenn auch geringe) kenntnisse in c++ hast. dazu dann z.b. visual studio express als ide und du kannst fleißig losprogrammieren und lernen.

ach und bei dir klingt es immer so, als wär ein algorithmus was besonderes. letztendlich ist alles was du syntaktisch korrekt schreibst ein algorithmus. also selbst "while(true)" wäre einer (wenn auch eine unsinnige endlosschleife