Hallo,
jeder kann einen Algorithmus entwerfen, den er selber nicht knacken kann. Aussagen muss dies aber noch gar nichts.
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.
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.
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)
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.
Um den Algorithmus zu verstehen braucht man in den meisten Fällen mehr oder weniger gute Mathematikkenntnisse
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.
Um einen eigenen Algorithmus zu entwickeln und dessen Sicherheit abschätzen/beweisen zu können braucht man _wirklich_ viel Ahnung von Mathematik
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.
![[HaBo]](/styles/default/logoklein.png)
