AES-512

Kurze Anmerkung zur Kryptographie.

Weil gerade einige Leser anfragen wegen der in diesem Video von/Interview mit Xennt erwähnten AES-512, was nur er habe, und AES normalerweise die Schlüssellängen 128, 192 und 256 Bit kennt.

Dazu hätte ich ein paar kurze Anmerkungen.

1. https://ieeexplore.ieee.org/document/6122835/authors
2. Ein Verfahren, das man selbst erfunden haben will und sich rühmt, dass man es nur selbst verwende, kann man – ungeachtet der Frage seiner Qualität – nun einmal nicht „Standard“ nennen und dann eben auch nicht AES – Advanced Encryption Standard
3. Es ist eine ganz blöde Idee, zu glauben, man könne Chiffren so ganz alleine und für sich selbst entwickeln. Das geht nicht gut. Chiffren stellt man der Crypto-Community vor, und wenn es auch nach Jahren noch niemandem gelungen ist, eine Schwäche daran zu finden, dann kann man vielleicht so ganz heimlich still und leise, so für sich auf dem verschlossenen Klo, einen ersten Gedanken darauf verwenden, dass sie vielleicht nicht so völlig und offensichtlich schlecht war.
4. Ich weiß zwar nicht, was er da gemacht hat, aber weil er es AES nennt, scheint das eine von ihm selbst auf doppelte Breite aufgeblasene Version von AES zu sein, nach dem Motto „viel hilft viel“.

   Auch das ist eine ganz blöde Idee. So funktioniert Kryptographie nicht.

   Erstens kann das schon mathematisch schief gehen. Klassiker: Die Chiffre IDEA.

   IDEA beruht darauf, die Daten in 16-Bit-Stücke zu zerschneiden und dann mit dem Schlüssel mit drei verschiedenen Rechenoperationen auf 16-Bit-Zahlen zu verarbeiten:

   • bitweises XOR
   • Addition modulo 2¹⁶
   • Multiplikation modulo 2¹⁶ + 1, wobei die 0 für 2¹⁶ steht.

   Wer ein bisschen Ahnung von Computerarithmetik hat, sieht sofort, und darauf beruht IDEA, dass alle diese Operationen umkehrbar sind: XOR ist seine eigene Umkehrung, einfach nochmal anwenden. Addition kann man durch Subtraktion (= Addition des Negativen modulo 2¹⁶ zurückrechnen. Multiplikation durch Multiplikation mit dem Inversen ( Multiplikation mit x^-1 modulo 2¹⁶ + 1) wieder zurückrechnen.

   Und deshalb kann man die Daten nicht nur ver-, sondern auch wieder entschlüsseln, indem man einfach alle Rechenoperationen a) in umgekehrter Reihenfolge und b) in der inversen Richtung einfach wieder zurückrechnet.

   Nun dachten einige Schlaumeier, dass 16-Bit-Rechnung doch veraltet ist, wir haben doch jetzt (damals!) 32-Bit-Prozessoren, also machen wir dasselbe einfach mit 32-Bit-Stücken.

   Preisfrage: Wer merkt, warum das mit 32 Bit nicht geht?

   Lösung: Es funktioniert mit 16 Bit, weil 2¹⁶ + 1 = 65537 eine Primzahl ist. Deshalb ist die Restklasse nullteilerfrei, und deshalb kann man darin fehlerfrei mit den Werten 1 bis 2^{16, also genau 65536 verschiedenen Werten, rechnen, multiplizieren, Inverse bilden.}

   2³² + 1 = 4294967297 = 6700417 · 641 ist aber keine Primzahl, weshalb man diese Rechenmethode in der Restklasse nicht anwenden kann, weil sie eben nicht nullteilerfrei ist. Denn 6700417 · 641 ≡ 0 modulo 2³² + 1 , und deshalb rechnet’s falsch, ist das nicht zu invertieren. Man kann es nicht mehr entschlüsseln. Deshalb funktioniert der Rechentrick nicht mit der doppelten Breite.

   Man kann nicht einfach etwas mit der doppelten Breite verwenden. Deshalb muss man Algebra lernen, wenn man Kryptographie machen will.

5. Chiffren sind ja nicht einfach nur „Großes Durcheinander, das unverständlichen Zahlensalat produziert“, sondern sie sollen das ja so tun, dass sie resistent gegen alle bekannten Angriffe wie Known Plaintext, Chosen Plaintext, Differentielle Analyse und so weiter sind. Kann man zum Bespiel etwas herausfinden, wenn man ein Paar aus Klartext und Chiffrat kennt, oder sogar mehrere Paare, die mit demselben Schlüssel verschlüsselt wurden?

   Die Enigma wurde so gebrochen. Die dusseligen Deutschen sendeten jeden Morgen pünktlich um 6 einen verschlüsselten Wetterbericht, der immer mit demselben Wort (bin jetzt nicht mehr ganz sicher, ich glaube, es war sogar WETTERBERICHT anfing), so dass die Briten jeden Morgen wussten, dass wenn um pünktlich 6 Uhr ein verschlüsselter Spruch kam, der Klartext mit WETTERBERICHT anfing, genug Klartext-Chiffretext hatten um den Schlüssel auszurechnen (die sogenannte Unizitätslänge war überschritten, ab der der Schlüssel eindeutig identifiziert wird).

   Hätten die Deutschen ihre – ohnehin nicht geheim, sondern für jeden offensichtlichen – Wetterberichte nicht verschlüsselt, sondern im Klartext gesendet oder einfach WETTERBERICHT weggelassen, wäre die Enigma nicht so umfangreich und leicht zu brechen gewesen.

   Außerdem gab es noch einen Offizier, der meinte, er muss auf die Funkdisziplin achten, damit der Feind das nicht knacken kann, und hat jedem, der Fehler gemacht hat, einen Anschiss geschickt. Und hat nicht gemerkt, dass er selbst es war, der das Brechen ermöglichte, weil er jeden seiner – verschlüsselten – Sprüche am Ende mit seinem langen Nachnamen unterschrieb, und man dadurch ebenfalls immer wusste, was am Ende des Klartextes stand, wenn die Sprüche von einer bestimmten Station kamen und mit dessen Stimme vorgelesen wurde.

   Deshalb versucht man Chiffren heute so zu bauen, dass solche Angriffe praktisch nicht möglich sind, weil Klartext und Schlüssel so intensiv durchmischt (permutiert, transponiert ,… ) werden müssen, dass man da auch über mehrere Runden nichts mehr rausrechnen kann.

   Macht man das jetzt aber doppelt so breit, verwendet man also doppelt so viele Klartext- und Schlüsselbits pro Durchgang, kann man natürlich mit derselben Zahl von Rechenschritten nicht mehr soviel Unordnung schaffen.

   Stellt Euch das so vor: Ein Hütchenspieler hat 3 Hütchen und macht 5 schnelle Züge. Danach können die Hütchen jede beliebige Reihenfolge haben.

   Hat er aber 13 Hütchen und auch nur 5 schnelle Züge, kann er nicht alle Hütchen bewegen, weil er bei jedem Zug immer nur zwei Hütchen bewegen kann, er also bestenfalls 10 der 13 Hütchen überhaupt bewegen kann. Und selbst wenn er das tut, muss er sie paarweise tauschen.

   Dasselbe Problem hat man bei Chiffren. Sind Daten und/oder Schlüssel plötzlich doppelt so breit, muss man plötzlich sehr viel mehr Aufwand treiben, um die nachgewiesen selbe Qualität an Durchmischung zu erreichen, die erforderlich ist, um gegen Angriffe resistent zu sein, und dann wird das Ding laaaangsam. Und wenn es nicht laaaaangsam wird, dann weiß man, dass da was faul ist.

   Anders gesagt: Wenn die Hausfrau in derselben Zeit doppelt so viele Kinder waschen soll, kann sie jedes einzelne Kind nicht mehr genauso gründlich waschen.

   Und deshalb ist das gar keine gute Idee zu glauben, viel hilft viel, ich nehme jetzt einfach 512 statt 256 Bit, und zu glauben, dass das unknackbar ist weil es exponentiell steige. Wenn das nämlich nicht mehr gut genug durchmischt ist, kann man umso leichter Schlüsselbits ausrechnen.

   Und 512 Bit Schlüssel, die man per Angriff ausrechnen kann, sind eben nicht viel sicherer als 256 Bit, bei denen man das nicht kann.

   Es ist ein gewaltiger Irrtum zu glauben, dass viel auch immer viel hilft und man einfach mehr Wumms aufträgt wie PS beim Auto.

Das ist eben nicht so einfach, wie man glaubt.

Ich habe vor ungefähr 20 Jahren mal eine Bank darauf hingewiesen, dass ihre Webseite irgendein grausiges Sicherheitsloch enthielt. Weiß nicht mehr, irgendwas wurde nicht geprüft und konnte beliebig gewählt werden.

Und bekam die Antwort: Wir verwenden 256-Bit Verschlüsselung, und alle Experten haben uns gesagt, dass 256-Bit-Verschlüsselungen nicht zu knacken sind.

Dass es nicht darum ging, ihre Verschlüsselung zu brechen, weil ich als Benutzer der Webseite den Schlüssel ja habe, und ich innerhalb der Verschlüsselung auf andere Weise angreifen kann, war ihnen nicht begreiflich zu machen. Da herrschte im Kopf die Gleichung „256-Bit-Verschlüsselung = unknackbar, also sind wir sicher, was labert der Spinner da?“. Als wäre Unknackbarkeit so eine Art Feenstaub, den man darüber streut.