Algorithmus zu Analysezwecken
-
Hallo,
folgender Algorithmus dient zu Übungs- bzw. Analysezwecken für Personen die daran interessiert sind.
Der Algorithmus soll einfach zu implementieren, schnell, auf 32 bit Prozessoren optimiert und sicher sein.
Hier die Beschreibung:
Der Plaintext wird in 32 bit Blöcke zerteilt wobei der letzte mit der Zahl pi gepadded wird.
Die Schlüssellänge beträgt 128 bit.
Die S-Box ist die S-Box vom AES.
Die Rundenzahl ist variabel sollte aber mindestens bei 10 liegen.
Der Schlüssel wird in vier Teilschlüssel aufgeteilt.
Jede Operation verwendet einen Teilschlüssel.
Der Block wird mit dem ersten Teilschlüssel geXORed, der S-Box übergeben, mit dem zweiten Teilschlüssel multipliziert modulo 2^32 , erneut der S-Box übergeben, mit dem dritten Teilschlüssel addiert modulo 2^32, erneut der S-Box übergeben und mit dem vierten Teilschlüssel wieder geXORed.
Danach wird der Schlüssel gehashed wobei der Schlüssel selbst die Anfangswerte der Hashfunktion (ABCD) ersetzt.
Danach beginnt die nächste Runde.
Wie gesagt, dient Personen die daran Interesse haben und Ihre kryptoanalytischen Fähigkeiten testen wollen.
Liebe Grüsse
-
Du beschreibst eine Blockchiffre mit einer viel zu kleinen Blockgröße (32 Bit). Selbst 64-Bit-Blöcke betrachtet man heute schon als veraltet. Darüber hinaus ist die Multiplikation mit einem Teilschlüssel modulo 232 nur dann invertierbar, wenn der Teilschlüssel ungerade ist. Eine Multiplikation wo beide Faktoren vom Schlüssel abhängen, ist auch nicht gerade gern gesehen in einer Chiffre, würde ich mal behaupten. So eine Multiplikation ist teuer.
Apropos "einfach zu implmentieren": Dazu fällt mir Speck ein.
-
Salsa gefällt mir aber besser als Speck.
https://en.wikipedia.org/wiki/Salsa20
-
Hallo, danke für die Antworten.
Darf ich fragen warum diese Blockgrösse als veraltet gilt?
Liebe Grüsse
-
Moba schrieb:
Darf ich fragen warum diese Blockgrösse als veraltet gilt?
Wenn du einen Text in Blöcke einer gewissen Größe zerstückelst, dann wird ab einer gewissen Datenmenge die Wahrscheinlichkeit sehr groß, dass im Ergebnis ein Block mehrmals auftaucht. Das kann dann benutzt werden, um Aussagen über das Verhältnis der zugehörigen Klartextblöcke¹ zueinander zu treffen.
Die Wahrscheinlichkeit zwei gleiche Ergebnisblöcke zu erzeugen ist sehr viel größer als man so naiv denkt (Geburtstags"paradoxon"). Bei einer Blocklänge von 64 Bit ist ab 2^32 * 64 Bit (also 32 GB) die Wahrscheinlichkeit für eine solche Kollision großer als 0.5! Und man möchte sicherlich weit unter 0.5 bleiben. Das heißt, bei einer Blockgröße von 64 Bit darf man (mit einem bestimmten Schlüssel!) nur einen Bruchteil von 32 GB verschlüsseln. Was nach heutigen Maßstäben eben nicht so besonders viel ist.
Eine Blockgröße von 128 Bit führt hingegen zu einer "Halbwertsgröße" von 2^64 * 128 Bit = knapp 300 Exabyte. Das ist (zumindest für die kurz- bis mittelfristige Zukunft) eine recht großzügige Datenmenge für einen einzelnen Schlüssel.Diese Überlegungen gehen natürlich davon aus, dass das Verfahren den Werteraum der Blöcke gleichmäßig belegt. Ist dies nicht der Fall, dann sinken die Angaben entsprechend. Es ist daher eine grundsätzliche Anforderung an ein gutes Verfahren, dass seine Ausgaben sich wie gleichmäßig verteilte Zufallswerte verhalten.
¹: Oder genauer gesagt: Über das Verhältnis der jeweils vorhergehenden Klartextblöcke.
-
Der Block wird mit dem ersten Teilschlüssel geXORed, der S-Box übergeben, mit dem zweiten Teilschlüssel multipliziert modulo 2^32 , erneut der S-Box übergeben, mit dem dritten Teilschlüssel addiert modulo 2^32, erneut der S-Box übergeben und mit dem vierten Teilschlüssel wieder geXORed.
Ist das überhaupt eine inverse Verschlüsselung?
Wenn der zweite Teilschlüssel 0 ist, wird der Chiffretext auf einmal unabhängig von dem Eingabetext. Genauso wenn die Multiplikation mod 2^32 Null wird. Also zufälligerweisse wenn S(B xor K1) * K2 = 0 mod 2^32 gilt. Wobei S der Substitution, B dem Block, K1 dem ersten Teilschlüssel und K2 dem zweiten Teilschlüssel entspricht.
