Das GNU-Handbuch zum Schutze der Privatsph re Copyright ? 2000 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. Richten Sie bitte Ihre Fragen, Fehlermeldungen oder Anregungen, sofern sie dieses Handbuch betreffen, an die Mailingliste . Mike Ashley ist der Autor des orginalen englischen Version dieses Handbuchs, Beitr ge lieferten auch Matthew Copeland, Joergen Grahn und David Wheeler. J. Horacio MG hat das Handbuch ins Spanische bersetzt. Harald Martin, Roland Goretzki und Peter Neuhaus haben das Handbuch ins Deutsche bersetzt. Peter Neuhaus hat das Handbuch berarbeitet und erweitert. ------------------------------------------------------------------------------- Inhaltsverzeichnis Vorwort Warum Kryptographie? Warum GnuPG? Aufbau des Buches 1. Konzepte Symmetrische Verschl sselung Public-Key-Verschl sselung Hybride Verschl sselungsverfahren Digitale Unterschriften 2. Grundlagen Erzeugen eines neuen Schl sselpaares Erzeugen einer Widerrufurkunde Austauschen von Schl sseln Exportieren eines ffentlichen Schl ssels Importieren eines ffentlichen Schl ssels Ver- und Entschl sseln von Dokumenten Digitale Signaturen Dokumente mit Klartextsignatur Abgetrennte Signatur 3. Schl sselverwaltung Verwaltung Ihres Schl sselpaares Schl ssel-Integrit t Editieren von Schl sseln Widerrufen von Schl ssel-Komponenten Aktualisieren des Verfallsdatums Authentisieren anderer Schl ssel Vertrauen in den Eigent mer eines Schl ssels Authentisieren von Schl sseln im Web of Trust Weitergabe von Schl sseln 4. GnuPG im Alltagsgebrauch Definition Ihres Sicherheitsbedarfs Die Wahl der Schl ssell nge Der Schutz Ihres geheimen Schl ssels Ausw hlen der Verfallsdaten und Benutzung von Unterschl sseln Verwaltung Ihres Web of Trust Aufbau Ihres Web of Trust 5. Kryptogesetzgebung Benutzungsbeschr nkungen Ausfuhrbeschr nkungen Digitale Signaturen A. Ressourcen im Internet GnuPG Kryptographie allgemein Kryptographie-Gesetzgebung Link-Sammlungen Keyserver B. Installation von GnuPG Unix und GNU/Linux C. Referenz gpg manpage -- encryption and signing tool D. Glossar Weitere B cher zum Thema Kryptographie Abbildungsverzeichnis 3-1. Ein hypothetisches Vertrauensnetz ------------------------------------------------------------------------------- Vorwort [Grundgesetz Artikel 10, Absatz 1: ``Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich.''] [``Eckpunkte der deutschen Kryptopolitik'', verabschiedet vom deutschen Bundeskabinett am 2. Juni 1999: ``Der Einsatz kryptographischer Verfahren ist von au erordentlicher Bedeutung f r eine effiziente technische Kriminalpr vention. Dies gilt sowohl f r die Gew hrleistung der Authentizit t und Integrit t des Datenverkehrs wie auch f r den Schutz der Vertraulichkeit.''] Elektronische Daten spielen im Zeitalter des Computers und der weltweiten Vernetzung eine herausragende Rolle. Privatleute, Firmen, Politiker, Organisationen und Beh rden machen zunehmend Gebrauch von der bequemen, schnellen und preisg nstigen M glichkeit, per E-Mail zu kommunizieren, und nutzen elektronische Speichermedien (Festplatten, Disketten, CDROMs), um darauf ihre pers nlichen Daten, Forschungsergebnisse, Firmengeheimnisse, Kunden- oder Patienteninformationen, Statisken, Notizen, Entw rfe, Umsatzzahlen usw. zu speichern. Bei der Abwicklung von Gesch ftsvorg ngen (Bestellung, Bezahlung, Vertr ge) spielt das Internet eine immer wichtigere Rolle. Den Weg, den Ihre Daten ber das Internet zu einer Zieladresse gehen, k nnen Sie weder vorhersagen noch vorherbestimmen. Alle Daten, die unverschl sselt (oder mit einer unsicheren Methode verschl sselt) ber's Netz gehen, sind quasi ffentlich. Man mu davon ausgehen, das diese Daten - von wem auch immer - mitgelesen oder manipuliert und - zu welchem Zweck auch immer - mi braucht werden k nnen. Daten, die Sie auf Ihrem Computer abgespeichert haben, sind meist nicht sicher vor unbefugten Zugriffen. Viele Rechner sind nicht einmal mit einem Pa wortschutz versehen, und selbst bei vorhandenem Pa wortschutz gibt es vielf ltige M glichkeiten, an diese Daten zu gelangen. Noch nie war es so einfach und effektiv m glich, in Ihre Privatsph re einzudringen oder Zugang zu Ihren vertraulichen Informationen zu erlangen. ------------------------------------------------------------------------------- Warum Kryptographie? Kryptographie (die Wissenschaft von der Verschl sselung) gew hrleistet * Vertraulichkeit * Integrit t und * Authentizit t Ihrer Daten und Ihrer Kommunikation. Wenn Sie E-Mails unverschl sselt verschicken, m ssen Sie sich dar ber im klaren sein, da deren Inhalt weniger vertraulich ist als bei einer Postkarte. Die Administratoren sowohl Ihres Mailservers als auch des Empf ngers k nnten ohne weiteres ihre E-Mails lesen, abfangen oder ver ndern. Auf ihrem Weg zum Empf nger durchlaufen E-Mails unter Umst nden etliche Rechner. Jeder, der Zugang zu einem dieser Rechner hat, auch jeder Cracker[1], der durch irgendwelche Sicherheitsl cher in diese Rechner eindringt, kann m helos auf Ihre E-Mails zugreifen. Unter Umst nden werden Ihre E-Mails sogar auf der Festplatte eines dieser Zwischenrechner gespeichert. Auch k nnte der Carrier, also der, der die Datenleitungen zu Verf gung stellt (in Deutschland meist die Deutsche Telekom oder Colt-Telekom) die Datenpakete, die ber seine Leitungen gehen, gezielt filtern. Es ist auch nicht auszuschlie en, da jemand diese Leitungen von au en anzapft. Es geht aber nicht allein darum, sich gegen Cracker oder korrupte Sytemadministratoren zu sch tzen, sondern auch gegen das planm ige Eindringen staatlicher Organisationen (des eigenen oder eines anderen Landes) in Ihre Privatsph re. Die Geheimdienste vieler L nder filtern heutzutage nicht nur Telefongespr che, sondern zunehmend auch die Daten, die ber das Internet transportiert werden, um daraus wirtschaftlich, politisch oder f r die Strafverfolgung nutzbare Daten zu gewinnen. Eine Studie der ``Kommission zur Technikfolgeabsch tzung des Europaparlamentes'' (STOA - Scientific and Technological Options Assessment) ber die ``Entwicklung von berwachungstechnologie und dem Risiko des Mi brauchs wirtschaftlicher Informationen'' zeigt beispielsweise, da das Belauschen elekronischer Kommunikation bereits systematisch und in gro em Stil betrieben wird. Eines der prominentesten Beispiele ist das ECHELON-System, das von den USA, Kanada, Gro britannien, Australien und Neuseeland gemeinsam unterhalten wird. Urspr nglich zum Belauschen des Ostblocks konzipiert, sammeln heute ber 120 Stationen mit gro em Aufwand Informationen unter anderem durch Abh ren von Satellitenverbindungen und Transatlantikkabeln, um Daten ber Einzelpersonen, Organisationen, Regierungen, Wirtschaftsunternehmen, Forschungsprojekte und internationale Institutionen zu gewinnen. Auf europ ischer Ebene plant die Arbeitsgruppe ``Polizeiliche Zusammenarbeit'' des Europa-Rats konkrete Ma nahmen f r die berwachung des Telekommunikations-Verkehrs. Das ``ENFOPOL 98'' genannte Dokument schlie t ausdr cklich das Internet und zuk nftige Technologien mit ein. Auch Daten, die unverschl sselt auf der Festplatte Ihres Rechners oder eines anderen Speichermediums liegen, sind vor unbefugten Zugriffen nicht sicher. Jemand k nnte sich ber eine Netzwerkverbindung Zugang verschaffen bzw. sich durch Diebstahl oder Einbruch in Besitz Ihrer Daten bringen. Wenn Sie Ihre Daten verschl sselt haben, kann ein Angreifer - selbst wenn er physisch im Besitz der Daten ist - nicht auf diese zugreifen. Ein weiteres Problem ist das Authentifizieren von elektronischen Daten. Wie bereits oben erw hnt, ist es m glich, die Absenderadresse und den Inhalt eines E-Mails zu f lschen. Gerade bei offizieller oder gesch ftlicher Korrespondenz, dem Austausch von Dokumenten und dem Abwickeln von Gesch ftsvorg ngen ber das Internet ist es wichtig, den Absender eindeutig zu identifizieren und die Integrit t der Daten berpr fen zu k nnen. Die einzige M glichkeit, um Vertraulichkeit, Integrit t und Authentizit t von elektronischen Dokumenten zu gew hrleisten, ist die Benutzung wirkungsvoller kryptographischer Verfahren, wie sie etwa bei GnuPG Anwendung finden. Durch Verschl sselung erreichen Sie, da Ihre Daten nur von den Personen gelesen werden k nnen, f r die sie auch bestimmt sind. E-Mails werden quasi in einen Briefumschlag gesteckt, der nur vom Empf nger ge ffnet werden kann. Dar berhinaus wird durch digitale Unterschriften eine eindeutige Zuordnung zum Urheber der Signatur m glich, und Manipulationen des Dokumentes oder Vort uschen eines falschen Urhebers (Absenders) lassen sich feststellen. In der Elektronischen Datenverarbeitung sollte f r Sie die gleiche Sicherheit selbstverst ndlich sein wie in anderen Bereichen. Wahrscheinlich w rden Sie weder ein intimes Liebesgest ndnis, noch eine Mitteilung an Ihren Rechtsanwalt, noch Ihre wissenschaftliche oder gesch ftliche Korrespondenz per Postkarte schicken. Auch lassen Sie wahrscheinlich keine vertraulichen Dokumente offen in Ihrer Wohnung oder an Ihrem Arbeitsplatz liegen. Ebensowenig w rden Sie einen Kaufvertrag ohne rechtsg ltige Unterschrift akzeptieren. Verschl sselung und digitale Signaturen sollten also ein allt glicher Vorgang f r Sie sein. Ob Sie nun berufliches oder privates Interesse am Schutz Ihrer Daten haben: mangelndes Problembewu tsein ist das gr te Risiko. ------------------------------------------------------------------------------- Warum GnuPG? GnuPG (der GNU Privacy Guard) ist ein Programm zum Verschl sseln und Signieren von digitalen Daten und arbeitet unabh ngig von den jeweiligen Datenformaten (E-Mail, Textdateien, Bilddaten, Sourcecode, Datenbanken, komplette Festplatten usw.). Es entspricht der im RFC2440 festgelegten OpenPGP-Spezifikation und ist kompatibel zu PGP 5.x der Firma NAI. GnuPG verwendet dazu haupts chlich ein hybrides Verfahren mit ffentlichem Schl ssel. Zum Verschl sseln kann GnuPG aber ebenso ausschlie lich symmetrische Verfahren einsetzen. GnuPG ist derzeit eine der sichersten Anwendungen zum Verschl sseln und Signieren von Daten. Bei sorgf ltiger Anwendung ist eine Verschl sselung mit GnuPG auch in absehbarer Zukunft nicht zu knacken. Im Gegensatz zu anderen Verschl sselungsprogrammen wie beispielsweise PGP von der Firma NAI ist GnuPG freie Software. Das bedeutet unter anderem, da der Programm-Quellcode frei verf gbar, frei von Patenten und frei von einschr nkenden Lizenzbedingungen ist [2]. Jeder Anwender kann so das Programm auf seine Integrit t hin pr fen. Das hei t beispielsweise, da sich Hintert ren (Key Recovery) oder 'Generalschl ssel' (Key Escrow) nicht versteckt einbauen lassen und jeder Anwender die M glichkeit hat, Fehler zu beseitigen, das Programm zu verbessern oder nach seinen Vorstellungen zu ver ndern. Dar berhinaus ist GnuPG nicht - wie beispielsweise amerikanische Verschl sselungsprogramme - durch Ausfuhrbestimmungen k nstlich in seiner Funktionalit t und Sicherheit beschr nkt. ------------------------------------------------------------------------------- Aufbau des Buches Die grundlegenden Konzepte und Hintergr nde der Verschl sselung und digitaler Signaturen werden in Kapitel 1 ``Konzepte'' behandelt. Kapitel 2 ``Grundlagen'' f hrt in die Arbeit mit GnuPG ein; die wichtigsten Funktionen, Arbeitsschritte und Optionen werden dort am Beispiel erkl rt. In Kapitel 3 ``Schl sselverwaltung'' wird ausf hrlich auf das Editieren, Authentifizieren und Verwalten von Schl sseln eingegangen. Auf die wichtigsten Aspekte des praktischen Einsatzes und das ``Web of Trust'' wird in Kapitel 4 ``GnuPG im Alltagsgebrauch'' eingegangen. Kapitel 5 gibt einen kurzen berblick ber die Kryptographie-Gesetzgebung. Im Anhang des Buches finden Sie ein ausf hrliches Glossar, das die verwendeten Fachausdr cke erkl rt, ein Literaturverzeichnis, eine Sammlung von Internet-Ressourcen sowie eine Anleitung zur Installation von GnuPG. ------------------------------------------------------------------------------- Kapitel 1. Konzepte GnuPG verwendet mehrere kryptographische Verfahren wie beispielsweise symmetrische Verschl sselung, Public-Key-Verschl sselung und Einweg-Hashing. Nat rlich k nnen Sie GnuPG auch ohne tiefere Kenntnis dieser Konzepte benutzen, doch wenn Sie GnuPG effektiv einsetzen m chten, sollten Sie ein wenig Hintergrundwissen haben. Dieses Kapitel f hrt in die grundlegenden kryptographischen Konzepte ein, wie sie von GnuPG benutzt werden. Andere B cher behandeln diese Themen viel detaillierter. Empfehlenswerte B cher zum tieferen Studium sind beispielsweise Bruce Schneiers ``Angewandte Kryptographie'' oder Reinhard Wobsts ``Abenteuer Kryptologie''. Weitere Literaturhinweise finden sich im Anhang B. ------------------------------------------------------------------------------- Symmetrische Verschl sselung Eine symmetrische Verschl sselung benutzt zum Ver- und Entschl sseln denselben Schl ssel. Zwei Korrespondenzpartner, die eine symmetrische Verschl sselung benutzen, m ssen sich vorher ber den Schl ssel einigen. Mit diesem Schl ssel verschl sselt der Absender die Nachricht und schickt sie an den Empf nger, der sie unter Benutzung desselben Schl ssels wiederherstellt. Nach diesem Prinzip funktionierte beispielsweise die deutsche Enigma. Die jeweiligen Tages-Schl ssel wurden als Code-B cher ausgegeben, und jeden Tag konsultierte dann ein Funker seine Kopie des Code-Buchs, um den aktuellen Tagesschl ssel zu ermitteln, mit dem der Funkverkehr f r den betreffenden Tag dann ver- und entschl sselt wurde. Zu den modernen Beispielen f r symmetrische Verschl sselungen geh ren z.B. Blowfish und IDEA. Ein gutes Verschl sselungverfahren legt den Schwerpunkt der Sicherheit auf die Geheimhaltung des Schl ssels und nicht auf die Geheimhaltung des verwendeten Algorithmus. Mit anderen Worten, es ist keine Hilfe f r einen Angreifer, wenn das Verschl sselungsverfahren bekannt ist, solange er nicht im Besitz des Schl ssels selbst ist. Die von GnuPG benutzten Verschl sselungsverfahren beruhen auf diesen Prinzipien. Da die gesamte Sicherheit auf dem Schl ssel beruht, ist es wichtig, da der Schl ssel mit verf gbaren Mitteln nicht zu erraten ist. Daraus folgt, da der Vorrat an m glichen Schl sseln, der sogenannte key space, m glichst gro sein mu . W hrend seiner Zeit in Los Alamos war der Nobelpreistr ger Richard Feynman ber hmt f r seine F higkeit, Safes zu knacken. Um es noch geheimnisvoller zu machen, schleppte er einen Satz von Werkzeugen mit, zu denen ein altes Stethoskop geh rte. In Wirklichkeit wandte er jedoch eine ganze Reihe von Tricks an, um die Zahl der Kombinationen, die er ausprobieren mu te, zu reduzieren; dann fing er an zu raten, bis er die richtige Kombination fand. Mit anderen Worten, er verringerte die Gr e des key space. Die Briten benutzten im 2. Weltkrieg Maschinen, um Schl ssel zu erraten. Die deutsche Enigma hatte einen sehr gro en key space, doch die Briten bauten spezialisierte Rechenmaschinen, Bombes genannt, um systematisch alle Schl ssel auszuprobieren, bis der jeweilige Tagesschl ssel gefunden war. Manchmal fanden sie den Tagesschl ssel innerhalb der Benutzungsdauer des neuen Schl ssels, an manchen Tagen fanden sie den richtigen Schl ssel berhaupt nicht. Heute k nnen Computer sehr schnell Schl ssel erraten, und eben deshalb ist in modernen Verschl sselungsverfahren die Schl sselgr e u erst wichtig. Die DES-Verschl sselung zum Beispiel benutzt einen 56-Bit-Schl ssel; das bedeutet, da es 2^56, also genau 72.057.594.037.927.936 m gliche Schl ssel gibt (das sind mehr als 72 Billiarden). Obwohl das eine sehr gro e Zahl ist, kann ein normaler Mehrzweckcomputer den gesamten key space innerhalb von Tagen pr fen. Ein spezialisierter Computer braucht hierf r m glicherweise nur ein paar Stunden. Die moderneren Verschl sselungsverfahren wie beispielsweise Blowfish und IDEA benutzen s mtlich 128-Bit-Schl ssel, was bedeutet, da es 2^128 (340.282.366.920.938.463.463.374.607.431.768.211.456!!!) m gliche Schl ssel gibt. Dies sind so unglaublich viel mehr Kombinationen als bei einer 56-Bit-Verschl sselung, da sogar selbst dann, wenn man alle Computer der Welt zusammen arbeiten lie e, das bisherige Alter des Universums noch eine zu kurze Zeit sein k nnte, um den richtigen Schl ssel zu finden. ------------------------------------------------------------------------------- Public-Key-Verschl sselung Das Hauptproblem bei symmetrischen Verschl sselungen ist nicht die Sicherheit der eingesetzten Verfahren, sondern der Austausch der Schl ssel. Wenn zwei Kommunikationspartner einmal die Schl ssel ausgetauscht haben, kann der betreffende Schl ssel f r sicheren Datenaustausch benutzt werden. Die Frage ist nur, auf welchem sicheren Wege der Schl sselaustausch stattgefunden hat. Wahrscheinlich w re es f r einen Angreifer viel leichter, den Schl ssel abzufangen, als alle m glichen Schl ssel im key space auszuprobieren (eine Erfahrung, die die Deutschen mit ihrer Enigma auch machen mu ten). Ein weiteres Problem ist die Anzahl der insgesamt benutzten Schl ssel. Wenn die Zahl der Leute, die miteinander kommunizieren wollen, n betr gt, so werden insgesamt n (n-1)/2 Schl ssel (also beispielsweise 45 Schl ssel bei 10 Leuten) ben tigt. Dies mag f r eine geringe Personenzahl noch angehen, l t sich aber bei gro en Personengruppen nicht mehr handhaben. Der Sinn von Verschl sselungsverfahren mit ffentlichem Schl ssel besteht darin, da das Sicherheitsrisiko beim gegenseitigen Schl sselaustausch g nzlich vermieden wird. Jeder hat ein Schl sselpaar mit einem ffentlichen und einem geheimen Schl ssel. Zum Verschl sseln einer Nachricht benutzt man den ffentlichen Schl ssel des Empf ngers, und nur dieser kann sie mit seinem geheimen Schl ssel wieder entschl sseln. Dadurch l st man das Problem des Schl sselaustausches bei symmetrischer Verschl sselung. Sender und Empf nger brauchen sich nicht auf einen Schl ssel zu einigen. Erforderlich ist nur, da der Absender eine Kopie des ffentlichen Schl ssels des Empf ngers besitzt. Dieser eine ffentliche Schl ssel kann von jedem benutzt werden, der mit dem Empf nger kommunizieren will. Somit sind dann insgesamt nur n Schl sselpaare notwendig, wenn n Leute verschl sselt miteinander kommunizieren wollen. Die Verschl sselung mit ffentlichem Schl ssel beruht auf sogenannten Fallt r-Algorithmen bzw. Einweg-Hashes. Das sind Funktionen, die leicht zu berechnen sind, doch umgekehrt ist es praktisch unm glich, aus dem Ergebnis dieser Hash-Funktionen wieder den Ausgangswert zu berechnen. So ist es z.B. leicht, zwei Primzahlen miteinander zu multiplizieren, um eine Nichtprimzahl zu erhalten, es ist aber schwer, eine Nichtprimzahl in ihre Primfaktoren zu zerlegen. Fallt r-Algorithmen sind hnlich, haben aber eine ``Fallt r''. Das hei t: Wenn ein St ck Information bekannt ist, kann man leicht die Umkehrfunktion berechnen. Wenn Sie z.B. eine aus zwei Primfaktoren bestehende Zahl haben, so macht die Kenntnis eines der Faktoren es leicht, den zweiten zu berechnen. Angenommen, ein Verfahren beruhe auf der Bildung einer Zahl aus Primfaktoren, dann enth lt der ffentliche Schl ssel eine aus zwei gro en Primfaktoren zusammengesetzte Zahl, und das Verschl sselungsverfahren benutzt dann diese Nichtprimzahl zum Verschl sseln der Nachricht. Das Verfahren zum Wiederherstellen dieser Nachricht erfordert dann die Kenntnis der Primfaktoren. So ist die Entschl sselung m glich, wenn Sie den privaten Schl ssel haben, der einen der Faktoren enth lt, ist aber praktisch unm glich, wenn Sie ihn nicht haben. Wie bei guten symmetrischen Verschl sselungsverfahren beruht die Sicherheit auch bei Public-Key-Verfahren ausschlie lich auf dem Schl ssel. Aus diesem Grund kann man die Schl sselgr e als ein Ma f r die Sicherheit des Systems nehmen. Allerdings kann man die Gr e eines symmetrischen Schl ssels nicht mit der von Public-Key-Verfahren vergleichen, um R ckschl sse auf deren relative Sicherheit ziehen zu k nnen. Bei einem Brute-Force-Angriff auf eine symmetrische Verschl sselung mit einer Schl sselgr e von 80 Bit mu der Angreifer bis zu 2^80-1 Schl ssel ausprobieren, um den richtigen Schl ssel zu finden. Bei einem Brute-Force-Angriff auf eine Public-Key-Verschl sselung mu der Angreifer bei einer Schl sselgr e von 512 Bit eine in 512 Bit codierte (bis zu 155 Dezimalstellen umfassende) Nichtprimzahl in ihre Primfaktoren zerlegen. Der Rechenaufwand f r den Angriff weist je nach der Verschl sselung gewaltige Unterschiede auf. W hrend 128 Bit f r symmetrische Schl ssel ausreichen, werden angesichts der heutigen Verfahren zur Faktorisierung grosser Zahlen f r die meisten Zwecke ffentliche Schl ssel mit 1024 Bits empfohlen. ------------------------------------------------------------------------------- Hybride Verschl sselungsverfahren Public-Key-Verschl sselung ist kein Allheilmittel. Viele symmetrische Verfahren sind vom Sicherheitsstandpunkt aus betrachtet wirksamer, und die Ver- und Entschl sselung ist bei Public-Key-Verfahren aufwendiger als bei entsprechenden symmetrischen Systemen, sie sind aber nichtsdestoweniger ein wirksames Werkzeug f r den sicheren Austausch von symmetrischen Schl sseln. Das ist die Idee bei hybriden Verschl sselungssystemen. Eine hybride Verschl sselung benutzt sowohl eine symmetrische Verschl sselung als auch ein asymmetrisches Public-Key-Verfahren. Die eigentliche Nachricht wird mit einem symmetrischen Sitzungsschl ssel verschl sselt, welcher von einem Zufallsgenerator erzeugt wird. Dieser Sitzungsschl ssel wird dann mit dem ffentlichen Schl ssel des Empf ngers verschl sselt. Sowohl PGP als auch GnuPG benutzen hybride Verschl sselungsverfahren. Der mit dem ffentlichen Schl ssel des Empf ngers verschl sselte Sitzungsschl ssel und die symmetrisch verschl sselte Nachricht werden automatisch zusammengefa t. Der geheime Schl ssel des Empf ngers wird zum Entschl sseln des Sitzungsschl ssels verwendet, und dieser wird dann zum Entschl sseln der eigentlichen Nachricht verwendet. Ein hybrides Verschl sselungsverfahren ist immer nur so gut wie der unsicherste Teil, egal ob das die Public-Key-Verschl sselung oder die symmetrische Verschl sselung ist. Da die symmetrischen Sitzungsschl ssel bei jedem Vorgang neu erzeugt werden, k nnte ein Angreifer - selbst wenn er einen Sitzungsschl ssel entschl sseln k nnte - nur die mit dem betreffenden Sitzungsschl ssel verschl sselte Nachricht entschl sseln. Er m te also f r jede weitere Nachricht, die er lesen m chte, erneut einen Sitzungsschl ssel entschl sseln. ------------------------------------------------------------------------------- Digitale Unterschriften Eine Hash-Funktion [3] ist eine kryptographische Pr fsumme. Durch eine eindeutige Funktion wird aus einer Datei eine wesentlich k rzere Datensequenz erzeugt, die ein eindeutiges Abbild der Ursprungsdatei ist. Die digitale Unterschrift eines Dokumentes ist das Ergebnis der Anwendung einer Hash-Funktion auf das Dokument. Um f r digitale Unterschriften brauchbar zu sein, mu die Hash-Funktion jedoch zwei wichtige Eigenschaften haben: Erstens sollte es unm glich sein, zwei Dokumente zu finden, die dasselbe Hash-Ergebnis haben. Zweitens sollte es bei einem gegebenen Hash-Ergebnis schwer sein, das urspr nglich Dokument wiederherzustellen, aus dem dieser Hash erzeugt wurde. Einige Public-Key-Verfahren k nnten auch zum Unterschreiben von Dokumenten benutzt werden.[4] Der Unterzeichner verschl sselt das Dokument mit seinem privaten Schl ssel. Jeder, der die Unterschrift pr fen und das Dokument sehen will, benutzt einfach den ffentlichen Schl ssel des Unterzeichners, um das Dokument zu entschl sseln. Dieses Verfahren besitzt in der Tat die beiden Eigenschaften, die eine gute Hash-Funktion braucht, doch ist es in der Praxis zu langsam, um effektiv nutzbar zu sein. Besser ist es, spezielle Hash-Algorithmen zu benutzen, welche diese beiden wichtigen Eigenschaften aufweisen; wie beispielsweise SHA1 und RIPE-MD160. Bei einem solchen Verfahren wird der Hash-Wert eines Dokumentes als Unterschrift verwendet. Man kann die Unterschrift dadurch pr fen, da man auf die Kopie des Dokumentes ebenfalls die Hash-Funktion anwendet und den Hash-Wert, den man erh lt, mit dem Hash-Wert des Originaldokumentes vergleicht. Wenn beide Werte bereinstimmen, dann sind beide Dokumente identisch. Das Problem ist jetzt nat rlich, Hash-Funktionen f r digitale Unterschriften zu benutzen, ohne einem Angreifer das Manipulieren der Unterschrift zu erm glichen. Wenn das Dokument und die Unterschrift unverschl sselt geschickt werden, k nnte ein Angreifer das Dokument ver ndern und eine entsprechende neue Unterschrift erzeugen, ohne da der Empf nger es merkt. Wenn nur das Dokument verschl sselt wird, k nnte ein Angreifer die Unterschrift verf lschen und so das Scheitern einer Unterschriftspr fung verursachen. Eine dritte M glichkeit besteht darin, ein hybrides Verfahren zu benutzen, um sowohl die Unterschrift als auch das Dokument zu verschl sseln. Der Unterzeichner benutzt seinen privaten Schl ssel, und jedermann kann dessen ffentlichen Schl ssel benutzen, um die Unterschrift und das Dokument zu pr fen. Dies klingt zwar gut, ist aber in Wirklichkeit Unsinn. Wenn dieses Verfahren das Dokument wirklich sichern k nnte, w rde es dieses auch gegen Verf lschung sichern, und dann w re die Unterschrift gar nicht n tig. Das ernstlichere Problem ist jedoch, da dies keinen Schutz gegen Verf lschung bietet, weder f r die Unterschrift noch f r das Dokument. Bei diesem Verfahren wird nur der Sitzungsschl ssel f r die symmetrische Verschl sselung unter Benutzung des privaten Schl ssels des Unterzeichners verschl sselt. Jeder kann den ffentlichen Schl ssel benutzen, um den Sitzungsschl ssel wiederherzustellen. Deshalb ist es f r einen Angreifer einfach, den Sitzungsschl ssel wiederherzustellen und ihn zum Verschl sseln von Ersatzdokumenten und Ersatzunterschriften zu benutzen, die er dann im Namen des Absenders an andere schickt. Ein wirklich funktionierendes Verfahren ist es, nur die Unterschrift mit einem Public-Key-Verfahren zu verschl sseln. Das hei t, es wird der geheime Schl ssel des Unterzeichners benutzt, um die digitale Unterschrift zu erzeugen, die dann jeder mit dem dazugeh rigen ffentlichen Schl ssel checken kann. Das unterzeichnete Dokument kann man unverschl sselt verschicken, wenn es ffentlich ist oder verschl sselt, wenn es vertraulich ist. Wenn das Dokument nach dem Unterzeichnen ver ndert wurde, wird die Unterschriftspr fung negativ ausfallen. Der von GnuPG standardm ig benutzte Digital Signature Algorithm (DSA) arbeitet nach dieser Methode. ------------------------------------------------------------------------------- Kapitel 2. Grundlagen Dieses Kapitel f hrt in die wesentlichen Funktionen des GNU Privacy Guard ein. Hier lernen Sie, wie man Schl sselpaare erzeugt, Schl ssel austauscht und berpr ft, Dokumente verschl sselt, entschl sselt und durch digitale Unterschriften authentifiziert. Wie bereits in Kapitel 1 erw hnt, bedient sich GnuPG eines Public-Key-Verfahrens, um eine sichere Kommunikation zu gew hrleisten. In einem solchen System hat jeder Benutzer ein Schl sselpaar, bestehend aus einem geheimen Schl ssel und einem ffentlichen Schl ssel. Der geheime Schl ssel darf unter keinen Umst nden jemand anderem zug nglich sein. Den ffentlichen Schl ssel sollte man f r jeden, mit dem man kommunizieren m chte, zug nglich machen. GnuPG benutzt ein erweitertes Schema, bei dem jeder Benutzer jeweils ein prim res Schl sselpaar hat und optional weitere untergeordnete Schl sselpaare haben kann. Das prim re und das untergeordnete Schl sselpaar werden geb ndelt, um die Schl sselverwaltung zu erleichtern; das B ndel kann vereinfacht als ein Schl sselpaar betrachtet werden. ------------------------------------------------------------------------------- Erzeugen eines neuen Schl sselpaares Damit Sie GnuPG zum Verschl sseln, Entschl sseln oder Signieren einsetzen k nnen, ben tigen Sie ein Schl sselpaar, das aus einem geheimen und einem ffentlichen Schl ssel besteht. Mit der Kommandozeilen-Option --gen-key k nnen Sie ein neues prim res Schl sselpaar erzeugen: alice$ gpg --gen-key gpg (GnuPG) 1.0.1; Copyright (C) 1999 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Bitte w hlen Sie, welche Art von Schl ssel Sie m chten: (1) DSA und ElGamal (voreingestellt) (2) DSA (nur signieren/beglaubigen) (4) ElGamal (signieren/beglaubigen und verschl sseln) Ihre Auswahl? Mit GnuPG k nnen Sie verschiedene Typen von Schl sselpaaren erzeugen, doch mu der prim re Schl ssel Unterschriften liefern k nnen. Es gibt daher nur drei Optionen. Option 1 erzeugt wirklich zwei Schl sselpaare, n mlich ein DSA-Schl sselpaar, das nur zum Unterschreiben geeignet ist, und au erdem noch ein untergeordnetes ElGamal-Schl sselpaar f r die Verschl sselung. Option 2 erzeugt nur das DSA-Schl sselpaar. Option 4[5] erzeugt ein einzelnes ElGamal-Schl sselpaar, das sowohl zum Unterzeichnen als auch zum Verschl sseln verwendbar ist. In allen F llen ist es m glich, sp ter noch weitere Unterschl ssel f r die Verschl sselung und Unterzeichnung hinzuzuf gen. In der Regel sollten Sie hier die Standardoption ausw hlen. Als n chstes w hlen Sie die Schl sselgr e. Bei einem DSA-Schl ssel mu diese zwischen 512 und 1024 Bits liegen, ein ElGamal-Schl ssel dagegen kann - zumindest theoretisch - eine beliebige Gr e haben. Der GnuPG erfordert es allerdings, da die Schl ssel nicht kleiner als 768 Bits sind. Wenn Option 1 mit einer Schl sselgr e von mehr als 1024 Bit gew hlt wurde, hat der ElGamal-Schl ssel die verlangte Gr e, doch der DSA-Schl ssel wird maximal 1024 Bits haben. Der DSA Schl ssel wird 1024 Bits haben. Es wird ein neues ELG-E Schl sselpaar erzeugt. kleinste Schl ssell nge ist 768 Bit standard Schl ssell nge ist 1024 Bit gr te sinnvolle Schl ssell nge ist 2048 Bit Welche Schl ssell nge w nschen Sie? (1024) Je gr er der Schl ssel ist, desto sicherer ist er gegen Brute-Force-Angriffe, doch sollte f r die meisten Zwecke die Standard-Schl sselgr e ausreichend sein, da es einfacher w re, die Verschl sselung zu umgehen, als sie zu knacken. Au erdem wird mit zunehmender Schl sselgr e die Ver- und Entschl sselung langsamer, und auch die Unterschrift wird l nger. Einmal festgelegt, kann die Schl sselgr e nicht nachtr glich ge ndert werden. Schlie lich m ssen Sie noch ein Verfallsdatum w hlen. Wenn Option 1 gew hlt wurde, gilt dieses Verfallsdatum sowohl f r die ElGamal- als auch die DSA-Schl sselpaare. Bitte w hlen Sie, wie lange der Schl ssel g ltig bleiben soll. 0 = Schl ssel verf llt nie = Schl ssel verf llt nach n Tagen w = Schl ssel verf llt nach n Wochen m = Schl ssel verf llt nach n Monaten y = Schl ssel verf llt nach n Jahren Der Schl ssel bleibt wie lange g ltig? (0) F r die meisten F lle reicht ein Schl ssel ohne Verfallsdatum v llig aus. Allerdings sollte man das Verfallsdatum immer sorgf ltig ausw hlen; denn, obwohl es sich auch noch nachtr glich ndern l t, kann es umst ndlich sein, das ge nderte Verfallsdatum allen Ihren Kommunikationspartnern mitzuteilen. Im n chsten Schritt m ssen Sie eine Benutzer-ID (Benutzer-Kennung) angeben. Das dient dazu, den soeben erzeugten Schl ssel einer realen Person zuzuordnen. Sie ben tigen eine User-ID, um Ihren Schl ssel eindeutig zu machen; das Programm baut diese User-ID aus Ihrem echten Namen, einem Kommentar und Ihrer E-Mail-Adresse in dieser Form auf: ``Heinrich Heine (Der Dichter) '' Ihr Name (``Vorname Nachname''): Es wird zun chst nur eine Benutzer-ID erzeugt, doch k nnen Sie sp ter weitere Benutzer-IDs hinzuf gen, wenn Sie den Schl ssel in verschiedenen Situationen benutzen wollen, also beispielsweise bei der Arbeit in Ihrer Firma oder f r Ihre politische Arbeit. Die Benutzer-ID sollten Sie mit aller Sorgfalt w hlen, da Sie sie sp ter nicht mehr ndern k nnen. Damit Ihr geheimer Schl ssel nicht von anderen mi braucht werden kann, wird er von GnuPG mit einem symmetrischen Verfahren verschl sselt. Dazu geben Sie ein sogenanntes ``Mantra'' (einen Pa wort-Satz) ein, das Sie wiederum jedesmal ben tigen, wenn Sie auf Ihren geheimen Schl ssel zugreifen. Sie ben tigen ein Mantra, um den geheimen Schl ssel zu sch tzen. Geben Sie das Mantra ein: Die L nge des Mantra ist theoretisch unbegrenzt. Sie sollten es mit Sorgfalt ausw hlen. Unter dem Gesichtspunkt der Sicherheit ist das Mantra einer der schw chsten Punkte im GnuPG (wie auch in anderen Verschl sselungssystemen mit ffentlichen Schl sseln), da es Ihr einziger Schutz ist, falls jemand in den Besitz Ihres privaten Schl ssels kommt. Man sollte f r das Mantra keine W rter aus einem W rterbuch oder Lexikon nehmen und nicht nur die Buchstaben des Alphabets, sondern auch Sonderzeichen verwenden. Je l nger das Mantra ist, desto sicherer ist es, aber andererseits sollten Sie sich das Mantra auch gut merken k nnen; nichts ist fataler als das Mantra auf einem Zettel oder in einer Datei zu notieren. Ein gut gew hltes Mantra ist entscheidend f r Ihre Datensicherheit. Es ist beispielsweise keine gute Idee, einen bekannten Ausspruch oder ein Zitat einer bekannten Pers nlichkeit als Mantra zu nehmen. Das w rde die Chance erh hen, das Mantra zu erraten: ein Angreifer k nnte einfach den Computer eine Zitatenliste durchprobieren lassen. Am besten denkt man sich einen unsinnigen Satz wie z.B: ``Die Currywurst schmeckt nach Zimt und Zucker'' oder ``Helmut Kohl ist bekannterma en Vegetarier'' aus. Ihrer Phantasie sind hierbei keine Grenzen gesetzt. Wenn Sie auch noch ein paar Rechtschreibfehler und Sonderzeichen einbauen, ist ein W rterbuchangriff praktisch unm glich: ``Dat K rriwurst schm ckt nach #imt und #ucker''. Benutzen Sie auch auf keinen Fall eines der soeben aufgef hrten Beispiele!!. ------------------------------------------------------------------------------- Erzeugen einer Widerrufurkunde Nach dem Erzeugen Ihres Schl sselpaars sollten Sie sofort mit der Option --gen-revoke eine Widerrufurkunde f r Ihre Schl ssel erzeugen. Wenn Sie Ihr Mantra vergessen oder wenn Ihr privater Schl ssel kompromittiert oder verloren gegangen ist, k nnen Sie mit dieser Widerrufurkunde andere davon in Kenntnis setzen, da der dazugeh rige ffentliche Schl ssel nicht mehr benutzt werden sollte. Ein zur ckgerufener ffentlicher Schl ssel kann noch benutzt werden, um Unterschriften zu pr fen, die Sie vor dem Widerruf abgegeben haben, er kann jedoch nicht benutzt werden, um k nftige Mitteilungen an Sie zu verschl sseln. Vorausgesetzt, Sie haben noch Zugang zu Ihrem widerrufenen geheimen Schl ssel, so k nnen Sie selbstverst ndlich noch Daten entschl sseln, die vor dem Widerruf f r Sie verschl sselt worden sind. alice$ gpg --output revoke.asc --gen-revoke mykey [...] wobei mykey entweder die Schl ssel-ID Ihres ersten Schl sselpaares oder irgendein Teil einer dazugeh rigen Benutzer-ID ist. Die erzeugte Widerrufurkunde wird in die Datei revoke.asc, bzw., wenn man die Option --output wegl t, auf die Standard-Ausgabe geschrieben. Da die Widerrufurkunde kurz ist, ist es kein Problem, eine ausgedruckte Kopie der Widerrufurkunde irgendwo sicher aufzubewahren, z.B. in Ihrem Bankschlie fach. Die Widerrufurkunde sollten Sie aber auf keinen Fall an Stellen aufbewahren, zu denen andere Personen Zugang haben, da im Prinzip jeder die Widerrufurkunde ver ffentlichen und so den entsprechenden Schl ssel nutzlos machen k nnte. ------------------------------------------------------------------------------- Austauschen von Schl sseln Um mit anderen zu kommunizieren, m ssen Sie untereinander Ihre ffentlichen Schl ssel austauschen. Zum Auflisten der Schl ssel in Ihrem ffentlichen Schl sselbund verwenden Sie die Befehlszeilen-Option --list-keys. alice$ gpg --list-keys /users/alice/.gnupg/pubring.gpg --------------------------------------- pub 1024D/FB5797A9 2000-06-06 Alice (Rechtsanw ltin) sub 1024g/C8B3998F 2000-06-06 ------------------------------------------------------------------------------- Exportieren eines ffentlichen Schl ssels Um jemandem Ihren ffentlichen Schl ssel zu schicken, m ssen Sie diesen zun chst exportieren. Hierzu benutzt man die Kommandozeilen-Option --export. Zur Indentifikation des zu exportierenden ffentlichen Schl ssels dient entweder die Schl ssel-ID oder irgendein Teil der Benutzer-ID. alice$ gpg --output alice.gpg --export alice@cyb.org Der Schl ssel wird in einem bin ren Format exportiert, doch kann dies unerw nscht sein, wenn Sie den Schl ssel per E-Mail verschicken oder auf einer WWW-Seite ver ffentlichen wollen. GnuPG unterst tzt daher die Kommandozeilen-Option --armor[6] die bewirkt, da der Output im ASCII-Format ausgegeben wird. (Im Allgemeinen kann jeder Output von GnuPG - beispielsweise Schl ssel, verschl sselte Dokumente oder Unterschriften - im ASCII-Format dargestellt werden, indem man die --armor-Option hinzuf gt.) alice$ gpg --armor --export alice@cyb.org -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org [...] -----END PGP PUBLIC KEY BLOCK----- ------------------------------------------------------------------------------- Importieren eines ffentlichen Schl ssels Ein ffentlicher Schl ssel kann zu Ihrem ffentlichen Schl sselbund hinzugef gt werden, und zwar mit folgender Option: --import alice$ gpg --import blake.gpg gpg: Schl ssel B2690E6F: ffentlicher Schl ssel importiert gpg: Anzahl insgesamt bearbeiteter Schl ssel: 1 gpg: importiert: 1 alice$ gpg --list-keys /users/alice/.gnupg/pubring.gpg --------------------------------------- pub 1024D/FB5797A9 2000-06-06 Alice (Rechtsanw ltin) sub 1024g/C8B3998F 2000-06-06 pub 1024D/B2690E6F 2000-06-06 Blake (Staatsanwalt) sub 1024g/F251B862 2000-06-06 Wenn ein Schl ssel einmal importiert ist, sollte er auf Authentizit t berpr ft werden. GnuPG arbeitet mit einem wirksamen und flexiblen Vertrauensmodell, bei dem Sie nicht jeden Schl ssel pers nlich zu authentifizieren brauchen, den Sie importieren. Einige Schl ssel k nnen dies jedoch erfordern. Ein Schl ssel wird dadurch authentifiziert, da Sie den Fingerabdruck des Schl ssels berp fen und dann den Schl ssel unterschreiben, um seine G ltigkeit zu best tigen. Der Fingerabdruck eines Schl ssels kann schnell mit der Befehlszeilen-Option --fingerprint gepr ft werden, um aber den Schl ssel zu best tigen, m ssen Sie ihn editieren. alice$ gpg --edit-key blake@cyb.org pub 1024D/B2690E6F created: 2000-06-06 expires: never trust: -/q sub 1024g/F251B862 created: 2000-06-06 expires: never (1) Blake (Staatsanwalt) Befehl> fpr pub 1024D/B2690E6F 2000-06-06 Blake (Staatsanwalt) Fingerprint: 6A51 852C 7491 95B5 C5F0 731C 141F C008 B269 0E6F Um den Fingerabdruck zu berpr fen, m ssen Sie den Eigent mer des Schl ssels kontaktieren und die Fingerabdr cke vergleichen. Sie k nnen pers nlich oder per Telefon mit ihm sprechen oder auf beliebigem anderen Wege kommunizieren, solange nur garantiert ist, da es sich um den rechtm igen Eigent mer handelt. Stimmen beide Fingerabdr cke berein, dann k nnen Sie sicher sein, da Sie eine echte Kopie des ffentlichen Schl ssels haben. Nach dem Pr fen des Fingerabdrucks k nnen Sie den Schl ssel unterschreiben, um ihn zu authentifizieren. Da die Schl ssel berpr fung ein Schwachpunkt in der Kryptographie mit ffentlichem Schl ssel ist, sollten Sie u erste Sorgfalt walten lassen und den Fingerabdruck eines Schl ssels immer gemeinsam mit dem Eigent mer pr fen, bevor Sie den Schl ssel unterschreiben. Befehl> sign pub 1024D/B2690E6F created: 2000-06-06 expires: never trust: -/q Fingerprint: 6A51 852C 7491 95B5 C5F0 731C 141F C008 B269 0E6F Blake (Staatsanwalt) Sind Sie wirklich sicher, da Sie vorstehenden Schl ssel mit Ihrem Schl ssel beglaubigen wollen: ``Alice (Rechtsanw ltin) '' Wirklich unterschreiben? Sie k nnen sich jederzeit vergewissern, welche Unterschrift Sie hinzugef gt haben. Jede Benutzer-ID auf dem Schl ssel hat dann sowohl eine oder mehrere Eigenbeglaubigungen als auch eine Unterschrift von jedem Benutzer, der den Schl ssel authentifiziert hat. Befehl> check uid Blake (Staatsanwalt) sig! B2690E6F 2000-06-06 [Eigenbeglaubigung] sig! FB5797A9 2000-06-06 Alice (Rechtsanw ltin) ------------------------------------------------------------------------------- Ver- und Entschl sseln von Dokumenten Der ffentliche und der geheime Schl ssel haben jeweils eine spezifische Aufgabe beim Ver- und Entschl sseln von Dokumenten. Das Public-Key-Verfahren kann man sich wie einen offenen Safe vorstellen. Wenn jemand ein Dokument unter Benutzung eines ffentlichen Schl ssels verschl sselt, wird dieses Dokument in den Safe gelegt, der Safe geschlossen und das Kombinationsschlo mehrmals verdreht. Der entsprechende geheime Schl ssel ist die Kombination, mit der man den Safe wieder ffnen und das Dokument wieder herausholen kann. Mit anderen Worten, es kann nur die Person, die den geheimen Schl ssel hat, auf ein Dokument zugreifen, das unter Benutzung des dazugeh rigen ffentlichen Schl ssels verschl sselt worden ist. Das Verfahren f r das Ver- und Entschl sseln von Dokumenten ist bei diesem Modell einfach: eine Nachricht an Alice verschl sseln Sie unter Verwendung von Alices ffentlichem Schl ssel, und diese entschl sselt sie mit ihrem geheimen Schl ssel. Umgekehrt geht es genauso: Alice verschl sselt eine Nachricht an Sie mit Ihrem ffentlichen Schl ssel, welche Sie dann mit Ihrem geheimen Schl ssel entschl sseln k nnen. Um ein Dokument zu verschl sseln, benutzt man die Option --encrypt. Dazu m ssen Sie die ffentlichen Schl ssel der vorgesehenen Empf nger haben. Sollten Sie auf der Kommandozeile den Namen der zu verschl sselnden Datei nicht angeben, werden die zu verschl sselnden Daten von der Standard-Eingabe gelesen. Das verschl sselte Resultat wird auf die Standard-Ausgabe oder in die Datei, die durch die Option --output spezifiziert ist, geschrieben. Das Dokument wird dar berhinaus auch noch komprimiert. alice$ gpg --output doc.gpg --encrypt --recipient blake@cyb.org doc Mit der Option --recipient wird der ffentliche Schl ssel spezifiziert, mit dem das Dokument verschl sselt werden soll. Entschl sseln l t sich das so verschl sselte Dokument jedoch nur von jemandem mit dem dazugeh rigen geheimen Schl ssel. Das bedeutet konsequenterweise aber auch, da Sie selbst ein so verschl sseltes Dokument nur wieder entschl sseln k nnen, wenn Sie Ihren eigenen ffentlichen Schl ssel in die Empf ngerliste aufgenommen haben. Zum Entschl sseln einer Nachricht wird die Option --decrypt benutzt. Sie ben tigen dazu den geheimen Schl ssel, f r den die Nachricht verschl sselt wurde und das Mantra, mit dem der geheime Schl ssel gesch tzt ist. blake$ gpg --output doc --decrypt doc.gpg Sie ben tigen ein Mantra, um den geheimen Schl ssel zu entsperren. Benutzer: ``Blake (Staatsanwalt) '' 1024-Bit ELG-E Schl ssel, ID F251B862, erzeugt 2000-06-06 (Hauptschl ssel-ID B2690E6F) Geben Sie das Mantra ein: Mit GnuPG k nnen Sie aber auch ohne Anwendung eines Public-Key-Verfahrens Dokumente verschl sseln und stattdessen ein symmetrisches Verfahren benutzen. Der Schl ssel f r die symmetrische Verschl sselung wird aus einem Pa wort - besser noch, einem Pa wort-Satz - generiert, das auf gar keinen Fall dem Mantra zum Schutz Ihres privaten Schl ssels entsprechen sollte. Je l nger das gew hlte Pa wort ist, desto sicherer ist der Schl ssel. Wenn Sie diesen symmetrischen Schl ssel an jemanden weitergeben, sollten Sie dazu einen sicheren Weg w hlen. Ein Dokument l t sich so durch Benutzung der Option--symmetricverschl sseln. alice$ gpg --output doc.gpg --symmetric doc Geben Sie das Mantra ein: Symmetrische Verfahren empfehlen sich beispielsweise, wenn Sie die verschl sselten Daten nicht weiter geben m chten, das Problem der Pa wort bergabe also entf llt. Ein m gliches Anwendungsbeispiel w re, da Sie alte E-Mails oder alte Datens tze aus Ihrer Umsatzstatisk auf ihrer Festplatte oder einer CDROM archivieren und vor fremden Zugriffen sch tzen m chten. Oder Sie k nnen auch ganze Verzeichnisse oder Festplatten verschl sseln. ------------------------------------------------------------------------------- Digitale Signaturen Eine digitale Unterschrift oder Signatur ist am ehesten mit einem Siegel zu vergleichen. Mit dem Siegel wird die Integrit t eines Dokumentes best tigt, das sich in einem Umschlag befindet, und erm glicht, da sich eine nachtr gliche Manipulation feststellen l t. Wenn das Dokument nachfolgend in irgendeiner Weise ver ndert wird, ergibt die Pr fung der Signatur ein negatives Ergebnis. Au erdem erm glicht die Signatur eine zweifelsfreie Zuordnung des Absenders. Eine digitale Unterschrift kann so demselben Zweck wie eine handgeschriebene Unterschrift dienen mit dem zus tzlichen Vorteil, eine Handhabe gegen Verf lschung zu bieten. Die GnuPG-Quelltextdistribution ist z.B. so unterschrieben, da die Benutzer nachpr fen k nnen, da der Quelltext nachtr glich nicht ver ndert worden ist und auch wirklich vom GnuPG-Team stammt. Die rechtliche Verbindlichkeit von digitalen Unterschriften ist von Land zu Land verschieden. In Deutschland ist das Signaturgesetz augenblicklich einer Novellierung unterworfen. Weitere Informationen und Quellenverweise finden Sie in Kapitel 4. Bei der Erzeugung und Pr fung von Unterschriften benutzt man das ffentlich/ geheime Schl sselpaar anders als bei der Ver- und Entschl sselung. Die Unterschrift wird hier mit dem geheimen Schl ssel des Unterzeichnenden erzeugt und dann jeweils mit dem entsprechenden ffentlichen Schl ssel gepr ft. So w rde beispielsweise Alice ihren geheimen Schl ssel benutzen, um ihren letzten Beitrag f r eine Zeitschrift zu signieren. Der Redakteur, der Alices Artikel bearbeitet, benutzt dann ihren ffentlichen Schl ssel, um die Unterschrift zu pr fen und so sicherzustellen, da der Beitrag wirklich von Alice selbst stammt und auch nicht nachtr glich ver ndert worden ist. Als Konsequenz aus der Verwendung digitaler Signaturen ergibt sich, da sich kaum abstreiten l t, da man eine digitale Unterschrift geleistet hat, da dies ja bedeuten w rde, da der geheime Schl ssel kompromittiert wurde. Die Kommandozeilen-Option --sign wird zum Erzeugen einer digitalen Unterschrift verwendet. Mit der Option --output legen Sie fest, in welche Datei das signierte Dokument geschrieben wird. alice$ gpg --output doc.sig --sign doc Sie ben tigen ein Mantra, um den geheimen Schl ssel zu entsperren. Benutzer: ``Alice (Rechtsanw ltin) '' 1024-bit DSA Schl ssel, 1024D/FB5797A9, erzeugt 2000-06-06 Geben Sie das Mantra ein: Das Dokument wird vor dem Unterschreiben komprimiert und die Ausgabe erfolgt im bin ren Format. Haben Sie ein unterschriebenes Dokument erhalten, k nnen Sie die Unterschrift pr fen, und zwar optional ohne oder mit Entnahme des unterschriebenen Originaldokumentes. Zur blo en berpr fung der Unterschrift benutzen Sie die Option --verify. Wenn Sie au erdem das unterzeichnete Dokument entnehmen wollen, verwenden Sie die Option --decrypt. blake$ gpg --output doc --decrypt doc.sig gpg: Unterschrift vom Die 06 Jun 2000 17:19:52 CEST, DSA Schl ssel ID FB5797A9 gpg: Korrekte Unterschrift von ``Alice (Rechtsanw ltin) '' ------------------------------------------------------------------------------- Dokumente mit Klartextsignatur In F llen, in denen es unerw nscht ist, das Dokument beim Unterschreiben zu komprimieren, benutzt man die Option --clearsign. Das bewirkt, da eine in ASCII dargestellte Signatur das Dokument wie ein Briefumschlag umgibt, das Dokument an sich aber nicht ver ndert wird. Der Vorteil dieses Verfahrens ist, da der Empf nger das Dokument auch ohne Pr fung der Signatur lesen kann. alice$ gpg --clearsign doc Sie ben tigen ein Mantra, um den geheimen Schl ssel zu entsperren. Benutzer: ``Alice (Rechtsanw ltin) '' 1024-Bit DSA Schl ssel, ID FB5797A9, erzeugt 2000-06-06 Geben Sie das Mantra ein: GnuPG markiert dann im Klartext den Anfang des signierten Dokuments und h ngt am Ende einen Block mit der eigentlichen OpenPGP-Signatur an. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hier steht irgend ein von GnuPG signierter Text [...] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5Pf40WyoKbftXl6kRAsWJAJ4hj7FzPX8M9MWZav9u6yjbHXWGKwCfSiKA wTaJ/lfY1ETv3R/uJrtGTbI= =BDOH -----END PGP SIGNATURE----- ------------------------------------------------------------------------------- Abgetrennte Signatur Der Nachteil bei signierten Dokumenten ist, da der Empf nger das Originaldokument aus der unterschriebenen Version erst wiederherstellen mu bzw. bei einem im Klartext unterschriebenen Dokument dieses gegebenenfalls noch editieren mu . Deshalb gibt es als Drittes noch die M glichkeit, Dokumente mit abgetrennter Unterschrift zu signieren. Dazu verwendet man die Option --detach-sig. Die Signatur wird dann in einer separaten Datei abgelegt. Das eigentliche Dokument bleibt unver ndert. alice$ gpg --output doc.sig --detach-sig doc Sie ben tigen ein Mantra, um den geheimen Schl ssel zu entsperren. Benutzer: ``Alice (Rechtsanw ltin) '' 1024-Bit DSA Schl ssel, ID FB5797A9, erzeugt 2000-06-06 Geben Sie das Mantra ein: Um die Signatur zu pr fen, ben tigen Sie sowohl das eigentliche Dokument als auch die abgetrennte Unterschrift. Die Option --verify kann zum Pr fen der Signatur benutzt werden. blake$ gpg --verify doc.sig doc gpg: Unterschrift vom Die 06 Jun 2000 17:34:43 CEST, DSA Schl ssel ID FB5797A9 gpg: Korrekte Unterschrift von ``Alice (Rechtsanw ltin) '' ------------------------------------------------------------------------------- Kapitel 3. Schl sselverwaltung Schl sselverf lschungen sind ein nicht zu untersch tzender Unsicherheitsfaktor bei der Public-Key-Kryptographie. Ein Angreifer kann beispielsweise die Schl sselbunde eines Benutzers manipulieren oder sich einen ffentlichen Schl ssel mit einer vorget uschten Identit t erzeugen und ihn an andere zum Herunterladen und Benutzen schicken. Wenn z.B. Chloe unbemerkt die Nachrichten, welche Alice an Blake sendet, lesen will, dann k nnte sie folgenderma en vorgehen: zuerst erzeugt sie ein neues Schl sselpaar mit einer gef lschten Benutzer-ID. Dann ersetzt sie Alices Kopie von Blakes ffentlichem Schl ssel durch den neuen Schl ssel. Anschlie end f ngt sie die Nachrichten ab, die Alice an Blake sendet. Diese Nachrichten kann sie dann mit dem neuen geheimen Schl ssel entschl sseln. Dann verschl sselt sie die Nachricht wieder, aber diesmal mit dem echten ffentlichen Schl ssel von Blake und schickt sie weiter an Blake. Chloe kann jetzt - ohne da jemand etwas bemerkt - alle von Alice an Blake geschickten Nachrichten mitlesen. Eine gute Schl sselverwaltung ist entscheidend f r die Integrit t Ihrer eigenen Schl sselbunde, wie auch der Schl sselbunde anderer Benutzer. Der Kern der Schl sselverwaltung von GnuPG ist das Signieren von Schl sseln und verfolgt zwei Hauptzwecke: es erlaubt Ihnen, Verf lschungen an Ihrem Schl sselbund zu entdecken, und es erm glicht Ihnen, die Zugeh rigkeit eines Schl ssels zu der von der jeweiligen Benutzer-ID genannten Person zu berpr fen. Schl sselunterschriften werden in einem Web of Trust genannten Schema benutzt, um die Authentisierung auch auf Schl ssel auszudehnen, die nicht direkt von Ihnen selbst, sondern von anderen Personen, denen Sie zutrauen, Schl ssel nur nach sorgf ltiger Pr fung zu signieren, signiert worden sind. Durch eine gewissenhafte Schl sselverwaltung k nnen Sie Schl sselverf lschungen als einen praktischen Angriff auf ihre sichere und vertrauliche Kommunikation abwehren. ------------------------------------------------------------------------------- Verwaltung Ihres Schl sselpaares Ein Schl sselpaar besteht aus einem ffentlichen und einem geheimen Schl ssel und einem Satz von Benutzer-IDs, um die Schl ssel einer realen Person zuzuordnen. Jeder dieser Bestandteile enth lt Informationen ber sich selbst. Bei einem ffentlichen Schl ssel sind dies seine ID sowie Angaben dar ber, wann er erzeugt worden ist, wann seine G ltigkeit abl uft usw. Bei der Benutzer-ID sind das der Name der realen Person, die durch die ID identifiziert wird, eine optionale Bemerkung sowie eine E-mail-Adresse. Der geheime Schl ssel enth lt dagegen keine Informationen ber die Benutzer-ID. Wenn Sie Informationen ber ein Schl sselpaar sehen m chten, dann rufen Sie am besten mit der Kommandozeilen-Option --edit-key den Schl sseleditor auf. Zum Beispiel: chloe$ gpg --edit-key chloe@cyb.org Geheimer Schl ssel ist vorhanden. pub 1024D/1B087D04 created: 2000-06-07 expires: never trust: -/u sub 2048g/6A3E902A created: 2000-06-07 expires: never sub 1792G/7D5D4DAE created: 2000-06-07 expires: 2002-06-07 sub 960D/C0A27DBE created: 2000-06-07 expires: 2002-06-07 (1) Chloe (Journalistin) (2) Chloe (Freie Autorin) Befehl> Zusammen mit dem ffentlichen Schl ssel wird angezeigt, ob der geheime Schl ssel verf gbar ist oder nicht. Alle Informationen ber die Bestandteile des ffentlichen Schl ssels werden dann aufgelistet. Die erste Spalte gibt den Typ des Schl ssels an. Das Schl sselwort pub identifiziert den ffentlichen Hauptschl ssel und das Schl sselwort sub identifiziert einen untergeordneten ffentlichen Schl ssel (Subkey). Die zweite Spalte gibt L nge, Typ und ID des Schl ssels an. Dabei steht D f r DSA-Schl ssel, g f r einen nur zur Verschl sselung geeigneten ElGamal-Schl ssel und G f r einen ElGamal-Schl ssel, der sowohl zur Verschl sselung als auch zum Unterschreiben verwendet werden kann. Das Datum der Erzeugung und das Verfallsdatum wird in den Spalten drei und vier angegeben. Die Benutzer-IDs werden nach den Schl sseln angegeben. Es stehen noch weitere Befehle zu Verf gung, um zus tzliche Informationen ber die Schl ssel zu erhalten. Der Befehl toggle schaltet zwischen den ffentlichen und den geheimen Komponenten eines Schl sselpaares um, wenn tats chlich beides zur Verf gung steht. Befehl> toggle sec 1024D/1B087D04 created: 2000-06-07 expires: never sbb 2048g/6A3E902A created: 2000-06-07 expires: never sbb 1792G/7D5D4DAE created: 2000-06-07 expires: 2002-06-07 sbb 960D/C0A27DBE created: 2000-06-07 expires: 2002-06-07 (1) Chloe (Journalistin) (2) Chloe (Freie Autorin) Die Information ist hnlich der Auflistung f r die Komponente des ffentlichen Schl ssels. Das Schl sselwort sec identifiziert den geheimen Hauptschl ssel und das Schl sselwort ssb identifiziert die geheimen Subkeys. Die Benutzer-IDs vom ffentlichen Schl ssel werden der Bequemlichkeit halber auch aufgelistet. ------------------------------------------------------------------------------- Schl ssel-Integrit t Wenn Sie Ihren ffentlichen Schl ssel weitergeben, so geben Sie damit die ffentlichen Komponenten Ihres Hauptschl ssels und Ihrer Subkeys ebenso wie Ihre Benutzer-IDs weiter. Wenn Sie diese Informationen jedoch ungesch tzt weitergeben, so besteht ein Sicherheitsrisiko, da es f r einen potentiellen Angreifer m glich ist, den Schl ssel zu verf lschen. Der ffentliche Schl ssel kann durch Hinzuf gen oder Ersetzen von Schl sseln oder von Benutzer-IDs modifiziert werden. Der Angreifer k nnte beispielsweise durch Verf lschen der E-Mail-Adresse einer Benutzer-ID die E-Mail an sich selbst umleiten. Durch Ver nderung der ffentlichen Schl ssel w re der Angreifer auch in der Lage, die zu ihm umgeleiteten Nachrichten zu entschl sseln. Die Benutzung digitaler Signaturen ist die L sung f r dieses Problem. Indem man den ffentlichen Schl ssel sowie die Benutzer-IDs mit seinem geheimen Schl ssel unterzeichnet, lassen sich Verf lschungen daran leicht feststellen. Dieser Vorgang wird Eigenbeglaubigung genannt; ein ffentlicher Schl ssel, der eigenbeglaubigte Benutzer-IDs enth lt, wird Zertifikat genannt. Ein Beispiel: Chloe hat zwei Benutzer-IDs und drei untergeordnete ffentliche Schl ssel bzw. Subkeys. Die Unterschriften auf den Benutzer-IDs k nnen mit dem Befehl check im Schl sseleditior gepr ft werden. chloe$ gpg --edit-key chloe geheimer Schl ssel ist vorhanden. pub 1024D/1B087D04 created: 2000-06-07 expires: never trust: -/u sub 2048g/6A3E902A created: 2000-06-07 expires: never sub 1792G/7D5D4DAE created: 2000-06-07 expires: 2002-06-07 sub 960D/C0A27DBE created: 2000-06-07 expires: 2002-06-07 (1) Chloe (Journalistin) (2) Chloe (Freie Autorin) Befehl> check uid Chloe (Journalistin) sig! 1B087D04 2000-06-07 [Eigenbeglaubigung] uid Chloe (Freie Autorin) sig! 1B087D04 2000-06-07 [Eigenbeglaubigung] Wie erwartet, wird f r jede Unterschrift der prim re Schl ssel mit der Schl ssel-ID 0x26B6AAE1 genommen. Die Eigenbeglaubigungen auf den Subkeys sind in dem ffentlichen Schl ssel enthalten, doch werden sie vom Schl sseleditor nicht gezeigt. ------------------------------------------------------------------------------- Editieren von Schl sseln Zu Ihrem urspr nglichen Schl sselpaar k nnen Sie sp ter sowohl neue Subkeys als auch neue Benutzer-IDs hinzuf gen. Eine neue Benutzer-ID wird durch Verwendung des Befehls adduid erzeugt. Dabei werden Sie wieder nach Ihrem wirklichem Namen, E-Mail-Adresse und einer optionalen Bemerkung gefragt. Ein Subkey wird durch Verwendung des Befehls addkey hinzugef gt und kann von beliebigem Typ sein. Das ist so hnlich, wie Sie es vom Erzeugen Ihres anf nglichen Schl sselpaares kennen. Wenn Sie einen neuen Subkey oder eine neue Benutzer-ID erzeugen, so werden diese mit Ihrem geheimen Schl ssel eigenbeglaubigt; deshalb m ssen Sie auch Ihr Mantra eingeben, wenn der Schl ssel erzeugt wird. Zus tzliche Benutzer-IDs sind n tzlich, wenn Sie f r verschiedene Zwecke verschiedene IDs ben tigen. So wollen Sie vielleicht eine Benutzer-ID f r Ihre Arbeit, eine f r Ihre politische T tigkeit und eine weitere f r private Korrespondenz haben. Ihre Mitarbeiter und Gesch ftspartner, Politische Mitstreiter und Freunde werden Sie dann jeweils unter einer anderen ID kennen. Zus tzliche Subkeys sind ebenfalls n tzlich. Die zu Ihrem prim ren ffentlichen Schl ssel geh rigen Benutzer-IDs werden von den Leuten, mit denen Sie kommunizieren, authentisiert, deshalb erfordert eine nderung des prim ren Schl ssels eine nochmalige Best tigung. Wenn Sie mit vielen Leuten kommunizieren, kann dies schwierig und zeitaufwendig sein. Andererseits ist es gut, von Zeit zu Zeit die Subkeys f r die Verschl sselung zu ndern. Wenn ein Schl ssel kompromittiert wurde, ist die Sicherheit aller mit diesem Schl ssel verschl sselten Daten gef hrdet. Durch das ndern der Schl ssel erreichen Sie jedoch, da in der Zukunft zu verschl sselnde Daten nicht auch noch gef hrdet werden. Subkeys und Benutzer-IDs k nnen auch gel scht werden. Dazu m ssen Sie diese zun chst im Schl sseleditor ausw hlen, indem Sie die Befehle key bzw. uid benutzen. So w hlt beispielsweise der Befehl key 2 den zweiten Subkey aus; ein nochmaliger Aufruf des Befehls key 2 macht diese Auswahl wieder r ckg ngig. Wird key ohne Argument aufgerufen, wird die komplette Auswahl an Subkeys wieder aufgehoben. Das gleiche gilt f r den Befehl uid. Wenn Sie die zu l schenden Benutzer-IDs ausgew hlt haben, werden diese mit dem Befehl deluid aus Ihrem Schl ssel entfernt. Ebenso l scht der Befehl delkey alle ausgew hlten Subkeys aus Ihren ffentlichen und geheimen Schl sseln. F r die lokale Schl sselverwaltung ist das L schen von Schl ssel-Komponenten ein geeignetes Mittel, um die ffentlichen Schl ssel anderer von unn tigem Ballast frei zu halten. Hingegen sollten Sie normalerweise keine Benutzer-IDs und Subkeys von Ihrem eigenen Schl ssel entfernen, da Sie so die Weiterverbreitung dieses Schl ssels verkomplizieren. Wenn ein anderer GnuPG-Benutzer Ihren aktuellen ffentlichen Schl ssel importiert, wird dieser standardm ig mit dessen alter Kopie Ihres ffentlichen Schl ssels zusammengef hrt. Dadurch werden effektiv alle Komponenten wieder hergestellt, die Sie gel scht haben. Um den Schl ssel wirklich zu aktualisieren, m te der Benutzer zuerst die alte Version Ihres Schl ssels l schen und dann die neue Version importieren. Dies bringt eine zus tzliche Belastung f r Ihre Kommunikationspartner mit sich. Es ist daher auch keine gute Idee, Ihren aktualisierten Schl ssel zu einem Key-Server zu schicken. Zum Aktualisieren Ihres eigenen Schl ssels ist es folglich besser, die jeweiligen Schl sselkomponenten zu widerrufen, statt sie zu l schen. ------------------------------------------------------------------------------- Widerrufen von Schl ssel-Komponenten Um einen Subkey zu widerrufen, w hlen Sie ihn im Schl sseleditor aus, dann k nnen Sie ihn mit dem Befehl revkey widerrufen. Der Schl ssel wird dadurch widerrufen, da man dem Schl ssel eine Widerruf-Unterschrift hinzuf gt. Anders als bei der Kommandozeilen-Option --gen-revoke tritt der Widerruf sofort in Kraft. Befehl> key 2 pub 1024D/1B087D04 created: 2000-06-07 expires: never trust: -/u sub 2048g/6A3E902A created: 2000-06-07 expires: never sub* 1792G/7D5D4DAE created: 2000-06-07 expires: 2002-06-07 sub 960D/6E82436B created: 2000-06-07 expires: 2002-06-07 (1) Chloe (Journalistin) (2) Chloe (Freie Autorin) Befehl> revkey M chten Sie diesen Schl ssel wirklich wiederrufen? j Sie ben tigen ein Mantra, um den geheimen Schl ssel zu entsperren. Benutzer: "Chloe (Journalistin) " 1024-Bit DSA Schl ssel, ID 1B087D04, erzeugt 2000-06-07 pub 1024D/1B087D04 created: 2000-06-07 expires: never trust: -/u sub 2048g/6A3E902A created: 2000-06-07 expires: never sub 1792G/7D5D4DAE created: 2000-06-07 expires: 2002-06-07 rev! subkey has been revoked: 2000-06-07 sub 960D/6E82436B created: 2000-06-07 expires: 2002-06-07 (1) Chloe (Journalistin) (2) Chloe (Freie Autorin) Beim Widerrufen einer Benutzer-ID wird anders verfahren. Durch Unterschriften auf einer Benutzer-ID wird best tigt, da der Eigent mer des Schl ssels tats chlich identisch mit der in der Benutzer-ID genannten Person ist. In der Theorie beschreibt eine Benutzer-ID eine Person f r immer, da diese Person sich nie ndert. In der Praxis k nnen sich jedoch Elemente der Benutzer-ID, so z.B. die E-Mail-Adresse oder eine Bemerkung, mit der Zeit ver ndern und so die Benutzer-ID unbrauchbar machen. Die Spezifikation von OpenPGP unterst tzt den Widerruf einer Benutzer-ID nicht. Man kann sich aber dadurch helfen, da man seine Eigenbeglaubigung f r die entsprechende Benutzer-ID widerruft. Aus den zuvor beschriebenen Sicherheitsgr nden werden die Korrespondenzpartner keiner Benutzer-ID ohne g ltige Eigenbeglaubigung trauen, GnuPG lehnt den Import eines solchen Schl ssels sogar g nzlich ab. Eine Unterschrift wird unter Verwendung des Befehls revsig. widerrufen. Da Sie eine beliebige Zahl von Benutzer-IDs unterschrieben haben k nnen, verlangt der Schl sseleditor von Ihnen f r jede Unterschrift eine Entscheidung, ob sie widerrufen werden soll oder nicht. Befehl> revsig Befehl> revsig Sie haben folgende User-IDs beglaubigt: Chloe (Journalistin) beglaubigt durch 1B087D04 um 2000-06-07 beglaubigt durch 1B087D04 um 2000-06-07 User-ID: ``Chloe (Journalistin) '' unterschrieben mit Ihrem Schl ssel 1B087D04 um 2000-06-07 Ein Widerrufszertifikat f r diese Unterschrift erzeugen (j/N)n User-ID: ``Chloe (Freie Autorin) '' unterschrieben mit Ihrem Schl ssel 1B087D04 um 2000-06-07 Ein Widerrufszertifikat f r diese Unterschrift erzeugen (j/N)j Es werden nun folgende Beglaubigungen entfernt: Chloe (Freie Autorin) beglaubiigt durch 1B087D04 um 2000-06-07 Wirklich ein Unterschrift-Widerrufszertifikat erzeugen? (j/N) j Sie ben tigen ein Mantra, um den geheimen Schl ssel zu entsperren. Benutzer: ``Chloe (Journalistin) '' 1024-Bit DSA Schl ssel, ID 1B087D04, erzeugt 2000-06-07 pub 1024D/1B087D04 created: 2000-06-07 expires: never trust: -/u sub 2048g/6A3E902A created: 2000-06-07 expires: never sub 1792G/7D5D4DAE created: 2000-06-07 expires: 2002-06-07 rev! subkey has been revoked: 2000-06-07 sub 960D/6E82436B created: 2000-06-07 expires: 2002-06-07 (1) Chloe (Journalistin) (2) Chloe (Freie Autorin) Eine widerrufene Benutzer-ID wird durch die Widerrufs-Signatur auf der Benutzer-ID angezeigt, wenn die Unterschriften auf den Benutzer-IDs des Schl ssels aufgelistet werden. Befehl check uid Chloe (Journalistin) sig! 1B087D04 2000-06-07 [Eigenbeglaubigung] uid Chloe (Freie Autorin) rev! 1B087D04 2000-06-07 [Widerruf] sig! 1B087D04 2000-06-07 [Eigenbeglaubigung] Ein Widerruf sowohl der Subkeys als auch der Eigenbeglaubigung auf Benutzer-IDs f gt dem Schl ssel eine Widerrufs-Signatur hinzu. Da also nur etwas hinzugef gt und nichts gel scht wird, ist ein Widerruf f r andere stets sichtbar, wenn Ihr aktueller ffentlicher Schl ssel weitergegeben und mit anderen lteren Kopien davon zusammengef hrt wird. Der Widerruf garantiert deshalb, da jeder die aktuelle Kopie Ihres ffentlichen Schl ssels haben kann. ------------------------------------------------------------------------------- Aktualisieren des Verfallsdatums Das Verfallsdatum eines Schl ssels kann mit dem Befehl expire im Schl sseleditor aktualisiert werden. Wenn kein Schl ssel ausgew hlt ist, wird das Verfallsdatum des prim ren Schl ssels aktualisiert, ansonsten das des jeweils ausgew hlten Subkeys. Das Verfallsdatum eines Schl ssels ist mit der Eigenbeglaubigung des Schl ssels verbunden. Es wird dadurch aktualisiert, da man die alte Eigenbeglaubigung l scht und eine neue hinzuf gt. Da die Korrespondenzpartner die alte Eigenbeglaubigung noch nicht gel scht haben, werden sie eine zus tzliche Eigenbeglaubigung auf dem Schl ssel sehen, wenn sie ihre Kopie Ihres Schl ssels aktualisieren. Die j ngste Eigenbeglaubigung hat jedoch jeweils Vorrang, und so werden alle Korrespondenzpartner unzweideutig die Verfallsdaten Ihrer Schl ssel kennen. ------------------------------------------------------------------------------- Authentisieren anderer Schl ssel Wie in Kapitel 2 bereits bereits ausf hrlich besprochen, wird der ffentliche Schl ssel eines Korrespondenzpartners dadurch authentisiert, da Sie pers nlich den Fingerabdruck seines Schl ssels pr fen und dann seinen ffentlichen Schl ssel mit Ihrem geheimen Schl ssel unterschreiben. Durch das pers nliche Pr fen des Fingerabdrucks k nnen Sie sicher sein, da der Schl ssel wirklich ihm geh rt. Da Sie den Schl ssel unterschrieben haben, k nnen Sie sicher sein, jede Verf lschung an ihm in der Zukunft zu entdecken. Leider ist dieses Verfahren umst ndlich, wenn Sie entweder eine gro e Zahl von Schl sseln authentisieren m ssen oder wenn Sie mit Leuten kommunizieren, welche Sie nicht pers nlich kennen. GnuPG geht dieses Problem mit einem Mechanismus an, der allgemein als Web of Trust bezeichnet wird. Im Web of Trust wird die Verantwortlichkeit f r das Authentisieren ffentlicher Schl ssel an Personen bertragen, denen Sie zutrauen, bei der Authentisierung von Schl sseln die n tige Sorgfalt walten zu lassen. Nehmen Sie zum Beispiel folgendes an: * Alice hat Blakes Schl ssel unterschrieben und * Blake hat Chloes Schl ssel und Dharmas Schl ssel unterschrieben. Wenn Alice Blake hinsichtlich der ordnungsgem en Authentisierung von Schl sseln vertraut, dann kann sie davon ausgehen, da Chloes und Dharmas Schl ssel g ltig sind, ohne da sie diese pers nlich pr fen mu . Sie benutzt einfach ihre authentisierte Kopie von Blakes ffentlichem Schl ssel, um zu pr fen, da Blakes Unterschriften auf den ffentlichen Schl sseln von Chloe und Dharma echt sind. Im allgemeinen wird, wenn Alice bei allen Partnern v llig darauf vertraut, da diese die von ihnen unterschriebenen Schl ssel richtig authentisieren, auch jeder mit einem g ltigen Schl ssel unterschriebene Schl ssel als g ltig betrachtet. Der Ausgangspunkt ist Alices Schl ssel, dessen G ltigkeit vorausgesetzt wird. ------------------------------------------------------------------------------- Vertrauen in den Eigent mer eines Schl ssels Vertrauen ist in der Praxis nat rlich immer subjektiv. So ist beispielsweise Blakes Schl ssel f r Alice g ltig, da sie ihn selbst unterschrieben hat, aber vielleicht traut sie Blake kein richtiges Authentisieren der von ihm unterschriebenen Schl ssel zu. In diesem Fall k nnte sie die G ltigkeit von Chloes und Dharmas Schl ssel bezweifeln, da sich diese nur auf Blakes Unterschrift st tzt. Das Web of Trust tr gt diesem Umstand Rechnung, indem es jedem ffentlichen Schl ssel in Ihrem Schl sselbund eine Angabe dar ber zuordnet, inwieweit Sie dem Eigent mer des Schl ssels dahingehend vertrauen, da er Schl ssel erst nach gr ndlicher Pr fung authentisiert. Es gibt vier Vertrauensstufen: Unbekannt Es ist nichts ber die F higkeit des Eigent mers bekannt, Schl ssel vor dem Signieren zu authentisieren. Alle Schl ssel in Ihrem ffentlichen Schl sselbund, die Ihnen nicht geh ren, fallen zun chst unter diese Vertrauensstufe. Kein Vertrauen Der Eigent mer ist daf r bekannt, andere Schl ssel nicht korrekt zu unterschreiben. Teilweises Vertrauen Der Eigent mer versteht die Implikationen des Unterschreibens von Schl sseln und authentisiert Schl ssel richtig, bevor er sie unterschreibt. Volles Vertrauen Der Eigent mer hat ein ausgezeichnetes Verst ndnis hinsichtlich des Unterschreibens von Schl sseln, und seine Unterschrift auf einem Schl ssel w re so gut wie Ihre eigene. Das Vertrauensma eines Schl ssels ist etwas, das Sie alleine dem Schl ssel zuordnen, und es wird als private Information betrachtet. Es wird nicht mit dem Schl ssel verpackt, wenn dieser exportiert wird; es wird sogar getrennt von Ihren Schl sselbunden in einer gesonderten Trustdatenbank (trustdb.gpg) gespeichert. Der GnuPG-Schl sseleditor kann benutzt werden, um das Ma Ihres Vertrauens in den Eigent mer eines Schl ssels anzugeben. Der Befehl lautet trust (Andererseits fragt GnuPG auch nach, wenn es die Information braucht und noch kein Vertrauensma angegeben wurde). In diesem Beispiel gibt Alice das Ma ihres Vertrauens zu Blake an und aktualisiert dann entsprechend die Trustdatenbank, um neu zu ermitteln, welche Schl ssel auf der Basis ihrer neuen Einstufung von Blake g ltig sind. alice$ gpg --edit-key blake pub 1024D/B2690E6F created: 2000-06-06 expires: never trust: -/f sub 1024g/F251B862 created: 2000-06-06 expires: never (1) Blake (Staatsanwalt) Befehl> trust pub 1024D/B2690E6F created: 2000-06-06 expires: never trust: -/f sub 1024g/F251B862 created: 2000-06-06 expires: never (1) Blake (Staatsanwalt) Bitte entscheiden Sie, inwieweit Sie diesem User zutrauen, den Schl ssel eines anderen Users korrekt zu pr fen (Vergleich mit Lichtbildausweisen, Vergleich der Fingerabdr cke aus unterschiedlichen Quellen ...)? 1 = Wei nicht so recht 2 = Kein Vertrauen 3 = Ich vertraue ihm normalerweise 4 = Ich vertraue ihm vollst ndig s = Bitte weitere Informationen anzeigen m = Zur ck zum Men Ihre Auswahl? 3 pub 1024D/B2690E6F created: 2000-06-06 expires: never trust: m/f sub 1024g/F251B862 created: 2000-06-06 expires: never (1) Blake (Staatsanwalt) Befehl> quit Das Vertrauen [7] in den Schl ssel-Eigent mer und in die G ltigkeit des Schl ssels wird rechts neben dem Schl ssel angezeigt. An erster Stelle wird das Vertrauen in den Eigent mer angezeigt, dann das Vertrauen in die G ltigkeit des Schl ssels. Die vier Vertrauensstufen werden folgenderma en abgek rzt: * Unbekannt (q), * kein Vertrauen (n), * teilweises Vertrauen (m) und * volles Vertrauen (f) In diesem Fall ist Blakes Schl ssel voll g ltig, da Alice ihn selbst unterschrieben hat. Anfangs fallen Blakes Schl ssel f r sie unter die Vertrauensstufe ``Unbekannt'', doch sie entscheidet sich daf r, ihn unter ``Teilweises Vertrauen`` einzustufen. ------------------------------------------------------------------------------- Authentisieren von Schl sseln im Web of Trust Das Web of Trust ist ein flexibleres und komfortableres Verfahren zur Authentisierung eines Schl ssels. Fr her wurde ein Schl ssel nur dann als g ltig betrachtet, wenn er von Ihnen pers nlich unterzeichnet war. Nach diesem Verfahren wird jetzt auch ein Schl ssel K als g ltig betrachtet, wenn er die folgenden zwei Bedingungen erf llt: 1. Schl ssel K ist von gen gend g ltigen Schl sseln unterschrieben, das hei t, da er entweder + von Ihnen pers nlich oder + von einem Schl ssel vollen Vertrauens oder + von drei Schl sseln teilweisen Vertrauens unterschrieben wurde. 2. Der Pfad unterschriebener Schl ssel, der vom Schl ssel K zur ck zu Ihrem eigenen Schl ssel f hrt, besteht aus maximal f nf Schritten. Die Pfadl nge, die Anzahl der erforderlichen Schl ssel Ihres teilweisen Vertrauens und die erforderliche Anzahl der Schl ssel Ihres vollen Vertrauens k nnen Ihrer jeweiligen Vertrauensstufe angepa t werden. Die oben angegebenen Zahlen sind die von GnuPG benutzten Standardwerte. Abbildung 3-1 zeigt ein Web of Trust, das seinen Ausgangspunkt bei Alice hat. Das Diagramm zeigt anschaulich, wer wessen Schl ssel unterschrieben hat und welche Schl ssel Alice aufgrund ihres Vertrauens in die anderen Mitglieder des Web of Trust als g ltig betrachtet. In diesem Beispiel wird angenommen, da zwei Schl ssel teilweisen Vertrauens oder ein Schl ssel vollen Vertrauens ben tigt werden, um einen anderen Schl ssel zu authentisieren. Die maximale Pfadl nge betr gt drei Schritte. Abbildung 3-1. Ein hypothetisches Vertrauensnetz [signatures] +-----------------------------------------------------------------------------+ | Vertrauen | G ltigkeit | |------------------------------------+----------------------------------------| | teilweise | v llig | teilweise | v llig | |------------------+-----------------+-------------+--------------------------| | |Dharma | |Blake, Chloe, Dharma, | | | | |Francis | |------------------+-----------------+-------------+--------------------------| |Blake, Dharma | |Francis |Blake, Chloe, Dharma | |------------------+-----------------+-------------+--------------------------| |Chloe, Dharma | |Chloe, |Blake, Dharma | | | |Francis | | |------------------+-----------------+-------------+--------------------------| |Blake, Chloe, | |Elena |Blake, Chloe, Dharma, | |Dharma | | |Francis | |------------------+-----------------+-------------+--------------------------| | |Blake, Chloe, | |Blake, Chloe, Elena, | | |Elena | |Francis | +-----------------------------------------------------------------------------+ Beim Berechnen der g ltigen Schl ssel in dem Beispiel gilt folgendes: Blakes und Dharmas Schl ssel werden immer als voll g ltig betrachtet, da sie direkt von Alice unterschrieben worden sind. Die G ltigkeit der anderen Schl ssel h ngt vom Vertrauen ab. Im ersten Fall genie t Dharma volles Vertrauen, woraufhin die Schl ssel von Chloe und Francis als g ltig betrachtet werden. Im zweiten Beispiel genie en Blake und Dharma nur teilweises Vertrauen. Da nun zwei Schl ssel teilweisen Vertrauens n tig sind, um einen Schl ssel voll zu authentisieren, wird der Schl ssel von Chloe als voll g ltig, der von Francis aber nur als teilweise g ltig betrachtet. Falls Chloe und Dharma nur teilweises Vertrauen genie en, wird Chloes Schl ssel nur teilweise g ltig sein, w hend Dharmas Schl ssel voll g ltig ist. Der Schl ssel von Francis jedoch wird ebenfalls nur als teilweise g ltig betrachtet, da nur ein voll g ltiger Schl ssel zur Authentisierung anderer Schl ssel benutzt werden kann, und Dharmas Schl ssel der einzige voll g ltige Schl ssel ist, der zum Unterschreiben des Schl ssels von Francis benutzt worden ist. Wenn teilweises Vertrauen in Blakes Schl ssel hinzukommt, kann Chloes Schl ssel voll g ltig werden und kann dann zur vollen Authentisierung des Schl ssels von Francis und zur teilweisen Authentisierung des Schl ssels von Elena benutzt werden. Wenn schlie lich Blake, Chloe und Elena volles Vertrauen genie en, reicht dies noch nicht aus, um den Schl ssel von Geoff zu authentisieren, da die maximal zul ssige L nge des Zertifizierungspfades aus drei Schritten bestehen soll, die Pfadl nge von Geoff zur ck zu Alice jedoch vier Schritte betr gt. Das Web of Trust erm glicht es Ihnen, GnuPG genau Ihren Vorstellungen von Sicherheit anzupassen. Sie k nnten beispielsweise auf mehreren kurzen Pfaden von Ihrem Schl ssel aus zu einem anderen Schl ssel K bestehen, um diesem zu vertrauen. Vielleicht entscheiden Sie sich aber auch f r l ngere Pfade oder sogar nur einen Pfad von Ihrem Schl ssel zu dem anderen Schl ssel K. Wenn Sie mehrfache kurze Pfade voraussetzen, so ist das eine starke Garantie daf r, da Schl ssel K demjenigen geh rt, von dem Sie dies annehmen. Der Preis daf r ist nat rlich, da die Authentisierung von Schl sseln schwieriger ist, da Sie pers nlich mehr Schl ssel unterschreiben m ssen, als wenn Sie weniger und daf r l ngere Pfade akzeptieren. ------------------------------------------------------------------------------- Weitergabe von Schl sseln Im Idealfall wird ein Schl ssel durch pers nliche bergabe an Ihre Korrespondenzpartner weitergegeben. In der Praxis werden jedoch Schl ssel oft per E-Mail oder irgendein anderes elektronisches Kommunikationsmittel weitergegeben. Die Weitergabe per E-Mail ist durchaus annehmbar, wenn Sie nur einige wenige Korrespondenzpartner haben. Wenn Sie viele Korrespondenzpartner haben, k nnten Sie beispielsweise Ihre(n) ffentlichen Schl ssel auf Ihrer Homepage im Web publizieren. Das setzt jedoch voraus, da Ihre Korrespondenzpartner auch wissen, wo sie Ihre(n) Schl ssel finden k nnen. Um dieses Problem zu l sen, gibt es Key-Server, die ffentliche Schl ssel sammeln und weitergeben. Ein bei dem Server eingegangener ffentlicher Schl ssel wird entweder der Datenbank des Servers hinzugef gt oder mit Ihrem eventuell schon vorhandenen Schl ssel zusammengef hrt. Wenn eine Anfrage nach einem Schl ssel beim Server eingeht, durchsucht dieser seine Datenbank und sendet den angeforderten ffentlichen Schl ssel zur ck, wenn er ihn gefunden hat. Ein Schl ssel-Server ist auch sinnvoll, wenn viele Leute h ufig die Schl ssel anderer Leute unterschreiben. Ohne einen Schl ssel-Server w rde Blake, wenn er Alices Schl ssel unterschreibt, an Alice eine Kopie ihres von ihm unterschriebenen Schl ssels schicken, so da Alice den so aktualisierten Schl ssel ihrem Schl sselbund hinzuf gen und ihn auch an alle ihre Korrespondenzpartner weitergeben k nnte. Mit dieser M he gen gen Alice und Blake weitgehend ihrer Verantwortung gegen ber der Allgemeinheit durch den Aufbau engmaschiger Vertrauensnetze und helfen so, die Sicherheit von GPG zu verbessern. Dies ist jedoch sehr l stig, wenn das Unterschreiben von Schl sseln h ufig vorkommt. Durch die Benutzung eines Schl ssel-Servers wird das etwas leichter. Wenn nun Blake Alices Schl ssel unterschreibt, so schickt er den unterschriebenen Schl ssel an den Schl ssel-Server, welcher dann Blakes Unterschrift seiner Kopie von Alices Schl ssel hinzuf gt. Personen, die daran interessiert sind, ihre Kopie von Alices Schl ssel zu aktualisieren, wenden sich dann selbst ndig an den Schl ssel-Server, um sich den aktualisierten Schl ssel zu holen. Alice braucht sich mit der Weitergabe berhaupt nicht zu befassen und kann Unterschriften auf ihrem Schl ssel wie jeder andere auch einfach durch Anfrage bei einem Schl ssel-Server holen. Ein oder mehr Schl ssel k nnen unter Verwendung der Kommandozeilen-Option --send-keys an den Key-Server geschickt werden. Die Option erwartet eine Schl ssel-ID oder Benutzer-ID als Argument und schickt die so spezifizierten Schl ssel an den Key-Server. Der Key-Server, an den die Schl ssel geschickt werden sollen, wird durch die Kommandozeilen-Option --keyserver spezifiziert. In hnlicher Weise wird die Option --recv-keys benutzt, um Schl ssel von einem Key-Server zu holen, doch m ssen Sie hier den Schl ssel mit einer Schl ssel-ID spezifizieren. Im folgenden Beispiel aktualisiert Alice ihren ffentlichen Schl ssel mit neuen Unterschriften vom Key-Server blackhole.pca.dfn.de und schickt dann ihre Kopie von Blakes ffentlichem Schl ssel ebenfalls dorthin, um alle neuen Unterschriften, die sie hinzugef gt hat, weiterzugeben. alice$ gpg --keyserver wwwkeys.de.pgp.net --recv-key FB5797A9 gpg: Schl ssels FB5797A9 von wwwkeys.de.pgp.net wird angefordert ... gpg: Schl ssel FB5797A9: 1 neue Signatur gpg: Anzahl insgesamt bearbeiteter Schl ssel: 1 gpg: neue Signaturen: 1 alice$ gpg --keyserver wwwkeys.de.pgp.net --send-key blake@cyb.org gpg: Senden an `wwwkeys.de.pgp.net' erfolgreich (status=200) Weltweit gibt es eine Vielzahl bekannter Key-Server. Die gr eren Key-Server synchronisieren sich wechselseitig. Am Besten benutzen Sie einen gut erreichbaren Key-Server im Internet und tauschen dann regelm ig ber diesen Schl ssel aus. Eine kleine Auswahl g ngiger Key-Server finden Sie im Anhang B des Buches. ------------------------------------------------------------------------------- Kapitel 4. GnuPG im Alltagsgebrauch GnuPG ist nicht nur eine komplexe Software, sondern es gibt auch einige technische, gesellschaftliche und rechtliche Aspekte, die ber cksichtigt werden sollten: * Technisch mu es verschiedenen Situationen mit drastisch unterschiedlichen Sicherheitsanforderungen gerecht werden, was die Schl sselverwaltung kompliziert. * Die Benutzung von GnuPG ist nicht unbedingt eine rein pers nliche Entscheidung. Um GnuPG effektiv nutzen zu k nnen, m ssen beide miteinander kommunizierenden Seiten es benutzen. * Die Haltung der Gesetzgeber zur elektronischen Verschl sselung und zu digitalen Signaturen unterscheidet sich von Land zu Land. Insbesondere die Frage einer legalen Benutzung von GnuPG bzw. Verschl sselung im allgemeinen steht gegenw rtig bei vielen nationalen Regierungen zur Debatte. Auf diese Aspekte wollen wir im folgenden eingehen. ------------------------------------------------------------------------------- Definition Ihres Sicherheitsbedarfs Einer der wichtigsten Gr nde, GnuPG zu benutzen, ist der Schutz Ihrer Privatsph re. Das bedeutet, da Sie mit anderen korrespondieren k nnen, ohne da Dritte die M glichkeit haben, mitzulesen, und da Sie vertrauliche Daten auf Ihrem Rechner dem unbefugten Zugriff anderer entziehen k nnen. Ebenso gibt Ihnen GnuPG die M glichkeit, Ihre Daten (E-Mail) durch digitale Signaturen zu authentifizieren und deren Integrit t zu sichern. Wie Sie GnuPG benutzen, sollte von der Zielstrebigkeit und Findigkeit derer abh ngen, die unerlaubt Ihre verschl sselten Nachrichten mitlesen wollen. Ein solcher ``Lauscher'' kann ein neugieriger Systemadministrator sein, der Ihre E-Mails mitliest, es k nnte ein Industriespion sein, der versucht, Ihre Firmengeheimnisse auszusp hen, oder es k nnte die Staatsanwaltschaft sein, die Ihnen auf den Fersen ist. Wenn Sie GnuPG benutzen, um mehr oder weniger zuf lliges Mitlesen zu verhindern, wird das wahrscheinlich anders aussehen, als wenn Sie Ihre Daten gegen einen entschlossenen Angreifer sch tzen wollen. Tipp: Ihr Ziel sollte es dabei sein, da der Aufwand zur Entschl sselung Ihrer Daten so gro wird, da der Wert der Daten diesen Aufwand nicht mehr rechtfertigt. Wenn Sie GnuPG auf Ihren pers nlichen Gebrauch abstimmen m chten, sind vor allem vier Punkte wichtig: 1. Die Wahl der Schl ssell nge Ihres ffentlichen und privaten Schl sselpaars 2. Der Schutz Ihres geheimen Schl ssels 3. Die Verfallsdaten Ihrer Schl ssel und die Benutzung von Unterschl sseln 4. Der Aufbau Ihres Web of Trust Eine gut gew hlte Schl ssell nge sch tzt Sie gegen Brute-Force-Angriffe auf verschl sselte Daten. Der Schutz Ihres privaten Schl ssels hindert einen Angreifer daran, einfach Ihren privaten Schl ssel zum Entschl sseln von verschl sselten Nachrichten zu verwenden und Nachrichten in Ihrem Namen zu unterschreiben. Ein sorgf ltig aufgebautes Web of Trust verhindert, da ein Unbefugter sich als einer Ihrer Korrespondenzpartner ausgeben kann. Wichtig ist die Frage, welchen Aufwand Sie entsprechend Ihren Sicherheitsanforderungen betreiben m chten, um Ihre Privatsph re oder Ihre Firmendaten zu sch tzen. ------------------------------------------------------------------------------- Die Wahl der Schl ssell nge Die Wahl der Schl ssell nge h ngt von der Art des jeweiligen Schl ssels ab. Bei OpenPGP besteht ein Schl sselbund gew hnlich aus mehreren ffentlichen und geheimen Schl sseln. Es sollte zumindest einen Hauptschl ssel zum Signieren und einen oder eventuell mehrere zus tzliche Unterschl ssel f r die Verschl sselung geben. Wenn man die Standardeinstellungen von GnuPG bei der Schl sselerzeugung verwendet, ist der Hauptschl ssel ein DSA-Schl ssel, die Unterschl ssel sind ElGamal-Schl ssel. DSA erlaubt eine Schl ssell nge bis zu 1024 Bit. Das ist angesichts der heutigen Rechenleistungen nicht besonders lang, entspricht jedoch dem Standard. Warum das so ist und warum ein DSA-Schl ssel mit 1024 Bit zur Benutzung sogar empfohlen wird, geht aus dem folgenden Absatz hervor. ElGamal-Schl ssel andererseits k nnen beliebig lang sein. GnuPG ist ein hybrides Verschl sselungsverfahren mit ffentlichem Schl ssel. Der ffentliche Schl ssel wird zum Verschl sseln eines 128-Bit-Sitzungsschl ssels benutzt, und der private Schl ssel wird zu dessen Entschl sselung verwendet. Allerdings beeinflu t die Schl ssell nge die Ver- und Entschl sselungsgeschwindigkeit erheblich, da der Rechenaufwand bei diesen Algorithmen exponentiell mit der L nge des Schl ssels steigt. Au erdem ist der praktische Nutzen eines gro en Schl ssels trotz seiner gr eren Sicherheit durchaus zweifelhaft. Wenn der Schl ssel lang genug ist, um einem Brute-Force-Angriff zu widerstehen, wird der Angreifer wahrscheinlich zu einer anderen Methode greifen, um an Ihre unverschl sselten Daten zu gelangen. Es k nnte ihm leichter fallen, in Ihre Wohnung oder Ihr B ro einzudringen oder Sie m glicherweise sogar zu berfallen. 1024 Bit sind alles in allem eine zu empfehlende Schl ssell nge. Wenn Sie wirklich einen l ngeren Schl ssel brauchen, dann sollten Sie ohnehin einen Fachmann in Sachen Datensicherheit konsultieren. ------------------------------------------------------------------------------- Der Schutz Ihres geheimen Schl ssels Das Allerwichtigste bei der Benutzung von GnuPG ist der Schutz Ihres geheimen Schl ssels. Wenn jemand Ihren geheimen Schl ssel in die Hand bekommt, dann kann er damit alle f r diesen Schl ssel verschl sselten Daten entschl sseln, und er kann digitale Unterschriften in Ihrem Namen leisten. Wenn Sie Ihren geheimen Schl ssel verlieren, sind Sie nicht l nger imstande, Daten zu entschl sseln, die f r Sie verschl sselt worden sind, und Sie k nnen keine Unterschriften mehr leisten. Den geheimen Schl ssels zu verlieren, ist eine Katastrophe f r Ihre Datensicherheit. Egal, wie Sie GnuPG benutzen, Sie sollten die Widerrufurkunde des ffentlichen Schl ssels und eine Sicherheitskopie Ihres geheimen Schl ssels auf einem schreibgesch tzten Datentr ger - beispielsweise einer CD-ROM oder Diskette - speichern und an einem sicheren Ort aufbewahren, z. B. in einem Bankschlie fach oder gut versteckt in Ihrer Wohnung. Um eventuellen Datentr gerdefekten vorzubeugen, sollten Sie vielleicht auch jeweils einen ASCII-Ausdruck (*** gpg --armor) auf Papier aufbewahren. Was immer Sie tun, die Widerrufurkunde und die Sicherheitskopie Ihres geheimen Schl ssels sollten auf Datentr ger gebracht werden, die eine sichere Aufbewahrung so lange erm glichen, wie Sie Ihren Schl ssel voraussichtlich behalten werden, und Sie sollten diese sorgf ltiger aufbewahren als die Kopie Ihres t glich benutzten geheimen Schl ssels. Als weitere Sicherheitsma nahme speichert GnuPG Ihren privaten Schl ssel nicht in ``roher'' Form ab, sondern verschl sselt ihn stattdessen unter Benutzung eines symmetrischen Verschl sselungsverfahrens. Deshalb brauchen Sie das ``Mantra'', um mit Ihrem geheimen Schl ssel zu entschl sseln oder zu signieren. Somit m te ein Angreifer gleich zwei Probleme l sen, um Zugang zu Ihrem geheimen Schl ssel zu bekommen: 1. Er m te tats chlich den Schl ssel in die Hand bekommen. 2. Er m te entweder dessen Verschl sselung knacken oder an das Mantra kommen. Die sichere Aufbewahrung Ihres geheimen Schl ssels ist wichtig, doch auch mit einigem Aufwand verbunden. Im Idealfall w rden Sie den geheimen Schl ssel auf einem mobilen, schreibgesch tzten Datentr ger, wie z. B. einer Diskette, speichern und ihn auf einem nicht vernetzten Computer benutzen, zu dem nur Sie Zugang haben. Vielleicht ist das f r Sie zu unbequem oder unm glich. Vielleicht besitzen Sie auch keinen eigenen Computer und haben nur am Arbeitsplatz oder in der Schule Zugang zu einem Computer. Das hei t aber nicht, da Sie nun GnuPG nicht benutzen k nnen oder sollten. Sie haben sich nur entschieden, da Ihnen Ihre Daten zwar wichtig genug sind, um sie zu verschl sseln, aber nicht so wichtig, da Sie besondere Ma nahmen treffen m ten, um die erste Barriere sicherer zu machen. Es ist letztlich Ihre Entscheidung, ob Ihr Sicherheitsanspruch damit schon erf llt ist oder nicht. Absolut unerl lich ist ein gutes Mantra, wenn Sie GnuPG benutzen. Jeder Angreifer, der Zugang zu Ihrem geheimen Schl ssel bekommt, mu dann noch die Verschl sselung Ihres geheimen Schl ssels knacken. Es ist so gut wie sicher, da ein Angreifer versuchen wird, das Mantra zu erraten, anstatt mit einem Brute-Force-Angriff den Schl ssel selbst herauszufinden. Es ist nicht gerade leicht, sich eine ausreichend gro e Zahl von unzusammenh ngenden Zeichen zu merken. Deshalb ist die Versuchung sehr gro , ein Mantra zu w hlen, das leichter zu erraten ist als ein nach dem Zufallsprinzip erstellter 128-Bit-Schl ssel, und die meisten Leute erliegen dieser Versuchung, soda es f r einen Lauscher besonders verlockend ist, zu versuchen, das Mantra zu erraten. Aber wenn Sie sich wirklich im klaren dar ber sind, da Sie eine Verschl sselung schlie lich deshalb benutzen, weil Sie verhindern m chten, da man Ihre Daten mitlesen kann, dann werden Sie dieser Versuchung nicht erliegen und die notwendige M he auf sich nehmen. Wenn das Mantra aus einem normalen Wort besteht, dann ist es ein leichtes, alle W rter in den W rterb chern s mtlicher Sprachen der Welt auszuprobieren. Selbst wenn die Reihenfolge der Buchstaben oder Zeichen innerhalb des Wortes ver ndert worden ist, ist es immer noch leicht, W rter aus dem W rterbuch mit einem Katalog von Permutationen auszuprobieren. Dasselbe Problem stellt sich bei Zitaten. Im Allgemeinen sind Mantras, die auf u erungen der nat rlichen Sprache beruhen, schlechte Mantras, da ihre Zuf lligkeit gering ist und da es in der nat rlichen Sprache eine Menge Redundanz gibt. Sie sollten Mantras aus der nat rlichen Sprache tunlichst vermeiden. Ein gutes Mantra ist eines, das nur sehr schwer zu erraten ist, obwohl Sie es sich gut merken k nnen. Es sollte Zeichen aus der ganzen Reihe der druckbaren Zeichen auf Ihrer gesamten Tastatur enthalten. Dazu geh ren auch Gro buchstaben, Ziffern und Sonderzeichen wie beispielsweise }, # oder ^. Tipp: Seien Sie kreativ und nehmen Sie sich ein wenig Zeit bei der Wahl Ihres Mantras! Eine gutes Mantra ist wichtig f r die Sicherheit Ihrer Daten und somit auch Ihrer Privatsph re oder Firmengeheimnisse! ------------------------------------------------------------------------------- Ausw hlen der Verfallsdaten und Benutzung von Unterschl sseln Wenn Sie ein neues Schl sselpaar erzeugen, werden standardm ig ein DSA-Hauptschl ssel zum Unterschreiben und ein ElGamal-Unterschl ssel zum Entschl sseln erzeugt. Dies ist von Vorteil, weil die Aufgaben der beiden Schl ssel verschieden sind und es sinnvoll sein k nnte, den beiden Schl sseln verschiedene Verfallsdaten zu geben. Der DSA-Hauptschl ssel wird benutzt, um digitale Unterschriften zu leisten, und er best tigt Ihre Identit t dadurch, da andere ihn signiert haben. Der ElGamal-Unterschl ssel wird nur benutzt, um an Sie geschickte verschl sselte Daten zu entschl sseln. Typischerweise sollte eine digitale Signatur eine lange oder unbegrenzte G ltigkeitsdauer haben; Sie wollen ja auch die Unterschriften auf Ihrem Schl ssel, die Sie m hsam zusammengetragen haben, nicht verlieren. Andererseits sollte der ElGamal-Unterschl ssel in gewissen Zeitabst nden gewechselt werden, um Ihre Datensicherheit zu erh hen, da ein Angreifer, wenn der ElGamal-Unterschl ssel geknackt ist, alle Dokumente lesen kann, die f r diesen Schl ssel verschl sselt worden sind oder es noch werden. In der Regel sollten Sie also eine unbeschr nkte G ltigkeitsdauer f r den DSA-Hauptschl ssel w hlen. Es gibt jedoch Gr nde, weshalb Sie vielleicht doch ein Verfallsdatum f r Ihren Hauptschl ssel w hlen sollten. Erstens kann es sein, da Sie dem Schl ssel nur eine beschr nkte Geltungsdauer geben wollen, z. B., wenn Sie den Schl ssel f r ein zeitlich befristetes Ereignis wie etwa eine politische Kampagne benutzen wollen und danach nicht mehr. Ein weiterer Grund k nnte in einer zus tzlichen Vorsichtsma nahme bestehen: Falls der Hauptschl ssel kompromittiert wird (und Sie m glicherweise auch keine Widerrufurkunde haben), w rde ein Verfallsdatum den Schl ssel genau an diesem Datum unbrauchbar werden lassen. Tipp: Einer solchen Kompromittierung sollten Sie jedoch m glichst durch Sicherheitsvorkehrungen vorbeugen, wie in 4.1.2 beschrieben. Das Erneuern von ElGamal-Unterschl sseln ist zwar kein Problem, kann aber unbequem werden. Kurz vor dem Verfallsdatums sollten Sie einen neuen ElGamal-Unterschl ssel erzeugen und die davon abgeleiteten ffentlichen Schl ssel bekannt geben. Diejenigen, die mit Ihnen korrespondieren wollen, m ssen ja, sobald der alte Schl ssel seine G ltigkeit verliert, Ihren aktualisierten ffentlichen Schl ssel bekommen, da sie mit dem dann ung ltigen Schl ssel nicht mehr verschl sseln k nnen. Je nachdem, wie Sie die Verteilung Ihrer ffentlichen Schl ssel organisieren, kann dies eine m hsame Angelegenheit werden. Sie m ssen aber Gott sei Dank keine neuen Unterschriften einholen, um Ihren neuen Unterschl ssel zu authentisieren. Eine Unterschrift mit Ihrem authentifizierten DSA-Hauptschl ssel best tigt die Echtheit des neuen Schl ssels. Die erzielte zus tzliche Sicherheit mag diese Unbequemlichkeit wert sein oder nicht. Genauso wie Sie, kann ein erfolgreicher Angreifer immer noch alle Dokumente lesen, die mit einem verfallenen Unterschl ssel verschl sselt worden sind. Das Wechseln der Unterschl ssel sch tzt nur Dokumente, die Sie nach diesem Wechsel verschl sseln. Um die mit dem neuen Unterschl ssel verschl sselten Dokumente zu lesen, m te der Angreifer erneut in den Besitz Ihres Schl ssels und ihres Mantras kommen. Es ist auch nicht n tig, mehr als einen g ltigen Unterschl ssel in einem Schl sselbund zu haben. Man erzielt keine zus tzliche Sicherheit dadurch, da man zwei oder mehr aktive Unterschl ssel hat. Es k nnen nat rlich mehrere verfallene Schl ssel in einem Schl sselbund sein, so da in der Vergangenheit verschl sselte Dokumente noch entschl sselt werden k nnen, doch braucht nie mehr als ein Unterschl ssel aktiv zu sein. ------------------------------------------------------------------------------- Verwaltung Ihres Web of Trust Genauso wie beim Schutz Ihres geheimen Schl ssels m ssen Sie auch bei der Verwaltung Ihres Web of Trust zwischen Bequemlichkeit und Sicherheit abw gen. Wenn Sie GnuPG lediglich zum Schutz gegen mehr oder weniger zuf lliges Mitlesen und Dokumentenf lschungen benutzen, dann k nnen Sie relativ vertrauensvoll hinsichtlich der digitalen Signaturen anderer Leute sein. Wenn Sie sich allerdings Sorgen machen, da ein zu allem entschlossener Angreifer an Ihren Firmendaten oder am Eindringen in Ihre Privatsph re interessiert ist, dann sollten Sie die Unterschriften anderer sorgf ltig pr fen. Ungeachtet Ihrer eigenen Sicherheitsbed rfnisse sollten Sie jedoch beim Unterschreiben anderer Schl ssel immer Sorgfalt walten lassen. Im Sinne des Web of Trust ist es nicht ratsam, einen Schl ssel zu unterschreiben, dessen Authentizit t Sie gerade noch so weit vertrauen, wie es f r Ihr eigenes Sicherheitsbed rfnis ausreichend ist. Andere, die einen h heren Sicherheitsbedarf haben, sollten sich auf Ihre Unterschrift verlassen k nnen. Wenn man sich auf Ihre Signatur nicht verlassen kann, dann schw cht dies das Web of Trust und macht die Kommunikation f r alle Benutzer von GnuPG schwieriger. Tipp: Lassen Sie also beim Unterschreiben von Schl sseln dieselbe Sorgfalt walten, die Sie von anderen auch angewandt sehen m chten, wenn Sie sich auf deren Unterschriften verlassen. Bei der Verwaltung Ihres Web of Trust sollten Sie sich auf zwei Dinge konzentrieren: Einerseits auf die Frage, wessen Schl ssel Sie gen gend vertrauen, um sie selber zu signieren, und andererseits auf das Abstimmen der Optionen --marginals-needed und --completes-needed. Jeder Schl ssel, den Sie pers nlich signieren, wird als g ltig betrachtet, deshalb ist es - au er in kleinen Gruppen - keine gute Praxis, pers nlich den Schl ssel jeder Person zu unterschreiben, mit der Sie kommunizieren. Sinnvoller ist es, sich daran zu gew hnen, den Unterschriften anderer zu vertrauen. Es ist wahrscheinlich die beste Strategie, beim Unterzeichnen von Schl sseln genau die Authentizit t des Schl ssels bzw. die Identit t des Schl sselbesitzers zu berpr fen und ansonsten durch Optionen zu bestimmen, wie sorgf ltig GnuPG bei der Authentisierung sein soll. Ein konkretes Beispiel: Sie m gen einigen wenigen engen Freunden voll vertrauen, von denen Sie wissen, da diese beim Unterschreiben von Schl sseln sorgf ltig vorgehen; den weiteren Schl sselbesitzern in Ihrem Schl sselbund vertrauen Sie in dieser Hinsicht nur teilweise. Danach k nnen Sie --completes-needed auf 1 und --marginals-needed auf 2 setzen. Wenn Sie hinsichtlich der Sicherheit st rker besorgt sind, k nnen Sie auch die Werte 1 bzw. 3 oder 2 bzw. 3 w hlen. Wenn Sie allerdings mit einem weniger gro en Vertrauen hinsichtlich der Authentizit t auskommen wollen und nicht so sehr m gliche Angriffe auf Ihre Privatsph re oder Firmendaten bef rchten, dann k nnen Sie die Werte 1 und 1 einsetzen. Je h her die Werte f r diese Optionen sind, desto schwieriger ist es, Ihnen einen gef lschten Schl ssel unterzuschieben. ------------------------------------------------------------------------------- Aufbau Ihres Web of Trust Es reicht nicht aus, wenn nur Sie selbst GnuPG benutzen wollen. Um GnuPG zur sicheren Kommunikation mit anderen zu nutzen, m ssen Sie ein funktionierendes Web of Trust aufbauen. Auf den ersten Blick scheint dies eine m hsame Aufgabe zu sein: Die Leute, mit denen Sie kommunizieren, m ssen GnuPG [8] ebenfalls benutzen, und die Schl ssel m ssen von ausreichend vielen Personen unterschrieben sein, so da sie als authentisch zu betrachten sind. Dies sind wohlgemerkt keine technischen Schwierigkeiten, sondern soziale. Nichtsdestoweniger m ssen Sie diese Schwierigkeiten meistern, wenn Sie GnuPG benutzen wollen. Anfangs ist es noch nicht so wichtig, da Sie mit allen Korrespondenzpartnern sicher kommunizieren k nnen. Wenn Sie mit dem Gebrauch von GnuPG beginnen, suchen Sie sich einen kleinen Kreis von Leuten - Sie selbst und noch ein oder zwei andere -, die ebenfalls ihr Recht auf eine gesch tzte Privatsph re in Anspruch nehmen wollen. Unterschreiben Sie jeweils, wenn Sie sich von der Identit t der anderen Person berzeugt haben, deren ffentlichen Schl ssel und lassen Sie sich im Gegenzug Ihren Schl ssel signieren. Dieses kleine, robuste Web of Trust ist Ihr Ausgangspunkt. Sie werden dessen Wert zu sch tzen lernen und - wenn Sie Ihr Web of Trust in der Zukunft weiter ausbauen - um so gewissenhafter und vorsichtiger sein. ber Ihr anf ngliches Web of Trust hinaus m chten Sie wahrscheinlich auch mit anderen Personen sicher kommunizieren; hierbei k nnen zwei Schwierigkeiten auftreten: 1. Sie wissen nicht immer, ob Ihr Gegen ber GnuPG benutzt oder berhaupt benutzen will. 2. Selbst wenn Sie wissen, da der andere GnuPG verwendet, k nnten Sie Schwierigkeiten bei der Authentifizierung seines ffentlichen Schl ssels haben. Das erste Problem r hrt daher, da viele Leute nicht ffentlich bekanntgeben, da sie GnuPG benutzen. Am besten, Sie gehen mit gutem Beispiel voran und sorgen daf r, da jeder Ihrer potentiellen Kommunikationspartner wei , da Sie GnuPG benutzen. Hierf r gibt es mehrere M glichkeiten: * Signieren Sie Nachrichten, die Sie an Ihre Korrespondenzpartner oder Mailinglisten verschicken, mit GnuPG. * Ver ffentlichen Sie Ihren ffentlichen Schl ssel auf Ihrer Website. * Geben Sie Ihren ffentlichen Schl ssel auf einen Key-Server und ver ffentlichen Sie die Schl ssel-ID in Ihrer E-Mail-Signatur oder auf Ihrer Visitenkarte. Indem Sie Ihren Schl ssel bekannt geben, machen Sie es auch f r andere akzeptabler, ihrerseits ihre Schl ssel bekannt zu geben. Au erdem erleichtern Sie es dadurch anderen, sicher mit Ihnen zu kommunizieren, da Sie die Initiative ergriffen und deutlich gezeigt haben, da Sie GnuPG benutzen. Die Authentisierung der ffentlichen Schl ssel ist schwieriger. Wenn Sie sich nicht pers nlich von der Identit t einer Person berzeugt haben, dann d rfen Sie deren Schl ssel auch nicht unterschreiben. In diesem Fall m ssen Sie auf die Unterschriften von anderen vertrauen und hoffen, eine Kette von Unterschriften zu finden, die von dem betreffenden Schl ssel zur ck zu Ihrem eigenen f hrt. Solch eine Kette kann nur zustande kommen, wenn Sie Ihren Schl ssel von anderen au erhalb Ihres anf nglichen Web of Trust haben unterschreiben lassen. Am einfachsten ist dies auf sogenannten Key-Signing-Partys zu erreichen: Das sind Zusammenk nfte, bei denen man sich gegenseitig authentifiziert und die ffentlichen Schl ssel unterzeichnet. Sollten Sie beispielsweise zu einer Konferenz gehen, halten Sie Ausschau nach einer Key-Signing-Party. Falls dort keine stattfindet, dann laden Sie doch einfach selbst zu einer ein. Auf jeden Fall sollten Sie aber Ihren GnuPG-Fingerabdruck immer bei sich haben (vielleicht auf Ihrer Visitenkarte) so da Sie spontan mit anderen die Schl ssel tauschen k nnen. Derjenige, dem Sie den Fingerabdruck gegeben haben, k nnte dann, nachdem er Ihre Identit t berpr ft hat, bei der n chsten Gelegenheit Ihren ffentlichen Schl ssel unterschreiben. Welchen Aufwand Sie betreiben, ist letztendlich Ihre Entscheidung und h ngt allein von Ihren Sicherheitsbed rfnissen ab. Niemand ist verpflichtet, seinen Schl ssel ffentlich zu machen oder die Schl ssel anderer zu unterschreiben. Eine der St rken von GnuPG ist die Flexibilit t, mit der man die Benutzung den eigenen Anspr chen anpassen kann. Sie werden jedoch feststellen, da Sie Ihr Web of Trust ausbauen m ssen, wenn sie GnuPG f r Ihre sichere Kommunikation einsetzen m chten. ------------------------------------------------------------------------------- Kapitel 5. Kryptogesetzgebung Die gesetzlichen und politischen Rahmenbedingungen zur Benutzung von Verschl sselungs-Software sind von Land zu Land sehr unterschiedlich und stetigem Wandel unterworfen. Deshalb m chten wir hier nur kurz die rechtliche Situation in der Bundesrepublik Deutschland anrei en. Die Internetseite vonBert-Jaap Koops bietet eine ausgezeichnete `` bersicht ber die Kryptographie-Gesetzgebung'', die Sie hinsichtlich rechtlicher Fragen in den verschiedenen Staaten zu Rate ziehen sollten. F r eine Betrachtung der Kryptogesetzgebung sind vor allem folgende Punkte von Interesse: * Beschr nkungen der Benutzung kryptographischer Verfahren, * Beschr nkungen hinsichtlich der Ausfuhr von kryptographischen Produkten und * die G ltigkeit von digitalen Signaturen. ------------------------------------------------------------------------------- Benutzungsbeschr nkungen Das Grundgesetz der Bundesrepublik Deutschland garantiert in Artikel 10 Absatz 1 die Unverletzlichkeit des Post- und Fermeldegeheimnisses. Darunter f llt auch das Verbergen des Nachrichteninhalts durch kryptographische Verfahren. Einschr nkungen dieses Grundrechtes sind prinzipiell auf Grund eines Gesetzes m glich (Art. 10, Abs. 2 GG). Im Gegensatz zu vielen anderen Staaten gibt es jedoch derzeit in Deutschland keine rechtlichen Beschr nkungen hinsichtlich des Einsatzes von Verschl sselungsverfahren. Nach den vom Bundeskabinett am 2. Juni 1999 verabschiedeten ``Eckpunkten der deutschen Kryptopolitik'' spricht sich die Bundesregierung sogar deutlich f r den ``Einsatz sicherer kryptographischer Verfahren'' zum ``verbesserte[n] Schutz deutscher Nutzer in den weltweiten Informationsnetzen'' aus und will deshalb ``die Verbreitung sicherer Verschl sselung in Deutschland aktiv unterst tzen''. In diesem Zusammenhang ist auch die F rderung des GnuPG-Projektes durch das Bundesministeriums f r Wirtschaft und Technologie zu sehen. ------------------------------------------------------------------------------- Ausfuhrbeschr nkungen Das sogenannte ``Wassenaar Abkommen''stuft starke Kryptographie als Kriegswaffe ein und sieht vor, da seine 33 Mitgliedsstaaten (zu denen auch die Bundesrepublik Deutschland geh rt) die Ausfuhr von kryptographischen Produkten mit einer Schl ssell nge von mehr als 64 Bit kontrollieren. [9] Der Export kryptographischer und kryptanalytischer Technologien unterliegt zwar prinzipiell nach 7 Abs. 1, 5 Abs. 1 AWG einem Genehmigungsvorbehalt, aber kryptographische Produkte, die frei auf dem Massenmarkt erh ltlich sind, k nnen gegenw rtig ohne Genehmigung aus der Bundesrepublik ausgef hrt werden. ------------------------------------------------------------------------------- Digitale Signaturen Mit der zunehmenden Bedeutung von Online-Banking, E-Commerce und Austausch von (amtlichen) Dokumenten ber das Internet, hat auch der Gesetzgeber, hinsichtlich einer juristischen Bewertung der G ltigkeit und Anerkennung digitaler Signaturen, Handlungsbedarf erkannt. Das ``Gesetz zur digitalen Signatur (Signaturgesetz, SigG)'' vom 22. Juli 1997 legt die ``Rahmenbedingungen f r digitale Signaturen'' fest ``unter denen diese als sicher gelten und F lschungen digitaler Signaturen oder Verf lschungen von signierten Daten zuverl ssig festgestellt werden k nnen'', stellt diese allerdings nicht der gesetzlichen Schriftform gleich. Zweck des Gesetzes ist vielmehr ``durch tats chliche Sicherheit Vertrauen in die gesetzliche digitale Signatur'' zu schaffen, ``so da sie vom Rechtsverkehr akzeptiert wird und Gerichte ihr im Rahmen der freien Beweisw rdigung die n tige Beweiskraft zuerkennen k nnen''. Eine Novellierung des Signaturengesetzes steht allerdings bevor. ------------------------------------------------------------------------------- Anhang A. Ressourcen im Internet Es gibt im Internet zahlreiche Informationsquellen zu den Themen ... Weitere Informationsquellen zu den Themen GnuPG, Kryptographie, Datensicherheit, Datenschutz, Informationssicherheit finden Sie auf Webseiten und Mailinglisten im Internet. ------------------------------------------------------------------------------- GnuPG Die aktuellen Informationen und Versionen von GnuPG finden Sie auf der GnuPG-Homepage http://www.gnupg.org. Die neueste Version von GnuPG Die aktuelle Version von GnuPG k nnen Sie unter http://www.gnupg.org/de/ download.html sowohl als .tar.gz, als .rpm oder als Bin rversion f r Windows herunterladen. Au erdem finden Sie dort die Signaturen und MD5 Pr fsummen, um die Integrit t der Dateien zu berpr fen, Links zu Mirror-Sites und Links zu weiteren Programmen, die GnuPG unterst tzen. Die neueste Version des Handbuchs Unter http://www.gnupg.org/de/docs.htmlfinden Sie die aktuelle Version dieses Handbuches. Au erdem k nnen hier weitere hilfreiche und interessante Dokumente heruntergeladen werden. GnuPG Mailinglisten Es gibt mehrere Mailinglisten zum Thema GnuPG: + announce@gnupg.org wird f r die Ank ndigung neuer Versionen und andere wichtige Nachrichten verwendet. Sie k nnen diese Mailingliste abonnieren, indem Sie eine E-Mail mit dem Betreff (Subject) ``subscribe'' an announce-request@gnupg.org senden. + gnupg-users@gnupg.org ist das allgemeine Diskussions- und Hilfsforum. Senden Sie eine E-Mail mit dem Betreff (Subject) ``subscribe'' an gnupg-users-request@gnupg.org. Weitere Mailinglisten, die vor allem f r Entwickler interessant sind finden Sie unter http://www.gnupg.org/de/docs.html. Ein Archiv dieser Mailinglisten ist online unter http://lists.gnupg.org verf gbar. Links Links zu anderen interessanten Webseiten und Projekten finden Sie unter http://www.gnupg.org/de/others.html und unter http://www.gnupg.org/de/ crypto.html. ftp.gnupg.org Alternativ k nnen Sie GnuPG als Tar-Archiv auch per Ftp von ftp:// ftp.gnupg.org/pub/gcrypt/ herunterladen. + ftp://ftp.gnupg.org/pub/gcrypt/gnupg/ (Hier finden Sie die aktuelle stabile Version.) + ftp://ftp.gnupg.org/pub/gcrypt/devel/ (Hier gibt es die aktuellen Entwicklerversionen.) + ftp://ftp.gnupg.org/pub/gcrypt/binary/ (Hier befinden sich vorkompilierte Bin rversionen f r Win32 und OS/2.) ------------------------------------------------------------------------------- Kryptographie allgemein Hier finden Sie allgemeine und aktuelle Informationen zum Thema Kryptographie. Crypto-gram Der monatliche Newsletter des Autors und Kryptographieexperten Bruce Schneier. Um Crypto-gram zu abonnieren, senden Sie eine E-Mail an crypto-gram-subscribe@chaparraltree.com. Unter http://www.counterpane.com/crypto-gram.html finden Sie ein Archiv des Newsletters. telepolis Das Onlinemagazin Telepolis bietet News, Features und einen Themenschwerpunkt zu Kryptographie, Kommunikationssicherheit und Datenschutz. ------------------------------------------------------------------------------- Kryptographie-Gesetzgebung Crypto Law Survey Die Internet-Seite von Bert-Jaap Koops bietet einen hervorragenden internationalen berblick ber gesetzliche Regelungen und Ausfuhrbestimmungen f r kryptographische Produkte. Sicherheit im Internet ``Sicherheit im Internet - Sicherheit in der Informationsgesellschaft'' ist eine Initiative des Bundesministeriums f r Wirtschaft und Technologie, des Bundesministeriums des Innern und des Bundesamtes f r Sicherheit in der Informationstechnik. Hier gibt es au er aktuellen Informationen und Pressemitteilungen aus den Ministerien Hintergrundartikel, einen Webkatalog mit weiteren Links und einen Newsletter. ------------------------------------------------------------------------------- Link-Sammlungen Peter Gutmanns ``crypto link farm'' Diese beinahe unersch pfliche Linksammlung bietet einen ausgezeichneten Ausgangspunkt f r die Suche nach weiteren Informationsquellen. Zu finden unter http://www.cs.auckland.ac.nz/~pgut001/links.html oder ber den deutschen Mirror http://www.han.de/~ott/security-links.html. ------------------------------------------------------------------------------- Keyserver Deutsche Keyserver: + http://www.pca.dfn.de/dfnpca/pgpkserv/ + http://germany.keyserver.net/en/ ------------------------------------------------------------------------------- Anhang B. Installation von GnuPG Dieses Kapitel beschreibt die Installation von GnuPG auf verschiedenen Plattformen. Die Beschreibung bezieht sich auf die Version 1.0.1 von GnuPG. Bitte lesen Sie auf jeden Fall auch die Dateien "README" und "INSTALL" im GnuPG Source-Verzeichnis. Wo Sie aktuelle Versionen von GnuPG als TAR-Archiv, RPM oder Binary f r Win32 bekommen, k nnen Sie im Anhang B nachlesen. ------------------------------------------------------------------------------- Unix und GNU/Linux Bevor Sie mit der Installation beginnen, vergewissern Sie sich bitte, da Ihre Quelldateien nicht modifiziert wurden. Das ist ein sehr wichtiger Schritt, denn nur so k nnen Sie sicher sein, da niemand irgendwelche Hintert ren oder beabsichtigte Schwachstellen in den Code eingebaut hat. Wenn Sie bereits eine Version von GnuPG installiert haben, k nnen Sie einfach die Signatur berpr fen. Benutzen Sie jedoch niemals die Version, die Sie gerade installieren m chten, f r diese berpr fung. Der ffentliche Schl ssel zur Pr fung der Signatur ist: pub 1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) Sollten Sie diesen Schl ssel noch nicht in Ihrem ffentlichen Schl sselbund haben, m ssen Sie ihn zuerst aus der Datei g10/pubring.asc aus den Sourcen importieren: alice$ gpg --import src/gnupg-1.0.0/g10/pubring.asc oder von einem Keyserver holen, also beispielsweise: alice$ gpg --keyserver blackhole.pca.dfn.de --recv-keys 0x57548DCD Dann k nnen Sie die Signatur berpr fen mit alice$ gpg --verify gnupg-1.0.1.tar.gz.asc Sollten Sie eine vetrauensw rdige Version von PGP 2 oder PGP 5 installiert haben, k nnen Sie die PGP 2 Signatur mit gnupg-1.0.1.tar.gz.sig berpr fen: alice$ pgp gnupg-1.0.1.tar.gz.sig gnupg-1.0.1.tar.gz Falls Sie weder GnuPG noch PGP installiert haben, dann benutzen Sie den MD5-Hashalgorithmus, um eine Pr fsumme des Tar-Files zu erzeugen. alice$ md5sum gnupg-1.0.1.tar.gz 37eeae62c1823edc787996bfee70351a gnupg-1.0.1.tar.gz Vergleichen Sie dann bitte die Checksumme mit der, die Sie unter http:// www.gnupg.org/download.html finden. Falls Sie GnuPG systemweit installieren m chten, so da es f r alle User nutzbar ist, und falls sich bei Ihrem System die Sourcen f r lokal installierte Software unter /usr/local/src/ befinden, kopieren Sie erst das TAR-File nach / usr/local/src, wechseln dann in dieses Verzeichnis und entpacken das TAR-File: root# cd /usr/local/src/ root# gzip -d gnupg-1.0.1.tar.gz root# tar xvf gnupg-1.0.1.tar Danach wechseln Sie in das neu angelegte Unterverzeichnis gnupg-1.0.1/ und f hren dann nacheinander root# ./configure root# make root# make install aus. Die ausf hrbare Datei "gpg" befindet sich dann in /usr/local/bin. F r weitere Optionen von configure benutzen Sie die Option --help und lesen die Datei INSTALL. Um zu verhindern, da vertrauliche Daten auf die Swap-Partition ausgelagert werden, empfiehlt es sich, das Set-User-ID Bit f r "gpg" zu setzen: root# chmod u+s /usr/local/bin/gpg GnuPG verhindert dann, da Teile seines Speicherbereichs auf die Festplatte ausgelagert werden. Wenn Sie dies nicht tun m chten, k nnen Sie die Option no-secmem-warning in die Datei ~/.gnupg/options einf gen, dann bekommen Sie diesbez glich auch keine Warnmeldungen mehr. Falls Sie keine Root-Rechte auf dem System haben oder der Systemadministrator nicht gewillt ist, GnuPG systemweit zu installieren, besteht immer noch die M glichkeit zu einer User-Installation. Legen Sie dazu am besten ein Unterverzeichnis "src/" in Ihrem Home-Verzeichnis an, wenn Sie dies nicht schon haben. Entpacken Sie das Tar-File in "~/src" und f hren dann: alice$ ./configure --prefix=$HOME aus. Dann k nnen Sie genau wie oben ein make und make install durchf hren. make install legt dann die Unterverzeichnisse "bin/" "lib/" "man/" "share/" in Ihrem Home-Verzeichnis an. Die ausf hrbare Datei befindet sich dann unter "$HOME/bin/ gpg". $HOME/bin sollte nat rlich in Ihrem Pfad liegen. ------------------------------------------------------------------------------- Anhang C. Referenz gpg manpage Name gpg -- encryption and signing tool Synopsis gpg [--homedir name] [--options file] [options] command [args] DESCRIPTION gpg is the main program for the GnuPG system. COMMANDS gpg recognizes these commands: -s, --sign Make a signature. This command may be combined with --encrypt. --clearsign Make a clear text signature. -b, --detach-sign Make a detached signature. -e, --encrypt Encrypt data. This option may be combined with --sign. -c, --symmetric Encrypt with symmetric cipher only This command asks for a passphrase. --store Store only (make a simple RFC1991 packet). --decrypt [file] Decrypt file (or stdin if no file is specified) and write it to stdout (or the file specified with --output). If the decrypted file is signed, the signature is also verified. This command differs from the default operation, as it never writes to the filename which is included in the file and it rejects files which don't begin with an encrypted message. --verify [[sigfile] [signed-files]] Assume that sigfile is a signature and verify it without generating any output. With no arguments, the signature packet is read from stdin (it may be a detached signature when not used in batch mode). If only a sigfile is given, it may be a complete signature or a detached signature, in which case the signed stuff is expected in a file without the ".sig" or ".asc" extension (if such a file does not exist it is expected at stdin; use a single dash ("-") as filename to force a read from stdin). With more than 1 argument, the first should be a detached signature and the remaining files are the signed stuff. --verify-files [files] This is a special version of the --verify command which does not work with detached signatures. The command expects the files to bee verified either on the commandline or reads the filenames from stdin; each anem muts be on separate line. The command is intended for quick checking of many files. --list-keys [names], --list-public-keys [names] List all keys from the public keyrings, or just the ones given on the command line. --list-secret-keys [names] List all keys from the secret keyrings, or just the ones given on the command line. --list-sigs [names] Same as --list-keys, but the signatures are listed too. --check-sigs [names] Same as --list-sigs, but the signatures are verified. --fingerprint [names] List all keys with their fingerprints. This is the same output as --list-keys but with the additional output of a line with the fingerprint. May also be combined with --list-sigs or --check-sigs. If this command is given twice, the fingerprints of all secondary keys are listed too. --list-packets List only the sequence of packets. This is mainly useful for debugging. --gen-key Generate a new key pair. This command is normally only used interactive. There is an experimental feature which allows to create keys in batch mode. See the file doc/DETAILS in the source distribution on how to use this. --edit-key name Present a menu which enables you to do all key related tasks: sign Make a signature on key of user name If the key is not yet signed by the default user (or the users given with -u), the program displays the information of the key again, together with its fingerprint and asks whether it should be signed. This question is repeated for all users specified with -u. lsign Same as --sign but the signature is marked as non-exportable and will therefore never be used by others. This may be used to make keys valid only in the local environment. revsig Revoke a signature. GnuPG asks for every signature which has been done by one of the secret keys, whether a revocation certificate should be generated. trust Change the owner trust value. This updates the trust-db immediately and no save is required. disable, enable Disable or enable an entire key. A disabled key can normally not be used for encryption. adduid Create an alternate user id. deluid Delete an user id. addkey Add a subkey to this key. delkey Remove a subkey. revkey Revoke a subkey. expire Change the key expiration time. If a key is selected, the time of this key will be changed. With no selection the key expiration of the primary key is changed. passwd Change the passphrase of the secret key. uid n Toggle selection of user id with index n. Use 0 to deselect all. key n Toggle selection of subkey with index n. Use 0 to deselect all. check Check all selected user ids. pref List preferences. toggle Toggle between public and secret key listing. save Save all changes to the key rings and quit. quit Quit the program without updating the key rings. The listing shows you the key with its secondary keys and all user ids. Selected keys or user ids are indicated by an asterisk. The trust value is displayed with the primary key: the first is the assigned owner trust and the second is the calculated trust value. Letters are used for the values: - No ownertrust assigned / not yet calculated. e Trust calculation has failed. q Not enough information for calculation. n Never trust this key. m Marginally trusted. f Fully trusted. u Ultimately trusted. --sign-key name Sign a public key with you secret key. This is a shortcut version of the subcommand "sign" from --edit. --lsign-key name Sign a public key with you secret key but mark it as non-exportable. This is a shortcut version of the subcommand "lsign" from --edit. --delete-key name Remove key from the public keyring --delete-secret-key name Remove key from the secret and public keyring --gen-revoke Generate a revocation certificate for the complete key. To revoke a subkey or a signature, use the --edit command. --export [names] Either export all keys from all keyrings (default keyrings and those registered via option --keyring), or if at least one name is given, those of the given name. The new keyring is written to stdout or to the file given with option "output". Use together with --armor to mail those keys. --send-keys [names] Same as --export but sends the keys to a keyserver. Option --keyserver must be used to give the name of this keyserver. Don't send your complete keyring to a keyserver - select only those keys which are new or changed by you. --export-all [names] Same as --export, but does also export keys which are not compatible to OpenPGP. --export-secret-keys [names], --export-secret-subkeys [names] Same as --export, but does export the secret keys. This is normally not very useful and a security risk. the second form of the command has the special property to render the secret part of the primary key useless; this is a GNU extension to OpenPGP and other implementations can not be expected to successful import such a key. --import [files], --fast-import [files] Import/merge keys. This adds the given keys to the keyring. The fast version does not build the trustdb; this can be done at any time with the command --update-trustdb. --recv-keys key IDs Import the keys with the given key IDs from a HKP keyserver. Option --keyserver must be used to give the name of this keyserver. --export-ownertrust List the assigned ownertrust values in ASCII format for backup purposes --import-ownertrust [files] Update the trustdb with the ownertrust values stored in files (or stdin if not given); existing values will be overwritten. --print-md algo [files] Print message digest of algorithm ALGO for all given files of stdin. If "*" is used for the algorithm, digests for all available algorithms are printed. --gen-random 0|1|2 [count] Emit COUNT random bytes of the given quality level. If count is not given or zero, an endless sequence of random bytes will be emitted. PLEASE, don't use this command unless you know what you are doing, it may remove precious entropy from the system! --gen-prime mode bits [qbits] Use the source, Luke :-). The output format is still subject to change. --version Print version information along with a list of supported algorithms. --warranty Print warranty information. -h, --help Print usage information. This is a really long list even it does list not all options. OPTIONS Long options can be put in an options file (default "~/.gnupg/options"). Do not write the 2 dashes, but simply the name of the option and any required arguments. Lines with a hash as the first non-white-space character are ignored. Commands may be put in this file too, but that does not make sense. gpg recognizes these options: -a, --armor Create ASCII armored output. -o, --output file Write output to file. -u, --local-user name Use name as the user ID to sign. This option is silently ignored for the list commands, so that it can be used in an options file. --default-key name Use name as default user ID for signatures. If this is not used the default user ID is the first user ID found in the secret keyring. -r, --recipient name, Encrypt for user id name. If this option is not specified, GnuPG asks for the user-id unless --default-recipient is given --default-recipient name Use name as default recipient if option --recipient is not used and don't ask if this is a valid one. name must be a non empty. --default-recipient-self Use the default key as default recipient if option --recipient is not used and don't ask if this is a valid one. The default key is the first one from the secret keyring or the one set with --default-key. --no-default-recipient Reset --default-recipient and --default-recipient-self. --encrypt-to name Same as --recipient but this one is intended for in the options file and may be used together with an own user-id as an "encrypt-to-self". These keys are only used when there are other recipients given either by use of --recipient or by the asked user id. No trust checking is performed for these user ids and even disabled keys can be used. --no-encrypt-to Disable the use of all --encrypt-to keys. -v, --verbose Give more information during processing. If used twice, the input data is listed in detail. -q, --quiet Try to be as quiet as possible. -z n Set compression level to n. A value of 0 for n disables compression. Default is to use the default compression level of zlib (normally 6). -t, --textmode Use canonical text mode. If -t (but not --textmode) is used together with armoring and signing, this enables clearsigned messages. This kludge is needed for PGP compatibility; normally you would use --sign or --clearsign to selected the type of the signature. -n, --dry-run Don't make any changes (this is not completely implemented). -i, --interactive Prompt before overwriting any files. --batch Use batch mode. Never ask, do not allow interactive commands. --no-batch Disable batch mode. This may be of use if --batch is enabled from an options file. --yes Assume "yes" on most questions. --no Assume "no" on most questions. --always-trust Skip key validation and assume that used keys are always fully trusted. You won't use this unless you have installed some external validation scheme. --keyserver name Use name to lookup keys which are not yet in your keyring. This is only done while verifying messages with signatures. The option is also required for the command --send-keys to specify the keyserver to where the keys should be send. All keyservers synchronize with each other - so there is no need to send keys to more than one server. Using the command "host -l pgp.net | grep wwwkeys" gives you a list of keyservers. Because there is load balancing using round-robin DNS you may notice that you get different key servers. --honor-http-proxy Try to access the keyserver over the proxy set with the variable "http_proxy". --keyring file Add file to the list of keyrings. If file begins with a tilde and a slash, these are replaced by the HOME directory. If the filename does not contain a slash, it is assumed to be in the home-directory ("~/.gnupg" if --homedir is not used). The filename may be prefixed with a scheme: "gnupg-ring:" is the default one. "gnupg-gdbm:" may be used for a GDBM ring. Note that GDBM is experimental and likely to be removed in future versions. It might make sense to use it together with --no-default-keyring. --secret-keyring file Same as --keyring but for the secret keyrings. --homedir directory Set the name of the home directory to directory If this option is not used it defaults to "~/.gnupg". It does not make sense to use this in a options file. This also overrides the environment variable "GNUPGHOME". --charset name Set the name of the native character set. This is used to convert some strings to proper UTF-8 encoding. Valid values for name are: iso-8859-1 This is the default Latin 1 set. iso-8859-2 The Latin 2 set. koi8-r The usual Russian set (rfc1489). --utf8-strings, --no-utf8-strings Assume that the arguments are already given as UTF8 strings. The default (--no-utf8-strings) is to assume that arguments are encoded in the character set as specified by --charset. These options effects all following arguments. Both options may used multiple times. --options file Read options from file and do not try to read them from the default options file in the homedir (see --homedir). This option is ignored if used in an options file. --no-options Shortcut for "--options /dev/null". This option is detected before an attempt to open an option file. --load-extension name Load an extension module. If name does not contain a slash it is searched in "/usr/local/lib/gnupg" See the manual for more information about extensions. --debug flags Set debugging flags. All flags are or-ed and flags may be given in C syntax (e.g. 0x0042). --debug-all Set all useful debugging flags. --status-fd n Write special status strings to the file descriptor n. See the file DETAILS in the documentation for a listing of them. --logger-fd n Write log output to file descriptor n and not to stderr. --no-comment Do not write comment packets. This option affects only the generation of secret keys. Output of option packets is disabled since version 0.4.2. --comment string Use string as comment string in clear text signatures. --default-comment Force to write the standard comment string in clear text signatures. Use this to overwrite a --comment from a config file. --no-version Omit the version string in clear text signatures. --emit-version Force to write the version string in clear text signatures. Use this to overwrite a previous --no-version from a config file. -N, --notation-data name=value Put the name value pair into the signature as notation data. name must consists only of alphanumeric characters, digits or the underscore; the first character must not be a digit. value may be any printable string; it will encoded in UTF8, so sou should have check that your --charset is set right. If you prefix name with an exclamation mark, the notation data will be flagged as critical (rfc2440:5.2.3.15). --set-policy-url string Use string as Policy URL for signatures (rfc2440:5.2.3.19). If you prefix it with an exclamation mark, the policy URL packet will be flagged as critical. --set-filename string Use string as the name of file which is stored in messages. --use-embedded-filename Try to create a file with a name as embedded in the data. This can be a dangerous option as it allows to overwrite files. --completes-needed n Number of completely trusted users to introduce a new key signer (defaults to 1). --marginals-needed n Number of marginally trusted users to introduce a new key signer (defaults to 3) --max-cert-depth n Maximum depth of a certification chain (default is 5). --cipher-algo name Use name as cipher algorithm. Running the program with the command --version yields a list of supported algorithms. If this is not used the cipher algorithm is selected from the preferences stored with the key. --digest-algo name Use name as message digest algorithm. Running the program with the command --version yields a list of supported algorithms. Please note that using this option may violate the OpenPGP requirement, that a 160 bit hash is to be used for DSA. --s2k-cipher-algo name Use name as the cipher algorithm used to protect secret keys. The default cipher is BLOWFISH. This cipher is also used for conventional encryption if --cipher-algo is not given. --s2k-digest-algo name Use name as the digest algorithm used to mangle the passphrases. The default algorithm is RIPE-MD-160. This digest algorithm is also used for conventional encryption if --digest-algo is not given. --s2k-mode n Selects how passphrases are mangled. If n is 0 a plain passphrase (which is not recommended) will be used, a 1 (default) adds a salt to the passphrase and a 3 iterates the whole process a couple of times. Unless --rfc1991 is used, this mode is also used for conventional encryption. --compress-algo n Use compress algorithm n. Default is 2 which is RFC1950 compression. You may use 1 to use the old zlib version which is used by PGP. The default algorithm may give better results because the window size is not limited to 8K. If this is not used the OpenPGP behavior is used, i.e. the compression algorithm is selected from the preferences; note, that this can't be done if you do not encrypt the data. --disable-cipher-algo name Never allow the use of name as cipher algorithm. The given name will not be checked so that a later loaded algorithm will still get disabled. --disable-pubkey-algo name Never allow the use of name as public key algorithm. The given name will not be checked so that a later loaded algorithm will still get disabled. --throw-keyid Do not put the keyid into encrypted packets. This option hides the receiver of the message and is a countermeasure against traffic analysis. It may slow down the decryption process because all available secret keys are tried. --not-dash-escaped This option changes the behavior of cleartext signatures so that they can be used for patch files. You should not send such an armored file via email because all spaces and line endings are hashed too. You can not use this option for data which has 5 dashes at the beginning of a line, patch files don't have this. A special armor header line tells GnuPG about this cleartext signature option. --escape-from-lines Because some mailers change lines starting with "From " to " Using an exact to match string. The equal sign indicates this. Using the email address part which must match exactly. The left angle bracket indicates this email address mode. +Heinrich Heine duesseldorf All words must match exactly (not case sensitive) but can appear in any order in the user ID. Words are any sequences of letters, digits, the underscore and all characters with bit 7 set. #34 Using the Local ID. This is a very low level method and should only be used by applications which really need it. The hash character indicates this method. An application should not assume that this is only a number. Heine, *Heine By case insensitive substring matching. This is the default mode but applications may want to explicitely indicate this by putting the asterisk in front. RETURN VALUE The program returns 0 if everything was fine, 1 if at least a signature was bad, and other error codes for fatal errors. EXAMPLES gpg -se -r Bob file sign and encrypt for user Bob gpg --clearsign file make a clear text signature gpg -sb file make a detached signature gpg --list-keys user_ID show keys gpg --fingerprint user_ID show fingerprint gpg --verify pgpfile, gpg --verify sigfile [files] Verify the signature of the file but do not output the data. The second form is used for detached signatures, where sigfile is the detached signature (either ASCII armored of binary) and [files] are the signed data; if this is not given the name of the file holding the signed data is constructed by cutting off the extension (".asc" or ".sig") of sigfile or by asking the user for the filename. ENVIRONMENT HOME Used to locate the default home directory. GNUPGHOME If set directory used instead of "~/.gnupg". http_proxy Only honored when the option --honor-http-proxy is set. FILES ~/.gnupg/secring.gpg The secret keyring ~/.gnupg/secring.gpg.lock and the lock file ~/.gnupg/pubring.gpg The public keyring ~/.gnupg/pubring.gpg.lock and the lock file ~/.gnupg/trustdb.gpg The trust database ~/.gnupg/trustdb.gpg.lock and the lock file ~/.gnupg/random_seed used to preserve the internal random pool ~/.gnupg/options May contain options /usr[/local]/share/gnupg/options.skel Skeleton options file /usr[/local]/lib/gnupg/ Default location for extensions WARNINGS Use a *good* password for your user account and a *good* passphrase to protect your secret key. This passphrase is the weakest part of the whole system. Programs to do dictionary attacks on your secret keyring are very easy to write and so you should protect your "~/.gnupg/" directory very well. Keep in mind that, if this program is used over a network (telnet), it is *very* easy to spy out your passphrase! BUGS On many systems this program should be installed as setuid(root). This is necessary to lock memory pages. Locking memory pages prevents the operating system from writing memory pages to disk. If you get no warning message about insecure memory 3our operating system supports locking without being root. The program drops root privileges as soon as locked memory is allocated. ------------------------------------------------------------------------------- Anhang D. Glossar 3DES Triple DES. Symmetrischer Verschl sselungsalgorithmus, der auf einer dreifachen Verschl sselung mit DES basiert. Gilt nach heutigen Ma st ben als sicher. Wird vom OpenPGP-Standard zwingend vorgeschrieben und gilt daher als der kleinste gemeinsame Nenner unter den verwendeten Verschl sselungsalgorithmen. 3DES hat eine Schl ssell nge von 168 Bit, die wirksame Schl ssell nge ist aber aufgrund des eingesetzten Verfahrens 112 Bit. Algorithmus Allgemein: (mathematisches) Verfahren, das in kleinste Teilschritte/ Handlungsanweisungen unterteilt ist. Siehe auch: Verschl sselungsalgorithmus. ASCII American Standard Code for Information Interchange. Standard-Zeichensatz f r das englische Alphabet. Besteht aus 128 Zeichen, jedes Zeichen wird durch eine 7 Bit lange Zahl dargestellt. Siehe auch: Bin r. ASCII-armor Die Ausgabe erfolgt nicht in bin rer Form, sondern in Form von am Bildschirm darstellbaren ASCII-Zeichen. Asymmetrische Verschl sselung Bei asymmetrischen Verfahren wird zum Verschl sseln ein anderer Schl ssel eingesetzt als zum Entschl sseln. Asymmetrische Verschl sselung findet in Public-Key-Verfahren Verwendung. Asymmetrische und symmetrische Verschl sselung lassen sich zu hybrider Verschl sselung kombinieren. Sowohl zum Verschl sseln als auch zum berpr fen von digitalen Signaturen wird der ffentliche Schl ssel eingesetzt, zum Entschl sseln und zum Signieren der geheime Schl ssel. Authentisierung Das Beglaubigen der Identit t. Hierzu ist die Eingabe eines Mantra erforderlich. Durch das Beglaubigen der Identit t wird verhindert, da sich eine andere Person als Urheber eines Dokumentes ausgeben kann oder ein f r einen bestimmten Empf nger verschl sseltes Dokument unbefugt lesen kann. Benutzer-ID (Engl. User-ID) Identifikation des Benutzers durch Name und E-Mail-Adresse und optional durch einen zus tzlichen Kommentar. Bin r Im Zweier-Zahlensystem (Bin rsystem) dargestellt. Intern werden alle Daten in einem Computer bin r dargestellt. Blowfish Von Bruce Schneier entwickelter, frei verwendbarer symmetrischer Verschl sselungsalgorithmus mit 128 Bit Schl ssell nge, der Teil der OpenPGP -Spezifikation ist. Brute Force Angriff auf verschl sselte Daten, bei dem alle m glichen Schl sselkombinationen durchprobiert werden. Brute-Force-Angriffe sind extrem rechenaufwendig. Selbst wenn alle Rechner der Welt zusammengeschaltet w ren, w rde das Durchprobieren aller Kombinationen bei einem 128-Bit-Schl ssel einige Milliarden Jahre dauern. CAST5 Symmetrischer Verschl sselungsalgorithmus mit 128 Bit Schl ssell nge. In der OpenPGP-Spezifikation vorgeschrieben. Certification Authority Zertifizierungsinstanz innerhalb eines hierarchischen Zertifizierungsmodells. Certification Authorities lassen sich auch problemlos in das von GnuPG favorisierte Modell des "Web of Trust" einbeziehen. Siehe auch: Web of Trust. Cracker Person, die vors tzlich, unbefugterweise und oft mit b sartiger Absicht in fremde Rechnersysteme eindringt, im deutlichen Gegensatz zu ``Hacker'', worunter man allgemein einen gutmeinenden Computer-Freak versteht (siehe hierzu auch RFC 1983). default Standard, Standard-Einstellung, Voreinstellung. DES Digital Encryption Standard. Symmetrischer Verschl sselungsalgorithmus mit einer Schl ssell nge von 56 Bit. Kann nach dem heutigen Stand der Technik - wenn auch mit erheblichem Aufwand - geknackt werden. Diffie-Hellmann Public-Key-Algorithmus. Wird zum sicheren Austausch von Schl sseln verwendet. Digest Algorithmus Hashalgorithmus. Digitale Signatur Auch digitale Unterschrift. Aus dem geheimen Schl ssel und einer Datei wird durch Anwendung einer Hash-Funktion eine eindeutige Zeichenfolge gebildet. Mit Hilfe des ffentlichen Schl ssels kann nun jeder berpr fen, ob die Datei tats chlich von dem angegebenen Urheber bzw Absender stammt und ob der Inhalt verf lscht wurde. Die digitale Signatur erm glicht es, die Integrit t und Authentizit t eines elektronischen Dokumentes unabh ngig vom Datenformat zu verifizieren. DSA Digital Signature Algorithm. Ein von der NSA entwickelter, sehr sicherer Algorithmus zum Signieren von Daten. DSA verwendet den Hash-Algorithmus SHA1. Eigenbeglaubigung Auch Selbstunterzeichnung. Indem der Benutzer seinen ffentlichen Schl ssel sowie die Benutzer-ID selbst mit seinem geheimen Schl ssel unterzeichnet, best tigt er deren Authentizit t, und so lassen sich Verf lschungen daran sehr leicht feststellen. Einweg-Hash Eine nicht umkehrbare Hashfunktion. Es ist nicht m glich, aus der durch die Hashfunktion erzeugten eindeutigen Pr fsumme die urspr nglichen Daten wieder herzustellen oder auch nur R ckschl sse darauf zu ziehen. ElGamal Auch ELG-E.Asymmetrischer Verschl sselungs-Algorithmus, der sowohl zum Verschl sseln als auch zum Signieren benutzt werden kann. Seit 1997 nicht mehr von Patenten gedeckt. Dieser Algorithmus gilt nach den heutigen Ma st ben als sicher und mu von jedem OpenPGP-System unterst tzt werden. Entropie Begriff aus der Thermodynamik. Ma f r die Unordnung eines Systems. Zum Erzeugen echter Zufallswerte ben tigt GnuPG Entropie. Diese kann man beispielsweise durch (willk rliche) Festplattenzugriffe, Mausbewegungen oder Tastatureingaben erzeugen. Fallt r-Algorithmus (Engl. Doortrap Algorithm) Ein Algorithmus, der leicht zu berechnen ist, dessen Umkehrfunktion aber sehr schwer zu berechnen ist. So ist es z.B. leicht, zwei Primzahlen miteinander zu multiplizieren, um eine Nichtprimzahl zu erhalten, es ist aber schwer, eine gro e Nichtprimzahl in ihre Primfaktoren zu zerlegen. Fingerabdruck (Engl. fingerprint) Eindeutige Pr fsumme (Hash) des ffentlichen Schl ssels ; ist wesentlich k rzer als der Schl ssel selbst. Wird zum berpr fen bzw. Verifizieren eines ffentlichen Schl ssels herangezogen. Freie Software Software, die nach Belieben - auch kommerziell - benutzt werden darf, z. B. um den Quelltext einzusehen und nach eigenen Vorstellungen abzu ndern, oder um die Software in ver nderter oder unver nderter Form - ohne ihr allerdings eigene Einschr nkungen aufzuerlegen - an andere weiterzugeben. Beispiele f r freie Software sind Linux und GnuPG. Siehe auch http:// www.gnu.org/philosophy/free-sw.html. Geheimschl ssel (Engl. Secret Key, Private Key) Bei asymmetrischen Verfahren der Hauptschl ssel, der sowohl zum Entschl sseln des Geheimtextes, zum digitalen Signieren von Dokumenten als auch zur Generierung des ffentlichen Schl ssels und der Widerrufurkunde verwendet wird. Siehe auch: ffentlicher Schl ssel. Geheimtext Die mit Hilfe eines Verschl sselungsverfahrens verschl sselten Daten. Siehe auch: Klartext. GNU Gnu's Not Unix. Abk rzung f r das seit 1984 bestehende GNU-Projekt der Free Software Foundation, dessen Ziel die Schaffung eines auf freier Software basierenden, Unix- hnlichen Betriebssystems ist. LINUX beruht in gro en Teilen auf GNU-Software. Siehe auch http://www.gnu.org GNU-GPL GNU General Public License. Eine Lizenz f r Freie Software, der auch GnuPG unterliegt. Jeder kann Software, die unter der GPL steht, frei benutzen, modifizieren und weitergeben; die einzigen Einschr nkungen sind, da man keine weiteren Einschr nkungen bei der Weitergabe auferlegen darf und da die Lizenz an sich nicht ver ndert werden darf. GnuPG GNU Privacy Guard. Freie, dem OpenPGP-Standard entsprechende Verschl sselungs-Software. Hashfunktion Auch kryptographische Pr fsumme oder Message Digest. Eine Hashfunktion ist eine Funktion, die aus einer Datei eine eindeutige Pr fsumme errechnet. Beispiele f r Hashalgorithmen sind SHA1 und MD5. Hybride Verschl sselung Verschl sselungsverfahren, bei dem sowohl symmetrische als auch asymmetrische Verschl sselungsalgorithmen eingesetzt werden. Bei GnuPG (und PGP) werden beispielsweise die eigentlichen Daten mit einem nach dem Zufallsprinzip erzeugten symmetrischen Sitzungsschl ssel verschl sselt. Dieser Sitzungsschl ssel wird dann, um einen sicheren Schl sseltausch zu erm glichen, mit dem ffentlichen Schl ssel des Empf ngers verschl sselt und von GnuPG zu einem Paket zusammengepackt. Auf der Empf ngerseite entschl sselt GnuPG zuerst mit dem geheimen Schl ssel des Empf ngers den Sitzungsschl ssel, mit dem dann die urspr nglichen Daten wiederhergestellt werden k nnen. Siehe auch: Public-Key-Verschl sselung. IDEA International Data Encryption Standard. Symmetrischer Verschl sselungsalgorithmus mit 128 Bit Schl ssell nge. Der IDEA-Algorithmus ist patentiert; kommerzieller Einsatz erfordert den Erwerb einer Lizenz. IDEA gilt nach den heutigen Ma st ben als sicher und kann von OpenPGP-Systemen optional unterst tzt werden. IDEA ist kein OpenPGP-Standard-Algorithmus und wird nicht von allen OpenPGP-Systemen unterst tzt. IETF Internet Engineering Task Force. Gremium, das technische Standards f r das Internet koordiniert. In den sogenannten Workinggroups der IETF, in denen sich Entwickler und Wissenschaftler aus eigenem Antrieb organisieren, werden die Standards erarbeitet und in RFC ("Request forComments") genannten Dokumenten beschrieben. Siehe auch http://www.ietf.org. Key Escrow Schl sselhinterlegung. Ma nahme, um beispielsweise ein Mitlesen verschl sselter Nachrichten durch staatliche Stellen oder den Arbeitgeber zu erm glichen. Key Recovery Die M glichkeit, durch eine in die Verschl sselungs-Software eingebaute "Hintert r" f r Unbefugte (staatliche Stellen, Arbeitgeber) das Wiederherstellen des geheimen Schl ssels zu vereinfachen. Key Recovery stellt einen Eingriff in das Grundrecht auf informationelle Selbstbestimmung dar und wird von GnuPG nicht unterst tzt. Da GnuPG freie Software ist, kann der Quelltext daraufhin berpr ft werden. Keyserver Zentrale Internet-Datenbanken zur Verwaltung und Ver ffentlichung von ffentlichen Schl sseln. Ein Keyserver f hrt keine Zertifizierung der verwalteten Schl ssel durch; dazu bedarf es zus tzlicher Ma nahmen wie z. B. der Einrichtung des Web of Trust. key space Der Anzahl an m glichen Schl sseln. Je l nger der Schl ssel ist, desto gr er ist auch die m gliche Anzahl an verschiedenen Schl sseln und desto schwieriger ist es, den Schl ssel durch Raten oder Ausprobieren herauszubekommen. Klartext Allgemein: unverschl sselte Daten. Siehe auch: Geheimtext. Kompromittierung Unbeabsichtigte oder unautorisierte Offenlegung des (Geheim-)Schl ssels bzw. der verschl sselten Daten. Kryptographie Wissenschaft von der Verschl sselung von Daten und deren Anwendung. LINUX Betriebssystem der Unix-Familie, das als freie Software f r verschiedene Rechner-Plattformen verf gbar ist. Benannt nach dem Initiator Linus Torvalds, der 1991 die erste Version im Internet ver ffentlicht hat, wird es von einem weltweiten Netzwerk von Programmierern st ndig weiterentwickelt. Linux basiert in gro en Teilen auf dem GNU-Projekt und ist der GNU GPL unterstellt. LINUX ist derzeit das meistverwendete Betriebssystem auf dem Gebiet der Internetserver und gewinnt immer mehr Marktanteile im Desktop-Bereich. Mantra Ein Pa wort-Satz. Der geheime Schl ssel ist bei GnuPG noch einmal selbst mit einem Mantra gesch tzt. Ohne das Mantra kann man den geheimen Schl ssel weder zum Entschl sseln noch zum Signieren verwenden. Ein sicheres Mantra sollte m glichst lang sein, m glichst wenig W rter aus dem W rterbuch/ Lexikon enthalten und trotzdem leicht zu behalten sein. Um sich das Mantra zu merken, sollte man es niemals aufschreiben, sondern quasi wie ein "Mantra" still in sich "hineinmurmeln". MD5 Message Digest 5. Ein kryptographisch sicherer Hashalgorithmus. NSA National Security Agency. Amerikanischer Geheimdienst, der sich vorrangig mit Kryptographie und dem weltweiten gezielten Abh ren der elektronischen Kommunikation besch ftigt. ffentlicher Schl ssel (Engl. public key) Bei asymmetrischen und hybriden Verschl sselungsverfahren der frei zug ngliche Schl ssel. Mit dem ffentlichen Schl ssel k nnen Daten verschl sselt und Signaturen berpr ft werden. Zum Signieren und Verschl sseln ist der geheime Schl ssel erforderlich. OpenPGP Protokoll, das den Austausch von verschl sselten Daten, Signaturen und Schl sseln regelt. Spezifiziert in RFC 2440. PGP Pretty Good Privacy. Eine von Philip Zimmermann in den USA entwickelte, weit verbreitete Verschl sselungs-Software. PGP benutzt den patentierten Algorithmus IDEA und fordert f r kommerzielle Anwender den Erwerb einer Lizenz. Der Quelltext von PGP ist ffentlich nicht verf gbar, die Integrit t der Software wird von Experten in Frage gestellt. Primzahl Auch Primfaktor. Zahl, die nur durch sich selbst oder die Zahl 1 teilbar ist. Die Zerlegung in Primfaktoren spielt bei vielen Verschl sselungsalgorithmen eine zentrale Rolle. Privatsph re (Engl. Privacy) Im Rahmen dieses Handbuches das Sch tzen vertraulicher Informationen vor dem Zugriff oder der Manipulation durch Dritte. Weil Daten, die ber das Internet oder ein lokales Netzwerk verschickt werden, leicht mitgelesen, abgefangen oder manipuliert werden k nnen, und weil Daten auf einem nicht vernetzten Einzelplatzrechner in der Regel auch nicht sicher vor unbefugten Zugriffen sind, ist die einzige M glichkeit zum Schutz dieser Privatsph re eine wirkungsvolle Verschl sselung. Public-Key-Verschl sselung Verschl sselungsverfahren mit einem ffentlichen (engl. public key) und einem geheimen Schl ssel (engl. secret key). Der ffentliche Schl ssel wird sowohl zum Verschl sseln als auch zum berpr fen von Signaturen ben tigt, der geheime zum Entschl sseln und zum Signieren. Public-Key-Verschl sselung setzt ein asymmetrisches Verschl sselungsverfahren voraus. In der Praxis wird meistens die hybride Verschl sselung eingesetzt. Quelltext (Engl. source code) Ein Computer-Programm in seiner urspr nglichen, vom Menschen lesbaren Textform; kann nicht direkt vom Prozessor ausgef hrt werden, sondern mu vorher von einem Compiler oder Interpreter in Bin rcode bersetzt werden. Kann von Programmierern oder Systemadministratoren ver ndert, den eigenen Anforderungen angepa t und auf eventuelle Sicherheitsrisiken gepr ft werden. Der Quelltext der meisten gebr uchlichen kommerziellen Software ist nur dem Hersteller zug nglich; erst in letzter Zeit gewinnt freie Software, bei welcher der Benutzer Zugriff auf die Quelltexte hat, zunehmend an Bedeutung. Der Quelltext von GnuPG, welches der GNU GPL unterliegt ist jedermann frei zug nglich. RIPE-MD-160 Ein Hash-Algorithmus. RFC Request For Comments. Dokumente, die (unter anderem) technische Standards f r das Internet beschreiben. Die RFCs werden von den sog. Workinggroups der IETF erarbeitet. Der Standard f r OpenPGP beispielsweise ist in RFC 2440 spezifiziert. Weitere Informationen sowie alle RFCs finden Sie unterhttp:// www.rfc-editor.org. RSA Ein Algorithmus zum Signieren und asymmetrischen Verschl sseln von Daten. RSA steht f r Rivest, Shamir und Adelman, die Erfinder des Algorithmus. Die Spezifikation von OpenPGP unterst tzt die optionale Verwendung von RSA. Dieser Algorithmus ist von Patenten gesch tzt und daher nicht frei verwendbar. Schl ssel Datensequenz, die benutzt wird, um mit einer Verschl sselungs-Software aus dem Klartext Geheimtext zu erzeugen (Verschl sselung) und um aus dem Geheimtext den Klartext wieder herzustellen (Entschl sselung). Auch zum Signieren und berpr fen einer digitalen Signatur wird ein Schl ssel ben tigt. Schl ssel ID (Engl. key ID) Eindeutige Kennzeichnung eines Schl ssels. Bestehend aus Schl ssell nge, verwendetem Algorithmus, den letzten 8 Stellen des Fingerabdrucks, dem Erzeugungsdatum und der Benutzer-ID. Schl sselbund (Engl. key ring) Eine Sammlung ffentlicher oder geheimer Schl ssel wird als Schl sselbund bezeichnet. Bei GnuPG die Dateien pubring.gpg und secring.gpg. Da ein Teilnehmer f r jeden Gespr chspartner, dem er verschl sselte E-Mail schicken will, dessen ffentlichen Schl ssel seinem ffentlichen Schl sselbund hinzuf gt, kann dieser recht gro werden. Schl sseleditor Ein Werkzeug zum Anzeigen und Bearbeiten von Schl sseln. Der GnuPG-Schl sseleditor z. B. ist ein interaktives Kommandozeilen-Interface. Es wird mit gpg --edit-key , gefolgt von der Schl ssel-ID, aufgerufen. Schl ssell nge Sowohl bei symmetrischer als auch bei asymmetrischer Verschl sselung beruht die Sicherheit ganz und gar auf dem Schl ssel. Deshalb ist die Schl ssell nge ein Ma f r die Sicherheit des Systems, doch kann man die L nge eines symmetrischen Schl ssels nicht mit der eines asymmetrischen Schl ssels vergleichen, um R ckschl sse auf ihre relative Sicherheit ziehen zu k nnen. Heutzutage gelten symmetrische Schl ssel als sicher ab einer L nge von etwa 80 Bit, asymmetrische etwa ab 1024 Bit, vorausgesetzt, da das zugrundeliegende Verschl sselungsverfahren keine Schwachstellen enth lt. Schl sselpaar Bei Public-Key Verfahren der geheime und der dazugeh rige ffentliche Schl ssel. Schl ssel-Server Siehe: Keyserver SHA1 Secure Hash Algorithm One. Von der NSA entwickelter Hashalgorithmus mit einer Schl ssell nge von 160 Bit. Selbstunterzeichnung Siehe: Eigenbeglaubigung Signatur Auch digitale Signatur. Aus der zu signierenden Datei und dem Geheimschl ssel wird mittels eines Einweg-Hashalgorithmus eine digitale Signatur erzeugt, deren Echtheit man mit dem ffentlichen Schl ssel berpr fen kann. Wird die Datei oder die Signatur ver ndert, ergibt sich bei der berpr fung der Signatur eine Fehlermeldung. Mit digitalen Signaturen kann man die Echtheit von digitalen Dokumenten wie beispielsweise Texten, Fotografien, Quelltext best tigen. Sitzungsschl ssel Der symmetrische Schl ssel, mit dem bei OpenPGP-Verfahren die eigentlichen Daten verschl sselt werden. Dieser Sitzungsschl ssel wird dann mit dem asymmetrischen ffentlichen Schl ssel verschl sselt. Auf diese Weise kann der Sitzungsschl ssel sicher bertragen werden. Symmetrische Verschl sselung Symmetrisch verschl sselte Daten m ssen mit dem gleichen Schl ssel entschl sselt werden, mit dem sie auch verschl sselt worden sind. Symmetrische Verschl sselung findet Verwendung bei der sicheren Aufbewahrung geheimer Daten. F r den Austausch geheimer Nachrichten ist symmetrische Verschl sselung nur in Kombination mit asymmetrischer Verschl sselung sinnvoll ( hybrides Verfahren). subkey Jeder Schl ssel besteht normalerweise aus zwei Schl sselpaaren: einem Hauptschl sselpaar zum Unterschreiben bzw. Pr fen der Unterschrift und einem Unterschl sselpaar zum Ver- bzw. Entschl sseln von Nachrichten. (Es kann auch mehrere Unterschl sselpaare geben.) Trust-Datenbank Datei, in der die Vertrauensstufen, die man den verschiedenen Schl sselbesitzern zuordnet, verwaltet werden. Twofish Von Bruce Schneier entwickelter, symmetrischer Verschl sselungsalgorithmus mit wahlweise 128 oder 256 Bit Schl ssell nge. Der OpenPGP-Standard spezifiziert 256 Bit. Unix Familie von Multi-User-Multi-Tasking-Multi-Platform-Betriebssystemen. W hrend Unix fr her ausschlie lich auf mittelgro en und gro en Rechenanlagen eingesetzt wurde, gewinnt es heute in Form von LINUX einen wachsenden Markt im Internet, in der Industrie und im Privatbereich. Verschl sselung Das Ver ndern eines Textes, Bildes bzw. allgemein einer Datei unter Verwendung eines Schl ssels und nach einen festgelegten Verfahren (Verschl sselungsalgorithmus), mit dem Ziel, den betreffenden Inhalt f r andere unkenntlich zu machen, wobei der Vorgang unter Verwendung des Schl ssels wieder umkehrbar ist. Verschl sselungsalgorithmus Methode, nach der aus dem Klartext der Geheimtext erzeugt wird. Es wird unterschieden zwischen symmetrischen und asymmetrischen Verschl sselungsalgorithmen. Beispiele f r Verschl sselungsalgorithmen: 3DES, Blowfish, ElGamal und Twofish. Siehe auch: Algorithmus. Vertrauensstufen (Engl. trustlevel) Ma f r das Vertrauen in die F higkeit des Schl sselbesitzers, Schl ssel sorgf ltig zu authentifizieren und zu signieren. Die vier Vertrauensstufen werden folgenderma en abgek rzt: q Unbekannt n kein Vertrauen m teilweises Vertrauen f volles Vertrauen GnuPG entscheidet, ausgehend von dieser Einstufung, ob es von anderen Kommunikationspartnern signierte und authentifizierte Schl ssel als echt anerkennt. F r ein sicheres Web of Trust ist es entscheidend, da man den einzelnen Benutzer-IDs in seinem Schl sselbund wohl berlegte Vertrauensstufen zuweist. Web of Trust ("Netzwerk gegenseitigen Vertrauens") Hier werden Schl sselunterschriften benutzt, um die G ltigkeit auch auf Schl ssel auszudehnen, die nicht direkt von Ihnen selbst, sondern von anderen Personen signiert worden sind. Dabei ist nicht das Vertrauen in die andere Person entscheidend, sondern das Vertrauen in deren F higkeit, Schl ssel sorgf ltig zu authentifizieren und richtig zu signieren. Verantwortungsbewu te Benutzer, die eine gute Schl sselverwaltung praktizieren, k nnen das Verf lschen des Schl ssels als einen praktischen Angriff auf sichere Kommunikation mit Hilfe von GnuPG abwehren. Widerrufurkunde Wenn ein geheimer Schl ssel kompromittiert worden ist, sollte man - um Sch den und Mi brauch zu vermeiden - die davon abgeleiteten ffentlichen Schl ssel f r ung ltig erkl ren. Dies geschieht durch die Ver ffentlichung einer aus dem geheimen Schl ssel erzeugten Widerrufurkunde. ------------------------------------------------------------------------------- Weitere B cher zum Thema Kryptographie Reinhard Wobst: ``Abenteuer Kryptologie - Methoden, Risiken und Nutzen der Datenverschl sselung'' Addison-Wesley Verlag, M nchen, 1998. ISBN 3-8273-1413-5 Bruce Schneier: ``Applied Cryptography - Protocols, Algorithms, and Source Code in C'' John Wiley & Sons, 1995. ISBN 0-471-11709-9 Bruce Schneier: ``Angewandte Kryptographie - Protokolle, Algorithmen und Sourcecode in C'' Addison-Wesley Verlag, M nchen, 1996. ISBN 3-89319-854-7 Christopher Creutzig, Andreas Buhl und Philip Zimmermann: ``PGP Pretty Good Privacy - Der Briefumschlag f r Ihre elektronische Post'' Art D'Ameublement 1999. ISBN 3-9802182-9-5 Gisbert W. Selke: ``Kryptographie. Verfahren, Ziele, Einsatzm glichkeiten'' O'Reilly Verlag, K ln, 2000. ISBN 3-89721-155-6 Fu noten [1] Eine Person, die vors tzlich, unbefugterweise und oft mit b sartiger Absicht in fremde Rechnersysteme eindringt, im deutlichen Gegensatz zu ``Hacker'', womit ein gutmeinender Computer-Freak gemeint ist (RFC 1983) [2] GnuPG steht unter der sogenannten GNU General Public License (GPL) der Free Software Foundation, die im Anhang des Buches abgedruckt ist. [3] Eine einfache Hash-Funktion ist f(x) = 0 f r alle ganzen Zahlen x. Eine interessantere Hash-Funktion ist f(x) = x mod 37, welche x auf den Rest von x dividiert durch 37 abbildet. [4] Die Verschl sselung mu die Eigenschaft haben, da der aktuelle ffentliche oder private Schl ssel vom Verschl sselungsverfahren als der ffentliche Schl ssel benutzt werden k nnte. RSA ist ein Beispiel eines solchen Verfahrens, ElGamal dagegen nicht. [5] Mit der Option 3 l t sich ein ElGamal-Schl sselpaar erzeugen, mit dem Sie keine Unterschriften leisten k nnen. [6] Viele Kommandozeilen-Optionen, die h ufig benutzt werden, k nnen auch in einer Konfigurationsdatei definiert werden. [7] GnuPG berfrachtet das Wort ``Vertrauen'', indem sowohl ``Vertrauen in einen Eigent mer'' als auch ``Vertrauen in einen Schl ssel'' gemeint sein kann. Dies kann Verwirrung stiften. Manchmal wird das Vertrauen in einen Eigent mer zur klareren Unterscheidung als Ownertrust bezeichnet. In diesem Handbuch ist jedoch der Begriff ``Vertrauen'' durchweg in der Bedeutung ``Vertrauen in den Eigent mer eines Schl ssels'' benutzt worden, und der Begriff ``G ltigkeit'' bezieht sich darauf, da ein Schl ssel der mit der Schl ssel-ID verkn pften Person geh rt. [8] In diesem Abschnitt bezieht sich GnuPG sowohl auf die GnuPG-Implementierung von OpenPGP als auch auf andere Implementierungen wie das PGP-Produkt von NAI. [9] In den USA beispielsweise unterliegen kryptographische Produkte strengen Ausfuhrbestimmungen, die sich erst allm hlich - unter wirtschaftlichem und wissenschaftlichen Druck - zu lockern scheinen.