Wie funktioniert eigentlich Verschlüsselung?

by Volker Weber

Die meisten Menschen können sich nicht recht vorstellen, wie Verschlüsselung funktioniert. Ich versuche mal, das mit möglichst wenigen Fachbegriffen zu erklären.

Wir wollen einen geheimen Klartext übertragen. Den drehen wir durch eine Mühle (Verschlüsselung), die einen Geheimtext ausspuckt. Den darf jetzt jeder lesen, weil das ein Buchstabensalat ist, den niemand versteht. Der Empfänger bildet aus dem Geheimtext durch Entschlüsselung wieder den Klartext. Verschlüsselung und Entschlüsselung nutzen bekannte, immer wieder geprüfte Verfahren.

Diese Verfahren benötigen einen Schlüssel. Das ist eine zufällige Zeichenkette. Je länger, desto besser. Es gibt nun zwei Möglichkeiten:

  1. Symmetrisch: Verschlüsselung und Entschlüsselung nutzen den selben Schlüssel. Dafür gibt es sehr effiziente Verfahren, die auch mit langen Schlüsseln superschnell funktionieren. Die haben aber einen Nachteil: ich muss (a) den Schlüssel auf geheimem Weg dem Empfänger übermitteln und (b) ich brauche für jede Kombination von Sender und Empfängern einen eigenen Schlüssel.
  2. Asymmetrisch: Verschlüsselung und Entschlüsselung nutzen ein Schlüsselpaar. Den geheimen Schlüssel kennt nur der Empfänger, den öffentlichen Schlüssel darf jeder wissen. Man erfragt nun vom Empfänger den öffentlichen Schlüssel und nutzt ihn, um den Klartext in den Geheimtext zu verwandeln. Der Empfänger nimmt seinen geheimen Schlüssel und bildet den Klartext. Vorteil: jeder Teilnehmer braucht nur ein Pärchen von Schlüsseln, um mit allen zu kommunizieren. Nachteil: diese Verfahren sind langsam und man muss jedem Empfänger seinen passenden Geheimtext schicken. Sehr ineffizient, wenn man mehr als einen Empfänger hat.

Deshalb setzt man eine Kombination der beiden Verfahren ein. Im ersten Schritt denkt sich der Sender irgendeinen Schlüssel für das erste Verfahren aus. Damit bildet er den Geheimtext. Den Schlüssel selbst übermittelt er zusammen mit dem Geheimtext an alle Empfänger, in dem er ihn jeweils mit dem öffentlichen Schlüssel des Empfängers mittels des zweiten Verfahrens verschlüsselt. Die Nachricht enthält also den Geheimtext der Nachricht und die Geheimtexte des Schlüssels und zwar so viele, wie die Nachricht Empfänger hat.

Warum funktionieren diese Verfahren nicht rückwärts? Warum kann man aus dem Geheimtext nicht auf den Klartext schließen, ohne den Schlüssel zu haben? Die Verfahren nutzen mathematische Funktionen, die in einer Richtung einfach gehen, in der anderen aber aufwändig sind.

Ein Beispiel: 28411 und 45491 sind Primzahlen. Das heißt, sie sind nicht teilbar (außer durch 1 und sich selbst). Multipliziere ich die beiden Zahlen, bekomme ich eine neue Zahl: 1292444801. Geht ganz schnell. Wenn ich jetzt aber rausfinden will, durch welche Zahlen ich 1292444801 teilen kann, muss ich sehr lange ausprobieren, bis ich eine der beiden Primzahlen gefunden habe. Kenne ich eine von beiden, teile ich zum Beispiel durch 28411, dann kommt 45491 raus.

Verschlüsselungsverfahren nutzen jetzt eine ganze Folge solcher Berechnungen, um Falltüren zu erzeugen, in denen es nur vorwärts, aber nicht rückwärts geht. Wie kann man das System überlisten? Es gibt nur zwei sinnvolle Möglichkeiten: ich verrate den geheimen Schlüssel des ersten Verfahrens, etwa durch eine Hintertür in der Software. Oder ich baue einen sehr, sehr schnellen Computer, der das Verfahren doch rückwärts kann.

Und dann gibt es noch eine ganz einfache Attacke, die mit der Bequemlichkeit des Nutzer spielt. Ich klaue dem Empfänger den ungeschützten geheimen Schlüssel. Also, ich nehme ihn nicht weg. Ich mache eine Kopie.

Comments

See how it works, using colors. :-)

Jan-Piet Mens, 2013-07-18

Seems I broke the link, so here: http://www.youtube.com/watch?v=3QnD2c4Xovk

Jan-Piet Mens, 2013-07-18

Und den sehr schnellen Computer, der das alles rückwärts kann, stellt sich die NSA ins Utah Data Center. Das eröfffnet im September.

Thomas Cloer, 2013-07-18

Das wissen wir nicht. Aber es hat einen anderen Anschein. Was dort gebaut wird, ist eine unfassbar große Scheune. Siehe "Heuhaufen" im vorigen Post. Die muss ein anderes, ebenfalls extrem schwer zu knackendes Problem lösen: moderne Speicher sind riesig, haben aber eine ganz kleine Tür. (Große Kapazität, kleine Bandbreite). Wer die Halme des Heuhaufens miteinander vergleichen will, müsste diese ganzen Halme immer wieder durch diese Tür schaffen.

Der sehr sehr schnelle Computer, den ich erwähnte, muss nicht groß sein. Er muss eine Technologie haben, von der Du und ich nichts wissen. Auch mit einem sehr sehr schnellen Pferd kann man nicht auf den Mond fliegen.

Volker Weber, 2013-07-18

Die Vorstellung ist so schwierig, weil wir kein Gefühl für Exponentialfunktionen haben. Du kennst das von der Geschichte mit dem Erfinder des Schachspiels. Ein Reiskorn auf das erste Feld, jeweils die doppelte Menge auf das folgende. 2^64.

Hier reden wir davon, dass man vielleicht 2^1024 knacken kann. Wir stellen aber gerade um auf 2^2048. Und das ist eben nicht doppelt so langwierig, sonder bestenfalls 2^1024 mal schwieriger.

Aus einer Minute würden also (Zahl mit 308 Nullen) Minuten. Exakt siehst Du das hier: http://www.wolframalpha.com/input/?i=2+%5E+1024

Wie Du siehst, ist es sogar egal, ob ich von Minuten oder Jahren spreche. Ein Jahr hat etwa eine halbe Million Minuten. Das nimmt nur sechs Nullen weg von den 308.

Volker Weber, 2013-07-18

Bzgl. Wie komme ich an die Schlüssel:
Ich brauche den Schlüssel garnicht , denn ich verkaufe Software, die einfach 2mal verschlüsselt und verkaufe das als Recovery-Funktion. Siehe EFS und die kommerzielle Variante von PGP (damals bei CA).
Vor dem Hintergrund der aktuellen Enthüllungen sollte man sich vielleicht auch mal überlegen, wo man seine Schlüssel herbekommt und ob amerikanische Unternehmen so eine gute Wahl sind.

Christian Henseler, 2013-07-18

Siehe oben, vorletzter Absatz: ich verrate den Schlüssel des ersten Verfahrens.

Volker Weber, 2013-07-18

Wie wäre es, wenn jemand anstelle der Rückwärtsentschlüsselung einfach "vorwärts" alle Schlüssel durchrechnet und in einer Art Tabelle speichert? Der Aufwand müsste nur ein einziges Mal betrieben werden.

Thomas Papenmeier, 2013-07-18

Ja, das ist einfach. Du hast dann (Zahl mit 616 Nullen) Schlüssel. Die kannst Du dann alle ausprobieren. Einer wird passen. Leider ist bis dahin das Universum erkaltet.

Volker Weber, 2013-07-18

Nein, Du hast dann soviele Schlüsselpaare und welcher öffentliche Schlüssel richtig ist, weißt Du ja. Die Frage wäre nur, wie schnell dann wiederum der Zugriff auf die Tabelle funktioniert.

Thomas Papenmeier, 2013-07-18

Gut, dann überschlage mal, wieviel Speicherplatz die Tabelle braucht. Ein Terabyte hat 12 Nullen. Wir wollen nun (Zahl mit 616 Nullen) Schlüsselpaare speichern.

Volker Weber, 2013-07-18

Nun, das eigentliche Problem ist nicht, wie sicher Verschlüsselungen funktionieren, sondern dass im Grunde keiner verschlüsselt. Das sieht man eben genau hier an dieser Diskussion. Keiner der Poster hält es für eine brauchbare Alternative, seinen Beitrag hier verschlüsselt zu publizieren. Und wer jetzt sagt, hier sei ja eh alles öffentlich, kann ja mal mitteilen, wie viel Prozent seiner nicht öffentlichen Nachrichten von ihm verschlüsselt werden. Wer aber letztlich nur jene Nachrichten verschlüsselt, deren Inhalt brisant ist oder sein könnte, der setzt quasi ein Ausrufezeichen hinter seine Mail, bei der ja - Volker hat's schon geschrieben - andere wichtige Informationen wie Sender und Empfänger weiterhin unverschlüsselt übertragen werden. Das Problem mit der Verschlüsselung ist also, dass sie nicht durchgängig eingesetzt wird und es für diesen Einsatz keinen so verbreiteten Standard gibt, dass unverschlüsselte E-Mails auffälliger wären. Dann aber, wenn es diesen Standard gäbe, hielte auch jemand einen Universalzweitschlüssel in der Hand, von dem wir erst spät erfahren, der uns aber nicht überrascht, da wir seine Existenz längst ahnten.

Ray Wiseman, 2013-07-18

Tja, der Trade-Off zwischen Speicherplatz (um vorberechnete Ergebnisse effizient abrufbar zu halten) und Rechenzeit (um die Ergebnisse ad-hoc bei Bedarf zu berechnen) ist ein ganz alter, aber im IT Sicherheitsbereich ziemlich wichtig. Schönes Beispiel: Rainbow-Tables - d.h. Listen von Passwörtern und dazu gehörigen Hashwerten. Damit kann man sich das Zurückrechnen vom Passwort-Hash für jedes Passwort sparen, aber die Dinger sind halt schnell mal etliche Gigabyte bis einige Terabyte gross (je nachdem, wie vollständig die Liste sein soll). Aber da man heutzutage ja die Passwörter mit einem Salt versieht (bzw. das tun sollte), bevor man sie hashed, sind die Rainbow Tables auch nicht mehr so hilfreich.

Die Verfügbarkeit von massiv parallelisierten Rechnern (CUDA et al) hat das bruteforcen allerdings in eine neue Dimension gebracht. c't hatte da vor einiger Zeit mal ein paar interessante Tests gemacht.

In der Tat sind aber die meisten erfolgreichen Angriffe nicht auf die eigentliche Kryptographie, sondern vielmehr auf das Design des Gesamtsystems. Da wird entweder schon gar keine Kryptographie eingesetzt oder sie wird mit dem von Volker schon angesprochenen Halbwissen eingesetzt und ist somit nur begrenzt hilfreich.

Ragnar Schierholz, 2013-07-18

Recent comments

Alexander Hüls on Und der Gewinner ist ... at 18:09
Adalbert Duda on Und der Gewinner ist ... at 09:31
Martin Cygan on Jede Menge neue Amazon Echos at 00:50
Christoph-Alexander Dettmann on WIWE: So sieht ein schlechtes EKG aus at 16:37
Volker Weber on WIWE: So sieht ein schlechtes EKG aus at 14:18
Christoph-Alexander Dettmann on WIWE: So sieht ein schlechtes EKG aus at 14:00
Johannes Matzke on WIWE: So sieht ein schlechtes EKG aus at 13:46
Hubert Stettner on Erhöhte Sicherheit bei neuem iPhone und neuer Apple Watch at 12:19
Martin Kautz on Und der Gewinner ist ... at 10:10
Thomas Cloer on Und der Gewinner ist ... at 09:51
Roland Dressler on Und der Gewinner ist ... at 09:27
Volker Weber on Und der Gewinner ist ... at 21:18
Horia Stanescu on WIWE: Mobiles EKG für Android oder iPhone at 21:10
Christoph-Alexander Dettmann on WIWE: Mobiles EKG für Android oder iPhone at 17:20
Thomas Cloer on Und der Gewinner ist ... at 17:11
Jochen Schug on Und der Gewinner ist ... at 16:52
Felix Binsack on Und der Gewinner ist ... at 16:35
Volker Weber on Upgrade to iOS 12 now at 15:40
Jochen Schug on Upgrade to iOS 12 now at 15:34
Jochen Schug on Und der Gewinner ist ... at 15:30
Volker Weber on Und der Gewinner ist ... at 15:16
Stephan Perthes on Und der Gewinner ist ... at 15:04
Torsten Bloth on Und der Gewinner ist ... at 14:44
Harald Gärttner on Und der Gewinner ist ... at 14:37
Karl Heindel on Und der Gewinner ist ... at 14:30

Ceci n'est pas un blog

I explain difficult concepts in simple ways. For free, and for money. Clue procurement and bullshit detection.

vowe

Contact
Publications
Stuff that works
Amazon Wish List
Frequently Asked Questions

rss feed  twitter  amazon

Local time is 01:32

visitors.gif

buy me coffee