Symmetrische vs. Asymmetrische Verschlüsselung
Nachdem ich beim Thema MD5-Hash schon die Symmetrie von Verschlüsselungsalgorithmen ins Spiel gebracht habe, möchte ich die Begriffe natürlich auch noch abschließend erläutern und die Thematik abrunden. Wie gestern aufgezeigt, ist ein Hash keine Verschlüsselung, da Hashalgorithmen immer nur in eine Richtung arbeiten. Verschlüsselungen dagegen sind in beide Richtung möglich (Ver- und Entschlüsselung) und verwenden für eben diese Vorgänge einen Schlüssel. Genau aus diesem Grund ist natürlich der Schlüssel (Key) eine der wichtigsten Parameter für Verschlüsselungsalgorithmen.
Betrachten wir den Begriff Symmetrie erst einmal allgemein: Symmetrie ist dadurch geprägt, dass ein Objekt durch Anwendung von definierten Transformation unverändert bleibt. Das klingt ziemlich kompliziert, ein Beispiel soll es daher verdeutlichen: Man nehme einen Kreis und teile ihn genau in der Mitte durch eine senkrechte Linie. Werden nun die Seiten an dieser Linie (vgl. Symmetrieache) gespiegelt, erhält man stets immer wieder den gleichen Kreis.
Symmetrie in der Kryptographie bzw. bezogen auf das Verschlüsselungskonzept passt sehr gut zu unserem Kreisbeispiel. Eine symmetrische Verschlüsselung ist dadurch geprägt, dass der Schlüssel für die Verschlüsselung und der Schlüssel für die Entschlüsselung absolut identisch ist. Wird also beispielsweise ein Klartext mit dem Schlüssel masterkey kodiert, kann der Klartext rückwärts nur eben wieder mit diesem Schlüssel masterkey ermittelt werden.
Asymmetrische Verschlüsselungsalgorithmen setzen dagegen auf Schlüsselpaare. D.h., dass ein Klartext mit einem Schlüssel1 verschlüsselt wird, und nur mit einem Schlüssel2 entschlüsselt werden kann. Beide Schlüssel bilden das Schlüsselpaar, wobei einer der Schlüssel öffentlich (public key) und der andere Schlüssel privat (private key) verwendet werden. Der Sender erhält hierzu den öffentlichen Schlüssel und kann nun seine Nachricht uns gegenüber verschlüsseln. Gerät nun diese kodierte Nachricht mit dem öffentlichen Schlüssel in die falsche Hände, ist dies unkritisch, da nur wir den privaten Schlüssel für die Entschlüsselung kennen.
Für eine bidirektionale Kommunikation könnte nun jemand auf die Idee kommen, dass beide Schlüssel ausgetauscht werden müssen. Das ist natürlich fatal und sollte einem als Entwickler niemals als Idee einfallen. Für bidirektionale Kommunikation müssen natürlich zwei Schlüsselpaare existieren, d.h. der Client besitzt ein Schlüsselpaar und der Server besitzt ein Schlüsselpaar und beide tauschen untereinander lediglich den öffentlichen Schlüssel aus. Der eine oder andere wird jetzt feststellen, dass wir indirekt schon das Verfahren von SSL beschrieben haben, da hier genau diese Vorgänge stattfinden.
Im Übrigen gibt es auch bei SSL noch Angriffsmöglichenkeiten wie eine Man-in-the-Middle-Attacke. Mehr hierzu gibts dann beim nächsten Mal.
Anzeige: "Samsung Galaxy S3 mit Android 4.0" jetzt günstig bei Amazon.de kaufen:
