Diplomarbeit. Parallelisierbarkeit kryptographischer Algorithmen

Transkript

1 Parallelisierbarkeit kryptographischer Algorithmen Diplomarbeit Hochschule Merseburg (FH) Fachbereich Informatik und Angewandte Naturwissenschaften Studiengang: Informatik eingereicht von Steffen Pankratz geboren am 1. Februar 1981 in Naumburg/Saale Erstprüfer: Prof. Dr. U. Heuert Zweitprüfer: Prof. Dr. M. Schenke

2 Danksagung Hiermit möchte ich allen Personen danken, die mich bei der vorliegenden Diplomarbeit aktiv unterstützt haben. Mein Dank gilt vor allem Herrn Prof. Dr. Heuert und Herrn Prof. Dr. Schenke von der Fachhochschule Merseburg für die Betreuung der Arbeit, die stetige Diskussionsbereitschaft und die kritischen und hilfreichen Anmerkungen zu dieser Arbeit. i

3 Inhaltsverzeichnis 1 Einleitung 1 2 Grundlagen Kryptographie Begriffsdefinition Geschichte Asymmetrische Algorithmen Symmetrische Algorithmen Data Encryption Standard (DES) Hash Algorithmen Das OpenSSL Projekt Engine Modul Unterstützung Parallelisierung Prozesse und Threads Realisierung Erwartungen an die Software Verwendetes Softwareentwicklungsmodell Wahl der Programmiersprache Entwicklungsumgebung Implementierung Installation Programmbedienung Tests und Ergebnisse 44 5 Zusammenfassung und Ausblick 51 Literatur- und Quellenverzeichnis 52 ii

4 Abkürzungsverzeichnis 54 Abbildungsverzeichnis 56 Tabellenverzeichnis 57 A Thesen zur Diplomarbeit 59 B Anlagen 60 C Eidesstattliche Erklärung 61 iii

5 Kapitel 1 Einleitung Heutzutage spielt Vertraulichkeit und Authentizität von Daten eine immer größer werdende Rolle. Um das zu gewährleisten, bietet sich die Verwendung von Kryptographie an. Daten nur zu verschlüsseln reicht bei Weitem nicht aus, da dadurch keinesfalls die Authentizität der Daten gesichert wird, was durch Einsatz von Einweghashfunktionen oder digitale Signaturen erreicht werden kann. Die Sicherheit der Verschlüsselung hängt vom verwendetem Algorithmus, der Schlüssellänge und der zu kodierenden Daten ab. Bei immer größer werdenden Datenmengen und längeren Schlüsseln, spielt der Zeitaufwand für die Ver- und Entschlüsslung, die Erstellung von Signaturen oder Prüfsummen eine bedeutende Rolle. Um diese Vorgänge zu beschleunigen, bietet es sich an, Prozesse oder Teilprozesse zu parallelisieren. Gerade in der Kryptoanalyse, dem Teilgebiet der Kryptologie, welches sich damit befasst, kryptographische Verfahren zu brechen, kommt verteiltes Rechnen zum Einsatz. Ein Beispiel gibt der Verschlüsselungsalgorithmus RSA-640, der erst vor Kurzem von einem Opteron-Cluster mit 80 Prozessoren von jeweils 2,2 GHz geknackt wurde (onl05b). Nun stellt sich die Frage, warum im Gegensatz zur Kryptoanalyse in der Kryptographie keine parallele Rechentechnik eingesetzt wird. Im Rahmen dieser Diplomarbeit wird untersucht, inwieweit kryptographische Vorgänge parallelisiert werden können. Es werden dabei verschiedene Themengebiete behandelt, wie die Analyse bestehender Verfahren und Algorithmen, die Einarbeitung in die OpenSSL Kryptobibliothek, sowie eine Implementierung mit Hinblick auf einen dynamischen und parallelen Einsatz mit dem openssl Programm. Im ersten Kapitel wird zunächst auf die Geschichte der Kryptographie eingegangen, von ihren Anfängen und der Entstehung bis hin in unsere Zeit. Desweiteren werden Grundlagen beschrieben, welche bei der Lösung der gestellten Problematik zum Einsatz kamen. Das nächste Kapitel beschreibt den Softwaremodellierungsprozess, die Entstehung und Probleme bei der Programmierung. Außerdem wird zusätzlich auf die Installation und den Einsatz der entstandenen Software eingegangen. Der vorletzte Abschnitt zeigt Tests und Ergebnisse des entwickelten Engine Moduls. Zum Schluss der Arbeit wird noch ein Resümee gezogen, was die Ergebnisse der Diplomarbeit und deren Bewertung betrifft. 1

6 Kapitel 2 Grundlagen In den nachfolgenden Ausführungen werden die wissenschaftlichen Grundlagen geschaffen, die als Voraussetzung für die Konzeption und Implementierung benötigt werden. 2.1 Kryptographie Begriffsdefinition Chiffre ist ein Synonym für ein Verschlüsselungsverfahren. Chiffretext (Ciphertext) ist das Ergebnis einer Verschlüsselung. Chiffrierung ist ein Synonym für Verschlüsselung, aber auch für ein Verschlüsselungsverfahren. Dechiffrierung ist ein Synonym für Entschlüsselung. Klartext (Plaintext) ist der unverschlüsselte Text. Kryptoanalyse beschäftigt sich mit der Analyse von verschlüsselten Daten, mit dem Ziel, eine verschlüsselte Nachricht lesbar zu machen. Kryptographie ist die Wissenschaft von der Verschlüsselung von Daten, zusammengesetzt aus dem griechischen kryptós, verborgen, und gráphein, schreiben. Kryptologie vereinigt Kryptographie und Kryptoanalyse Geschichte Die klassische Kryptographie kennt nur sehr einfache Verfahren, welche auch nicht sonderlich sicher sind. Sie sind dennoch ein Standbein der modernen Kryptographie. Der früheste Einsatz von 2

7 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Kryptographie findet sich bei den Ägyptern um 1900 vor Christus, welche unübliche Hieroglyphen verwendeten. Hebräische Gelehrte nutzten ungefähr 600 bis 500 vor Christus einfache Zeichenaustauschalgorithmen. Atbash Atbash ist eine hebräische Geheimschrift, die um 600 vor Christus in Palästina benutzt wurde. Es ist eine sehr einfache Substitutionschiffre und beruht auf der Umdrehung des Alphabets. Das hebräische Alphabet unterscheidet sich von unserem Heutigem, aber das Prinzip ist das Gleiche. Das Geheimtextzeichen wird im umgedrehten Alphabet, unter dem zu verschlüsselten Klartextbuchstaben, abgelesen. Alphabet: Atbash: ABCDEFGHIJKLMNOPQRSTUVWXYZ ZYXWVUTSRQPONMLKJIHGFEDCBA Für die Nachricht HALLOWELT ergibt sich demnach SZOOLDVOG. Skytale von Sparta Um 2500 vor Christus setzten die Spartaner Transpositionschiffren ein. Transposition ist ein anderer Begriff für Permutation 1. Eines der bekanntesten Verfahren ist die Skytale von Sparta. Die Skytale war ein Zylinder mit festem Radius, auf den spiralförmig ein Pergamentband aufgewickelt wurde. Das Wort skytale ist altgriechisch und steht für Stab. Die Nachricht wurde in Längsrichtung auf das aufgewickelte Band geschrieben. Der Empfänger benötigte einen Stab gleichen Durchmessers, auf den er das Band aufwickeln und danach die Nachricht lesen konnte. Die so erzeugten Geheimtexte wurden hauptsächlich zur militärischen Nachrichtenübermittelung verwendet. Beispiel einer Spaltentransposition: Aus der Nachricht HALLOWELT wird unter Verwendung einer Skytale des Umfangs U = 3 (der Text wird in 3 Spalten aufgeteilt): H A L L O W E L T Wenn nun jede Spalte von oben nach unten abgeschrieben wird, ergibt sich folgendes Ergebnis: HLEAOLLWT Es gibt durchaus noch viel kompliziertere Transpositionschiffren. Der alleinige Einsatz von Trans- 1 ist eine Veränderung der Reihenfolge der Elemente einer Menge 3

8 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN position ist allerdings nicht sicher, deshalb wird sie in der modernen Kryptographie zusammen mit der Substitution 2 verwendet. Caesar Chiffrierung Eine sehr einfache Substitution ist die Caesar Chiffrierung. Ansich ist sie nur eine Verschiebung des Klartextalphabets um eine bestimmte Anzahl von Stellen. Im Beispiel wird das Geheimtextalphabet um vier Stellen nach links verschoben: Klartextalphabet Geheimtextalphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ EFGHIJKLMNOPQRSTUVWXYZABCD Eine Nachricht wird chiffriert, indem jeder Klartextbuchstabe durch den darunter stehenden Geheimtextbuchstaben ersetzt wird. Aus dem Wort HALLOWELT wird in diesem Fall: LEPPSAIPX. Substitutionschiffren ordnen einen Buchstaben des Alphabets jeweils einen Anderen zu,deshalb werden sie auch als monalphabetische Verschlüsselung bezeichnet. Monoalphabetische Chiffrierungen lassen sich relativ leicht mit Hilfe einer Häufigkeitsanalyse brechen. Statistisch gesehen, kommt nicht jeder Buchstabe in einer bestimmten Sprache gleich häufig vor. Im Deutschen tritt das e mit einer Häufigkeit von durchschnittlich 17,4 Prozent, das s mit 7,3, r mit 7, a mit 6,5 und so weiter auf. (Beu96) Um einen verschlüsselten Text lesbar zu machen, wird zunächst die Häufigkeit eines jeden Geheimtextzeichens untersucht. Danach werden verschiedene Buchstaben ausprobiert, die aufgrund ihrer Häufigkeit passen könnten. Je länger eine chiffrierte Nachricht ist, desto leichter lässt sie sich brechen. Vigenère-Chiffre Um die Schwäche des Cäsar-Codes zu umgehen, entwickelte der französische Diplomat Blaise de Vigenère 1586 die nach ihm benannte Chiffre. Die Vigenère-Chiffre verschlüsselt gleichzeitig mehrere Buchstaben des Alphabets. Eine solche Chiffre wird polyalphabetisch genannt. Um eine Botschaft zu verschlüsseln, werden ein Schlüsselwort und das Vigenère-Quadrat (Tabelle 2.1) benötigt. Falls das Schlüsselwort kleiner als die Nachricht ist, wird es wiederholt aneinander gehängt. Das Quadrat setzt sich aus 26 Alphabeten zusammen. Die erste Zeile enthält das um 0 Stellen verschobene, die zweite das um 1 Stelle verschobene, die dritte das um 3 Stellen verschobene Alphabet und so weiter. Die letzte Zeile des Vigenère-Quadrats spiegelt das um 25 Stellen verschobene Alphabet wider. Klartext Schlüsselwort HALLOWELT GEHEIMGEH Man stellt sich das Quadrat als Koordinatensystem vor, die x-achse von A-Z (oben, von links nach 2 Ein Buchstabe oder Zeichen wird durch einen anderen Buchstaben bzw. Zeichen ersetzt wird 4

9 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN rechts) und ebenso die y-achse (links, von oben nach unten). Der jeweilige Buchstabe im Klartext dient als x-wert und der darunter liegende Schlüsselbuchstabe als y-wert. Für das oben gezeigte Beispiel ergibt sich dann folgender Chiffretext: Geheimtext: NGSPIKPA Die Häufigkeit der Buchstaben ist bei diesem Verfahren viel gleichmäßiger verteilt. Die beiden L im Klartext werden zu unterschiedlichen Geheimtextbuchstaben verschlüsselt (nämlich S und P ). Tabelle 2.1: Vigenère-Quadrat A B C D E F G H I J K L M N O P Q R S T U V W X Y Z B C D E F G H I J K L M N O P Q R S T U V W X Y Z A C D E F G H I J K L M N O P Q R S T U V W X Y Z A B D E F G H I J K L M N O P Q R S T U V W X Y Z A B C E F G H I J K L M N O P Q R S T U V W X Y Z A B C D F G H I J K L M N O P Q R S T U V W X Y Z A B C D E G H I J K L M N O P Q R S T U V W X Y Z A B C D E F H I J K L M N O P Q R S T U V W X Y Z A B C D E F G I J K L M N O P Q R S T U V W X Y Z A B C D E F G H J K L M N O P Q R S T U V W X Y Z A B C D E F G H I K L M N O P Q R S T U V W X Y Z A B C D E F G H I J L M N O P Q R S T U V W X Y Z A B C D E F G H I J K M N O P Q R S T U V W X Y Z A B C D E F G H I J K L N O P Q R S T U V W X Y Z A B C D E F G H I J K L M O P Q R S T U V W X Y Z A B C D E F G H I J K L M N P Q R S T U V W X Y Z A B C D E F G H I J K L M N O Q R S T U V W X Y Z A B C D E F G H I J K L M N O P R S T U V W X Y Z A B C D E F G H I J K L M N O P Q S T U V W X Y Z A B C D E F G H I J K L M N O P Q R T U V W X Y Z A B C D E F G H I J K L M N O P Q R S U V W X Y Z A B C D E F G H I J K L M N O P Q R S T V W X Y Z A B C D E F G H I J K L M N O P Q R S T U W X Y Z A B C D E F G H I J K L M N O P Q R S T U V X Y Z A B C D E F G H I J K L M N O P Q R S T U V W Y Z A B C D E F G H I J K L M N O P Q R S T U V W X Z A B C D E F G H I J K L M N O P Q R S T U V W X Y Entschlüsselt wird, indem in der jeweiligen Zeile, die mit dem Schlüsselbuchstaben beginnt, der Buchstabe des Chiffretextes gesucht und dann an der Stelle der dazu gehörige Wert auf der x-achse abgelesen wird. Playfair-Chiffre Diese Chiffre hat ihren Namen von Baron Playfair von St. Andrews und wurde von dessen Freund um 1854 erfunden. Dieses Verfahren verschlüsselt statt Buchstaben ganze Buchstabengruppen von jeweils zwei Zeichen. Es wird ein Schlüsselwort benötigt, welches in eine 5x5 Matrix eingetragen wird. Tabelle 2.2 zeigt eine solche Matrix mit dem Codewort GEHEIM. Jeder Buchstabe kommt nur einmal vor und I und J teilen sich ein Element. Zuerst wird das Schlüsselwort (doppelte Buchstaben nur einmal) und danach das Alphabet, ohne die bereits notierten Zeichen, eingetragen. Anschließend wird die Nachricht in Gruppen zu je zwei Buchstaben zerlegt. Enthält danach eine der Gruppen gleiche Buchstaben oder es bleibt am Schluss ein einzelner Buchstabe übrig, wird ein belie- 5

10 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Tabelle 2.2: 5*5-Matrix der Playfair-Chiffre mit dem Codewort GEHEIM G E H I/J M A B C D F K L N O P Q R S T U V W X Y Z biger Füllbuchstabe ein- beziehungsweise angefügt. Für das Beispiel ergibt sich dann Folgendes: Die zweite Gruppe besteht aus zwei L und am Schluss bleibt T alleine übrig. Durch Einfügen eines Füllbuchstabens, hier X, lässt sich dieses Problem lösen. Klartext Klartext gruppiert Klartext mit Füllbuchstaben HALLO WELT HA LL OW EL T HA LX LO WE LT Bei der Verschlüsselung werden drei Fälle unterschieden: 1. Beide Buchstaben liegen in derselben Reihe: Jeder Buchstabe wird verschlüsselt, indem er durch den Nächstfolgenden derselben Zeile ersetzt wird. Handelt es sich beim Klartextbuchstaben um den Letzten der Zeile, wird mit dem Ersten der Zeile verschlüsselt. 2. Beide Buchstaben liegen in derselben Spalte: Jeder Buchstabe wird verschlüsselt, indem er durch den unter ihm Stehenden derselben Spalte ersetzt wird. Handelt es sich beim Klartextbuchstaben um den Untersten der Spalte, wird er mit dem Obersten der Spalte verschlüsselt. 3. Beide Buchstaben liegen weder in derselben Reihe noch in derselben Spalte: In der Zeile des Klartextbuchstabens wird nach links oder rechts gegangen, bis die Spalte, in welcher der andere Buchstabe der Gruppe liegt, diese Zeile schneidet. Mit dem Buchstaben an dem Schnittpunkt wird dann verschlüsselt. Für das Beispiel ergibt sich dann folgender Geheimtext: Geheimtext: GC NW NP EB OR hintereinander geschrieben: GCNWNPEBOR Die Entschlüsselung erfolgt nach demselben Prinzip, nur in umgekehrter Richtung: statt nachfolgend wird vorangehend, statt darunter stehend wird darüber genommen. Nur der dritte Fall wird genau so entschlüsselt wie bei der Verschlüsselung. Der besondere Vorteil des Verfahrens ist, dass mit der Entschlüsselung eines Teils noch nicht auf den Klartext geschlossen werden kann. 6

11 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN One Time Pad One Time Pad, aus dem Englischem übersetzt Einmalblock, ist das einzige kryptographische Verfahren, welches theoretisch nicht brechbar, aber in der Praxis zu aufwendig ist, da: 1. Der Schlüssel genau so lang sein muss wie der Klartext. 2. Der Schlüssel streng zufällig gewählt sein muss. 3. Jeder Schlüssel nur ein einziges Mal verwendet werden darf und danach unwiderruflich vernichtet werden muss. Das Verfahren ist auch unter dem Namen Vernam-Chiffre bekannt und wurde 1917 von Gilbert Vernam von AT&T und Major Joseph Mauborgne erfunden. Es besteht aus einer langen Folge von Zufallsschlüsselzeichen, die in einem Schreibblock (ursprünglich ein Lochstreifen für Fernschreiber) aufgeschrieben werden. Bei der Verschlüsselung wird jedes Klartextzeichen mit einem Zeichen aus dem One Time Pad verschlüsselt. Schlüsselbuchstaben werden nur genau einmal und nur in einer einzigen Nachricht verwendet. Die Verschlüsselung selber ist eine Addition des Geheimtext- und Schlüsselbuchstabens modulo 26, wobei die Zeichen als Zahlen dargestellt werden (A = 1, B = 2,..., Y = 25, Z = 0). Wenn die Nachricht HALLOWELT lautet und die dazugehörige Schlüsselsequenz aus dem ONE TIME PAD SDFLAEWRO lautet, sieht die Verschlüsselung folgendermaßen aus: (H + S) mod 26 = ( ) mod 26 = 1 = A (A + D) mod 26 = ( 1 + 4) mod 26 = 5 = E (L + F) mod 26 = (12 + 6) mod 26 = 18 = R (L + L) mod 26 = ( ) mod 26 = 0 = X (O + A) mod 26 = (15 + 1) mod 26 = 16 = P (W + E) mod 26 = (23 + 5) mod 26 = 2 = B (E + W) mod 26 = ( ) mod 26 = 2 = B (L + R) mod 26 = ( ) mod 26 = 4 = D (T + O) mod 26 = ( ) mod 26 = 9 = I Der Geheimtext lautet demzufolge AERXPBBDI und die Entschlüsselung erfolgt ähnlich dem Verschlüsselungsschema: (26 + A - S) mod 26 = ( ) mod 26 = 8 = H (26 + E - D) mod 26 = ( ) mod 26 = 1 = A (26 + R - F) mod 26 = ( ) mod 26 = 12 = L (26 + X - L) mod 26 = ( ) mod 26 = 12 = L (26 + P - A) mod 26 = ( ) mod 26 = 15 = O 7

12 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN (26 + B - E) mod 26 = ( ) mod 26 = 23 = W (26 + B - W) mod 26 = ( ) mod 26 = 5 = E (26 + D - R) mod 26 = ( ) mod 26 = 12 = L (26 + I - O) mod 26 = ( ) mod 26 = 20 = T Der Kern des Verfahrens ist: Der Schlüssel muss genau so lang sein wie die Nachricht und beide werden miteinander durch eine umkehrbare Verknüpfung (Modulo, XOR-Verknüpfung aber auch jede andere bijektive Funktion) ver- beziehungsweise entschlüsselt. Das One Time Pad ist bewiesen sicher, es ist aber sehr unpraktisch und wird daher selten eingesetzt. Schlüssel müssen zuvor über einen sicheren Kanal ausgetauscht werden. Zusätzlich muss jeweils ein eigener Schlüssel für jede Beziehung zwischen Sender und Empfänger verwendet werden. Wenn jeder mit jedem kommunizieren wollte, steigt die Anzahl der Schlüssel quadratisch mit der Anzahl der Kommunikationspartner. Kerckhoff-Prinzip Ende des 19. Jahrhunderts wurde von Auguste Kerckhoffs von Nieuwenhof ein Grundsatz (Kerckhoff- Prinzip) formuliert. Dieser besagt, die Sicherheit eines kryptographischen Verfahrens sollte alleine auf der Geheimhaltung des Schlüssels basieren (adl05). Die Enigma Die Handhabung langer Schlüssel, wie beim One Time Pad Verfahren, ist in der Praxis sehr schwierig. Die von Arthur Scherbius 1923 konstruierte Enigma bietet die Möglichkeit aus einen langen Schlüssel einen Kurzen zu generieren. Die Enigma ist eine polyalphabetische Chiffriermaschine. Während des 2. Weltkrieges wurde die Enigma (griechisch für Rätsel) zur Sicherung des Funkverkehrs der deutschen Wehrmacht und der deutschen Marine eingesetzt. Während des Krieges wurde die Maschine immer wieder umgebaut und verbessert. Die Funktionsweise der Enigma ist recht komplex. Die Eingabe erfolgt über eine Schreibmaschinentastatur (26 Tasten). Jede Taste ist einzeln elektrisch mit drei Rotoren, mit insgesamt bis zu 6 Ringen verbunden. Auf jedem dieser Ringe befindet sich das gesamte Alphabet und bei jedem Tastendruck werden die Walzen systematisch um eine Stelle weiter gedreht, so dass derselbe Buchstabe immer wieder anders verschlüsselt wird. Die Walzen haben elektrische Kontakte. Wird eine Taste gedrückt, so fließt Strom von der Taste durch die Walzen bis zu einer Anzeige, wo der ver- beziehungsweise entschlüsselte Buchstabe aufleuchtet. Die Verschlüsselung ist umkehrbar, das heißt derselbe Tagesschlüssel konnte zum chiffrieren und dechiffrieren genutzt werden. Die Enigma verwendet also ein symmetrisches Verfahren. 8

13 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Moderne Kryptologie Die Anfänge begründete Claude Elwood Shannon 1949 mit der Veröffentlichung seines Artikels Communication Theory of Secrecy Systems im Bell System Technical Journal, Ausgabe 28. Darin definierte er das erste allgemeine, mathematische Modell der Kryptologie. Er stellte zudem fest, dass Kryptographie vornehmlich auf mathematischen Verfahren und Algorithmen basiert. Die wohl bedeutendsten Veröffentlichungen für die moderne Kryptographie waren DES und das erste Public-Key Cryptosystem im Jahre Letzteres wurde von Whitfield Diffie und Martin Hellmann publiziert. Das RSA Verfahren wurde im darauf folgendem Jahr entwickelt. Die moderne Kryptographie definiert drei Hauptziele für sicheren Datenverkehr (Mat03, S. 99): Vertraulichkeit: Nachrichten sollen von Unbefugten nicht gelesen werden können Integrität: Nachrichten sollen nicht unbemerkt verfälscht werden können Authentizität: Die Echtheit des Absenders soll überprüfbar sein Asymmetrische Algorithmen Dieses Verfahren wird auch als Public Key Verfahren bezeichnet. Im Gegensatz zu symmetrischen Verfahren, bei denen derselbe Schlüssel für die Ver- und Entschlüsselung benutzt wird, benötigt man bei diesem Algorithmus für beide Vorgänge verschiedene Schlüssel. Deshalb spricht man auch von Asymmetrie. Bei der Überführung einer Nachricht in Chiffretext wird der öffentliche Schlüssel und zur Entschlüsselung der private (geheime) Schlüssel eingesetzt. Der öffentliche Schlüssel ist für jeden zugänglich und jeder kann damit Botschaften codieren. Der Besitzer des öffentlichen Schlüssels ist aber der Einzige, der mit Hilfe seines privaten Schlüssels, diese Nachrichten dechiffrieren kann. Abbildung 2.1 veranschaulicht den Sachverhalt noch einmal. Der in Bild 2.1 schematisch dargestellte Ablauf findet so in der Praxis nicht statt. Da asymmetrische Verschlüsselungsverfahren sehr langsam sind, sind sie für große Datenmengen ungeeignet. Deswegen wird zur eigentlichen Verschlüsselung der Nachricht ein symmetrisches Verfahren (siehe 2.1.4) benutzt. Dabei wird ein, dem Empfänger, bis dato unbekannter Schlüssel verwendet. Dieser so genannte Sitzungsschlüssel (Session Key) wird dann mit dem öffentlichen Schlüssel des Empfängers verschlüsselt. Nach dem Erhalt der Nachricht dechiffriert der Empfänger den verschlüsselten Session Key mit seinem privatem Schlüssel. Danach kann dann die eigentliche Nachricht entschlüsselt werden. Der gerade beschriebene Ablauf wird als Hybride-Verschlüsselung bezeichnet. Sie verbindet sowohl die Vorteile von symmetrischen als auch von asymmetrischen Verfahren. Asymmetrische Verfahren kommen unter anderem auch bei der Verschlüsselung, Authentifizierung und Sicherung der Integrität, zum Beispiel beim -Verkehr (PGP, S/MIME 3 ) oder auch bei kryptographischen Pro- 3 S/MIME steht für Secure Multipurpose Internet Mail Extensions. S/MIME erweitert das MIME-Format um Funktionen für Verschlüsselung und digitale Signaturen. 9

14 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Abbildung 2.1: Public Key Verfahren (Ehl02) 10

15 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN tokollen wie SSH 4 zum Einsatz. Ein wichtiger Einsatzbereich ist die elektronische Signatur, welche die Authentizität und Unveränderbarkeit der Daten garantiert. Wird zum Beispiel eine E Mail unter Verwendung eines privaten Schlüssels unterschrieben, wird dieser Vorgang Signieren genannt. Dabei wird der Hashwert einer Nachricht bestimmt und anschließend unter Verwendung des privaten Schlüssels codiert. Die Nachricht wird mit der angehängten Signatur zum Empfänger übermittelt. Dieser entschlüsselt dann mit dem öffentlichen Schlüssel des Senders die Signatur und vergleicht daraufhin den Wert mit der von ihm berechneten Prüfsumme. Das Problem bei Public-Key-Verfahren liegt darin, dass nicht garantiert werden kann, dass ein öffentlicher Schlüssel auch wirklich dem in der Benutzer-ID des Schlüssels genannten Absenders gehört. Um solche Man in the Middle 5 Angriffe zu erkennen, bietet sich der Einsatz von Zertifikaten an. So genannte Trustcenter sind für die Ausstellung von Zertifikaten verantwortlich. Durch ein Zertifikat wird eine Person eindeutig einem öffentlichen Schlüssel zugeordnet. Nationale Behörden kontrollieren die Trustcenter auf Einhaltung der Gesetze. In Deutschland ist die kontrollierende Behörde die Regulierungsbehörde Telekommunikation und Post (RegTP). Zertifikate werden durch das deutsche Signaturgesetz (SigG (Deu01)) in verschiedenen Klassen eingeteilt. Die Verteilung, das Speichern, das Widerrufen, das Erstellen und die Verwaltung von digitalen Zertifikaten wird durch eine Infrastruktur mit der Bezeichnung PKI (Public Key Infrastructure (PKI) übernommen. Die wichtigsten Teile einer PKI sind ((cry05)): Digitale Zertifikate: digital signierte elektronische Daten zum Nachweis der Echtheit von Kommunikationsobjekten Zertifizierungsstelle (Certification Authority kurz CA): übernimmt die Ausstellung von Zertifikaten Registrierungsstelle (Registration Authority): Identitätsprüfung und der Zertifizierungsvorgang mit Hilfe der Zertifizierungsstelle Zertifikatssperrliste (Certificate Revocation Lists): Liste mit zurückgezogenen, abgelaufenen und für ungültig erklärten Zertifikaten, die Liste ist ebenfalls digital signiert Verzeichnisdienst: ein durchsuchbares Verzeichnis, welches ausgestellte Zertifikate enthält; Meist ein LDAP-Server 6 Validierungsdienst: Dienst zur Überprüfung von Zertifikaten in Echtzeit, beispielsweise über OCSP 7 4 Mit SSH bzw. Secure Shell wird sowohl ein kryptographisches Protokoll als auch eine konkrete Implementierung dieses Protokolls bezeichnet. 5 Ein böswilliger Dritter täuscht zwei Kommunikationspartner, indem er ihnen jeweils die Identität des anderen vorspiegelt. 6 LDAP (Lightweight Directory Access Protocol) Netzwerkprotokoll, das die Abfrage und die Modifikation von Informationen eines Verzeichnisdienstes erlaubt 7 OCSP (Online Certificate Status Protocol) Netzwerkprotokoll, welches den Status von X.509-Zertifikaten abfragt 11

16 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Eine andere Möglichkeit die Authentizität (Echtheit) eines Public Keys zu überprüfen ist das Web of Trust (Netz des Vertrauens). Es verfolgt die Idee, die Echtheit von digitalen Schlüsseln durch ein Netz von gegenseitigen Bestätigungen (Signaturen) zu sichern. Wenn zum Beispiel Person X mit Person Y unter Verwendung des öffentlichen Schlüssels von Person Y kommunizieren möchte, vergewissert sich Person X mittels einer dritten Person Z über die Echtheit von Person Y. Die wichtigsten Standards im Zusammenhang mit Asymmetrischen Verfahren hat die Firma RSA definiert. Die Public Key Cryptography Standards, welche aus 15 einzelnen Standards bestehen (mittlerweile sind PKCS #2 und PKCS #4 in PKCS #1 zusammengefasst worden). PKCS #1 RSA Cryptography Standard PKCS #3 Diffie Hellman Key Agreement Standard PKCS #5 Password Based Cryptography Standard PKCS #6 Extended Certificate Syntax Standard PKCS #7 Kryptographic Message Syntax Standard PKCS #8 Private Key Information Syntax Standard PKCS #9 Selected Attribute Types PKCS #10 Certification Request Syntax Standard PKCS #11 Cryptographic Token Interface Standard PKCS #12 Personal Information Exchange Syntax PKCS #13 Elliptic Curve Cryptography Standard PKCS #14 Pseudo Random Number Generation Standard PKCS #15 Cryptographic Token Information Format Standard (Sch96, S ) und (Sec04) Nähere Information sind auf der Seite von RSA erhältlich, node.asp?id= Symmetrische Algorithmen Symmetrischen Verfahren verwenden zur Ver- bzw. Entschlüsselung immer den gleichen Schlüssel (Abbildung 2.2). Symmetrische Ver- und Entschlüsselungsvorgänge sind in der Regel viel schneller (Faktor 1000 und mehr) als bei asymmetrischen Verfahren, aber die Schlüsselverteilung kann hier jedoch problematisch sein (Eri04, S. 219). Symmetrische Algorithmen werden in Block- und Stromchiffre unterteilt. 12

17 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Abbildung 2.2: Ablauf einer symmetrischen Verschlüsselung (Ehl02) Stromchiffre Stromchiffre verwenden ein Bit oder ein Byte (manchmal aber auch ein 32 Bit Wort) zur Ver- oder Entschlüsselung. Blockchiffre Blockchiffre benötigen Datenblöcke fester Länge. Meist sind diese acht Byte lang. Feistelnetzwerke/Feistelchiffre Das Verfahren hat seinen Namen vom Erfinder Horst Feistel und stammt aus den frühen 70er Jahren. Feistelchiffren sind die Prototypen aller modernen Blockchiffren. Ein Block der Länge n wird in zwei Hälften L und R, die jeweils die Länge n halbe haben, geteilt, wobei n gerade sein muss (Sch96, S. 401). Dann wird eine bestimmte Anzahl von Runden durchgeführt Die Ausgabe der i-ten Runde wird durch die Ausgabe der vorherigen Runde bestimmt ( es wird eine Blockchiffrierung iteriert ). L i = R i 1 R i = L i 1 f (R i 1,K i ) K i... Teilschlüssel der i-ten Runde, f... beliebige Rundenfunktion 13

18 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Die Besonderheit dieses Konzeptes ist die Umkehrbarkeit der Rundenfunktion, die eine Umkehrfunktion für die Entschlüsselung überflüssig macht. Die linke Hälfte des Blocks wird mit der Ausgabe der Funktion f XOR verknüpft. Dadurch gilt: L i 1 f (R i 1,K i ) f (R i 1,K i ) = L i 1 Die Rundenfunktion kann noch so kompliziert sein, entscheidend ist nur, dass die Eingabewerte für die Funktion f in jeder Runde rekonstruiert werden können. Es existiert auch noch ein erweitertes Feistel-Netzwerk ( Extended Feistel-Network ), welches mit beliebig vielen Subblöcken arbeiten kann (Thö01b). Beispiele dafür sind die Blockalgorithmen CAST 256, RC6 und MARS. 14

19 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Abbildung 2.3: Arbeitsweise eines Feistel-Netzwerks (Geh98) 15

20 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Nachfolgend eine Auflistung der gängigsten, symmetrischen Algorithmen: AES (Advanced Encryption Standard) oder Rijndael Standardverschlüsselung der US Regierung von Joan Daemen und Vincent Rijmen Blowfish 1993 von Bruce Schneier entwickelt unpatentiert CAST-128, CAST-256 von Carlisle M. Adams unpatentiert unter anderem Anwendung in PGP IDEA (International Data Encryption Algorithm) 1990 an der ETH Zürich entwickelt Software-patentiert von Ascom Systec unter anderem Anwendung in PGP RC2, RC4, RC5, RC6 von Ronald Linn Rivest Twofish vom Counterpane Team 16

21 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Betriebsmodi kryptographischer Algorithmen Es gibt verschiedene Modi, wie ein kryptographischer Algorithmus eingesetzt werden kann. Nachfolgend werden die verbreitetsten näher erläutert. ECB - Electronic Codebook Dieser Modus ist sehr einfach. Hier wird ein Block fester Länge dem Algorithmus zur Ver- oder Entschlüsselung übergeben. Nacheinander werden alle Blöcke mit dem selbem Schlüssel verarbeitet (Ert03, S. 71). Wenn bei der Verschlüsselung die erforderliche Blockgröße nicht erreicht wird, muss der Block aufgefüllt werden. Dieser Vorgang nennt sich Padding. Dies kann durch Anfügen von Nullen oder Zufallsbytes geschehen, wobei Nullen sicherheitsbedenklicher sind. Die wirkliche Länge des Blocks ist entscheidend bei der Entschlüsselung. Daher enthält das letzte Byte des aufgefüllten Blocks Informationen über die wirkliche Länge des Blocks. Verschlüsselung: C i = E K (P i ) Entschlüsselung: P i = D K (C i ) C... Chiffretextblock, P... Klartextblock, i... Index der Klartext- bzw. Chiffretextblöcke E... Verschlüsselungsfunktion, D... Verschlüsselungsfunktion, K... aktueller Schlüssel Nachteile dieses Modus ist, dass Blöcke gelöscht, ersetzt oder sogar neu hinzugefügt werden können. Außerdem werden gleiche Blöcke immer in dieselben Chiffreblöcke überführt. CBC - Cipher Block Chaining Um den Schwächen des ECB Modus entgegenzuwirken, werden alle Klartextblöcke (ab dem Zweiten) vor dem Verschlüsseln mit dem vorigen Chiffreblock xor-verknüpft. So hängt jeder Block von seinem Vorgänger ab und eine Manipulation würde die Daten ab der veränderten Stelle unbrauchbar machen. Beim Entschlüsseln werden alle Blöcke (ab dem Zweiten) nach dem Entschlüsseln mit dem Vorgängerblock xor-verknüpft. Verschlüsselung: C i = E K (P i C i 1 ) Entschlüsselung: P i = C i 1 D K (C i ) Zufallsdaten werden zur Verschlüsselung des ersten Blocks benutzt, um gleiche Blöcke nicht immer in gleiche Chiffreblöcke zu kodieren. Einen solchen Zufallsdatenblock wird Initialisierungsvektor (IV) oder Initialisierungsvariable genannt. 17

22 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN CFB - Cipher Feedback In diesem Modus können Datenmengen verschlüsselt werden, die kleiner als die eigentliche Blockgröße sind. Die kleinste mögliche Einheit wäre ein Bit, also 1 Bit CFB, wobei sich die Verwendung einer Stromchiffrierung anbieten würde. Grundsätzlich gilt n Bit CFB, wobei n kleiner oder gleich der Blockgröße des verwendeten Algorithmus sein muss. Der schematische Ablauf für 8 Bit CFB wird in Abbildung 2.4 dargestellt. Am Anfang wird wieder ein Initialisierungsvektor benötigt. Verschlüsselung: C i = P i E K (C i 1 ) Entschlüsselung: P i = C i E K (C i 1 ) Abbildung 2.4: 8 Bit Cipher Feedback (Thö01a) OFB - Output Feedback Dieser Modus ist dem CBC Modus sehr ähnlich. Es wird ebenfalls ein IV benötigt und die Initialisierung erfolgt nach demselben Muster (Buc99, S. 70). Verschlüsselung: C i = P i S i Entschlüsselung: P i = C i S i S i... ein Block des Schlüssels aus dem Schieberegister S i ist unabhängig vom Klar- und Chiffretext: S i = E K (S i 1 ) 18

23 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Abbildung 2.5: 8 Bit Output Feedback (Sch96, S. 240) Es existieren noch einige andere Betriebsmodi. Diesen wird aber kaum Bedeutung beigemessen. Der Vollständigkeit halber werden diese nachfolgend aufgezählt: Block Chaining Modus (BC) Cipher Block Chaining mit Prüfsumme (CBCC) Counter Modus Plaintext Block Chaining (PBC) Plaintext Feedback (PFB) Propagating Cipher Block Chaining Modus (PCBC) (Sei04) 19

24 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Data Encryption Standard (DES) Der Daten Encryption Standard (DES) ist vermutlich das am häufigsten verwendete Kryptoverfahren des 20. Jahrhunderts. (Mil03, S. 115). Die Grundstruktur, des in den 70er Jahren entwickelten Algorithmus, ist ein 16 Runden Feistel Netzwerk. DES arbeitet mit 64 Bit großen Datenblöcken, das heißt es werden aus 8 Byte Klartext 8 Byte Chiffretext bei der Entschlüsselung erzeugt. Der Schlüssel wird mit 64 Bit angegeben. Jedes achte Bit dient einer Paritätsprüfung, daher beträgt die Netto-Schlüssellänge 56 Bit. Der schematische Ablauf einer typischen DES Verschlüsselung ist in Abbildung 2.6 dargestellt. Abbildung 2.6: 16 Runden DES (Mil03, S. 134) Die Eingangspermutation (IP) und die Ausgangspermutation, (FP) welche am Anfang beziehungsweise am Ende des Algorithmus durchgeführt werden, tragen nicht zur Sicherheit bei (Mil03, S. 135). Es ist nicht geklärt, wieso diese dann verwendet werden, aber es wird von implementationstechnischen Gründen ausgegangen (Sch96, S. 317). Tabelle 2.3 zeigt die Eingangspermutation und Tabelle 2.4 die Ausgangspermutation (die folgenden Tabellen werden von links nach rechts und von oben nach unten gelesen). Die Eingangspermutation verschiebt zum Beispiel das erste Bit auf Position 40, das Zweite 20

25 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN auf Position 8, das Dritte auf Position 48 und so weiter. Tabelle 2.3: Eingangspermutation von DES Tabelle 2.4: Ausgangspermutation von DES Um den jeweiligen Rundenschlüssel berechnen zu können, muss der 64 Bit Schlüssel auf 56 Bit reduziert werden. Das wird durch die Schlüsselpermutation in Tabelle 2.5 und das Wegfallen jedes achten Bits erreicht. Mit dem nun vorliegendem 56 Bit Schlüssel wird in jeder der 16 Runden ein neuer 48 Bit langer Teilschüssel gebildet. Dieser ergibt sich folgendermaßen: Der Schlüssel wird geteilt und je nach Rundenanzahl die beiden 28 Bit langen Hälften um die in Tabelle 2.6 gegeben Anzahl von Bits nach rechts verschoben. Durch die Verschiebung kommen verschiedene Teilmengen des Schlüssels in einem Teilschlüssel vor. Die Rundenfunktion benötigt einen 48 Bit Teilschlüssel, deshalb werden die beiden 28 Bit langen Schlüssel durch eine Kompressionspermutation (siehe Tabelle 2.7) auf 48 Bit reduziert. Die Kompressionspermutation hat diesen Namen, weil sie die Bitreihenfolge und die Teilmenge der Bits verändert. Nachdem die Eingabedaten die Eingangspermutation durchlaufen haben, werden sie in zwei Hälften, L und R, der Länge 32 Bit aufgeteilt. Die Rundenfunktion bringt zuerst R i mit Hilfe einer Expansionspermutation von 32 auf 48 Bit Länge. 21

26 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Tabelle 2.5: Schlüsselpermutation von DES Tabelle 2.6: Bits, um die der Schlüssel, beim Verschlüsseln, in der jeweiligen Runde verschoben wird Runde: Anzahl: Tabelle 2.7: Kompressionspermutation von DES

27 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Wie in Tabelle 2.8 zu erkennen ist, kommen einige der Eingabebits doppelt im Ausgabeblock vor. Zum Beispiel die Bits an den Positionen 1, 4, 5, 8,9 12, 13 und so weiter. Tabelle 2.8: Expansionspermutation von DES Danach wird der expandierte Wert mit dem entsprechenden Rundenschlüssel XOR verknüpft. Das Ergebnis wird in acht Blöcke zu je 6 Bit aufgeteilt. Anschließend erfolgt die Substitution in acht Substitutions Boxen (S-Box). Der erste Block wird von S-Box 1 bearbeitet, der zweite Block von S-Box 2 und so weiter. Tabelle 2.9 veranschaulicht die acht S-Boxen, die bei DES eingesetzt werden. Eine besteht aus vier Zeilen mit je 16 Spalten. Jede der S-Boxen erhält 6 Bit an Daten als Eingabe und gibt 4 Bit aus. Sei der zweite Block , so wird dieser auf S-Box 2 angewandt, indem das erste und sechste Bit die Zeile und die mittleren vier Bits die Spalte bestimmen. Für das Beispiel wäre das Zeile 11 (dezimal Zeile 3) und Spalte 0101 (dezimal Spalte 15). Die 4 Bit langen Ausgaben der acht S-Boxen bilden dann einen 32 Bit großen Block, welcher mit einer P-Box (siehe Tabelle 2.10) permutiert wird. Nach dieser Permutation erfolgt letztendlich die bitweise Addition (XOR) mit L i und es beginnt die nächste Runde. Die Verschlüsselung endet nach 16 Runden und der bereits vorher erwähnten, finalen Permutation (FP). Die Entschlüsselung erfolgt genau nach demselben Schema, nur dass die Teilschlüssel in umgekehrter Reihenfolge eingesetzt werden und die Verschiebung der Bits nach rechts nach Tabelle 2.11 erfolgt. Es gibt verschiedene Abwandlungen von DES: DES mit unabhängigen Teilschlüsseln, DESX, Crypt(3), Gerneralized DES, DES mit alternativen S-Boxen, RDES, S m DES, DES mit schlüsselabhängigen S- Boxen, wobei Triple DES (3DES) die Bekannteste ist. Triple DES wurde als Zwischenlösung für DES eingesetzt, weil DES von Experten für nicht mehr als sicher erachtet wurde. Ein Grund ist der nur 56 Bit lange Schlüssel, 3DES verwendet 3 verschiedene Schlüssel, was die effektive Schlüssellänge auf 112 Bit festmacht. Tripel DES ist aufgrund seiner Implementierung drei Mal so langsam, aber um Größenordnungen sicherer. Die Zeit von DES und 3DES scheint abgelaufen. Sie werden in den nächsten Jahren von anderen Algorithmen ersetzt. 23

28 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Tabelle 2.9: Die acht Substitutions Boxen von DES S1: S2: S3: S4: S5: S6: S7: S8:

29 2.1. KRYPTOGRAPHIE KAPITEL 2. GRUNDLAGEN Tabelle 2.10: P-Box Permutation von DES Tabelle 2.11: Bits, um die der Schlüssel, beim Entschlüsseln, in der jeweiligen Runde verschoben wird Runde: Anzahl: Hash Algorithmen Hashwerte werden für die Authentifizierung und zur Sicherung der Datenintegrität eingesetzt. Hashfunktionen errechnen aus Eingaben beliebiger Länge eine Prüfsumme fester Länge, welche als Hashwert bezeichnet wird (Buc99, S. 165). Bedingungen für eine gute Hashfunktion sind (Wik05a): 1. Datenreduktion: Speicherbedarf eines Hashwertes soll deutlich kleiner sein als die der Quelle 2. Zufälligkeit: ähnliche Quellen sollen grundverschiedene Hashwerte hervorbringen 3. Eindeutigkeit: mehrmaliges Berechnen des Hashwertes einer Quelle muss genau dasselbe Ergebnis liefern 4. Effizienz: die Funktion muss schnell berechenbar sein, ohne großen Speicherverbrauch auskommen und sollte die Quelle möglichst nur einmal lesen müssen Besonders wichtig für kryptographische Hash-Funktionen: 5. Kollisionsfreiheit: es darf nicht zwei Quellelemente mit demselben Hash-Wert geben 6. Unumkehrbarkeit: es darf keine effizient berechenbare, inverse Funktion geben, um für ein gegebenen Hash-Wert ein passende Quelle zu finden Sehr bekannt ist MD5, welches einen 128 Bit langen Hashwert erzeugt. Heutzutage ist MD5, wie seine Vorgänger MD2 und MD4, nicht unumstritten. Aus sicherheitsrelevanten Gründen sollte MD5 daher nicht mehr eingesetzt werden. Es wird auch davon abgeraten SHA-1 einzusetzen, weil der Algorithmus als nahezu gebrochen gilt (onl05a). Empfohlen wird der Einsatz von SHA-256 oder RIPEMD- 160 (RW05). SHA, kurz für Secure Hash Algorithm, ist, genau wie MD5, ein Hashalgorithmus und erzeugt einen 160Bit Hashwert (SHA-0 und SHA-1) hat die NIST 8, SHA-256, SHA-384 und SHA-512 publiziert. Die Länge der angefügten Zahl gibt Auskunft über die Länge des Hashwertes in Bit. SHA-384 und SHA-512 haben außerdem noch den Vorteil, Dateien bis zu einer Größe von Bit verarbeiten zu können. Im Februar 2004 wurde SHA-224 veröffentlicht. 8 National Institute of Standards and Technology der USA 25

30 2.2. DAS OPENSSL PROJEKT KAPITEL 2. GRUNDLAGEN 2.2 Das OpenSSL Projekt Das OpenSSL Projekt vereint die Implementierungen verschiedener kryptographischer Algorithmen, eines ASN.1 Parsers, Funktionen zur Verwendung von Zertifikaten, SSL (Secure Sockets Layer v2/v3) und TLS (Transport Layer Security) in einer Software. Zu finden ist es unter org/. Es basiert auf der SSLeay Bibliothek, von Eric A. Young und Tim Hudson und wird heute von einer Vielzahl von Freiwilligen weiterentwickelt. OpenSSL steht unter einer Apache ähnlichen Lizenz und ist privat sowie kommerziell frei einsetzbar. Die drei großen Hauptbestandteile von OpenSSL sind die Kryptobibliothek(libcrypto), die Bibliothek für SSL/TLS(libssl) und das openssl Kommandozeilen Programm. libcrypto libcrypto beinhaltet die Unterstützung für Symmetrische Algorithmen (Blowfish, CAST, DES, IDEA, RC2, RC4, RC5), Public Key Verfahren (DSA, RSA), Verfahren zur Schlüsselerzeugung, verschiedenste Hashfunktionen (MD2, MD4, MD5, MDC2, RIPEMD, SHA und SHA-1), Verfahren zur Authentifizierung mittels Hashwerten (HMAC), für die Verwendung von Zertifikaten (X509, X509v3) und einen ASN.1 Parser. Des weiteren bietet dieses Modul noch viele hilfreiche Funktionen für den Programmierer. Dazu gehört zum Beispiel das BIO Ein/Ausgabe System, eine einfache, nichtblockierende IO (Input Output) Abstraktion, oder auch die EVP API, welche einen Zugriff auf die unterstützten kryptographischen Funktionen (Public Key Kryptographie, digitale Signaturen, Hash- und Kryptographischealgorithmen) von OpenSSL auf höherer Ebene zulässt (High-level Interface). libssl Diese Bibliothek unterstützt SSL in Version 2.0 und 3.0 und TLS in Version 1. TLS ist die Weiterentwicklung von SSL 3.0. Es handelt sich um ein Netzwerkprotokoll zur verschlüsselten Datenübertragung. Eine der wohl bekanntesten Anwendung von SSL/TLS ist das HTTPS Protokoll, welches eine gesicherte HTTP Verbindung über SSL/TLS zwischen Rechnern ermöglicht. OpenSSL bietet dem Programmierer mit diesem Modul ein mächtiges Werkzeug um eigene SSL/TLS Anwendungen zu schreiben. openssl Das openssl Programm ermöglicht die Benutzung der in den Bibliotheken ssl und crypto implementierten, kryptographischen Algorithmen und Verfahren. Das openssl Kommandozeilenprogramm lässt sich auf zwei unterschiedliche Arten bedienen: einerseits in einem interaktiven Modus, wobei über eine Art Eingabeaufforderung Befehle eingegeben werden können (zum Verlassen muss q, quit oder exit eingegeben werden), andererseits in einem Batchmodus, welcher die Übergabe aller nötigen Para- 26

31 2.3. PARALLELISIERUNG KAPITEL 2. GRUNDLAGEN meter beim Aufruf von openssl erfordert. Das Programm läuft ohne weitere Interaktion bis zum Ende durch. Zum Umfang des Programms gehören unter anderem: Erzeugung von RSA, DH und DSA Schlüsseln Ausstellen von X.509 Zertifikaten, Erzeugen von Certificate Revocation Lists (CRL) und das Bearbeiten von Certificate Signing Request (CSR) Hashwertberechnung und -überprüfung, sowie das Signieren mittels Hashwerten Ver- und Entschlüsselung mit kryptographischen Funktionen ein SSL/TLS Client und ein Test Server Verarbeitung von S/MIME signierten oder verschlüsselten s Engine Modul Unterstützung Die Möglichkeit, eigene Engine Module für OpenSSL zu schreiben, war erstmals mit Veröffentlichung von Version möglich. Erst mit Version floss die Unterstützung für Engine Module mit in den Hauptzweig von OpenSSL mit ein. Vorher gab es ein separates Paket, nämlich openssl-engine- $VERSIONS NUMMER.tar.gz. Der Hauptgedanke dabei ist die Unterstützung von kryptographischen Geräten, um Schnittstellen zur Berechnung in Hardware ansprechen zu können. Aber auch die Möglichkeit zu schaffen, kryptographische Algorithmen, die nicht von OpenSSL unterstützen werden, nutzen zu können. Auch das Ersetzen vorhandener Implementierungen durch eine eigene Engine ist möglich. Anwender und Programmierer haben die Wahl Engine Module statisch oder dynamisch mit OpenSSL einzusetzen. Damit eine bestimmte Engine verwendet werden kann, muss entweder OpenSSL neu übersetzt (statisch) oder das Engine Modul als dynamische Bibliothek genutzt werden. Dynamische Engine Module liegen als Dynamic Shared Object Datei vor. Auf Windows Betriebssystemen haben diese üblicherweise die Endung.dll und auf UNIX-Derivaten lib*.so. OpenSSL bietet von Haus aus eigene Engine Module für verschiedene Kryptohardware an. Die Einsatzbereiche von Engine Modulen bieten ungeahnte Möglichkeiten. Engine Module sind für jede Art von Kryptohardware denkbar, solange die Hardware die benötigten Schnittstellen anbietet. 2.3 Parallelisierung Dieser Abschnitt soll einen kleinen Einblick geben, was sich hinter dem Begriff Parallelisierung verbirgt. Bei der Parallelisierung wird ein Vorgang in mehrere kleinere Teilaufgaben untergliedert. Diese können unabhängig voneinander, gleichzeitig berechnet werden. Teilaufgaben werden immer durch Prozesse, Threads oder durch verteiltes Rechnen gelöst. Verteiltes Rechnen (engl. Distributed Computing) ist eine Technik der Anwendungsprogrammierung, bei der die einzelnen Prozesse 27

32 2.3. PARALLELISIERUNG KAPITEL 2. GRUNDLAGEN einer verteilten Anwendung ein gemeinsames Ergebnis berechnen. (Wik05c) Viele Rechnersysteme sind zeitweise nicht ausgelastet, zum Beispiel nachts, oder Anwendung benötigen nur einen Teil der vorhanden CPU Leistung. Diese ungenutzten Ressourcen können für verteiltes Rechen eingesetzt werden. Einer der bekanntesten Vertreter ist Die Abkürzung steht für Search for extraterrestrial intelligence at home, und lautet übersetzt etwa Suche nach außerirdischer Intelligenz zu Hause. Wie auch bei anderen Vertretern von Distributed Computing Projekten braucht der Anwender eine Software, welche die Daten empfängt, die Durchführung der Berechnung veranlasst und das Zurücksenden der Ergebnisse erledigt. wurde im Juni 2004 auf eine neue Softwareplattform, namens BOINC, umgestellt. Berkeley Open Infrastructure for Network Computing, kurz für BOINC, ist eine Softwareplattform für verteiltes Rechnen. Anwender haben damit die Möglichkeit ihre freien Rechenkapazitäten verschiedensten Projekten über nur einen Client zu Verfügung zu stellen. Nähere Information sind auf der offiziellen Homepage zu finden. Um ein Programm zu parallelisieren ist eine Anpassung des Programms an die wirklich verfügbaren Prozessoren nötig. Dieser Vorgang wird Skalieren genannt. Ziele der Parallelisierung sind: alle verfügbaren Prozessoren über die gesamte Zeitdauer auszulasten Aufwand für Kommunikation und Synchronisation so gering wie möglich zu halten Aufwand für Bereitstellung der Daten für bzw. von den Prozessoren zu minimieren Es wird zwischen funktioneller Parallelität und Datenparallelität unterschieden. Funktionelle Parallelität Die Idee dieses Konzeptes ist es, einen Algorithmus in funktionell unterschiedliche, parallel berechenbare Teile zu untergliedern....die Anzahl funktionell unterschiedlicher parallel ausführbarer Abschnitte eines Programms hängt in der Regel von der Aufgabenklasse ab, nicht aber vom Umfang der dabei zu verarbeitenden Daten. (Bur93, S. 113) Datenparalellität Werden gleiche Berechnungen auf unterschiedliche, voneinander unabhängige Daten ausgeführt, kann man diese aufteilen und parallel berechnen lassen. Die in einem Algorithmus enthaltenen Abhängigkeiten sind entscheidend, ob sich eine Aufgabe in parallel zu verarbeitende Teilaufgaben zerlegen lässt oder nicht Prozesse und Threads Die Ausführung von Threads, aber auch von Prozessen, ist nur dann wirklich parallel, wenn Möglichkeiten zur parallelen Verarbeitung durch Hardware bereitgestellt werden, zum Beispiel mehrere Pro- 28

33 2.3. PARALLELISIERUNG KAPITEL 2. GRUNDLAGEN zessoren. Nichtparallele Vorgänge laufen sonst nebenläufig ab, das heisst der Scheduler des Betriebssystems ist für die Vergabe von Rechenzeit der Prozesse verantwortlich (Bur93, S. 98). Mit der Absicht, Parallelität nicht nur innerhalb des Betriebssystems, sondern auch innerhalb eines Programms zur erreichen, bietet es sich an Threads zu verwenden. Was genau unterscheidet Threads nun eigentlich von Prozessen? Ein Prozess, welcher auch gerne als Task oder Job bezeichnet wird, ist ein Programm was gerade ausgeführt wird. Bild 2.7 zeigt schematisch den Aufbau eines Prozessekontextes. Abbildung 2.7: Prozeß-Modell (Mag96) Ein Prozeß besteht aus den folgenden Komponenten: ausführbarer Code (Kopie des Programms im Hauptspeicher) statischer Speicher, dieser enthält: alle Variablen der Speicherklassen static, extern und alle globalen Variablen den Heap und alle dynamisch erzeugten Objekte Stack, dieser enthält: alle dynamischen Variablen und alle lokal deklarierten Variablen die an eine Funktion übergebenen Argumente die Zwischenergebnisse von Berechnungen Registersatz, dieser enthält: allgemein verwendbare Register den Programmzeiger (program counter), welcher auf die nächste, ausführbare Instruktion im Programm verweist 29

34 2.3. PARALLELISIERUNG KAPITEL 2. GRUNDLAGEN den Stackzeiger (stack pointer), der die Grenze des belegten Stack-Bereichs angibt Threads werden auch als Light Weight Processes (LWP) bezeichnet und sind ausführende Instanzen innerhalb eines Prozesses. Das Wort Thread kommt aus dem Englischem und bedeutet soviel wie Faden. Threads können, im Gegensatz zu Prozessen, Ressourcen gemeinsam nutzten. Abbildung 2.8: Prozeß-Modell unter Verwendung von Threds (Mag96) Der Verwaltungsaufwand von Threads ist geringer als der für Prozesse, wenn das Betriebssystem Threads unterstützt. Beim Threadwechsel ist kein vollständiger Austausch des Prozesskontextes notwendig, da Threads eines Prozesses den gleichen Adressraum verwenden. Ebenso entfällt aufwändige Interprozess-Kommunikation. Durch diese Vorteile kann eine bessere Performance erreicht werden, als wenn gleiche Aufgaben durch mehrere Prozesse erledigt werden müssten. Auf Multiprozessorsystemen können Threads für eine bessere Auslastung sorgen, indem sich Threads eines Prozesses auf verschiedene CPUs verteilen. Threads haben neben all diesen Vorteilen auch Nachteile. Dazu gehört das synchronisieren von Threads, was sehr komplex ist. Bei den meisten Betriebssystemen kann ein Thread folgende Zustände annehmen: rechnend (engl. running) - Thread führt Befehle auf der CPU aus rechenbereit (engl. ready) - Thread ist gestoppt blockiert (engl. waiting) - Thread wartet auf ein Ereignis 30

35 Kapitel 3 Realisierung Nachdem die theoretischen Grundlagen geschaffen wurden, bestand der nächste Schritte darin, Möglichkeiten zur Parallelisierung von kryptographischen Vorgängen zu finden. Dabei wurde festgestellt, dass bei keinem der kryptographischen Vorgänge das Konzept von funktioneller Parallelität umsetzbar ist. Bei Blockalgorithmen, im ECB Betrieb, ist eine Parallelisierung über Datenparallelität realisierbar. Da zur parallelen Bearbeitung, voneinander unabhängige Daten benötigt werden, ist der ECB Modus der einzig brauchbare Modus für die Parallelisierung. Bruce Schneier erwähnt in seinem Buch, Angewandet Kryptographie auf Seite 248, ein Verfahren, welches als Verschränkung bezeichnet wird. Dieses Verfahren soll die parallel Verarbeitung im CBC, CFB und OFB Modus ermöglichen. Das die Beschreibung sehr oberflächlich ist und keine weiterführende Literatur zu finden war, wurde beschlossen einen Blockalgorithmus zu parallelisieren. Erst später wurde herausgefunden, dass RSA, zumindest theoretisch, Chancen zur parallelen Verarbeitung bietet. 3.1 Erwartungen an die Software Nach Übereinkunft mit Prof. Dr. Heuert sollte die fertige Software auf GNU/Linux Systemen sowie auf Windows Betriebssystemen der Firma Microsoft lauffähig sein. Die Verwendung von OpenSSL ist Bestandteil der Aufgabenstellung dieser Diplomarbeit. Ziel war es nun, ein Engine Modul für OpenS- SL zu programmieren, welches die parallele Ver- und Entschlüsselung ermöglicht. Da wie schon in Abschnitt 3. erwähnt, ein Algorithmus, welcher den ECB Betriebsmodus unterstützt, für die Parallelisierung notwendig ist, fiel die Wahl auf DES. DES ist ein sehr bekannter Algorithmus, der in vielen Anwendungen zum Einsatz kommt, auch wenn er heute nicht mehr unumstritten ist. Die Auswahl eines geeigneten kryptographischen Algorithmus unterlag keinen bestimmten Voraussetzungen außer der Unterstützung des ECB Modus. 31

36 3.2. VERWENDETES SOFTWAREENTWICKLUNGSMODELL KAPITEL 3. REALISIERUNG 3.2 Verwendetes Softwareentwicklungsmodell Es gibt mehrere Ansätze bei der Entwicklung von Softwarelösungen und der damit verbundenen Qualitätssicherung, wie die Gestaltung des Entwicklungsprozess abzulaufen hat. Mit steigender Komplexität der Projekte nimmt auch die Fehlerwahrscheinlichkeit zu. Mit der Absicht, Fehler zu vermeiden beziehungsweise früher zu erkennen, wird der Entwicklungsprozess in kleine übersichtliche Teile aufgegliedert. Eine iterative Herangehensweise hat sich dabei bewährt. Das Spiralmodell von Barry Boehm eignet sich hierfür sehr gut. Es ist eine Erweiterung des Wasserfallmodells zu einem iterativen Prozess. Somit ist es für eine schnelle Entwicklung inkrementeller Softwareversionen bestens geeignet. Die Software wird durch schrittweise Entwicklung zu einzelnen Versionen fertig gestellt. Das Spiralmodell gliedert sich in vier Entwicklungsphasen, welche einen Zyklus durchlaufen. Jede Runde führt zu einer immer besseren Version der Software(VH03, S.28). Dazu gehören: 1. Quadrant: Zielsetzung und Finden von Alternativen 2. Quadrant: Risikoanalyse 3. Quadrant: Realisierung und Tests 4. Quadrant: Planung des nächsten Umlaufs Das inkrementelle Vorgehen ermöglicht mehr Flexibilität durch das Einbringen neuer Erkenntnisse und Erfahrungen in Nachfolgeversionen. Zudem können einzelne Bausteine leichter auf ihre Funktionsweise getestet werden. Das Spiralmodell ermöglichte schnell einen Engine-Modul-Prototypen zu entwickeln. In kleinen Schritten sollte anschließend die Funktionalität stetig erweitert werden. Während der Benutzung und Tests der Prototypen können auftretende Probleme festgehalten und in Nachfolgeversionen beseitigt werden. Zur Lösung der Aufgabenstellung waren mehrere Umläufe nötig: 1. Dummy Engine Modul 2. Engine Modul, welches DES im ECB Modus rechnet 3. Auslagerung der DES Berechnungsaufrufe in eine externe Funktion 4. Verwendung von Threads und Konvertierung der ausgelagerten Funktion zur Threadfunktion 5. Implementierung der für OpenSSL benötigten Callback Funktion in multithreaded Applikationen 6. Einsatz eines Threadpools zur Performancesteigerung 7. Verbesserung der Performance und der Bedienbarkeit 32

37 3.2. VERWENDETES SOFTWAREENTWICKLUNGSMODELL KAPITEL 3. REALISIERUNG Abbildung 3.1: Spiralmodell (Wik05b) 33

38 3.3. WAHL DER PROGRAMMIERSPRACHE KAPITEL 3. REALISIERUNG 3.3 Wahl der Programmiersprache Da die Realisierung als Modul für OpenSSL vorgesehen war, fiel die Wahl der Sprache leicht. OpenS- SL ist überwiegend in C geschrieben und nur geringe Teile davon in Assembler. So wurde C gewählt, eine Highlevel Programmiersprache. Um Software, die auf verschiedensten Rechnerplattformen lauffähig sein soll, zu entwickeln, sollten Funktionen des jeweiligen Betriebssystems nicht direkt benutzt werden. Das war bei der Verwendung von Threads nicht möglich. Für Unix-Derivate, die sich an den POSIX Standard halten, wozu GNU/Linux und Solaris gehören, bot sich die Verwendung von PO- SIX Threads (kurz pthreads) an. Mit der Verwendung von pthreads sind also alle POSIX 1 konformen UNIX-Derivate abgedeckt. Das POSIX Subsystem war Bestandteil älterer Versionen von Windows. Bei neueren Versionen wurde es durch Windows Services for UNIX ersetzt. Aber der Standard für Threads (IEEE Std c-1995) war nie Bestandteil der POSIX Implementierung unter Windows, deswegen wurden unter Windows Funktionen der systemeigenen C Run Time Library genutzt. Die verwendete Threadpool Implementierung dagegen ist in C++ geschrieben und nutzt die Win32 Threads API. 3.4 Entwicklungsumgebung Bei der Entwicklung kamen hauptsächlich zwei verschiedene Rechner zum Einsatz. Beide Computer basieren auf der x86-architektur. Beim GNU/Linux System kam ein AMD Athlon XP2000+ ( MHz) mit 1024MB RAM Arbeitsspeicher zum Einsatz. Der Windows Rechner läuft mit einem Intel Pentium III (700MHz) mit 512MB RAM Arbeitsspeicher. So konnte, nahezu parallel, auf beiden Systemen entwickelt und getestet werden. Die später umgesetzte Threadpool Idee wurde hingegen komplett auf einem Intel Pentium D Rechner (Dual-Core) der Hochschule Merseburg im Rechnernetz-Labor umgesetzt. Das Dual-Core System ist mit 2.8 GHz getaktet und ist mit 2GB Arbeitspeicher ausgestattet. Die nachfolgende Tabelle zeigt die bei der Entwicklung eingesetzte Software, inklusive der Betriebssysteme, der einzelnen Rechnersysteme. 3.5 Implementierung Am Anfang galt es sich mit OpenSSL vertraut zu machen. Die Verzeichnisstruktur des OpenSSL Quellarchives ist klar strukturiert. Einzig der Code selbst beanspruchte einige Zeit zum Einlesen. Dieser enthält viele Makros und Anweisungen zur bedingten Kompilierung. Das machte das Ganze an vielen Stellen unübersichtlich, da immer erst die benötigten Header Dateien gesucht werden mussten. Es war zuerst angedacht OpenSSL soweit zu verändern, dass der eigene Code dynamisch zur Laufzeit nachgeladen werden kann. Dieses sollte durch Umbiegen von Funktionszeigern erreicht werden. 1 POSIX (Portable Operating System Interface for UniX) ist ein gemeinsam von der IEEE und der Open Group für Unix entwickeltes standardisiertes Applikationsebeneninterface 34

39 3.5. IMPLEMENTIERUNG KAPITEL 3. REALISIERUNG Tabelle 3.1: Betriebssysteme und verwendete Software bei der Entwicklung GNU Linux System Windows System I Windows System II Betriebssystem Linux Windows XP SP2 Windows 2003 Server Compiler GNU Compiler Collection (GCC) MVSC Debugger GNU Debugger (GDB) 6.3 Teil von Visual Studio.NET 2003 MVSC Teil von Visual Studio.NET 2003 OpenSSL 0.9.8a 0.9.7i 0.9.7i OpenSSL verwendet intern EVP, um zur Laufzeit durch Funktionszeiger die benötigten Algorithmen zu laden. An dieser Stelle sollten die Funktionszeiger dann nicht auf die OpenSSL internen Routinen, sondern auf die im zu entwickelten Modul zeigen. Seit Version sind die Rückgabewerte der Funktion, welche den Funktionszeiger setzen, mit dem Schlüsselwort const versehen, was das es die Implementation ohne große Änderungen am Sourcecode unmöglich machte. Trotzdem wurde dieser Weg eingeschlagen, der zunächst auch viel versprechend schien. Gleichzeitig wurde aber eine andere Alternative gesucht, die gänzlich ohne Änderungen an OpenSSL selber funktionieren sollte. Bei Tests kam es immer wieder zu fehlerhaften Ergebnissen. Ohne tiefere Eingriffe in OpenSSL und einen erhöhten Mehraufwand in die Einarbeitung der komplexen internen Vorgänge in OpenS- SL wäre die Idee des Umbiegens der Funktionszeiger nicht schaffbar. Die Suche nach einer anderen Möglichkeit, die Funktionalität von OpenSSL durch ein eigenes Modul zu erweitern, fand ein Ende mit der Verwendung eines Engine Moduls. Diese Vorgehensweise hatte außerdem den Vorteil, die volle Funktionalität des openssl Kommandozeilenprogramms nutzen zu können. Bei der ersteren Variante wäre das nur durch zusätzliche Eingriffe oder eine eigene Anwendung realisierbar gewesen. Da die Möglichkeit, Engine Module zu schreiben, noch ziemlich neu ist, ist eine brauchbare Dokumentation eher Mangelware. Daher musste sich durch den vorhandenen Quellencode gekämpft werden, um anhand eines Beispiels die Funktionsweise zu verstehen. Das OpenSSL Projekt gibt das auch offen zu und sucht nach Freiwilligen, die eine Dokumentation schreiben würden. Nachfolgend soll kurz auf die entstandenen Prototypen aus den einzelnen Durchlaufzyklen des Spiralmodells, wie schon in Abschnitt 3.2 erwähnt, eingegangen werden. Prototyp 1: Dummy Engine Modul Das Ziel dieser Runde war, openssl dazu zu bringen das Modul als Engine korrekt zu laden. Dazu gehörte es auch Erfahrungen zu sammeln, um das Engine Modul für openssl zugänglich zu machen. Vorraussetzung dafür ist die Installation des Moduls, welche ausführlich in Kapitel 3.6 beschrieben wird. Damit die Engine auch als solche dynamisch geladen werden kann, sind folgende zwei Aufruf unbedingt notwendig: IMPLEMENT DYNAMIC CHECK FN() 35

40 3.5. IMPLEMENTIERUNG KAPITEL 3. REALISIERUNG IMPLEMENT DYNAMIC BIND FN(fn) Wobei der Parameter fn eine Funktion ist, welche die ENGINE initialisiert. Es werden verschiedene Aufrufe in dieser Funktion getätigt, zu den wichtigsten gehören: int ENGINE set init function(engine *e, ENGINE GEN INT FUNC PTR init f); - setzt die Engine eigene Initialisierungsfunktion int ENGINE set id(engine *e, const char *id); - setzt die Engine ID int ENGINE set name(engine *e, const char *name); - setzt den Namen der Engine int ENGINE set ciphers(engine *e, ENGINE CIPHERS PTR f); - registriert die durch die Engine implementierten Symmetrischen Verschlüsselungsverfahren In dieser Funktion werden auch die noch weiter unten beschriebenen Callback Funktionen gesetzt. Prototyp 2: Engine Modul, welches DES im ECB Modus rechnet In diesem Durchlauf wurde die vorherige Dummy-Engine erweitert, so dass es nun möglich war DES zu rechnen. Dazu wurde die für jeden symmetrischen Algorithmus notwendige EVP CIPHER Struktur definiert. In dieser Struktur werden die verschiedenen Merkmale eines Algorithmus bestimmt: Blockgröße, Schlüssellänge, Größe des Initialisierungsvektors und so weiter. Der folgende Codeausschnitt zeigt die bei der Programmierung verwendete EVP CIPHER Struktur für DES im ECB Modus: static const EVP_CIPHER des_ecb = { NID_des_ecb, 8, /* block_size */ 8, /* key_len */ 8, /* iv_len */ FLAGS EVP_CIPH_ECB_MODE, /* Various flags */ init_key, /* init key */ des_ecb_cipher, /* encrypt/decrypt data */ NULL, /* cleanup ctx */ sizeof(des_key_schedule), /* how big ctx->cipher_data needs to be */ EVP_CIPHER_set_asn1_iv, /* Populate a ASN1_TYPE with parameters */ EVP_CIPHER_get_asn1_iv, /* Get parameters from a ASN1_TYPE */ CTRL, /* Miscellaneous operations */ NULL /* Application data */ }; 36

41 3.5. IMPLEMENTIERUNG KAPITEL 3. REALISIERUNG Die zwei wichtigsten Elemente der Struktur sind Funktionzeiger auf die Funktionen, welche für die Behandlung der Daten ( do cipher ) und für die Schlüsselinitialisierung ( init key ) verantwortlich sind. Beim Ver- oder Entschlüsseln von Daten erzeugt openssl standardmäßig 4096 Bit große Ein- und Ausgabebuffer. Die do cipher Funktion kriegt beim Aufruf unter anderem Zeiger auf diese Buffer übergeben. Es werden dann jeweils acht Bit der Daten aus dem Eingabepuffer ver- oder entschlüsselt und in den Ausgabebuffer geschrieben. Das geschieht durch den Aufruf von void DES ecb encrypt(const DES cblock *input, DES cblock *output, DES key schedule *ks, int enc);. Diese Funktion ist in der OpenSSL crypto Bibliothek definiert. Der Vorgang wird in einer Schleife solange wiederholt, bis alle Eingabedaten verarbeitet wurden. for(i=0; i<=inl; i+=bl) { DES_ecb_encrypt((DES_cblock *)(in + i), (DES_cblock *)(out + i), ctx->cipher_data, ctx->encrypt); } Solange die gesamten Eingabedaten nicht verarbeitet wurden, erzeugt das openssl Programm neue Buffer und ruft danach do cipher auf. Prototyp 3: Auslagerung der DES Berechnungsaufrufe in eine externe Funktion Hier wurden die für die Parallelisierung vorgesehenen Programmteile in einer Funktion ausgelagert. Dabei wurden Möglichkeiten zur Parameterübergabe an diese Funktion geschaffen. Die kryptographischen Vorgänge finden hier nun in der ausgelagerten Funktion statt, die Abarbeitung erfolgt wie schon oben bei Prototyp 2 beschrieben. Prototyp 4: Verwendung von Threads und Konvertierung der ausgelagerten Funktion zur Threadfunktion Die im vorigem Schritt ausgelagerte Funktion wurde zur Threadfunktion umfunktioniert. Es handelt sich um die Funktion, die ein Thread nach seiner Erzeugung ausführt. In der do cipher Funktion wird nun eine vorher festgelegte Anzahl an Threads generiert. Die Ver- beziehungsweise Entschlüsselungsvorgänge finden jetzt in den einzelnen Threads statt. Die Abarbeitung der Buffer beginnt bei Position null und wird nach jedem Aufruf von DES ecb encrypt um acht erhöht. Über einen Mutex wird die Variable, welche die aktuelle Position enthält, geschützt. So ist garantiert, dass nur ein Thread ab der aktuellen Position acht Bit exklusiv berechnet. Am Ende der do cipher Funktion wird auf die Beendigung der Threads gewartet. Dadurch wird sichergestellt, dass alle Threads vor einem eventuell nächsten Durchlauf fertig sind, weil ansonsten die Buffer mit neuen Daten überschrieben werden könnten. 37

42 3.5. IMPLEMENTIERUNG KAPITEL 3. REALISIERUNG Prototyp 5: Implementierung der f ür OpenSSL benötigten Callback Funktion in multithreaded Applikationen: Wenn OpenSSL unter Verwendung von Threads, also Multi-threaded eingesetzt wird, benötigt es bestimmte Callback-Funktionen, die je nach Betriebssystem und betriebssystem interner Threadimplementierung verschieden sind. Unter Windows wurde nur die locking Funktion benötigt. Diese Funktion ist für das Setzen und Auflösen von Mutexen innerhalb von OpenSSL verantwortlich. Bei Verwendung von POSIX Threads musste zusätzlich noch eine id Funktion programmiert werden, da das Betriebssystem keine eindeutige Prozessidentifikationsnummer für die einzelnen Threads zurückgibt. Beim Programmieren der Callback Funktion wurde sich weitestgehend an die OpenSSL Vorgaben aus crypto/threads/mttest.c gehalten. Unter Verwendung von pthread self() war es nun möglich, durch einen id Funktionsaufruf, eine eindeutige Prozess-ID für jeden einzelnen Thread zu bekommen. Die nachfolgende Liste zeigt die von OpenSSL durch Mutexe gesperrten Ressourcen und auch die Tiefe der Sperren bei der Verschlüsselung einer 151Kb großen Eingabedatei mit dem des-ecb Modul unter Linux. 0:<<ERROR>> 15:err 12:ex_data 0:x509 0:x509_info 0:x509_pkey 0:x509_crl 0:x509_req 0:dsa 0:rsa 0:evp_pkey 0:x509_store 0:ssl_ctx 0:ssl_cert 0:ssl_session 0:ssl_sess_cert 0:ssl 0:ssl_method 2:rand 57:rand2 8:debug_malloc 3:BIO 0:gethostbyname 38

43 3.5. IMPLEMENTIERUNG KAPITEL 3. REALISIERUNG 0:getservbyname 0:readdir 0:RSA_blinding 0:dh 2:debug_malloc2 0:dso 0:dynlock 5:engine 0:ui 0:hwcrhk 0:fips 0:fips2 Prototyp 6: Einsatz eines Threadpools zur Performancesteigerung Wie später im Kapitel Tests und Ergebnisse (4.) zusehen ist, brachte die bisherige Threadimplementierung keinerlei Performancegewinn, was sich nur durch den sehr hohen Overhead beim Handling der Threads erklären lässt. Es wurde nun eine Möglichkeit gesucht, Threads einmalig zu erzeugen und dann immer wieder mit neuen Daten für die Bearbeitung zu versorgen. Die vor hergenannten Bedingungen würden durch die Verwendung eins Threadpools erfüllt. Es wird eine bestimmte Anzahl an Threads angelegt (Threadpool), die solange blockieren, bis der Threadpool mit Jobs gefüllt wird. Die zubearbeitende Aufgabe wird in Jobs unterteilt, welche dann bis zur Bearbeitung zwischengespeichert werden mussten. Wenn ein Job erzeugt wird, wird den blockierten Threads ein Signal gesendet und sie beginnen damit vorhandene Jobs zu bearbeiten. Die Threads arbeiten so lange, bis alle Jobs abgearbeitet sind. Es wurde beschlossen auf eine vorhandene Threadpool-Implementierung zurückzugreifen, um eine möglichst schnelle Umsetzung zu realisieren. Ebenso wurde festgelegt diese Implementation nur auf Windows lauffähig zu machen. Die dann verwendete Umsetzung (Quelle von Thomas George bietet dennoch zusätzlich Unterstützung für die Verwendung von pthreads. Der Autor verweist darauf, dass seine Implementation auf Unix-Derivaten gänzlich ungetestet ist. Bei der Initialisierung der Engine wird der Threadpool mit einer vorher festgelegten Anzahl an Threads erzeugt. In der do cipher Funktion werden dann Jobs erzeugt, welche jeweils acht Bit weiterverarbeiten. Es gibt keine Möglichkeit auf die Beendigung der Abarbeitung aller Jobs zu warten. Jedoch ist dieses unbedingt erforderlich, da sonst die Ein- und Ausgabebuffer des jeweiligen do cipher Aufrufes verloren gehen würden. Als Workaround wird in einer while Schleife mit einem sleep(0) Aufruf geprüft, wie viel Jobs noch vorhanden sind. while (Thread::get_threadpool().get_jobcount() > 0 ) 39

44 3.5. IMPLEMENTIERUNG KAPITEL 3. REALISIERUNG { } #ifdef WIN32 Sleep(0); #else sleep(0); #endif Das Programm verweilt in der Schleife solange die Menge der Jobs größer null ist. Die original Implementation verringert die Anzahl der Jobs schon vor der Berechnung, deswegen mussten einige Klassenmethoden umgeschrieben und hinzugefügt werden, damit die Jobanzahl erst danach verkleinert wird. Prototyp 7: Verbesserung der Performance und der Bedienbarkeit Wie sich bei Tests (siehe 4.) herausstellte, macht es keinen Sinn bei kleinen Buffern zu parallelisieren. Deshalb wurde die Thread- und die Threadpoolimplementierung dahingehend erweitert, dass standardmäßig erst aber einer Blockgröße von mindestens 4096 Bit parallel gerechnet wird. Über das Setzen von Umgebungsvariablen hat der Anwender nun die Möglichkeit die Anzahl der Threads (NR THREADS), die Mindestblockgröße (MIN BLOCK LENGTH), ab der parallelisiert werden soll, und die maximale Anzahl der Jobs (NR JOBS nur beim Threadpool) flexibel zu variieren. Beim Initialisieren der Engine wird geprüft, ob die Umgebungsvariablen gesetzt sind. Ist dies nicht der Fall, werden folglich die Standartwerte verwendet. Bei der Threadumsetzung werden in der do cipher Funktion die Bufferdaten anteilig, auf die Anzahl der Threads, in eigenständige Bereiche geteilt. Durch diese Unterteilung entfällt die Synchronisation über ein Mutex, da nun jeder Thread für seinen Bereich alleine verantwortlich ist. Die Threadpool-Variante offerierte gleich mehrere Ansätze für Performanceverbesserungen. Für die Thread- und Jobverwaltung wurden die STL Klassen dequeue und vector eingesetzt. Alle STL Aufrufe wurden komplett entfernt und durch eine eigene Klasse ersetzt. Diese neue Klasse bildet die Funktion einer verketteten Liste nach. Bei der Standardbuffergröße von 4096 Bit und einer Blockgröße von 8 Bit mussten 512 Jobs erzeugt werden. Um diesen Overhead bei der Joberzeugung entgegenzuwirken, wurde die maximale Anzahl der Jobs auf zwei festgelegt. Ebenso wie bei der Threadimplementation wird jetzt der gesamte Bufferbereich auf die Anzahl der Jobs aufgeteilt. Im nachfolgendem Abschnitt soll auf Besonderheiten im Zusammenhang mit OpenSSL auf Windows Betriebssystemen eingegangen werden. Anders als auf GNU Systemen wird OpenSSL nicht einfach mit dem magischem Dreisatz./configure; make ; make install konfiguriert, übersetzt und installiert. Windows ist von Haus aus ohne installierten Compiler ausgestattet. Zur Auswahl stehen verschiedenste Compiler (MVSC, Borland C, MinGW oder GCC als Teil von Cygwin). Es ist außerdem ratsam 40

45 3.6. INSTALLATION KAPITEL 3. REALISIERUNG einen unterstützten Assembler zu installieren. Dadurch wird ein schnellerer Code erzeugt. Beispielsweise arbeiten RSA Routinen mit Assembler Unterstützung zweimal schneller. Bei der eingesetzten IDE, Microsoft Visual Studio.NET 2003, ist Microsoft s Macro Assembler ( ml ) mit dabei. Weiterhin wird noch ActiveState Perl ( benötigt. Auf GNU Linux Systemen gehört Perl dagegen zum festen Bestandteil des Systems. Wenn alle nötigen Voraussetzungen erfüllt sind und sich an die Anweisungen in der Datei INSTALL.W32 hält, steht nichts im Wege, um OpenSSL erfolgreich unter Windows zu kompilieren. Es gibt keine gute Variante, es zu installieren. Deswegen wurde ein kleines Batch Skript geschrieben ( install openssl win32.bat ßiehe Anhang), das leicht zu konfigurieren ist und OpenSSL nach individuellen Wünschen installiert. Bestimmte Makroaufrufe (DLL EXPORT extern declspec(dllexport)) ermöglichten es erst, die für OpenSSL notwendigen Symbole in der Engine dll zu exportieren. Für die Linuxversion waren keine zusätzlichen Aufrufe notwendig. Ein Test der Engine unter Windows mit Version 0.9.8a von OpenSSL offenbarte einen Programmfehler in OpenSSL. Der Fehler tritt.. Dieser Fehler wurde auf der User- Mailingliste (urlopenssl-usersopenssl.org) von OpenSSL gemeldet, wobei einer der Hauptentwickler den Fehler bestätigte: The automatic dynamic support when an unknown engine is looked up doesn t work yet. Richard is looking into that. (Dr Stephen N. Henson) In der Vorgänger-Version 0.9.7i trat der Fehler nicht auf und deswegen wurde unter Windows mit OpenSSL in der Version 0.9.7i entwickelt und getestet. Das Testen des Engine Moduls verlief folgendermaßen: Von einer beliebigen Testdatei wurde mittels dem Programm openssl und dem Aufruf openssl sha1 inputfile der 160Bit lange SHA1 Hashwert bestimmt. 2 Um die Richtigkeit der Verschlüsselung zu prüfen, wurde die Testdatei unter Einsatz des Engine Moduls verschlüsselt und ohne dieses wieder entschlüsselt. Das Testen der Entschlüsselung verlief genauso ab, nur wurde zuerst ohne Engine Modul verschlüsselt und danach mit dem Engine Modul entschlüsselt. OpenSSL überprüft intern, ob die gleiche Anzahl gelesener Bits auch erfolgreich verschlüsselt beziehungsweise entschlüsselt wurden. Wäre dies nicht der Fall, hätte openssl eine Fehlerausgabe produziert. Aber nur wenn der Hashwert der entschlüsselten Ausgabedatei mit dem der Testdatei übereinstimmte, war die fehlerlose Funktion des Engine Moduls garantiert. 3.6 Installation Das im Rahmen der Diplomarbeit erstellte Engine Modul ist mit den OpenSSL Versionen und lauffähig. Ältere Version wurden nicht getestet. Mit dem vorliegenden Engine Modul kann DES 2 SHA1 siehe Abschnitt (Hashalgorithmen) 41

46 3.6. INSTALLATION KAPITEL 3. REALISIERUNG im ECB Modus zur parallelen Ver- und Entschlüsslung verwendet werden. Es sollten die Anmerkungen zur Version unter Windows Betriebssystemen aus dem Abschnitt Erfahrungen bei der Programmierung beachtet werden. Je nach Zielplattform wird das Engine Modul, wie nachfolgend beschrieben, kompiliert. Für GNU Linux System werden GCC, OpenSSL (inklusive Entwicklungsdateien) und make benötigt. Ein make Aufruf sollte die Datei libdes-ecb.so erzeugen. Für Windows liegt eine Visual Studio.NET 2003 Projektdatei (siehe Anlagen) bei. Nach erfolgreichem Compilerund Linker-Durchlauf sollte die Datei des-ecb.dll vorliegen. Es gibt verschiedene Wege, die jeweilige Shared Object Datei für OpenSSL zugänglich zu machen. Auf Unix-Derivaten (GNU/Linux, Solaris) erfordert dieses teilweise Adminstratorrechte (root Rechte). Die einfachste Art, libdes-ecb.so auf Unix ähnlichen System für openssl benutzbar zu machen, ist das Setzen der Umgebungsvariablen LD LIBRARY PATH. Die Variable sollte danach den Pfad zur Bibliothek enthalten. Die Bibliothek kann aber auch in einen anderen Suchpfad für Shared Libraries abgelegt werden, zum Beispiel /usr/lib. Ab Version sucht OpenSSL auch standardmässig im Pfad: INSTALLATIONS PREFIX/lib/engines. Beide Varianten benötigen Administratorrechte, genau wie das Editieren der OpenSSL Konfigurationsdatei openssl.cnf. Die Reihenfolge der Einträge innerhalb der jeweiligen Engine Sektion ist nicht willkürlich. Nachfolgend die mindestens benötigten Einträge um die Engine nutzen zu können: openssl_conf = openssl_init [ openssl_init ] engines = engine_section [ engine_section ] des-ecb = des-ecb_section [des-ecb_section] dynamic_path = /home/kratz00/diplom/coding/libdes-ecb.so engine_id = des-ecb init = 1 Die Konfigurations kann auch unter Windows verwendet werden. Dafür werden eventuell auch Adminstratorrechte benötigt. Die Datei des-ecb.dll wird einfach im gleichen Verzeichnis, indem sich die openssl.exe befindet abgelegt. Es gibt aber auch einen Weg, der gänzlich ohne Adminstratorrechte auskommt. Dabei wird OpenSSL kompiliert und danach direkt aus dem Quellverzeichnis verwendet. 42

47 3.7. PROGRAMMBEDIENUNG KAPITEL 3. REALISIERUNG 3.7 Programmbedienung Wie schon in Abschnitt 2.2 erwähnt, kann OpenSSL auf verschiedene Art benutzt werden. Nachfolgend ein Aufruf für den Betrieb im Batchmode: openssl enc -engine des-ecb -e -des-ecb -in inputfile -out outputfile -k secret openssl - das Programm selbst enc - zur Ver- und Entschlüsselung von Symmetrischen Algorithmen -engine des-ecb - Verwendung einer Engine Implementierung (optional) und Name der Engine -des-ecb - Wahl das Kryptographischen Algorithmus und dessen Betriebsmodus -e - für Verschlüsselung (encrypt) bzw -d für Entschlüsselung (decrypt) -in inputfile - gibt an, welche Datei verschlüsselt werden soll, optional (Default: Standardeingabe) -out outputfile - bestimmt, in welcher Datei das verschlüsselte Ergebnis gespeichert wird, optional Default: Standardausgabe) -k secret - das zu verwendende Passwort, optional, openssl fragt ansonsten in beiden Betriebsmodi nach dem Passwort, sogar zweimal um eine versehentliche falsche Eingabe zu erkennen Derselbe Vorgang, diesmal aber im Interaktivem Modus als User kratz00 auf einem Linux System namens hypnos : kratz00@hypnos: $ openssl OpenSSL> enc -engine des-ecb -e -des-ecb -out testo -in /home/panki/pxlinux tar.gz engine "des-ecb" set. enter des-ecb encryption password: Verifying - enter des-ecb encryption password: OpenSSL> quit kratz00@hypnos: $ Die Konfiguration des Engine Moduls ist über folgende Umgebungsvariablen möglich: NR THREADS - setzt die Anzahl der zu erzeugenden Threads MIN BLOCK LENGTH - bestimmt die Mindestblocklänge ab der Parallelisiert wird NR JOBS - legt die Anzahl der zu verwendeten Jobs fest (nur bei der Threadpoolimplemenation) 43

48 Kapitel 4 Tests und Ergebnisse Zum Testen der Performance wurde das OpenSSL Kommandzeilenprogramm eingesetzt. Es wurden beide Threadimplementierungen auf verschiedenen Rechnern, mit unterschiedlichen Betriebsystemen und Prozessoren getestet. Der Aufruf von openssl speed -evp des-ecb auf einem Unix System ergibt folgende Ausgabe. Doing des-ecb for 3s on 16 size blocks: des-ecb s in 2.96s Doing des-ecb for 3s on 64 size blocks: des-ecb s in 2.89s Doing des-ecb for 3s on 256 size blocks: des-ecb s in 2.85s Doing des-ecb for 3s on 1024 size blocks: des-ecb s in 2.90s Doing des-ecb for 3s on 8192 size blocks: des-ecb s in 2.93s OpenSSL 0.9.7i 14 Oct 2005 built on: Mon Oct 17 17:58:00 CEST 2005 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) compiler: gcc -fpic -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The numbers are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes des-ecb k k k k k Unter Windows ist die Ausgabe leicht anders: To get the most accurate results, try to run this program when this computer is idle. First we calculate the approximate speed... 44

49 KAPITEL 4. TESTS UND ERGEBNISSE Doing des-ecb times on 16 size blocks: des-ecb s in 29.30s Doing des-ecb times on 64 size blocks: des-ecb s in 26.34s Doing des-ecb times on 256 size blocks: des-ecb s in 25.33s Doing des-ecb times on 1024 size blocks: des-ecb s in 25.48s Doing des-ecb times on 8192 size blocks: des-ecb s in 25.47s OpenSSL 0.9.7i 14 Oct 2005 built on: Thu Dec 15 11:13: options:bn(64,32) md2(int) rc4(idx,int) des(idx,cisc,4,long) aes(partial) idea(i nt) blowfish(idx) compiler: cl /MD /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAM E_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM /Fdout32dll -DOPENSSL_NO_KRB5 available timing options: TIMEB HZ=1000 timing function used: ftime The numbers are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes des-ecb k k k k k Die Ausgaben sind deshalb so unterschiedlich, weil die betriebssystemeigenen Funktionen zur Zeitberechnung unterschiedlich sind. Während unter Windows mehrmals, abhängig von der Eingabe- /Ausgabebufferblockgröße, gerechnet wird, wird das auf Unix Systemen jeweils nur eine bestimmte Zeit lang getan. Um jetzt die Engine testen zu können muss der Aufruf noch um -engine des-ecb erweitert werden und sieht dann folgendermaßen aus: openssl speed -evp des-ecb -engine des-ecb Hier an dieser Stelle soll klar gemacht werden, wenn nachfolgend von Blöcken, Blockgröße etc. geschrieben wird, dass es sich nicht um die relevanten Blöcke für die eigentliche Ver- und Entschlüsselung durch DES handelt. Mit diese Begriffen sind die Ein- und Ausgabebuffer die OpenSSL intern bereitstellt gemeint, welche die zu ver- oder entschlüsselten Daten, der Ver- und Entschlüsselungsroutine zuführt. Sofern möglich wurden beide Implementationen auf allen zur Verfügung stehenden Systemen getestet. Die Interpretationen der Ergebnisse für beide Umsetzungen waren, unabhängig vom Testsystem, immer die Selben. Es folgen die Testergebnisse der Threadumsetzung, welche auf einer Sun Fire V440 Workstation (4 CPUs mit je 1.5 GHz) unter Solaris 9 berechnet wurden: Ohne Parallelisierung - Sun Fire V440: Doing des-ecb for 3s on 16 size blocks: des-ecb s in 3.00s Doing des-ecb for 3s on 64 size blocks: des-ecb s in 3.00s Doing des-ecb for 3s on 256 size blocks: des-ecb s in 3.00s Doing des-ecb for 3s on 1024 size blocks: des-ecb s in 2.99s 45

50 KAPITEL 4. TESTS UND ERGEBNISSE Doing des-ecb for 3s on 8192 size blocks: des-ecb s in 2.99s OpenSSL 0.9.8a 11 Oct 2005 built on: Tue Nov 1 19:24:02 MET 2005 options:bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fpic -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -mcpu=ultrasparc -O3 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -DMD5_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The numbers are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes des-ecb k k k k k Threadimplementierung - Sun Fire V440 mit 2 Threads und 16 Bit Mindestblocklänge: Using default Value for NR_THREADS: 2 Using requested Value for MIN_BLOCK_LENGTH: 16 engine "des-ecb" set. Doing des-ecb for 3s on 16 size blocks: des-ecb s in 0.94s Doing des-ecb for 3s on 64 size blocks: des-ecb s in 0.86s Doing des-ecb for 3s on 256 size blocks: des-ecb s in 1.24s Doing des-ecb for 3s on 1024 size blocks: des-ecb s in 1.69s Doing des-ecb for 3s on 8192 size blocks: des-ecb s in 4.46s OpenSSL 0.9.8a 11 Oct 2005 built on: Tue Nov 1 19:24:02 MET 2005 options:bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fpic -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -mcpu=ultrasparc -O3 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -DMD5_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The numbers are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes des-ecb k k k k k Aus den vorhergehenden Ausgaben zu erkennen, dass die Threadimplementation bei keiner der verwendeten Blockgrößen Sinn macht und bei kleinen Blöcken extrem unperformant ist. Es ist sehr gut 46

51 KAPITEL 4. TESTS UND ERGEBNISSE erkennbar, dass sich bei zunehmender Blockgröße, das des-ecb Modul der Standardimplementierung leistungsmäßig nähert. Gerade bei kleinen Blöcken wird von den drei Sekunden nicht mal real eine Sekunden DES gerechnet. Das Ganze lässt sich auf Thread-Overhead zurückführen. Vor allem bei geringen Blockgrößen werden viel öfters Threads erzeugt, als bei großen Blöcken. Das bedeutet, dass der Overhead durch Threads größer ist als der Performancegewinn durch den Einsatz einer zweiten CPU. Wie sich das Modul unter Verwendung von vier Threads verhält, zeigt nachfolgende Ausgabe: Threadimplementierung - Sun Fire V440 mit 4 Threads und 16 Bit Mindestblocklänge: Using requested Value for NR_THREADS: 4 Using requested Value for MIN_BLOCK_LENGTH: 16 engine "des-ecb" set. Doing des-ecb for 3s on 16 size blocks: des-ecb s in 1.05s Doing des-ecb for 3s on 64 size blocks: des-ecb s in 1.07s Doing des-ecb for 3s on 256 size blocks: des-ecb s in 1.31s Doing des-ecb for 3s on 1024 size blocks: des-ecb s in 1.72s Doing des-ecb for 3s on 8192 size blocks: des-ecb s in 6.09s OpenSSL 0.9.8a 11 Oct 2005 built on: Tue Nov 1 19:24:02 MET 2005 options:bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fpic -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -mcpu=ultrasparc -O3 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -DMD5_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The numbers are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes des-ecb k k k k k Leider brachte das auch nicht den gewünschten Leistungsgewinn durch Parallelisierung. Aufgrund des doppelt so großen Threadoverheads ist die gleich Implementation mit vier Threads sogar unperformanter als mit zwei Threads. Deshalb ist schlussfolgernd zu sagen, dass trotz der Fähigkeit, parallel zu rechnen, diese Implementierung keinen erkennbaren Nutzen aufweist. Nachfolgend die Testergebnisse der Threadpoolumsetzung, welcher auf einem Pentum D (Dual-Core mit 2,8 GHz) unter Windows 2003 Server Editon erzielt wurden: Ohne Parallelisierung - Dual-Core System: To get the most accurate results, try to run this program when this computer is idle. 47

52 KAPITEL 4. TESTS UND ERGEBNISSE First we calculate the approximate speed... Doing des-ecb times on 16 size blocks: des-ecb s in 29.30s Doing des-ecb times on 64 size blocks: des-ecb s in 26.34s Doing des-ecb times on 256 size blocks: des-ecb s in 25.33s Doing des-ecb times on 1024 size blocks: des-ecb s in 25.48s Doing des-ecb times on 8192 size blocks: des-ecb s in 25.47s OpenSSL 0.9.7i 14 Oct 2005 built on: Thu Dec 15 11:13: options:bn(64,32) md2(int) rc4(idx,int) des(idx,cisc,4,long) aes(partial) idea(int) blowfish(idx) compiler: cl /MD /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAM E_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM /Fdout32dll -DOPENSSL_NO_KRB5 available timing options: TIMEB HZ=1000 timing function used: ftime The numbers are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes des-ecb k k k k k Threadpoolimplementierung - Dual-Core System mit 2 Threads, 2 Jobs und 16 Bit Mindestblocklänge: Using default Value for NR_THREADS: 2 Using requested Value for MIN_BLOCK_LENGTH: 16 Using default Value for NR_JOBS: 2 engine "des-ecb" set. To get the most accurate results, try to run this program when this computer is idle. First we calculate the approximate speed... Doing des-ecb times on 16 size blocks: des-ecb s in s Doing des-ecb times on 64 size blocks: des-ecb s in s Doing des-ecb times on 256 size blocks: des-ecb s in s Doing des-ecb times on 1024 size blocks: des-ecb s in 49.34s Doing des-ecb times on 8192 size blocks: des-ecb s in 19.34s OpenSSL 0.9.7i 14 Oct 2005 built on: Wed Dec 7 11:19: options:bn(64,32) md2(int) rc4(idx,int) des(idx,cisc,4,long) aes(partial) idea(i nt) blowfish(idx) compiler: cl /MDd /W3 /WX /Zi /Yd /Od /nologo -DOPENSSL_SYSNAME_WIN32 -D_DEBUG 48

53 KAPITEL 4. TESTS UND ERGEBNISSE -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DDEBUG -DDSO_WIN32 -DBN_ASM -DMD5_ASM -DSHA1_A SM -DRMD160_ASM /Fdout32dll -DOPENSSL_NO_KRB5 available timing options: TIMEB HZ=1000 timing function used: ftime The numbers are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes des-ecb k k k k k Ab 8012 Bit, wo wirklich parallel gerechnet wurde, ist ganz klar ein Unterschied zu erkennen. Der gleiche Datendurchsatz wurde in viel kürzerer Zeit als bei der Standardimplementation verarbeitet. Eine Erhöhung der Jobanzahl oder sogar der Threadanzahl auf dieser zwei CPU Maschine verschlechterte das Ergebnis. Die Verschlechterung lässt sich auf den erhöhten Mehraufwand für das Threadund Jobmanagment zurückführen. Da die Parallelisierung erst aber einer Blockgröße über 1024 Bit Erfolge verbucht, wurde beschlossen die Standard-Blockgröße, ab der parallelisiert wird, auf 4096 Bit zu setzen. Diesen Wert verwendet openssl nämlich standardmässig bei Ver- und Entschlüsselungsvorgängen. Bei kleineren Blöcken erfolgt die Berechnung damit sequenziell, ohne jegliche Parallelisierung. Wie schon vorher im Abschnitt Programmbedienung geschildert, kann der Nutzer die Blockgröße aber jederzeit variieren. Die Threadpoolimplementierung konnte, wie vorher schon erwähnt, nur auf Windows getestet werden. Fazit Der Overhead durch Threadoperationen ist bei keiner der Implementation zu vernachlässigen, daher könnte das Engine Modul auf einem Einprozessorsystem theoretisch niemals gleichwertig sein. Diese Behauptung würde durch Tests bestätigt. Abschließend stellt Abbildung 4.1 beide Implementierungen auf den Zwei vorher schon genannten Windows Systemen grafisch dar. Dafür wurde die Zeit, welche für die Bearbeitung der 16 Bit großen Blöcke benötigt wurde normiert. Das Diagramm zeigt ausgehend von 100 Prozent Arbeitsaufwand, für die Berechnung der 16 Bit Blöcke, ob mehr oder weniger Aufwand, für die Berechnung einer gleich großen Datenmenge, bei unterschiedlichen Blockgrößen erforderlich war. 49

54 KAPITEL 4. TESTS UND ERGEBNISSE Abbildung 4.1: Grafische Darstellung der Messergebnisse 50