Eigener Kryptoalgorithmus
-
Hallo, ich würde hier gerne meinen Algorithmus vorstellen.
Ich behaupte nicht ein Profi zu sein und, dass der Algorithmus hochprofessionell ist.
Es ist einer meiner ersten Gehversuche was das anbelangt.
Harte Kritik ist erwünscht aber bitte sachlich.
Womöglich blamiere ich mich auch aber das Risiko gehe ich ein.
Man kann ihn ja gemeinsam verbessern.Er ist bewusst in einer einfachen Struktur geschaffen um sehr performancestark zu sein.
Ziel ist es sowohl sicher als auch schnell zu sein.
Daher wurde zumindest in der ersten Version auf S-Boxen verzichtet.Der Klartextblock mit 128 bit wird in jeder Runde variabel (schlüsselabhängig) "bit geshifted", und zwar in dem die Zahl um die bitweise verschoben wird berechnet wird in dem der Schlüssel modulo 128 genommen wird.
Danach wird der Block in 16 Teile a 8 bit zerlegt und schlüsselbasiert neu geordnet.
Das passiert in dem die Nummern der Postionen mit einem Hash-Algorithmus gehasched werden und das Ergebnis modulo 16 genommen wird. Dabei werden die Standardwerte des Hash-Alogorithmus durch den Schlüssel ersetzt.
Ohne Schlüssel sollte es nicht möglich sein die ursprüngliche Ordnung widerherzustellen.Danach wird der wiederzusammengesetzte Block mit dem Schlüssel "gexored" um durch Informationsverlust weitere Sicherheit herzustellen.
Jede einzelne Routine ist schlüsselabhängig.
Die Rundenanzahl ist beliebig wählbar sollte aber mindestens zehn Runden in der Standardversion bzw. Anwendung haben.
Keyshedule:
Der Schlüssel wird jede Runde mit einer Hashfunktion gehashed bei der der Schlüssel die Standardwerte des Hashalgorithmus ersetzt.
Damit sollte es unmöglich sein selbst bei Kenntnis eines Rundenschlüssels Schlüssel vorheriger Runden oder zukünftiger Runden vorherzusagen.
Alternativ kann der Schlüssel auch selbst die Verschlüsselungsroutine durchlaufen, was aber Perfomance kosten würde.
In zukünftigen Versionen kann der Algorithmus um S-Boxen erweitert werden und zwar variable 16 S-Boxen die jede Runde schlüsselabhängig geändert werden bzw. wird auch deren Position schlüsselabhängig jede Runde geändert.
Mir ist bewusst, dass der Algortithmus sehr einfach ist, das ist aber bewusst so.
Er kann wie gesagt erweitert werden.
-
Hört sich, grob gesehen, ziemlich gut an.
Poste doch bitte mal den Quelltext.
-
Vielen Dank, am Quelltext arbeite ich gerade.
Liebe Grüsse
-
Es gelten wie immer die allgemeinen Ratschläge und kritischen Einwände bzgl eigener Ausflüge in die Kryptologie:
http://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-ownTL;DR es ist unheimlich schwierig einen guten Krypto-Algorithmus zu erfinden wenn man nicht Experte auf dem Gebiet ist.
"Anyone can invent an encryption algorithm they themselves can't break; it's much harder to invent one that no one else can break".
(Bruce Schneier)
-
scrontch schrieb:
TL;DR es ist unheimlich schwierig einen guten Krypto-Algorithmus zu erfinden wenn man nicht Experte auf dem Gebiet ist.
Es muss ja nicht unbedingt einer werden, der Geheimdiensten Kopfschmerzen bereitet. Aber den gemeinen Hobby-Hacker kann man schon mit relativ einfachen Mitteln in den Wahnsinn treiben.
-
Das sieht so aus, als ob Du Dich an einem SPN orientiert und die Sache mit der Substitution einfach weggelassen hast. Richtig?
-
Ich wollte noch anmerken, dass durch die einfach Struktur eine Implementierung einfacher ist und Implementierungsfehler eher vermieden werden was in der Praxis zu mehr Sicherheit führt.
Und: Bei allen bekannten Algorithmen kann man ein einen einzelnen Byteblock vom Anfang bis zum Ende verfolgen. Bei meinem Algorithmus ist das nicht möglich. Der Weg eines Byteblocks ist ohne Schlüssel nicht nachzuverfolgen.
-
Wie ist denn so die Diffusion deines Verschlüsselungsverfahrens? Gut oder schlecht?
-
Das habe ich noch nicht ausreichend überprüft. Ich möchte ihn zuerst implementieren. Ich stehe mit diesem Algorithmus erst am Anfang. Vielleicht können wir ihn ja gemeinsam einer Kryptoanalyse unterziehen. Ich glaube aber, dass es dazu wichtig ist ein Mal den Algorithmus präzise zu definieren und zu implementieren. Vor allem bei der Implementation brauche ich Hilfe. Werde das auch im dementsprechenden Forum posten.
-
die Diffusion sollte man eigentlich ausrechnen können (ich kann das leider nicht) und wird auch von der verwendeten Hashfunktion abhängen ...
-
-Emil- schrieb:
die Diffusion sollte man eigentlich ausrechnen können (ich kann das leider nicht) und wird auch von der verwendeten Hashfunktion abhängen ...
Ich glaube, Du verwechselst Konfusion mit Diffusion.
@Moba:
Deine Verschlüsselungsfunktion ist eine Verkettung von verschiedenen Schritten:- Du vertauscht die Reihenfolge von Bits und Bytes. Dieser Schritt ist linear.
- Du addierst Rundenschlüssel. Dieser Schritt ist affin-linear.
Die Verkettung von affin-linearen Funktionen ergibt eine affin-lineare Funktion. Der ganze Aufwand mit den mehreren Runden ist damit überflüssig. Die Verschlüsselungsfunktion lässt sich damit schreiben als
wobei eine Schlüssel-abhängige Permutationsmatrix ist (128x128, in jeder Zeile und Spalte ist genau eine 1, der Rest ist 0), ein Schlüssel-abhängiger 128-Bit-Vektor ist und die Arithmetik im Körper stattfindet. Das + ist also ein XOR.
Damit hält der Verschlüsselungsalgorithmus keiner Chosen-Plaintext-Attack stand. Das ist schlecht. Sehr schlecht.
Das mit den Runden ist erst dann sinnvoll, wenn man nichtlineare Abbildungen mit einbaut. Das lässt sich dann eben nicht mehr so kompakt zusammenfassen. Die nichtlinearen Schritte sind ganz wichtig! Außerdem will man keine Schlüssel-abhängigen Speicherzugriffe haben. Die sind über Cache-Timings sichtbar. Damit "leckt" das Verfahren Information über andere Kanäle. Du willst also Nichtlinearität ohne Lookup-Tabellen und auch sonst keine komplizierten Bit/Byte-Neuordnungen, die Schlüssel-abhängig sind. Ich bin überhaupt kein Fan davon, so viel vom Schlüssel abhängig zu machen. Die Schlüssel-abhängige Neuordnung von Bytes macht die Implementierung doch nur kompliziert und eine Gefahr bezüglich Seitenkanälen. Eine gute Strategie ist zum Beispiel, die Diffusion zu optimieren und die Sache mit der Konfusion einfach durch das regelmäßige "Einbringen" von Rundenschlüsseln abzuhaken. Nichtlinearität ohne Lookup-Tabellen-basierte S-Boxen bekommst Du zum Beispiel über eine geschickte Verknüpfung von logischen und/oder arithmetischen Operationen (siehe ChaCha20, Blake2, Keccak, NORX, ...)
Was ich empfehlen kann:
https://www.schneier.com/crypto-gram/archives/1998/1015.html#cipherdesignIch bin da jetzt auch nicht der Profi. Ich habe bisher nur zum Spaß diverse Verschlüsselungsalgorithmen anderer Leute implementiert und aus Interesse das eine oder andere Paper zu Designs oder Angriffen gelesen. Aber ich habe ja auch nicht den Anspruch, eine Blockchiffre selbst zu entwerfen, die andere Leute dann analysieren sollen.
-
Hallo, vielen Dank für die Antworten.
Vielleicht können wir ihn ja gemeinsam verbessern bzw. vielleicht taugt er ja als Basis bei der sich einige einbringen können.
@krümelkacker: Auch danke für deine Antwort.
Liebe Grüsse
P.S.: Danke für den Link, habe ihn gelesen.
Das mit den arithmetischen Operationen werde ich mir übrigens ansehen, danke.
-
Die schlüsselbasierte Transposition war mir deswegen wichtig, da es die Struktur und gewisse Zusammenhänge total zerreisst, so wie bei einem Text wo alle Buchstaben und somit auch die Wörter und Zusammenhänge zerrissen werden. Schlüsselabhängig habe ich das ganze gemacht, damit der Weg der einzelnen bytes und bits nicht nachvollziehbar ist bzw. die Analyse schwieriger ist und das ganze weniger linear zu machen in Bezug darauf, das ganze als Formel darzustellen (ich hoffe ich täusche mich nicht).
Ausserdem sorgt es für eine gute Diffusion (wenn ich da nicht etwas verwechsle).
Die S-Boxen wollte ich schlüsselabhängig machen, damit die Substitution weniger statistische Rückschlüsse und Analysemöglichkeiten lässt. Schliesslich stellt die Substitution normaler S-Boxen nur eine monoalphabetische Substitution dar.Inzwischen denke ich an eine statische schlüsselabhängige S-Box die einem Vignere-Quadrat entspricht, wobeich ich nicht weiss ob man dann nicht gleich bitweise XORen kann.
Die schlüsselabhängige Rotation soll die Analyse ebenfalls erschweren.
Inzwischen habe ich den Algorithmus so modifiziert, dass es am Anfang jeder Runde ein "Whitening" gibt in dem mit dem Schlüssel geXORed wird.
Alternativ kann man noch die Mixcolumns von AES vor dem XORen am Schluss der Runde auch noch einbauen was mir aber etwas viel vorkommt.
Wie gesagt ich hoffe ich blamiere mich nicht.
Eure Gedanken inklusive Verbesserungsvorschlägen dazu würden mich interessieren.
-
Moba, du würdest dich blamieren, wenn du deine eigene Verschlüsselung im kommerziellen Bereich einsetzen würdest.
Denn die gängigen Verschlüsselungen und Hash Funktionen wurden in Wettbewerben auf Herz und Nieren geprüft. Da haben einige Kryptographie Experten Tagen, Wochen, Monate an Großrechnern damit verbracht, Fehler im Algorithmus zu finden.
Das gemeine an einer Verschlüsselung ist, dass Sicherheitslöcher im Algorithmus und fehlerhafte Implementierungen erst sehr spät entdeckt werden (siehe RC4 oder Heartbleed). Denn was testet man bei einer Implementierung? Man prüft ob diese invers ist und ob diese Testvektoren entsprechen, sofern welche vorhanden sind. Und dann nutzt man die Implementierung ein paar tausend mal und stellt nach Jahren fest, ups wenn der zweite Teilschlüssel 0 ist, ist meine Verschlüsselung nicht invers. (siehe anderen Post von dir).
Deswegen können wir hier keine gute Beurteilung deines Algorithmus machen. Wir sind weder Experten noch haben wir die Rechner-Kapazitäten eine statistische Analyse deines Algorithmus zu machen. Schaue dir ruhig mal https://eprint.iacr.org/2007/120.pdf an. Und pfeife dir vor allen Dingen auch mal das Buch Practical Cryptography von Bruce Schneier rein.
Du hast schon genug zu tun, wenn du einen Verschlüsselung implementieren möchtest. Hast du dir schon die Verschlüsselungsmodi von Blockchiffren angeschaut? Schau dir mal https://de.wikipedia.org/wiki/Electronic_Code_Book_Mode an.
-
Moba schrieb:
Die schlüsselbasierte Transposition war mir deswegen wichtig, da es die Struktur und gewisse Zusammenhänge total zerreisst, so wie bei einem Text wo alle Buchstaben und somit auch die Wörter und Zusammenhänge zerrissen werden. Schlüsselabhängig habe ich das ganze gemacht, damit der Weg der einzelnen bytes und bits nicht nachvollziehbar ist bzw. die Analyse schwieriger ist und das ganze weniger linear zu machen in Bezug darauf, das ganze als Formel darzustellen (ich hoffe ich täusche mich nicht).
Die schlüsselabhängige Rotation soll die Analyse ebenfalls erschweren.
Eine schlüsselabhängige Neuanordnung von Bits und Bytes ist dafür nicht notwendig. Sie macht das Verfahren nur unnötig schwierig zu implementieren / ineffizient.
Moba schrieb:
Ausserdem sorgt es für eine gute Diffusion (wenn ich da nicht etwas verwechsle).
Ich würde behaupten, dass die schlüsselabhängige Neuanordnung von Bits und Bytes es dir schwieriger macht, dafür zu argumentieren, dass Dein Verfahren für eine effektive Diffusion sorgt.
Moba schrieb:
Die S-Boxen wollte ich schlüsselabhängig machen, damit die Substitution weniger statistische Rückschlüsse und Analysemöglichkeiten lässt. Schliesslich stellt die Substitution normaler S-Boxen nur eine monoalphabetische Substitution dar.
Du verwendest "normale S-Boxen" ja auch nicht allein. Der Trick liegt an der Komposition mit den anderen Schritten die dafür sorgen, dass ein einzelnes Bit von mehreren anderen abhängt oder Schlüsselmaterial einschleusen. In dieser Kombination haben die S-Boxen lediglich eine Aufgabe: Sie müssen möglichst "nichtlinear" sein. Nehmen wir AES als Beispiel. Es gibt vier Operationen, die sich größtenteils abwechseln:
- AddRoundKey
- SubBytes
- ShiftRows
- MixColumns
Regelmäßiges
AddRoundKeymacht die Chiffre vom Schlüssel abhängig.SubBytesist dazu da, die Chiffre nichtlinear zu machen, so dass sie schlecht linear approximierbar ist. Die anderen beiden Schritte sorgen für die schnelle Diffusion. Wegen ihnen wirkt sich eine kleine Änderung nach zwei Runden auf den ganzen Zustand aus. Weil über AddRoundKey regelmäßig Schlüsselmaterial mit dem Zustand kombiniert wird und es diese schnelle Diffusion gibt, hat AES auch automatisch eine starke Konfusion. Das ist schon relativ elegant bis auf einen kleinen Haken: Schnelle Softwareimplementierungen basieren auf Lookup-Tabellen für SubBytes+MixColumns (4 Tabellen à 256 32-Bit Einträgen für jede Verschlüsselungsrichtung). Sowas will man heutzutage eher nicht haben, weil es eine Angriffsfläche bzgl Seitenkanal-Attacken bietet.Moba schrieb:
Wie gesagt ich hoffe ich blamiere mich nicht.
Der Versuch, eine interessante Chiffre zu konstruieren, ohne dabei in Sachen Kryptanalyse die Hausaufgaben gemacht zu haben und ohne dabei irgendwie einen Überblick zu haben, warum andere Chiffren was wie machen, ist schon irgendwie... -- man kann dich so jedenfalls nicht ganz ernst nehmen.
Wie gesagt, ich bin in dem Thema auch nicht besonders fit. Kann gut sein, dass du das nächste Mal eine chiffre vorschlägst, die für meine Augen gut aussieht. Das heißt dann aber noch nichts, weil ich eben nicht viel Ahnung von Krypt-Analyse habe. Und die, die vom Thema mehr Ahnung haben als ich, sind wahrscheinlich schwer davon zu überzeugen, die für eine Krypt-Analyse nötige Arbeit zu investieren.
Spannender ist da z.B. CAESAR: Competition for Authenticated Encryption: Security, Applicability and Robustness. 15 von den zahlreichen Einreichungen haben es in die dritte Runde geschafft. Ich bin darauf gespannt, welche Chiffren aus der dritten Runde ausgewählt und empfohlen werden.
