home *** CD-ROM | disk | FTP | other *** search
Text File | 1994-03-13 | 123.0 KB | 2,857 lines |
- Phils Pretty Good Software
- präsentiert:
-
- =====
- PGP
- =====
-
-
- Pretty Good Privacy
- Prima Geschützte Privatsphäre
- Chiffrierung mit öffentlichen Schlüsseln für die Allgemeinheit
-
-
-
- --------------------------
- PGP Handbuch
- Teil II: Spezielle Themen
- --------------------------
- von Philip Zimmermann
- Überarbeitet am 14. Juni 1993
-
- Übersetzt von
- Christopher Creutzig und Abel Deuring
-
-
- PGP Version 2.3a
- 1. Juli 1993
- Software von
- Philip Zimmermann
- sowie
- Branko Lancester, Hal Finney und Peter Gutmann
-
-
-
- Zusammenfassung: PGP verwendet eine System mit öffentlichen
- Schlüsseln für die Verschlüsselung von E-Mail und von Dateien.
- Es ermöglicht eine sichere Kommunikation zwischen Personen, die
- nie direkt getroffen haben müssen. Ein abhörsicherer Kanal für
- den Austausch eines Schlüssels ist nicht erforderlich. PGP
- bietet viele Möglichkeiten und ist schnell. Es hat eine
- ausgefeilte Schlüsselverwaltung, bietet digitale
- Unterschriften, komprimiert die unverschlüsselten Daten, und
- hat eine ergonomische Oberfläche.
-
-
- Copyright (c) für Programm und Dokumentation: Philip Zimmermann.
- Informationen zur Lizensierung von PGP, Distribution,
- Copyrights, Warenzeichen, Gewährleistungen,
- Exportbeschränkungen enthält der Abschnitt "Rechtsfragen"
- Inhalt
- ======
-
- Kurzbeschreibung
- Spezielle Themen
- Auswahl eines Schlüssels über seine Schlüssel-ID
- Trennung der Unterschrift von der Nachricht
- Entschlüsselung einer Nachricht und Speicherung zusammen mit
- einer Unterschrift
- Der Austausch von ASCII-Text zwischen unterschiedlichen
- Computern
- Vermeidung von "Spuren des Klartextes" auf des Festplatte
- Anzeige des entschlüsselten Klartextes am Bildschirm
- Verschlüsseln einer Nachricht "nur für Augen der EmpfängerIn"
- Beibehaltung des originalen Dateinamens des Klartextes
- Ändern der BenutzerIn-ID und des Mantra
- Ändern der Vertrauensparameter für einen öffentlichen
- Schlüssel
- Prüfen, ob eine Datei mit öffentlichen Schlüsseln intakt ist
- telefonische Kontrolle eines öffentlichen Schlüssel
- PGP als Filterprogramm im Unix-Stil
- Unterdrückung nicht unbedingt notwendiger Fragen: BATCHMODE
- "Ja" als Standardantwort bei Bestätigungsabfragen: FORCE
- Der Beendigungscode (exit code) von PGP
- Umgebungsvariable (environment variable) für das Mantra
- Einstellen der Konfigurationsparameter: CONFIG.TXT
- TMP - Name des Verzeichnis für temporäre Dateien
- LANGUAGE - Auswahl der Sprache für Textmeldungen von PGP
- MYNAME - Standard-BenutzerIn-ID für Unterschriften
- TEXTMODE - standardmäßig ASCII-Text verschlüsseln
- CHARSET - Der Zeichensatz Ihres Computers
- ARMOR - ASCII Darstellung einer verschlüsselten Datei
- ARMORLINES - maximale Größe von ASCII-dargestellten Dateien
- KEEPBINARY - verschlüsselte Binärdatei nach Entschlüsselung
- nicht löschen
- COMPRESS - Datenkompression ein- oder ausschalten
- COMPLETES_NEEDED - Anzahl der erforderlichen voll
- vertrauenswürdigen Unterschriften
- MARGINALS_NEEDED - Anzahl der erforderlichen teilweise
- vertrauenswürdigen Unterschriften
- CERT_DEPTH - Schachtelungstiefe von Unterschriften
- BAKRING - Dateiname der Sicherheitskopie der Datei mit
- geheimen Schlüsseln
- PAGER - Auswahl der Programms für die Textanzeige am
- Bildschirm
- SHOWPASS - Anzeige des Mantra während der Eingabe
- TZFIX - Zeitzonenkorrektur
- CLEARSIG - Nachrichten im Klartext mit ASCII-Unterschrift
- VERBOSE - keine, normale oder ausführliche Meldungen
- INTERACTIVE - Bestätigungsabfrage beim Hinzufügen von
- öffentlichen Schlüsseln
- Schutz gegen gefälschte Zeitangaben
- Ein Blick aufs Detail
- Zufallszahlen
- Der konventionelle Verschlüsselungsalgorithmus bei PGP
- Datenkomprimierung
- Textprüfsummen (message digests) und digitale Unterschriften
- Kompatibilität mit alten Versionen von PGP
- Angriffsmöglichkeiten
- Bekannt gewordenes Mantra und bekannt gewordener geheimer
- Schlüssel
- Fälschung des öffentlichen Schlüssels
- Nicht richtig gelöschte Dateien
- Viren und Trojanische Pferde
- Lücken in der physischen Sicherheit
- "Sturmangriffe" (tempest attacks)
- Probleme bei Mehrplatz-Computern
- Statistik von Nachrichtenverbindungen
- Kryptanalyse
- Rechtsfragen
- Warenzeichen, Copyright, Garantie
- Patentrechte auf die Algorithmen
- Lizensierung und Vertrieb
- Exportkontrolle [auf die USA bezogen d.Ü.]
- Computer-orientierte politische Vereinigungen [in den USA]
- Literatur
- Die Adresse des Autors
- Anhang: Bezugsquellen für PGP
-
- Kurzbeschreibung
- ================
-
- Pretty Good(tm) Privacy (PGP), von Phil's Pretty Good Software,
- ist ein sehr sicheres kryptographisches Programm für MSDOS,
- Unix, VAX/VMS, Commodore Amiga, Apple Macintosh und andere
- Computer. PGP kombiniert die Vorteile des
- Verschlüsselungsalgorithmus von Rivest, Shamir und Adleman
- (RSA), der mit öffentlichen Schlüsseln arbeitet, mit der
- Geschwindigkeit konventioneller Verschlüsselung, mit
- Textprüfsummen für digitale Unterschriften, mit guter Ergonomie
- und einem ausgefeilten System zur Schlüsselverwaltung.
-
- Dieser zweite Teil des Handbuchs beinhaltet spezielle Themen,
- die nicht im ersten Teil "Grundlagen" enthalten sind. Das Lesen
- dieses Teils ohne Kenntnis des ersten ist nicht sehr sinnvoll.
- Andererseits ist die Kenntnis dieses zweiten Teils für die
- Benutzung von PGP nicht unbedingt erforderlich.
-
-
-
- Spezielle Themen
- ================
-
-
- Auswahl eines Schlüssels über seine Schlüssel-ID
- ------------------------------------------------
-
- Bei allen Kommandos, die die Angabe einer BenutzerInnen-ID oder
- eines Teils der BenutzerInnen-ID erfordern, kann statt dessen
- auch die hexadezimale Schlüssel-ID benutzt werden. In diesem
- Fall muß vor der Schlüssel-ID ein "0x" geschrieben werden.
- Beispiel:
-
- pgp -kv 0x67F7
-
- listet alle Schlüssel, in denen 67F7 ein Teil der Schlüssel-ID
- ist.
-
- Diese Option ist insbesondere dann praktisch, wenn es von einer
- Person zwei verschiedene Schlüssel mit ein und derselben
- BenutzerIn-ID gibt. In diesem Fall läßt sich mit Hilfe der
- Schlüssel-ID einer der beiden Schlüssel eindeutig auswählen.
-
-
-
- Trennung der Unterschrift von der Nachricht
- -------------------------------------------
-
- Normalerweise wird eine Unterschrift in der selben Datei
- gespeichert wie der Text, der unterschrieben wird. Dadurch ist
- die Prüfung einer Unterschrift in den meistens Fällen einfach
- und bequem möglich. Unter bestimmten Umständen ist es aber
- sinnvoll, die Unterschrift in einer eigenen Datei, unabhängig
- von der Textdatei, zu speichern. Hierfür dient die Option "b"
- (für "break") zusammen mit der Option "s" (für "sign").
- Beispiel:
-
- pgp -sb letter.txt
-
- Hier wird eine Datei "letter.sig" erzeugt, die nur die
- Unterschrift enthält. Der Inhalt der Datei "letter.txt" wird
- nicht in "letter.sig" gespeichert.
-
- Wenn die Unterschrift in einer eigenen Datei ("letter.sig" in
- obigem Beispiel) erzeugt wurde, werden beide Dateien (im
- Beispiel "letter.sig" und "letter.txt") an die EmpfängerIn
- geschickt. Sie benötigt beide Dateien, um die Echtheit
- Unterschrift zu prüfen. Wenn sie die Datei mit der Unterschrift
- durch PGP bearbeiten läßt, stellt das Programm fest, daß diese
- Datei keinen Text enthält, und fragt die BenutzerIn nach dem
- Namen der Textdatei. Erst danach kann PGP die Unterschrift
- prüfen. Wenn die EmpfängerIn bereits weiß, daß Text und
- Unterschrift in getrennten Dateien gespeichert sind, kann sie
- auch beide Dateinamen in der Kommandozeile angeben:
-
- pgp letter.sig letter.txt
- oder:
- pgp letter letter.txt
-
- In diesem Fall fragt PGP nicht nach dem Namen der Textdatei.
-
- Die Unterschrift in einer eigenen Datei zu speichern, ist dann
- sinnvoll, wenn die Unterschriften unabhängig vom Text
- protokolliert werden sollen. Die abgetrennte Unterschrift ist
- auch für die Dateien mit ausführbaren Programmen (bei MSDOS:
- *.EXE und *.COM) sinnvoll, um eine Virusprüfung durchzuführen.
- Sie ist auch dann sinnvoll, wenn mehrere Personen ein Dokument
- (beispielsweise einen Vertrag) unterschreiben sollen, ohne daß
- die Unterschriften "verschachtelt" werden. Die Unterschrift
- jeder einzelnen Person wird unabhängig von den anderen
- gespeichert.
-
- Wenn man eine verschlüsselte Nachricht erhält, bei der
- Unterschrift und Text in einer Datei stehen, kann die
- Unterschrift auch nachträglich vom Text getrennt werden. Dies
- geschieht mit der "-b" Option bei der Entschlüsselung:
-
- pgp -b letter
-
- Hier wird "letter.pgp" entschlüsselt. Falls eine Unterschrift
- vorhanden ist, wird sie geprüft und in einer eigenen Datei
- "letter.sig" gespeichert.
-
-
- Entschlüsselung einer Nachricht und Speicherung zusammen mit
- -------------------------------------------------------------
- einer Unterschrift
- ------------------
-
- Normalerweise will man eine verschlüsselte Nachricht
- vollständig entschlüsseln, die Unterschrift (oder mehrere
- verschachtelte Unterschriften) prüfen, und hierbei eine
- "Schicht" nach der anderen abtrennen, bis der originale
- Klartext übrig bleibt.
-
- Manchmal will man aber die Nachricht nur entschlüsseln, und die
- Unterschriften bei der Nachricht belassen. Dies ist
- beispielsweise dann sinnvoll, wenn man die Kopie einer
- unterschriebenen Nachricht an eine dritte Person weiterleiten
- möchte, gegebenenfalls erneut verschlüsselt. Angenommen, es
- kommt eine Nachricht, die Charlie unterschrieben hat,
- verschlüsselt mit dem öffentlichen Schüssel der EmpfängerIn.
- Die Nachricht soll entschlüsselt, und zusammen mit Charlie's
- Unterschrift an Alice weitergeleitet werden, gegebenenfalls mit
- ihrem öffentlichen Schlüssel verschlüsselt. Mit PGP kein
- Problem.
-
- Mit folgendem Kommando wird eine Nachricht entschlüsselt, ohne
- daß die Unterschriften abgetrennt werden:
-
- pgp -d letter
-
- Hier wird die Datei "letter.pgp" entschlüsselt, und
- Unterschriften werden, falls vorhanden, zusammen mit dem
- entschlüsselten Klartext in der Ausgabedatei gespeichert.
-
- Die Ausgabedatei kann archiviert werden, oder, gegebenenfalls
- wieder verschlüsselt, an eine andere Person weitergeleitet
- werden.
-
-
-
- Der Austausch von ASCII-Text zwischen unterschiedlichen
- --------------------------------------------------------
- Computern.
- ----------
-
- Mit PGP kann jede Art von "Klartext" verschlüsselt werden,
- irgendwelche Binärdaten ebenso wie ASCII-Text. Wahrscheinlich
- wird PGP am häufigsten für die Verschlüsselung von E-Mail
- benutzt, so daß der "Klartext" aus ASCII-Daten besteht.
-
- ASCII-Text wird aus verschiedenen Computern leicht
- unterschiedlich dargestellt. Beispielsweise endet eine Zeile
- bei MSDOS mit den beiden Zeichen für "Wagenrücklauf" und
- "Zeilenvorschub" (carriage return / line feed). Bei Unix endet
- eine Zeile nur mit dem Zeichen für "Zeilenvorschub". Beim
- Macintosh endet eine Zeile mit dem Zeichen für "Wagenrücklauf",
- ohne "Zeilenvorschub". Traurig, aber wahr.
-
- Nicht verschlüsselte ASCII-Daten werden bei E-mail-Systemen
- normalerweise in eine "kanonische", maschinenunabhängige Form
- gebracht, wenn sie zwischen zwei Computern ausgetauscht werden.
- Bei kanonischer Textdarstellung besteht ein Zeilenende aus den
- Zeichen "Wagenrücklauf" und "Zeilenvorschub". Beispielsweise
- konvertiert das weit verbreiteten KERMIT den ASCII-Text in
- diese kanonische Form, bevor der Text an einen anderen Computer
- gesendet wird, und das KERMIT auf dem Computer, der den Text
- empfängt, konvertiert ihn wieder in diejenige Form, die sein
- Betriebssystem braucht. Dadurch ist es einfach, Texte zwischen
- verschiedenen Computern auszutauschen.
-
- Diese automatische Anpassung der Textdarstellung an das
- jeweilige Betriebssystem ist bei verschlüsselten Nachrichten
- nicht möglich, weil der Klartext durch die Verschlüsselung dem
- Übertragungsprogramm verborgen bleibt. Diese Aufgabe muß das
- Verschlüsselungsprogramm übernehmen. Deshalb kann man bei PGP
- angeben, ob der "Klartext" als Binärdaten oder als ASCII-Text
- angesehen werden soll. In letzterem Fall wird der Klartext vor
- der Verschlüsselung in kanonische Form gebracht. Bei der
- Entschlüsselung wird er dann in die Form gebracht, die für das
- Betriebssystem des Computers, auf dem entschlüsselt wird,
- geeignet ist.
-
- Wenn die Option "t" beim Verschlüsseln und / oder
- Unterschreiben einer Nachricht mit angegeben wird, konvertiert
- PGP den Text vor der Verschlüsselung bzw. dem Unterschreiben in
- die kanonische Form:
-
- pgp -et message.txt EmpfängerIn_ID
-
- Diese Option schaltet PGP automatisch ab, sobald es in der zu
- verschlüsselnden Datei Daten findet, die es nicht als Text
- betrachtet.
-
- Falls der Klartext aus einem 8 Bit Zeichensatz besteht, falls
- er also mehr Zeichen enthält als der ASCII-Standard für den
- englischen Zeichensatz, verwendet PGP gegebenenfalls bei der
- Konvertierung in die kanonische Form den Zeichensatz LATIN1
- (ISO 8859-1 Latin Alphabet 1). Dies hängt davon ab, was als
- Parameter "CHARSET" in der PGP-Konfigurationsdatei eingetragen
- ist. LATIN1 ist eine Obermenge von ASCII, mit diakritischen
- Zeichen für viele europäische Sprachen.
-
-
-
- Vermeidung von "Spuren des Klartextes" auf des Festplatte
- ---------------------------------------------------------
-
- Nachdem PGP eine Datei verschlüsselt hat, kann es bei Bedarf
- die Klartext-Datei überschreiben und danach löschen, so daß
- keine "Spuren" des Klartextes auf der Festplatte verbleiben.
- Dies verhindert, daß der Klartext mit einem Sektor-Editor oder
- einem ähnlichen Programm noch gelesen werden kann. Diese Option
- ist sinnvoll, um zu vermeiden, daß vertrauliche Informationen
- unkontrolliert auf der Festplatte verbleiben.
-
- Um den Klartext nach der Verschlüsselung und/oder dem
- Unterschreiben von der Festplatte zu löschen, wird die Option
- "w" (wipe = wischen) verwendet:
-
- pgp -esw message.txt EmpfängerIn_ID
-
- Hier wird eine verschlüsselte, unterschriebene Datei
- "message.pgp" erzeugt, und die Klartext-Datei wird danach
- überschrieben und gelöscht.
-
- Diese Option sollte mit Vorsicht benutzt werden. Zudem muß
- betont werden, daß hierdurch keinerlei Fragmente der Klartextes
- gelöscht werden, die ein Textverarbeitungsprogramm häufig auf
- der Festplatte ablegt, wenn man einen Text eintippt und
- bearbeitet. Die meisten Textverarbeitungsprogramm erzeugen
- Backup-Dateien und benutzen temporäre Dateien. Außerdem wird
- die Klartext-Datei nur einmal überschrieben. Das ist zwar
- ausreichend, um ein Lesen des Klartextes mit den üblichen
- Werkzeugen der Datenwiederherstellung zu verhindern, reicht
- aber nicht aus, um einen gezielten und ausgefeilten Leseversuch
- zu abzuwehren, bei dem eine schwache Restmagnetisierung der
- überschriebenen Daten mittels spezieller Hardware ausgewertet
- wird. [Weiteres hierzu steht weiter unten im Abschnitt "Nicht
- richtig gelöschte Dateien" d.Ü.]
-
-
-
- Anzeige des entschlüsselten Klartextes am Bildschirm
- ----------------------------------------------------
-
- Um den entschlüsselten Klartext nur am Bildschirm zu lesen
- (ähnlich dem Unix-Kommando "more"), ohne daß er in eine Datei
- geschrieben wird, kann die Option "-m" ("more") verwendet
- werden:
-
- pgp -m letter.pgp
-
- Dieser Befehl zeigt den entschlüsselten Klartext am Bildschirm
- an. [Mit den Tasten "Leertaste", "Return", "b" kann im Text
- "geblättert" werden. Mit "q" wird das Lesen beendet. Diese
- Befehle gelten für die PGP-interne Textanzeigefunktion. Durch
- einen entsprechenden Eintrag in der Datei "config.txt" kann
- auch ein anderes Programm für die Textanzeige am Bildschirm
- gewählt werden. d.Ü.]
-
-
-
- Verschlüsseln einer Nachricht "nur für Augen der EmpfängerIn"
- -------------------------------------------------------------
-
- Um festzulegen, daß die EmpfängerIn den entschlüsselten
- Klartext NUR am Bildschirm lesen, ihn aber nicht in eine Datei
- schreiben kann, kann die Option "-m" bei Verschlüsseln
- verwendet werden:
-
- pgp -sem message.txt EmpfängerIn_ID
-
- Wenn die EmpfängerIn eine so verschlüsselte Nachricht mit ihrem
- privaten Schlüssel und ihrem Mantra entschlüsselt, wird der
- Klartext nur auf ihrem Bildschirm angezeigt, aber nicht auf der
- Festplatte gespeichert. Die Textanzeige erfolgt auf dem
- Bildschirm so, wie zuvor unter "Anzeige des entschlüsselten
- Klartextes am Bildschirm" beschrieben. Wenn die EmpfängerIn die
- Nachricht ein zweites Mal lesen will, muß sie die Nachricht
- erneut entschlüsseln.
-
- Diese Option ist der sicherste Weg, um zu verhindern, daß
- vertrauliche Nachrichten versehentlich als Klartext auf der
- Festplatte der EmpfängerIn "liegen bleiben". Diese Option wurde
- in PGP auf Anfrage eines Benutzers eingebaut, der seiner
- Liebsten intime Nachrichten schicken wollte, aber befürchtete,
- daß sie unabsichtlich eine entschlüsselte Nachricht auf dem
- Computer ihres Ehemanns "liegen lassen" könnte.
-
-
-
- Beibehaltung des originalen Dateinamens des Klartextes
- -----------------------------------------------------
-
- Normalerweise gibt PGP der Datei mit dem entschlüsselten
- Klartext den gleichen Namen wie der Datei mit dem
- verschlüsselten Text, aber ohne Suffix. Ein anderer Name für
- die Klartext-Datei kann mit der Option "-o" festgelegt werden.
- Bei den meisten E-Mail-Nachrichten ist dies sinnvoll, weil man
- so den Dateinamen bei der Entschlüsselung festlegen kann, und
- typische E-Mail-Nachrichten häufig unbrauchbare originale
- Dateinamen wie "to_phil.txt" oder "crypted.msg" haben.
-
- Wenn PGP eine Klartext-Datei verschlüsselt, fügt es den
- originalen Dateinamen dem Klartext vor der Komprimierung bei.
- Normalerweise verwendet PGP diesen originalen Dateinamen bei
- der Entschlüsselung nicht, aber bei Bedarf kann PGP angewiesen
- werden, der entschlüsselte Klartext-Datei diesen Namen zu
- geben. Das ist sinnvoll, wenn PGP dazu benutzt wird, Dateien zu
- ver- und entschlüsseln, deren Name von Bedeutung ist. [Bei der
- Amiga-Version von PGP ist letzteres die Standard-Einstellung.
- d.Ü.]
-
- Um den originalen Namen der Klartext-Datei bei der
- Entschlüsselung zu erhalten, kann die Option "-p" (preserve)
- verwendet werden:
-
- pgp -p verschlüsselte_datei
-
- Ich benutze diese Option normalerweise nicht, weil andernfalls
- ungefähr die Hälfte der an mich gerichteten E-Mail-Nachrichten
- den gleichen Dateinamen wie "to_phil.txt" oder "prz.txt"
- hätten.
-
-
-
- Ändern der BenutzerIn-ID und des Mantra
- ---------------------------------------
-
- Ab und zu kann es erforderlich sein, das Mantra zu ändern,
- beispielsweise dann, wenn jemand beim Eintippen des Mantra
- zugeschaut hat.
-
- Oder die BenutzerIn-ID muß geändert werden, wegen Heirat, oder
- wegen einer geänderten E-Mail-Adresse. Oder es soll dem
- Schlüssel eine zweite oder dritte BenutzerIn-ID hinzugefügt
- werden, um mehrere E-Mail-Adressen oder Berufsbezeichnungen
- einzutragen. Mit PGP können einem Schlüssel mehrere BenutzerIn-
- IDs hinzugefügt werden, und jede dieser IDs kann für die
- Auswahl des Schlüssel aus der Datei mit den öffentlichen
- Schlüsseln (keyring) verwendet werden.
-
- Die eigene BenutzerIn-ID und das Mantra kann mit folgendem
- Kommando geändert werden:
-
- pgp -ke BenutzerIn-ID [schlüsseldatei]
-
- PGP fragt dann nach der neuen BenutzerIn-ID und dem neuen
- Mantra.
-
- Wenn der optionale Parameter [schlüsseldatei] angegeben wird,
- muß es sich um eine Datei mit öffentlichen Schlüsseln sein,
- nicht mit geheimen.
-
- Der Parameter "BenutzerIn-ID" muß die eigene ID sein. PGP
- erkennt dies daran, daß diese ID sowohl in der Datei mit
- öffentlichen Schlüsseln als auch in der Datei geheimen
- Schlüsseln auftaucht. Beide Dateien werden geändert, auch wenn
- ein eine Datei mit öffentlichen Schlüsseln als Parameter
- angegeben wurde.
-
-
-
- Ändern der Vertrauensparameter für einen öffentlichen Schlüssel
- ---------------------------------------------------------------
-
- Manchmal muß die Vertrauens-Einstellung für einen öffentlichen
- Schlüssel geändert werden. Was diese Vertrauensparameter sind,
- steht in Teil 1 des Handbuchs im Abschnitt "Öffentliche
- Schlüssel vor Manipulation schützen"
-
- Mit folgendem Befehl können die Vertrauensparameter für einen
- öffentlichen Schlüssel geändert werden:
-
- pgp -ke BenutzerIn-ID [schlüsseldatei]
-
- Wenn der optionale Parameter [schlüsseldatei] angegeben wird,
- muß es eine Datei mit öffentlichen Schlüsseln sein, keine Datei
- mit geheimen Schlüsseln.
-
-
-
- Prüfen, ob eine Datei mit öffentlichen Schlüsseln intakt ist
- ------------------------------------------------------------
-
- Normalerweise prüft PGP automatisch jeden Schlüssel und jede
- Unterschrift, die einer Datei mit öffentlichen Schlüssel
- hinzugefügt werden, und paßt automatisch die
- Vertrauenseinstellungen und Gültigkeitswert an. Theoretisch
- paßt es die Gültigkeitswerte für alle betroffenen Schlüssel an,
- wenn ein Schlüssel der Datei mit öffentlichen Schlüsseln
- hinzugefügt oder aus der Datei gelöscht wird. Manchmal möchte
- man aber auch dann eine umfassende Analyse haben, wenn keine
- Änderungen an der Datei erforderlich sind: Prüfen der
- Bestätigung(en) der einzelnen Schlüssel, Prüfen der
- Vertrauensparameter, Neuberechnung der Gültigkeitswerte, und
- Vergleich des eigenen, absolut vertrauenswürdigen Schlüssels
- mit der Sicherheitskopie auf einer schreibgeschützten Diskette.
- Es ist sinnvoll, diese Integritätsprüfung in regelmäßigen
- Abständen durchzuführen, um sicherzustellen, daß die Datei mit
- öffentlichen Schlüsseln wirklich intakt ist. Mit der Option
- "-kc" ("key ring check") führt PGP eine vollständige Analyse
- der Datei mit öffentlichen Schlüsseln aus:
-
- pgp -kc
-
- Mit folgendem Befehl prüft PGP die Unterschriften für einen
- bestimmten öffentlichen Schlüssel:
-
- pgp -kc BenutzerIn_ID [schlüsseldatei]
-
- Weitere Informationen darüber, wie der eigene Schlüssel mit
- einer Sicherheitskopie verglichen wird, stehen bei der
- Beschreibung des Parameters BAKRING im Abschnitt über die
- Konfigurationsdatei in diesem Handbuch.
-
-
-
- telefonische Kontrolle eines öffentlichen Schlüssel
- ---------------------------------------------------
-
- Es kann vorkommen, daß man einen öffentlichen Schlüssel
- bekommt, der nicht von einer anderen Person bestätigt ist, der
- man vertraut. Dann stellt sich die Frage, wie sich die Echtheit
- dieses Schlüssels feststellen läßt. Der beste Weg hierfür ist
- die Kontrolle des Schlüssels über einen anderen Kanal als den,
- über den der Schlüssel geschickt wurde. Wenn man die Person
- kennt, der der öffentliche Schlüssel gehört, und wenn man auch
- ihre Stimme am Telefon erkennt, besteht eine einfache und
- bequeme Lösung des Problems darin, sie anzurufen, und den
- Schlüssel im Gespräch zu kontrollieren. Hierzu braucht man sich
- nicht mühsam den ganzen - ASCII-dargestellten - Schlüssel
- vorzulesen. Es reicht, den verhältnismäßig kurzen "fingerprint"
- des Schlüssels zu vergleichen. Den "fingerprint" eines
- Schlüssel gibt PGP mit der Option "-kvc" aus:
-
- pgp -kvc BenutzerIn_ID [schlüsseldatei]
-
- PGP zeigt die BenutzerIn_ID zusammen mit dem 16 Byte langen
- "fingerprint" an. Wenn beide GesprächspartnerInnen diesen PGP-
- Befehl ausführen, können sie den Schlüssel anhand des
- "fingerprint" kontrollieren.
-
- Wenn die Echtheit sowohl des eigenen öffentlichen Schlüssel als
- auch des öffentlichen Schlüssels der GesprächspartnerIn
- überprüft ist, kann die Echtheit der Schlüssel wechselseitig
- durch eine Unterschrift bestätigt werden. Dies ist ein sicherer
- und komfortabler Weg, um mit dem Aufbau eines Netzes
- vertrauenswürdiger Schlüssel innerhalb eines Kreises von
- FreundInnen zu beginnen.
-
-
- PGP als Filterprogramm im Unix-Stil
- -----------------------------------
-
- Unix-Fans sind es gewöhnt, "pipes" zu verwenden, um Daten
- zwischen zwei Programm auszutauschen. Der Output eines
- Programms kann mittels einer "pipe" als Input in ein zweites
- Programm gelenkt werden. Damit dies funktioniert, müssen die
- Programme ihre Daten aus "standard input" lesen und nach
- "standard output" schreiben. PGP kann in dieser Form arbeiten.
- Falls Ihnen schleierhaft ist, was obiges zu bedeuten hat,
- werden Sie diese Möglichkeit wahrscheinlich auch nicht
- brauchen, so daß Sie diesen Abschnitt überlesen können.
-
- Wenn die -f Option verwendet wird, arbeitet PGP als Unix-
- Filter. Beispiel:
-
- pgp -feast BenutzerIn-ID <inputfile >outputfile
-
- Diese Option kann die Verwendung von PGP zusammen mit E-Mail-
- Programmen vereinfachen.
-
- Wenn man PGP als Unix-Filter verwendet, möglicherweise in einem
- Unix-Script oder in einer MSDOS-Batchdatei, kann es sinnvoll
- sein, die Umgebungsvariable PGPPASS zu verwenden, damit man das
- Mantra nicht erst dann eingeben muß, wenn PGP nach ihm fragt.
- PGPPASS ist weiter unten beschrieben.
-
-
-
- Unterdrückung nicht unbedingt notwendiger Fragen: BATCHMODE
- -----------------------------------------------------------
-
- Wird BATCHMODE in der PGP-Befehlszeile eingeschaltet, stellt
- PGP während des Programmlaufes keinerlei unnötige Fragen.
- Beispiel:
-
- pgp +batchmode verschlüsselte_datei
-
- Dies ist sinnvoll, wenn PGP aus Unix Shell-Scripts oder aus
- einer MSDOS-Batchdatei aufgerufen wird. Manche PGP-Befehle für
- die Schlüsselverwaltung brauchen in jedem Fall Eingaben durch
- die BenutzerIn. Sie sollten deshalb in Shell-Scripten vermieden
- werden.
-
- BATCHMODE kann auch bei der Prüfung der Echtheit einer
- Unterschrift verwendet werden. Ist die Unterschrift nicht in
- Ordnung, wird als Beendigungscode (exit code) 1 zurückgegeben.
- Bei einer intakten Unterschrift gibt PGP den Wert 0 zurück.
-
-
-
- "Ja" als Standardantwort bei Bestätigungsabfragen: FORCE
- --------------------------------------------------------
-
- FORCE veranlaßt PGP, "ja" als Standardantwort anzunehmen, wenn
- es danach fragt, ob eine bereits existierende Datei
- überschrieben werden soll, oder ob ein öffentlicher Schlüssel
- aus der Datei mit öffentlichen Schlüsseln mit "-kr" entfernt
- werden soll. Beispiel:
-
- pgp +force verschlüsselte_datei
-
- oder:
-
- pgp -kr +force smith
-
- FORCE kann praktisch sein, wenn PGP aus einer MSDOS-Batchdatei
- bzw. einem Unix-Script aufgerufen wird.
-
-
-
- Der Beendigungscode (exit code) von PGP
- ---------------------------------------
-
- Um der Betrieb von PGP aus Unix-Scripten oder MSDOS-
- Stapeldateien zu unterstützen, gibt PGP eine Statusmeldung aus
- die aufrufende Shell zurück. Ein Beendigungscode von Null
- bedeutet, daß kein Fehler auftrat; jeder andere Wert
- signalisiert einen Fehler. Jeder Fehler erzeugt einen anderen
- Code. [Näheres hierzu bitte den Quelltexten entnehmen :) d.Ü.]
-
-
-
- Umgebungsvariable (environment variable) für das Mantra
- -------------------------------------------------------
-
- Normalerweise fragt PGP das Mantra genau zu dem Zeitpunkt ab,
- wenn ein geheimer Schlüssel benötigt wird. Das Mantra kann aber
- auch in der Umgebungsvariablen PGPPASS gespeichert werden. Wenn
- PGPPASS definiert ist, versucht PGP, ihren Wert als Mantra für
- den Zugriff auf einen geheimen Schlüssel zu verwenden. Ist das
- in PGPPASS gespeicherte Mantra nicht korrekt, fragt PGP nach
- dem richtigen Mantra.
-
- Unter MSDOS könnte das Mantra so gesetzt werden:
-
- SET PGPPASS=Zaphod Beeblebrox wird
- Bundespräsident
-
- Die Eingabe eines Mantra während des Laufes von PGP ist dann
- nicht mehr erforderlich, vorausgesetzt, daß "Zaphod Beeblebrox
- wird Bundespräsident" wirklich das richtige Mantra ist.
-
- Die Verwendung von PGPPASS ist einerseits gefährlich, macht
- aber andererseits die Arbeit mit PGP wesentlich einfacher, wenn
- man regelmäßig größere Mengen verschlüsselter Nachrichten
- erhält.
-
- Die Auswertung einer Umgebungsvariablen (eben PGPPASS) habe ich
- auf vielfachen Wunsch hin in PGP aufgenommen. Die Verwendung
- von PGPPASS ist aber gefährlich, weil das Mantra dann nicht nur
- in Ihrem Gedächtnis, sondern auch irgendwo im Speicher Ihres
- Rechner steht. Leichtsinnig wäre es, das Mantra in einer Datei
- auf demselben Rechner speichern, auf dem auch Ihre Datei
- SECRING.PGP steht. Nicht nur sehr leichtsinnig, sondern einfach
- dumm wäre es, das Mantra in einer Batchdatei, am Ende gar
- AUTOEXEC.BAT, zu speichern. Jedermann könnte sich in der
- Mittagspause an Ihren Rechner setzen, und sowohl Ihr Mantra als
- auch die Datei mit Ihren geheimen Schlüssel mitgehen lassen.
-
- Die Gefährlichkeit von PGPPASS kann nicht stark genug betont
- werden. Bevor Sie sich überlegen, ob Sie PGPPASS trotzdem
- verwenden, sollten Sie auf jeden Fall die Abschnitte "Probleme
- bei Mehrplatzcomputern" und "Öffentliche Schlüssel vor
- Manipulation schützen" im ersten und im zweiten Teil des
- Handbuches genau lesen.
-
- Falls Sie PGPPASS unbedingt brauchen, ist es am sichersten, das
- Kommando zum Setzen von PGPPASS unmittelbar vor der Benutzung
- von PGP einzutippen, und unmittelbar nach der Benutzung von PGP
- PGPPASS wieder zu löschen, oder den Computer auszuschalten. Sie
- sollten PGPPASS auf keinen Fall verwenden, wenn andere Personen
- Zugang zu Ihrem Computer haben. Es könnte jemand vorbeikommen
- und Ihr Mantra ganz einfach durch Abfragen der
- Umgebungsvariablen herausfinden.
-
-
-
- Einstellen der Konfigurationsparameter: CONFIG.TXT
- ==================================================
-
- PGP kann über einige einstellbare Parameter
- anwendungsspezifisch konfiguriert werden. Diese Parameter
- stehen in der Textdatei "config.txt". "config.txt" muß in
- demjenigen Verzeichnis stehen, das durch die Umgebungsvariable
- PGPPATH angegeben wird. Durch die Einstellungen in "config.txt"
- kann PGP bequem auf die individuellen Bedürfnisse angepaßt
- werden, so daß es nicht erforderlich ist, bei jedem Aufruf von
- PGP mühsam eine größere Anzahl von Parametern in die
- Kommandozeile einzutippen.
-
- Die einzelnen Konfigurationsparameter können je nach Typ als
- Wert ganze Zahlen, Zeichenketten (also Text), oder "on/off"
- ("ein/aus") haben. Eine Beispielkonfiguration, an der man sich
- bei der individuellen Einstellung orientieren kann, ist PGP
- beigelegt.
-
- Leere Zeilen werden in "config.txt" ignoriert, ebenso alles,
- was in einer Zeile rechts von einem '#', der
- Kommentarmarkierung, steht. [Beachten Sie, daß in der
- Beispielkonfiguration die Zeilen für die Einstellung mancher
- Parameter ebenfalls mit einem '#' beginnen. Für die Aktivierung
- dieser Parametereinstellung muß das '#' am Zeilenanfang
- gelöscht werden. Die Verwendung eines '#' ist auch sinnvoll, um
- mehrere Parametereinstellungen auszuprobieren, ohne die Texte
- der einzelnen Einstellungen zu löschen. Beispiel:
-
- # Die folgende Einstellung ist besser, wenn
- Texte zu
- # ver- oder entschlüsseln sind, die unter
- Windows
- # bearbeitet wurden:
- # charset = latin1
- # Für MSDOS ist das folgende besser:
- charset = cp850
-
- Hier wertet PGP nur die Zeile "charset = cp850" aus; die Zeile
- "charset = latin1" wird ignoriert. Durch einfaches "Umstellen"
- des '#' kann die obere Einstellung aktiviert werden. d.Ü.]
- Bei den Parameternamen wird nicht zwischen Groß- und
- Kleinschreibung unterschieden.
-
- Ein Ausschnitt aus einer typischen Konfigurationsdatei:
-
- # TMP is the directory for PGP scratch files, such as a RAM disk.
- TMP = "e:\" # Can be overridden by environment variable TMP.
- Armor = on # Use -a flag for ASCII armor whenever applicable.
- # CERT_DEPTH is how deeply introducers may introduce introducers.
- cert_depth = 3
-
- Wenn bestimmte Parameter nicht in "config.txt" definiert sind,
- oder wenn diese Datei nicht existiert, oder wenn PGP die Datei
- nicht findet, setzt es automatisch sinnvolle Standardwerte ein.
-
- Die Parameter aus "config.txt" können auch in der Kommandozeile
- angegeben werden. Dadurch ist es möglich, im Einzelfall mit
- anderen Parametern zu arbeiten, ohne daß "config.txt" extra
- hierfür geändert werden muß. Die beiden Kommandos im
- nachfolgenden Beispiel haben dasselbe Ergebnis:
-
- pgp -e +armor=on brief.txt mueller
- pgp -ea brief.txt mueller
-
- Zu den einzelnen Parametern in "config.txt":
-
-
-
- TMP - Name des Verzeichnis für temporäre Dateien
- ------------------------------------------------
-
- Standardeinstellung: TMP = ""
-
- TMP gibt an, welches Verzeichnis PGP für temporäre Dateien
- verwendet. Ein sinnvoller Platz für temporäre Dateien ist -
- falls vorhanden - eine RAM-Disk. Bei Verwendung einer RAM-Disk
- wird PGP etwas schneller, zudem wird die Sicherheit ein wenig
- gesteigert. Wenn TMP nicht definiert ist, werden temporäre
- Dateien im aktuellen Verzeichnis gespeichert. Falls eine
- Umgebungsvariable TMP definiert ist, verwendet PGP deren Wert
- als Namen des Verzeichnisses für temporäre Dateien.
-
-
- LANGUAGE - Auswahl der Sprache für Textmeldungen von PGP
- --------------------------------------------------------
-
- Standardeinstellung: LANGUAGE = en
-
- PGP gibt eine Reihe von Anfragen, Warnungen und Erläuterungen
- am Bildschirm aus. Normalerweise erscheinen diese Texte auf
- englisch. PGP kann so angepaßt werden, daß es diese Meldungen
- in anderen Sprachen ausgibt, ohne daß die Datei mit dem
- ausführbaren Programm (also z.B. PGP.EXE für MSDOS) geändert
- werden muß.
-
- Eine Reihe von Menschen aus verschiedenen Ländern haben die
- Textmeldungen von PGP in ihre Muttersprache übersetzt. Diese
- übersetzten Texte stehen in einer speziellen Datei namens
- "language.txt", die im PGP-Programmpaket enthalten ist.
- "language.txt" kann die Meldungen in mehreren Sprachen
- enthalten. Zur Zeit existieren neben den originalen englischen
- Texten Übersetzungen in Spanisch, Holländisch, Deutsch,
- Französisch, Italienisch, Russisch, Litauisch und Lettisch.
- Andere Sprachen können problemlos ergänzt werden.
-
- Mit dem Parameter LANGUAGE wird festgelegt, in welcher Sprache
- die Meldungen anzeigt werden sollen. LANGUAGE kann folgende
- Werte annehmen:
-
- "en" für Englisch "es" für Spanisch
- "de" für Deutsch "nl" für Holländisch
- "fr" für Französisch "it" für Italienisch
- "ru" für Russisch "lt3" für Litauisch
- "lv" für Lettisch "esp" für Esperanto.
-
- Bei der Einstellung:
-
- LANGUAGE = fr
-
- würden beispielsweise die Texte auf Französisch erscheinen -
- vorausgesetzt, LANGUAGE.TXT enthält französische Texte.
-
- Wenn PGP eine Meldung am Bildschirm anzeigen muß, sucht es in
- "language.txt" nach dem Text in der gewählten Sprache. Falls
- PGP die Datei nicht findet, oder wenn Texte in der gewählten
- Sprache in "language.txt" nicht vorhanden sind, oder wenn eine
- einzelne Meldung nicht übersetzt ist, wird der englische Text
- ausgegeben.
-
- Um Festplatten- und Diskettenplatz zu sparen, sind die meisten
- Übersetzungen nicht im Standard-PGP-Paket enthalten. Sie können
- aber getrennt erhältlich. [vgl. hierzu "Anhang: Bezugsquellen
- für PGP" am Ende dieses Textes. d.Ü.]
-
- [Sollen auch die Hilfetexte von PGP (Kommando "pgp -h" in einer
- anderen Sprache als englisch ausgegeben werden, muß außerdem
- eine Datei namens "???.hlp" existieren, wobei "???" für einen
- der oben genannten Werte steht, also z.B. "de.hlp" für Deutsch.
- d.Ü.]
-
-
-
- MYNAME - Standard-BenutzerIn-ID für Unterschriften
- --------------------------------------------------
-
- Standardeinstellung: MYNAME = ""
-
- Mit MYNAME kann ausgewählt werden, welchen geheimen Schlüssel
- PGP automatisch für Unterschriften wählt. Wenn MYNAME nicht
- definiert ist, wird der neueste geheime Schlüssel verwendet.
- Wenn die Option "-u BenutzerIn_ID" beim Aufruf von PGP
- angegeben wird, hat diese Auswahl Vorrang vor der Auswahl durch
- MYNAME.
-
-
- TEXTMODE - standardmäßig ASCII-Text verschlüsseln
- -------------------------------------------------
-
- Standardeinstellung: TEXTMODE = off (aus)
-
- Der Parameter TEXTMODE ist äquivalent zu der Kommandozeilen-
- Option "-t". Wenn "TEXTMODE=on" (ein) gewählt wird, geht PGP
- davon aus, daß die zu verschlüsselnden Daten kein Binärdaten,
- sondern ASCII-Text sind. Dann werden die Daten vor der
- Verschlüsselung in "kanonische Form" konvertiert. Text in
- kanonischer Form hat als Zeilentrennung die Zeichen
- "Wagenrücklauf" (carriage Return) und "Zeilenvorschub" (line
- feed).
-
- PGP schaltet die Konvertierung in kanonische Form automatisch
- aus, wenn es Daten erkennt, die es für Binärdaten hält.
-
- In der gegenwärtigen VAX/VMS-Implementierung ist "TEXTMODE=on"
- den Standardeinstellung.
-
- Genaueres zu Fragen der Textkonvertierung steht weiter oben in
- diesem Handbuch im Abschnitt "Der Austausch von ASCII-Text
- zwischen unterschiedlichen Computern."
-
-
-
- CHARSET - Der Zeichensatz Ihres Computers
- -----------------------------------------
-
- Standardeinstellung: CHARSET = NOCONV
-
- PGP kann die Sonderzeichen vieler Sprachen für die Zeichensätze
- verschiedener Computer konvertieren. Damit dies korrekt
- funktioniert, müssen Sie den Parameter CHARSET richtig
- einstellen. Diese Konvertierung erfolgt nur bei der
- Verschlüsselung von Textdateien. Falls Sie mit PGP
- ausschließlich Texte verschlüsseln, die nur Buchstaben des
- "normalen Alphabet", also keine Umlaute, Buchstaben mit
- Akzenten oder anderen diakritischen Zeichen, enthalten, ist der
- Parameter CHARSET für Sie unwichtig.
-
- CHARSET teilt PGP mit, welchen Zeichensatz Ihr Computer
- verwendet. CHARSET kann folgende Werte annehmen:
-
- NOCONV - keine Konvertierung
- LATIN1 - ISO 8859-1 Lateinisches Alphabet 1
- KOI8 - verwendet auf vielen russischen
- Unix-Anlagen
- ALT_CODES - verwendet auf russischen MSDOS-
- Computern
- ASCII
- CP850 - für die meisten westeuropäischen
- Sprachen
- unter MSDOS
-
- LATIN1 verwendet PGP für die interne kanonische
- Textdarstellung. Wenn also CHARSET = LATIN1 gewählt wird,
- findet keine Zeichenkonvertierung statt. Zu beachten ist, daß
- PGP auch KOI8 wie LATIN1 behandelt, obwohl KOI8 für einen
- völlig anderen Zeichensatz (kyrillisch) steht. Eine
- Konvertierung von KOI8 in LATIN1 oder CP850 wäre sinnlos. Die
- Einstellungen NOCONV, LATIN1 und KOI8 sind für PGP äquivalent.
-
- Wenn Sie mit MSDOS arbeiten und Nachrichten verschicken oder
- erhalten, die in einer westeuropäischen Sprache geschrieben
- sind, sollten Sie "CHARSET=CP850" einstellen. Wenn Sie eine
- Nachricht mit der Option "-t" oder "TEXTMODE=on" verschlüsseln,
- konvertiert PGP Ihren CP850-Text vor der Verschlüsselung in den
- LATIN1-Zeichensatz. Bei der Entschlüsselung wird LATIN1 in
- CP850 umgewandelt.
-
- Weiteres hierzu steht weiter oben in diesem Handbuch im
- Abschnitt "Der Austausch von ASCII-Text zwischen
- unterschiedlichen Computern."
-
-
- ARMOR - ASCII Darstellung einer verschlüsselten Datei
- -----------------------------------------------------
-
- Standardeinstellung: ARMOR = off (aus)
-
- Der Parameter ARMOR ist äquivalent zur Kommandozeilenoption
- "-a". Wenn "ARMOR=on" (ein) gewählt wird, stellt PGP die
- verschlüsselten Daten im Radix-64-Format dar. Die Format ist
- für den Versand über manche E-Mail-Kanäle sinnvoll. Die von PGP
- erzeugten Dateien im Radix-64-Format haben das Suffix ".asc".
-
- Wenn Sie PGP hauptsächlich für E-Mail einsetzen, kann es
- sinnvoll sein, "ARMOR=on" (ein) zu wählen.
-
- Weiteres hierzu steht im ersten Teil des Handbuches im
- Abschnitt "Versand von Nachrichten im Radix-64 Format".
-
-
- ARMORLINES - maximale Größe von ASCII-dargestellten Dateien
- -----------------------------------------------------------
-
- Standardeinstellung: ARMORLINES = 720
-
- Wenn PGP eine sehr große Datei im Radix-64 Format erzeugen
- soll, teilt es diese Datei in mehrere Dateien auf, die jeweils
- klein genug sind, um im Internet versandt zu werden.
- Normalerweise lassen Mailer-Programme für das Internet keine
- Nachrichten zu, die mehr als ca. 50000 Byte groß sind. Eine
- Datei mit 720 Zeilen im Radix-64 Format liegt weit genug unter
- dieser Grenze, um problemlos versandt werden zu können. Die
- einzelnen Dateien, die PGP erzeugt, erhalten als Suffix ".as1",
- ".as2", ".as3" usw.
-
- Der Parameter ARMORLINES gibt an, wieviele Zeilen eine von PGP
- erzeugte "*.asc"-Datei maximal enthalten darf. Wird ARMORLINES
- auf Null gesetzt, kann eine "*.asc"-Datei beliebig groß werden.
-
- Im Fido-Netz dürften Nachrichten in der Regel nicht länger als
- 32 kB sein, so daß "ARMORLINES=450" eine sinnvolle Einstellung
- für Fido ist.
-
- Weiteres hierzu steht im ersten Teil des Handbuches im
- Abschnitt "Versand von Nachrichten im Radix-64 Format".
-
-
- KEEPBINARY - verschlüsselte Binärdatei nach Entschlüsselung
- -----------------------------------------------------------
- nicht löschen
- -------------
-
- Standardeinstellung: KEEPBINARY = off (aus)
-
- Wenn PGP eine "*.asc"-Datei einliest, erkennt es automatisch,
- daß es eine Datei im Radix-64 Format ist, und konvertiert sie
- zurück in ihre binäre Form (also eine "*.pgp Datei), bevor es
- mit der eigentlichen Entschlüsselung beginnt. Bei der
- Entschlüsselung erzeugt PGP natürlich auch eine Datei mit dem
- Klartext.
-
- PGP ermöglicht die Auswahl, ob man die "*.pgp"-Datei behalten
- möchte, oder ob sie nach der Entschlüsselung gelöscht werden
- soll. Die "*.asc"-Datei bleibt in jedem Fall erhalten.
-
- Wenn "KEEPBINARY = on" eingestellt wird, bleibt die "*.pgp"
- Datei erhalten; wird "KEEPBINARY = off" eingestellt, wird die
- "*.pgp" nach der Entschlüsselung gelöscht.
-
- Weiteres hierzu steht im ersten Teil des Handbuches im
- Abschnitt "Versand von Nachrichten im Radix-64 Format".
-
-
- COMPRESS - Datenkompression ein- oder aussschalten
- --------------------------------------------------
-
- Standardeinstellung: COMPRESS = on
-
- Mit "COMPRESS = on / off" (ein/aus) kann eingestellt werden, ob
- PGP den Klartext vor der Verschlüsselung komprimiert. Die
- Einstellung "off" ist im wesentlichen für das Debuggen von PGP
- interessant. In der Regel sollte "COMPRESS = on" gewählt
- werden, damit PGP den Klartext vor der Verschlüsselung
- komprimiert. [Das reduziert Versandkosten und -zeit, und
- erschwert in der Regel eine Kryptanalyse. d.Ü.]
-
-
- COMPLETES_NEEDED - Anzahl der erforderlichen voll
- -------------------------------------------------
- vertrauenswürdigen Unterschriften
- ---------------------------------
-
- Standardeinstellung: COMPLETES_NEEDED = 1
-
-
- Mit COMPLETES_NEEDED läßt sich einstellen, wieviele voll
- vertrauenswürdige Unterschriften unter einem Schlüssel PGP
- verlangt, um diesen Schlüssel als vollständig bestätigt zu
- betrachten. Mit diesem Parameter hat man also die Möglichkeit,
- PGP mehr oder weniger mißtrauisch einzustellen.
-
- Genaueres hierüber finden Sie im Abschnitt "Öffentliche
- Schlüssel vor Manipulation schützen" im ersten Teil des
- Handbuches.
-
-
- MARGINALS_NEEDED - Anzahl der erforderlichen teilweise
- ------------------------------------------------------
- vertrauenswürdigen Unterschriften
- ---------------------------------
-
- Standardeinstellung: MARGINALS_NEEDED = 2
-
- Mit MARGINALS_NEEDED läßt sich einstellen, wieviele teilweise
- vertrauenswürdige Unterschriften unter einem Schlüssel PGP
- verlangt, um diesen Schlüssel als vollständig bestätigt zu
- betrachten. Mit diesem Parameter hat man also die Möglichkeit,
- PGP mehr oder weniger mißtrauisch einzustellen.
-
- Genaueres hierüber finden Sie im Abschnitt "Öffentliche
- Schlüssel vor Manipulation schützen" im ersten Teil des
- Handbuches.
-
-
- CERT_DEPTH - Schachtelungstiefe von Unterschriften
- --------------------------------------------------
-
- Standardeinstellung: CERT_DEPTH = 4
-
- CERT_DEPTH gibt an, bis zu welcher Tiefe PGP Unterschriften
- unter öffentliche Schlüssel prüft, d.h., wie "indirekt" die
- Bestätigung der Echtheit eines Schlüssels sein darf. Wenn Sie
- beispielsweise CERT_DEPTH = 1 wählen, erkennt PGP nur solche
- Schlüssel als voll vertrauenswürdig an, die von einer Person
- unterschrieben sind, deren öffentlichen Schlüssel Sie
- persönlich mit Ihrem geheimen Schlüssel unterschrieben haben.
- Setzen Sie CERT_DEPTH = 0, erkennt PGP nur die Schlüssel als
- voll vertrauenswürdig, die Sie selbst unterschrieben haben.
- Wenn Sie CERT_DEPTH = 2 setzen, ist für PGP auch der Schlüssel
- von Carol voll trauenswüdrig, wenn Carols Schlüssel von Bob,
- Bobs Schlüssel von Alice, und Alices Schlüssel von Ihnen selbst
- unterschrieben ist. Der kleinste zulässige Wert für CERT_DEPTH
- ist 0, der größte 8.
-
- Genaueres hierüber finden Sie im Abschnitt "Öffentliche
- Schlüssel vor Manipulation schützen" im ersten Teil des
- Handbuches.
-
-
- BAKRING - Dateiname der Sicherheitskopie der Datei mit geheimen
- ---------------------------------------------------------------
- Schlüsseln
- ----------
-
- Standardeinstellung: BAKRING = ""
-
- Die Prüfung der Echtheit eines öffentlichen Schlüssels durch
- Unterschriften basiert letztlich auf die Echtheit Ihres eigenen
- Schlüssels, den PGP als absolut vertrauenswürdig ansieht. (Sie
- können auch mehrere eigene Schlüssel haben, die PGP als voll
- vertrauenswürdig anerkennt.) Um mögliche Fälschungen an Ihrer
- Datei mit öffentlichen Schlüsseln erkennen zu können, muß PGP
- kontrollieren, ob auch Ihr eigener Schlüssel nicht gefälscht
- wurde. Hierfür vergleicht PGP Ihren öffentlichen Schlüssel mit
- einer Sicherheitskopie Ihres geheimen Schlüssels, die auf einem
- fälschungssicherem Medium, z.B. einer schreibgeschützten
- Diskette, steht. Zusammen mit dem geheimen Schlüssel sind alle
- Informationen gespeichert, die Ihr öffentlicher Schlüssel hat.
- Dies bedeutet, daß PGP Ihren öffentlichen Schlüssel mit der
- Sicherheitskopie Ihres geheimen Schlüssels vergleichen kann.
-
- Mit dem Parameter BAKRING können Sie den Pfadnamen festlegen,
- unter dem PGP die Sicherheitskopie Ihres geheimen Schlüssels
- sucht. Für MSDOS können Sie z.B. "BAKRING = a:\secring.pgp"
- angeben, so daß PGP die Sicherheitskopie auf einer
- schreibgeschützten Diskette sucht. Den Vergleich mit der
- Sicherheitskopie führt PGP nur durch, wenn Sie mit "pgp -kc"
- Ihre gesamte Datei mit öffentlichen Schlüsseln prüfen.
-
- Wenn BAKRING nicht definiert ist, führt PGP diese Kontrolle
- Ihres eigenen öffentlichen Schlüssel nicht durch.
-
- Genaueres hierüber finden Sie im Abschnitt "Öffentliche
- Schlüssel vor Manipulation schützen" im ersten Teil des
- Handbuches.
-
-
- PAGER - Auswahl der Programms für die Textanzeige am Bildschirm
- ---------------------------------------------------------------
-
- Standardeinstellung: PAGER = ""
-
- Wenn Sie beim Entschlüsseln die Option "-m" angeben, können Sie
- den entschlüsselten Text am Bildschirm lesen, ohne daß PGP ihn
- in eine Datei schreibt. Standardmäßig verwendet PGP hierzu
- eigene Routinen, die ähnlich dem "more" Programm bei Unix
- arbeiten.
-
- Falls Sie ein anderes Programm für Textanzeige am Bildschirm
- bevorzugen, können Sie es unter "PAGER =..." eintragen. Unter
- MSDOS können Sie z.B. das populäre Shareware-Programm
- "list.com" verwenden. In diesem Fall würde der PAGER-Eintrag so
- lauten:
-
- PAGER = list
-
- Wenn jedoch die AbsenderIn einer Nachricht die Option "-m"
- (Klartext nach Entschlüsseln nicht in eine Datei schreiben)
- angegeben hat, verwendet PGP in jedem Fall seine eigene
- Anzeigefunktion.
-
- Weiteres hierzu steht im Abschnitt "Anzeige des entschlüsselten
- Klartextes am Bildschirm".
-
-
- SHOWPASS - Anzeige des Mantra während der Eingabe
- -------------------------------------------------
-
- Standardeinstellung: SHOWPASS = off (aus)
-
- Normalerweise zeigt PGP das Mantra während der Eingabe nicht am
- Bildschirm an. Dadurch wird es für neugierige Augen schwerer,
- das Mantra mitzulesen. Es gibt aber Menschen, die
- Schwierigkeiten haben, ihr Mantra korrekt einzutippen, ohne daß
- sie es am Bildschirm sehen können. So entstand der Wunsch, PGP
- für die Anzeige des Mantra konfigurierbar zu machen. In der
- Abgeschiedenheit einer Wohnung ist es nicht allzu
- problematisch, das Mantra am Bildschirm anzuzeigen.
-
- Wird "SHOWPASS = on" eingestellt, zeigt PGP das Mantra beim
- Eintippen am Bildschirm an.
-
-
- TZFIX - Zeitzonenkorrektur
- --------------------------
-
- Standardeinstellung: TZFIX = 0
-
- PGP versieht Schlüssel und Unterschriften mit einer Zeitmarke
- in Greenwich Mean Time (GMT), oder Coordinated Unviersal Time
- (UTC), was für unsere Zwecke dasselbe ist. Wenn PGP das
- Betriebssystem nach Datum und Zeit fragt, nimmt es an, daß die
- Zeit als GMT-Zeit zurückgegeben wird.
-
- Unter Umständen wird die Zeit aber auf schlecht konfigurierten
- MSDOS-Rechnern als US Pacific Standard Time plus 8 Stunden
- zurückgegeben. Seltsam, nicht wahr? Vielleicht liegt es an
- einer Art US-Westküsten-Chauvinismus, daß MSDOS davon ausgeht,
- die lokale Zeit sei die US Pacific Time, und GMT hierauf
- basierend ausrechnet. Dies wirkt sich nachteilig aus auf das
- Verhalten der MSDOS-internen Funktionen, die PGP verwendet.
- Wenn jedoch die MSDOS Umgebungsvariable TZ für Ihre Zeitzone
- korrekt definiert ist, korrigiert dies auch irrtümliche Annahme
- von MSDOS, die ganze Welt lebe an der Westküste der USA.
-
- TZFIX gibt die Anzahl der Stunden an, die PGP zur
- "Betriebssystemzeit" addiert, um GMT-Zeitangaben für
- Unterschriften und Schlüssel zu erhalten. Wenn die MSDOS
- Umgebungsvariable TZ korrekt definiert ist, kann TZFIX auf dem
- Standardwert 0 bleiben. Unter Unix ist TZFIX in der Regel auch
- nicht notwendig. TZFIX kann aber für irgendwelche obskuren
- Betriebssysteme sinnvoll sein, die nie etwas von GMT gehört
- haben.
-
- Für MSDOS Systeme, bei denen TZ nicht definiert ist, sollten
- Sie TZFIX auf 0 setzen in Kalifornien, auf -1 in Colorado, -2
- in Chicago, -3 in New York, -8 in London, -9 in Amsterdam.
- Während der Zeitumstellung im Sommer müssen Sie diese Werte um
- eins verringern. Was für ein Durcheinander.
-
- Die Definition der MSDOS Umgebungsvariablen TZ in AUTOEXEC.BAT
- ist eine wesentlich sauberere Lösung. In diesem Fall liefert
- MSDOS die korrekt GMT Zeit, und berücksichtigt auch die
- Sommerzeit, abhängig von der von der jeweiligen Zeitzone:
-
- In Los Angeles: SET TZ=PST8PDT
- In Denver: SET TZ=MST7MDT
- In Arizona: SET TZ=MST7
- (In Arizona gibt es keine Sommerzeit... Zumindest wird dort
- die Uhr im Sommer nicht umgestellt,)
- In Chicago: SET TZ=CST6CDT
- In New York: SET TZ=EST5EDT
- In London: SET TZ=GMT0BST
- In Amsterdam: SET TZ=MET-1DST
- In Moskau: SET TZ=MSK-3MSD
- In Aukland: SET TZ=NZT-13
-
- [Bei der Frage, wer an dem Durcheinander mit den Zeitangaben
- und Zeitzonen schuld ist, bin ich anderer Meinung als Philip
- Zimmermann: Dies kann man ausnahmsweise mal nicht nur Microsoft
- in die Schuhe schieben - MSDOS gehört zu den "obskuren
- Betriebssystemen", die nichts von GMT wissen -, sondern auch
- Borland. Die MSDOS-Version von PGP ist mit Borland C übersetzt
- worden. Die Funktion gmtime(...) der Laufzeitbibliothek gibt
- die Zeit als GMT zurück, und benötigt hierfür eine Angabe, um
- wieviel lokale Zeit und GMT differieren. Diese Angabe bezieht
- gmtime() aus der Umgebungsvariablen TZ. Der oben erwähnte
- "Westküstenchauvinismus" ist also meiner Meinung nach Borland
- anzulasten.
-
- Die ersten drei Zeichen des Wertes von TZ müssen Buchstaben
- sein, danach muß eine ein- oder zweistellige Zahl, ggf. mit
- einem Minuszeichen davor, stehen. Stehen hinter der Zahl noch
- Buchstaben, wertet gmtime() dies als Signal, daß es eine
- Sommerzeit gibt. Welche Buchstaben vor und ggf. hinter der Zahl
- stehen, wertet gmtime() nicht weiter aus.
-
- Bei der Sommerzeit-Option ist zu beachten, daß gmtime() als
- Beginn und Ende der Sommerzeit die in den USA zutreffenden Tage
- verwendet, die von den in Europa üblichen etwas abweichen. Wie
- es mit der Sommerzeit in anderen Weltgegenden aussieht, weiß
- ich nicht.
-
- Falls Ihnen jetzt von dem ganzen Durcheinander um Zeitzonen der
- Kopf raucht: Geben Sie einfach den MSDOS-Befehl
-
- SET TZ=MET-1
-
- und prüfen Sie, mit dem Befehl
-
- pgp
-
- die GMT-Zeitangabe, die PGP dann liefert. Falls die GMT-Zeit
- falsch ist, wählen Sie solange einen anderen Wert für TZ, bis
- GMT richtig ist. Es kommen nur 24 Werte infrage...
-
- Ansonsten der Hinweis: "Zu Risiken und Nebenwirkungen lesen Sie
- das Borland Referenzhandbuch und den run time source code und
- fragen Sie Ihre Borland-Hotline und Ihren Borland-Händler".
- d.Ü.]
-
-
- CLEARSIG - Nachrichten im Klartext mit ASCII-Unterschrift
- ---------------------------------------------------------
-
- Standardwert: CLEARSIG = off (aus)
-
- Normalerweise liegen mit PGP unterschriebene Nachrichten in
- Binärform vor, auch dann, wenn sie nicht verschlüsselt werden.
- Auch die Unterschrift wird in Binärform an die unterschriebenen
- Daten angehängt. Um eine solche unterschriebene Nachricht über
- einen 7-Bit E-Mail-Kanal zu versenden, kann die ASCII-
- Darstellung im Radix-64-Format verwendet werden. (vgl. den
- ARMOR Parameter) Die Daten bestehen dann zwar aus druckbaren
- ASCII-Zeichen, der originale Text ist aber mit bloßen Auge
- trotzdem nicht mehr zu erkennen, obwohl die Nachricht nicht
- verschlüsselt ist. Die EmpfängerIn einer solchen Nachricht muß
- die "ASCII-Transportverpackung" mit Hilfe von PGP wieder
- "entfernen", bevor sie die Nachricht lesen kann.
-
- Wenn die originale Nachricht nicht eine Binärdatei, sondern
- ASCII-Text ist, besteht die Möglichkeit, eine Unterschrift so
- an den Text anzufügen, daß er nicht in seiner Darstellung
- geändert wird. In diesem Fall wird nur die Unterschrift im
- Radix-64 Format dargestellt. Der Text bleibt also auch ohne
- Hilfe von PGP für die EmpfängerIn lesbar. Für die Prüfung der
- Unterschrift ist PGP natürlich trotzdem erforderlich.
-
- Diese Option wird so eingeschaltet: CLEARSIG=on, ARMOR=on,
- (ersatzweise die "-a" Option), TEXTMODE=on (ersatzweise die
- "-t" Option). Beispiel:
-
- pgp -sta +clearsig=on message.txt
-
- Eine so unterschriebene Nachricht ähnelt einer "MIC-CLEAR"-
- Nachricht, die mit Privacy Enhanced Mail (PEM) erzeugt wurde.
-
- Wichtiger Hinweis: Eine solche Nachricht wird als Textnachricht
- versandt, und unterliegt dadurch möglichen Änderungen auf dem
- Versandweg. So können Zeichensatzkonvertierungen vorkommen, es
- können Leerzeichen eingefügt oder gelöscht werden. Wenn dies
- passiert, wird PGP die Nachricht als verändert erkennen, was zu
- einem in diesem Fall unberechtigten Verdacht einer echten,
- inhaltlichen Fälschung führt. Weil auch PEM dies Problem hat,
- schien es sinnvoll, diese Möglichkeit des unterschriebenen
- Klartextes trotz ihr Störanfälligkeit in PGP aufzunehmen.
-
- Seit PGP Version 2.2 werden Blanks am Ende einer Zeile bei der
- Berechnung einer Unterschrift nicht mehr berücksichtigt, wenn
- CLEARSIG=on gesetzt ist.
-
-
- VERBOSE - keine, normale oder ausführliche Meldungen
- ----------------------------------------------------
-
- Standardeinstellung: VERBOSE = 1
-
- VERBOSE kann auf 0, 1, oder 2 gesetzt werden, je nachdem, wie
- detaillierte Meldungen man von PGP haben möchte:
-
- 0 - Meldungen werden nur ausgegeben, wenn es Probleme gibt. Das
- richtige für Unix Fans.
-
- 1 - Die Standardeinstellung. PGP zeigt in sinnvollem Umfang
- diagnostische Meldungen und Bedienungshinweise
-
- 2 - ausführliche Meldungen. Diese Option ist hauptsächlich für
- die Fehlersuche gedacht. Normalerweise ist sie nicht sinnvoll.
- Ach so, PGP hat doch keinerlei Probleme, oder?
-
-
- INTERACTIVE - Bestätigungsabfrage beim Hinzufügen von
- -----------------------------------------------------
- öffentlichen Schlüsseln
- -----------------------
-
- Standardeinstellung: INTERACTIVE = off (aus)
-
- Wenn "INTERACTIVE=on" (ein) gesetzt wird, fragt PGP beim
- Bearbeiten einer Datei, die mehrere öffentliche Schlüssel
- enthält, für jeden Schlüssel einzeln nach, ob er in pubring.pgp
- aufgenommen werden soll.
-
-
-
- Schutz gegen gefälschte Zeitangaben
- ===================================
-
- Eine nicht ganz leicht verständliche Angreifbarkeit von PGP
- betrifft unehrliche BenutzerInnen, die gefälschte Zeitangaben
- für die Bestätigung ihrer öffentlichen Schlüssel und ihre
- Unterschriften verwenden. LeserInnen, die PGP nur gelegentlich
- benutzen, und mit den Tücken öffentlicher Schlüssel nicht sehr
- vertraut sind, können diesen Abschnitt überspringen.
-
- Nichts hindert eine unehrliche BenutzerIn daran, die
- Einstellung von Datum und Zeit auf ihrem Computer zu ändern,
- und bei dieser falschen Datumseinstellung ihre
- Schlüsselbestätigungen und Unterschriften zu erzeugen. So kann
- diese unehrliche BenutzerIn es so erscheinen lassen, als habe
- sie eine Unterschrift viel früher oder später geleistet, als es
- tatsächlich der Fall ist, oder als habe sie ihre Paar von
- öffentlichem und geheimem Schlüssel zu einem anderen Zeitpunkt
- generiert. Dies kann von juristischem oder finanziellem Nutzen
- sein. Beispielsweise kann dadurch ein Schlupfloch entstehen, um
- eine Unterschrift nicht anerkennen zu müssen.
-
- Abhilfe bieten könnte eine allgemein vertrauenswürdige
- Institution oder ein Notar, der/die notariell beglaubigte
- Unterschriften mit einer vertrauenswürdigen Zeitangabe machen
- kann. Dies setzt nicht notwendigerweise eine zentrale
- Institution voraus. Unter Umständen kann jede vertrauenswürdige
- VermittlerIn oder eine unbeteiligte dritte Person diese Aufgabe
- wahrnehmen, ähnlich öffentlich bestellten Notaren. Die
- Bestätigung eines öffentlichen Schlüssels könnte von dem Notar
- unterschrieben werden, und die Zeitmarke bei der Unterschrift
- des Notars könnte juristische Bedeutung erlangen. Der Notar
- könnte über solche Bestätigungen Protokoll führen. Das
- Protokoll wäre öffentlich einsehbar.
-
- Der Notar könnte auch die Unterschrift anderer durch seine
- eigene Unterschrift bestätigen. Dies könnte als urkundliche,
- beweiskräftige Unterschrift gelten, so, wie es "real
- existierende Notare" mit Unterschriften auf Papierdokumenten
- seit langem machen. Auch in diesem Fall würde der Notar über
- die Unterschriften Protokoll führen, indem er die von dem
- Textdokument abgetrennten Unterschriften archiviert. Die
- Unterschrift des Notars hätte eine vertrauenswürdige
- Zeitangabe, mit größerer Glaubhaftigkeit als die Zeitangabe der
- originalen Unterschrift. Eine Unterschrift würde durch die
- hinzukommende notarielle Unterschrift und das Protokoll des
- Notars "Beweiskraft" erhalten.
-
- Das Problem notariell beglaubigter Unterschriften und
- glaubwürdiger Zeitmarken bedarf weiterer Diskussion. Eine gute
- Abhandlung hierüber ist der Aufsatz von Denning in IEEE
- Computer 1983 (s. Literaturliste). Die möglichen Verfahren für
- Bestätigung und Beglaubigung müssen noch viel detaillierter
- ausgearbeitet werden. Dies wird sich durch die zunehmende
- Nutzung von PGP ergeben, und dadurch, daß bei anderen
- Programmen, die das Prinzip öffentlicher Schlüssel verwenden,
- andere Bestätigungsverfahren entwickelt werden.
-
-
-
- Ein Blick aufs Detail
- =====================
-
-
- Zufallszahlen
- -------------
-
- PGP verwendet einen kryptographisch zuverlässigen
- Pseudozufallszahlengenerator, um wechselnde Schlüssel für die
- konventionelle Verschlüsselung einzelner Dateien zu erzeugen.
- Die Datei, die den Startwert für den Zufallszahlengenerator
- enthält, heißt "randseed.bin". Sie kann ebenso wie die anderen
- von PGP benötigten Dateien in dem Verzeichnis stehen, das durch
- die Umgebungsvariable (environmental variable) PGPPATH
- angegeben wird. Falls die Datei nicht vorhanden ist, wird sie
- automatisch erzeugt. Sie erhält einen Startwert aus echten
- Zufallszahlen, die aus dem zeitlichen Abstanden von
- Tastatureingaben abgeleitet werden.
-
- In die Datei "randseed.bin" werden bei jedem Aufruf des
- Zufallszahlengenerators neue Daten geschrieben, unter
- Einbeziehung der aktuellen Uhrzeit und anderer echter
- Zufallsdaten. Im Zufallszahlengenerator wird der konventionelle
- Verschlüsselungsalgorithmus verwendet.
-
- Die Datei "randseed.bin" sollte wenigstens ein bißchen vor
- Mitlesen geschützt sein, um das Risiko klein zu halten, daß ein
- Angreifer die nächsten Schlüssel, die PGP generieren wird, oder
- die letzten Schlüssel, die PGP generiert hat, berechnet. Dieser
- Angreifer hätte Schwerstarbeit zu erledigen, weil PGP die Datei
- "randseed.bin" vor und nach jeder Benutzung kryptographisch "in
- die Mangel nimmt". Trotzdem ist es keine unangebrachte
- Vorsicht, darauf zu achten, daß die Datei nicht in die falsche
- Hände gerät.
-
- LeserInnen, denen diese algorithmisch abgeleiteten
- Zufallszahlen unheimlich sind, sollten nicht vergessen, daß sie
- der Sicherheit desselben konventionellen
- Verschlüsselungsalgorithmus vertrauen, um eine Nachricht zu
- verschlüsseln. Wenn der Algorithmus für die Verschlüsselung
- sicher genug ist, sollte er hinreichend zuverlässig sein, um
- Zufallszahlen zu erzeugen, die den konventionellen Schlüssel
- bilden. Zu beachten ist noch, daß PGP zur Erzeugung eines
- Paares von öffentlichem und geheimem Schlüssel, die über
- längere Zeit sicher sein sollen, echte Zufallszahlen verwendet,
- die im wesentlichen aus den Zeitabständen von Tastatureingaben
- abgeleitet werden.
-
- [Anmerkung des Übersetzers: Die Erzeugung von
- Pseudozufallszahlen, also von Zahlen, die zwar "zufällig
- aussehen", die aber aus einem Algorithmus abgeleitet werden,
- ist eine schwierige Aufgabe. Wegen der "guten Zufallsqualität"
- wird auch bei Anwendungen, die nichts mit Verschlüsselung zu
- tun haben, wie Statistik oder numerischer Mathematik, gerne ein
- Verschlüsselungsalgorithmus verwendet, um Zufallszahlen zu
- erzeugen. Die Probleme bei Verschlüsselung und bei der
- Erzeugung von Zufallszahlen sind ähnlich: In beiden Fällen geht
- es darum, Bitfolgen zu erzeugen, die möglichst wenig Systematik
- zeigen. Bei der Verschlüsselung sind diese Bitfolgen der
- verschlüsselte Text, bei der Erzeugung von Zufallszahlen sind
- die Bitfolgen eben die Zufallszahlen. LeserInnen, denen die
- Verwendung der Datei "randseed.bin" trotz dieser Argumente
- unheimlich bleibt, können sie immer noch vor jedem Start von
- PGP einfach löschen. Allerdings müssen sie dann für die
- Verschlüsselung eines Klartextes jedesmal ungefähr 90
- Tastendrücke für die Erzeugung einer echten Zufallszahl
- ausführen. d.Ü.]
-
-
-
- Der konventionelle Verschlüsselungsalgorithmus bei PGP
- ------------------------------------------------------
-
- Wie weiter oben bereits erwähnt, verwendet PGP für die
- Verschlüsselung des Klartextes einen schnellen konventionellen
- Verschlüsselungsalgorithmus; der mit öffentlichen Schlüsseln
- arbeitende Algorithmus wird nur dazu verwendet, den aktuell für
- eine Nachricht verwendeten konventionellen Schlüssel zu
- chiffrieren, so daß er zusammen mit der verschlüsselten
- Nachricht verschickt werden kann. Im folgenden werden wir über
- diesen Algorithmus sprechen. Von DES reden wir nicht.
-
- Der "Federal Data Encryption Standard" (DES) ist ein guter
- Algorithmus für die meisten kommerziellen Anwendungen.
- Allerdings vertraut die US-Regierung nicht auf DES, um ihre
- eigenen geheimen Daten zu schützen. Vielleicht liegt der Grund
- darin, daß der Schlüssel bei DES nur 56 Bit lang ist, kurz
- genug für einen Angriff "mit brutaler Gewalt", bei dem eine
- spezielle Maschine verwendet wird, die aus einer Vielzahl von
- DES-Verschlüsselungschips besteht, die einfach alle 2^56
- möglichen Schlüssel "ausprobiert". Auch hatten Biham und Shamir
- kürzlich einigen Erfolg beim Angriff auf eine volle 16-Runden-
- DES-Verschlüsselung. ["16 Runden" bedeutet, daß der DES-
- Algorithmus 16 mal hintereinander für die Verschlüsselung
- desselben Datenblocks verwendet wird, also gewissermaßen eine
- 16-fache Verschlüsselung. Diese 16 Runden sind Standard bei
- DES; übrigens auch bei der im folgenden beschriebenen IDEA-
- Verschlüsselung. d.Ü.]
-
- PGP verwendet DES nicht für die konventionelle Verschlüsselung.
- Statt dessen wird ein anderer blockorientierter Ein-Schlüssel
- Algorithmus namens IDEA(tm) verwendet. Eine künftige Version
- von PGP könnte DES optional unterstützen, falls genug
- BenutzerInnen danach fragen. Aber ich nehme an, daß IDEA besser
- als DES ist.
-
- IDEA verwendet - kryptographisch ungewöhnlich - 64 Bit lange
- Blöcke für Klartext und verschlüsselten Text, mit 128 Bits
- langen Schlüsseln. Der Algorithmus basiert auf dem Konzept der
- Mischung von Operationen verschiedener algebraischer Gruppen.
- Eine Software-Implementierung von IDEA ist wesentlich schneller
- als ein DES-Software-Implementierung. Ähnlich wie DES, kann
- IDEA für "cipher feedback" (CFB, Rückführung der
- verschlüsselten Textes) und für "cipher block chaining" (CBC,
- Verkettung von Blöcken verschlüsselten Textes) verwendet
- werden. PGP verwendet IDEA mit 64-Bit CFB.
-
- Die IPES/IDEA-Verschlüsselung wurde an der ETH Zürich von James
- L. Massey und Xuejia Lai entwickelt und 1990 veröffentlicht.
- IDEA ist keine Entwicklung aus dem Bastelkeller. Seine
- Entwickler haben unter Kryptologen einen hervorragenden Ruf. In
- ihren ersten Veröffentlichungen nannten sie den Algorithmus
- IPES (Improved Proposed Encryption Standard - Vorschlag für
- einen verbesserten Verschlüsselungsstandard), später änderten
- sie den Namen in IDEA (International Data Encryption Standard -
- Internationaler Standard für Datenverschlüsselung). Bis heute
- hat IDEA kryptanalytischen Angriffen wesentlich besser stand
- gehalten als andere Verfahren wie FEAL, REDOC-II, LOKI, Snefru
- und Khafre. Es gibt erste Anhaltspunkte dafür, daß IDEA dem
- sehr erfolgreichen differentiellen kryptanalytischen Angriff
- von Biham und Shamir wesentlich besser standhält als DES. Biham
- und Shamir untersuchten IDEA erfolglos auf Schwachstellen.
- Akademische Arbeitsgruppen von Kryptanalytikern aus Belgien,
- England und Deutschland suchen Angriffsmöglichkeiten bei IDEA,
- ebenso militärische Geheimdienste mehrerer europäischer Länder.
- Je mehr und je länger dieser neue Algorithmus Angriffsversuche
- aus den gefürchtetsten Arbeitsgruppen der kryptanalytischen
- Welt auf sich zieht, desto mehr steigt das Vertrauen in ihn.
-
- Ein berühmter Eishockeyspieler sagte einmal: "Ich versuche, an
- die Stelle zu laufen, von der ich meine, daß der Puck dort sein
- müßte." Viele Leute beginnen zu glauben, daß die Tage von DES
- gezählt sind. Ich bin dabei, in Richtung IDEA zu laufen.
-
- Die ausschließliche Verwendung von RSA mit langen Schlüsseln
- ist wegen der langen Rechenzeit für die Ver- und
- Entschlüsselung großer Datenmengen ergonomisch unsinnig. Das
- macht absolut niemand im wirklichen Leben. Trotzdem liegt die
- Frage nahe, ob die Kombination einer Verschlüsselung mit
- öffentlichen Schlüsseln und einer zweiten, konventionell
- arbeitenden Verschlüsselung die Gesamtsicherheit herabsetzt,
- und das nur, um das Programm schneller zu machen. Schließlich
- ist eine Kette nur so stark wie ihr schwächstes Glied. Viele
- Leute, die wenig Erfahrung mit Kryptographie haben, sind der
- Meinung, daß RSA vom Prinzip her sicherer sei als eine
- konventionelle Verschlüsselung. Das stimmt nicht. RSA kann
- durch "weiche" Schlüssel leicht angreifbar werden, andererseits
- können konventionelle Verschlüsselungen bei Wahl eines guten
- Algorithmus sehr sicher sein. In den meisten Fällen ist es
- schwierig, genau zu sagen, wie gut eine konventionelle
- Verschlüsselung ist, ohne sie wirklich zu knacken. Ein guter
- konventioneller Algorithmus könnte durchaus schwerer zu knacken
- sein als ein RSA-Schlüssel nach militärischem Standard. Der
- Reiz einer Verschlüsselung mit öffentlichen Schlüsseln besteht
- nicht darin, daß sie aus sich heraus sicherer als eine
- konventionelle Verschlüsselung ist - ihr Reiz besteht in der
- wesentlich bequemeren und vielseitigeren Handhabung der
- Schlüssel.
-
-
-
- Datenkomprimierung
- ------------------
-
- Normalerweise komprimiert PGP den Klartext, bevor er
- verschlüsselt wird. Verschlüsselte Daten lassen sich nicht mehr
- komprimieren. [Das liegt daran, daß verschlüsselte Daten sehr
- "zufällig aussehen", Kompressionsalgorithmen aber darauf
- basieren, eine bestimmte Systematik in den Daten zu erkennen,
- und auf Grundlage dieser Systematik eine kürzere Darstellung
- der Daten zu suchen. d.Ü.] Die Kompression spart
- Übertragungszeit und Festplattenkapazität, und, viel wichtiger,
- sie erhöht die Sicherheit der Verschlüsselung. Die meisten
- kryptanalytischen Techniken gehen von der Redundanz des
- Klartextes aus, um die Verschlüsselung zu knacken. Die
- Datenkompression reduziert die Redundanz des Klartextes, und
- erhöht dadurch wesentlich die Sicherheit vor kryptanalytischen
- Angriffen. Die Datenkompression kostet zwar etwas Rechenzeit,
- aber vom Standpunkt der Sicherheit aus ist das gerechtfertigt,
- wenigstens nach meiner bescheidenen Meinung.
-
- Dateien, die für eine Kompression zu klein sind, oder die sich
- nicht gut komprimieren lassen, werden von PGP nicht
- komprimiert.
-
- Bei Bedarf läßt sich auch PKZIP oder ein anderes
- Datenkomprimierungsprogramm verwenden, um den Klartext vor der
- Verschlüsselung zu komprimieren. PKZIP ist ein weit
- verbreitetes und effizient arbeitendes Kompressionsprogramm von
- PKWare Inc. für MSDOS, das als Shareware vertrieben wird. Oder
- man kann ZIP benutzen, ein PKZIP-kompatibles Freeware-Programm
- für Unix und andere Betriebssysteme, zu erhalten bei Jean-Loup
- Gailly. Die Verwendung von PKZIP oder ZIP hat unter bestimmten
- Umständen Vorteile, weil diese Programme im Gegensatz zu PGP in
- der Lage sind, mehrere Dateien in einer einzigen komprimierten
- Datei zusammenzufassen. Bei der Dekompression werden natürlich
- wieder die einzelnen Originaldateien erzeugt. PGP versucht
- nicht, eine bereits komprimiert vorliegende Klartext-Datei
- erneut zu komprimieren. Die EmpfängerIn einer so komprimierten
- Datei muß sie nach der Entschlüsselung mit PKUNZIP
- dekomprimieren. Wenn der entschlüsselte Klartext eine PKZIP-
- komprimierte Datei ist, erkennt PGP das automatisch, und weist
- die EmpfängerIn darauf hin, das es sich wahrscheinlich um eine
- PKZIP-Datei handelt.
-
- Für die technisch interessierten LeserInnen sei noch erwähnt,
- daß die aktuelle Version von PGP die Freeware-Kompressions-
- Routinen enthält, die Jean-Loup Gailly, Mark Adler und Richard
- B. Wales geschrieben haben. Diese ZIP-Routinen verwenden
- Algorithmen, die funktionsäquivalent zu denjenigen von PKZIP
- 2.0 von PKWare sind. Diese ZIP-Routinen wurde im wesentlichen
- deshalb in PGP eingebaut, weil sie als gut portierbarer C-
- Quellcode zu Verfügung stehen, weil sie wirklich gut
- komprimieren, und weil sie schnell sind.
-
- Peter Gutmann hat ein schönes Kompressions- und
- Archivierungsprogramm namens HPACK geschrieben, das von vielen
- FTP-Servern im Internet zu beziehen ist. HPACK verschlüsselt
- komprimierte Dateien, unter Verwendung des PGP-Dateiformats und
- der PGP-Schlüsseldateien. Es bat mich, hier auf HPACK
- aufmerksam zu machen.
-
-
-
- Textprüfsummen (message digests) und digitale Unterschriften
- ------------------------------------------------------------
-
- Um eine digitale Unterschrift zu erzeugen, verwendet PGP den
- geheimen Schlüssel, jedoch nicht für die "Verschlüsselung" des
- gesamten Textes - das würde zuviel Rechenzeit kosten. Statt
- dessen "verschlüsselt" PGP eine "Textprüfsumme" mit dem
- geheimen Schlüssel.
-
- Diese Textprüfsumme ist ein kleines (128 Bit langes)
- "Destillat" einer Nachricht, von der Idee her ähnlich einer
- Quersumme oder eine CRC-Summe. Man kann sich die Textprüfsumme
- auch als eine Art Fingerabdruck der Nachricht vorstellen. Die
- Textprüfsumme "repräsentiert" die Nachricht in dem Sinn, daß
- sich bei jeder Änderung an der Nachricht eine andere
- Textprüfsumme für die Nachricht ergibt. An der Textprüfsumme
- läßt sich also erkennen, ob sich ein Fälscher an der Nachricht
- zu schaffen gemacht hat. Die Textprüfsumme wird durch eine
- kryptographisch zuverlässige Einweg-Hash-Funktion berechnet.
- [Eine Einwegfunktion ist eine Funktion, bei der es keine
- Möglichkeit gibt - oder keine Möglichkeit bekannt ist -, aus
- dem Funktionswert auf das Funktionsargument zurückzuschließen.
- Eine Hashfunktion ist eine Funktion, die eine große Menge von
- Funktionsargumenten möglichst gleichmäßig auf eine
- vergleichsweise kleine Menge von Funktionswerten abbildet.
- d.Ü.] Ein Fälscher kann wegen des immensen erforderlichen
- Rechenaufwands keine zweite Nachricht produzieren, die dieselbe
- Textprüfsumme wie die Originalnachricht hat. In dieser Hinsicht
- ist das bei PGP verwendete Verfahren zur Berechnung der
- Textprüfsumme wesentlich besser als die üblichen Quersummen
- oder CRC-Summen, bei denen es einfach ist, zu einer gegebenen
- Nachricht eine zweite Nachricht zu finden, die die identische
- Quer- oder CRC-Summe hat. Andererseits kann aus der
- Textprüfsumme ebenso wenig wie aus einer Quer- oder CRC-Summe
- die Originalnachricht berechnet werden.
-
- Die Textprüfsumme alleine reicht nicht aus, um die Echtheit
- einer Nachricht zu kontrollieren. Der Algorithmus für ihre
- Berechnung ist allgemein bekannt, und er verwendet keinen
- geheimen Schlüssel. Wenn man die Textprüfsumme einfach so zur
- Nachricht hinzufügte, könnte ein Fälscher die Nachricht ändern
- und die Prüfsumme für die geänderte Nachricht neu berechnen.
- Für eine zuverlässige Kontrolle der Echtheit einer Nachricht
- muß die AbsenderIn die Prüfsumme mit ihrem geheimen Schlüssel
- "verschlüsseln". Erst hierdurch entsteht eine authentische
- Unterschrift.
-
- Die Textprüfsumme wird von dem PGP-Programm der AbsenderIn
- einer Nachricht berechnet. Die digitale Unterschrift entsteht
- dadurch, daß die AbsenderIn die Textprüfsumme und die Zeitmarke
- mit ihrem geheimen Schlüssel "verschlüsselt". Die AbsenderIn
- verschickt Nachricht und digitale Unterschrift. Die EmpfängerIn
- erhält Nachricht und digitale Unterschrift; ihr PGP-Programm
- ermittelt die Textprüfsumme, indem es die digitale Unterschrift
- mit dem öffentlichen Schlüssel der AbsenderIn "entschlüsselt".
- Zur Kontrolle wird die Textprüfsumme aus der erhaltenen
- Nachricht berechnet. Wenn die aus der Nachricht berechnete
- Textprüfsumme und die in der Unterschrift enthaltene
- Textprüfsumme übereinstimmen, ist gewährleistet, daß die
- Nachricht nicht geändert wurde, und daß sie von derjenigen
- Person stammt, deren öffentlicher Schlüssel für die Kontrolle
- der Unterschrift verwendet wurde.
-
- Ein Fälscher müßte die Nachricht entweder so ändern, daß die
- Textprüfsumme gleich bleibt - was unmöglich ist, oder er müßte
- mit der geänderten Textprüfsumme eine neue digitale
- Unterschrift erzeugen - was ohne den geheimen Schlüssel der
- AbsenderIn auch nicht möglich ist.
-
- Eine digitale Unterschrift beweist, wer eine Nachricht
- abgeschickt hat, und ob die Nachricht aufgrund eines
- technischen Fehlers oder absichtlich geändert wurde. Ebenso
- verhindern sie, daß eine AbsenderIn die Unterschrift unter
- einer Nachricht ableugnen kann.
-
- Die Verwendung der Textprüfsumme für die digitale Unterschrift
- hat neben der Geschwindigkeit noch weitere Vorteile im
- Vergleich zur "Verschlüsselung" der gesamten Nachricht mit dem
- geheimen Schlüssel. Die Unterschriften haben alle die gleiche
- geringe Länge, unabhängig von der Größe der jeweiligen
- Nachricht. Sie ermöglichen der Software eine automatische
- Kontrolle der Korrektheit einer Nachricht, ähnlich wie Quer-
- oder CRC-Summen. Die Unterschrift kann getrennt von der
- Nachricht gespeichert werden, bei Bedarf sogar in einem
- öffentlich zugänglichen Archiv, ohne daß vertrauliche
- Informationen aus der Nachricht offengelegt werden, weil es
- unmöglich ist, aus der Kenntnis der Textprüfsumme irgend etwas
- über den Inhalt der Nachricht zu ermitteln.
-
- De bei PGP verwendet Algorithmus für die Berechnung der
- Textprüfsumme ist MD5 (Message Digest 5), von der RSA Data
- Security Inc. für Public Domain Verwendung freigegeben. Ronald
- Rivest, der Entwickler von MD5, schreibt darüber:
-
- "Es ist zu vermuten, daß der Rechenaufwand, zwei Nachrichten
- mit derselben Textprüfsumme zu erhalten, in der Größenordnung
- von 2^64 Rechenoperationen liegt, und daß der Rechenaufwand,
- eine Nachricht mit einer vorgegebenen Prüfsumme zu erzeugen, in
- der Größenordnung von 2^128 Operationen liegt. Der MD5-
- Algorithmus ist sorgfältig auf Schwachstellen untersucht.
- Andererseits ist er verhältnismäßig neu, so daß eine weitere
- Analyse seiner Sicherheit natürlich gerechtfertigt ist, wie bei
- jedem neuen Vorhaben dieser Art. Der Grad von Sicherheit, den
- MD5 bietet, dürfte ausreichen, um zusammen mit RSA hochgradig
- sichere Systeme für digitale Unterschriften zu implementieren."
-
-
-
- Kompatibilität mit alten Versionen von PGP
- ==========================================
-
- Es tut mir leid, aber Version 2.x von PGP ist nicht kompatibel
- zu Version 1.0. Für Version 1.0 generierte Schlüssel müssen
- durch neue ersetzt werden. Ab Version 2.0 verwendet PGP andere
- Algorithmen für die konventionelle Verschlüsselung, für die
- Datenkompression und für die Berechnung der Textprüfsummen.
- Außerdem gibt es ab Version 2.0 ein wesentlich besseres Konzept
- für die Verwaltung der Schlüssel. Die Änderungen sind zu
- umfangreich, um eine Kompatibilität mit Version 1.0 aufrecht zu
- erhalten. Vielleicht hätten wir ein Konvertierungsprogramm für
- die Schlüssel von Version 1.0 schreiben können oder sollen,
- aber wir alle waren nach Fertigstellung von PGP 2.0 erschöpft,
- und wir wollten endlich die neue Version auf die Menschheit
- loslassen und hinter dem Projekt die Tür zu machen. Außerdem
- könnte die Konvertierung der alten in neue Schlüssel
- möglicherweise mehr Probleme schaffen als Probleme zu lösen,
- weil wir einen neuen einheitlichen Stil für die BenutzerIn-ID
- empfehlen, die den vollen Namen und die E-Mail-Adresse in einer
- speziellen Syntax umfaßt.
-
-
- Version 2.0 ist weitgehend kompatibel mit neueren Versionen.
- Weil neue Versionen von PGP auch neue Möglichkeiten bieten,
- können die älteren Versionen manche Dateien, die mit neueren
- erzeugt wurden, nicht in jedem Fall bearbeiten.
-
- Wir haben uns Mühe gegeben, die internen Datenstrukturen dieser
- Version von PGP so zu entwerfen, daß sie an künftige Änderungen
- angepaßt werden können, so daß hoffentlich niemand noch einmal
- bei einer kommenden Version von PGP die alten Schlüssel
- wegschmeißen und neue Schlüssel generieren muß.
-
-
-
- Angriffsmöglichkeiten
- =====================
-
- Kein Datensicherheitssystem ist unangreifbar. Die Sicherheit
- von PGP kann auf vielerlei Art ausgehebelt werden. Bei jedem
- Datensicherheitssystem müssen AnwenderInnen beurteilen, ob die
- Daten, die geschützt werden sollen, für den Angreifer so viel
- Wert haben, daß sich für ihn der Aufwand eines Angriffs lohnt.
- Dies kann durchaus zu der Entscheidung führen, sich nur von
- simplen Angriffen zu schützen, ohne sich um aufwendige Angriffe
- Gedanken zu machen.
-
- Die folgende Diskussion mag manchmal maßlos paranoid
- erscheinen, aber so eine Einstellung ist für eine fundierte
- Auseinandersetzung mit möglichen Angriffen durchaus angemessen.
-
-
-
- Bekannt gewordenes Mantra und bekannt gewordener geheimer
- ---------------------------------------------------------
- Schlüssel
- ---------
-
- Die wahrscheinlich einfachste Angriffsmöglichkeit ergibt sich,
- wenn man das Mantra für den geheimen Schlüssel irgendwo
- aufschreibt. Falls jemand dies Mantra lesen kann und ihm/ihr
- dann noch die Datei mit dem geheimen Schlüssel in die Hände
- fällt, kann er/sie alle verschlüsselten Nachrichten lesen und
- mit dem geheimen Schlüssel gefälschte digitale Unterschriften
- erzeugen.
-
- Offensichtliche Paßworte, die einfach zu raten sind, sind
- ungeeignet, wie die Namen von Kindern oder der PartnerIn. Ein
- einzelnes Wort als Mantra kann ebenfalls leicht geraten werden,
- wenn ein Computer die Wörter eines Lexikons solange als Paßwort
- ausprobiert, bis das richtige gefunden ist. Deshalb ist eine
- Paß-Phrase, [also eine Kombination mehrerer Worte - von uns
- "Mantra" genannt d.Ü.] wesentlich besser als ein einfaches
- Paßwort. Ein verfeinerter Angriff könnte darin bestehen, einen
- Computer ein Lexikon mit berühmten Zitaten durcharbeiten zu
- lassen, um das Mantra zu finden. Eine leicht zu merkendes, aber
- schwer erratbares Mantra läßt bequem aus ein paar kreativ
- sinnlosen Sprüchen oder weithin unbekannten literarischen
- Zitaten zusammenstellen.
-
- Weiteres hierzu steht im Abschnitt "Private Schlüssel vor
- Diebstahl schützen" in Teil 1 des Handbuchs.
-
-
-
- Fälschung des öffentlichen Schlüssels
- -------------------------------------
-
- Eine der gefährlichsten Angriffsmöglichkeiten besteht darin,
- daß der öffentliche Schlüssel gefälscht werden kann. Dies ist
- der ernsteste, wichtigste Ansatzpunkt für das Knacken einer
- Verschlüsselung mit öffentlichen Schlüsseln, unter anderem,
- weil die meisten Neulinge die Gefahr nicht sofort erkennen. Die
- Bedeutung der Fälschbarkeit eines Schlüssels und geeignete
- Gegenmaßnahmen sind detailliert im Abschnitt "Öffentliche
- Schlüssel vor Manipulation schützen" in Teil 1 des Handbuchs
- beschrieben.
-
- Zusammengefaßt: Wenn man einen öffentlichen Schlüssel für die
- Verschlüsselung einer Nachricht oder für die Prüfung einer
- Unterschrift verwenden will, muß sichergestellt sein, das er
- nicht gefälscht ist. Der Echtheit eines neu erhaltenen
- öffentlichen Schlüssels sollte man nur dann vertrauen, wenn man
- ihn unmittelbar, auf sicherem Weg, von seiner BesitzerIn
- erhalten hat, oder wenn seine Echtheit von jemandem bestätigt
- ist, dem/der man vertraut. Man muß auch dafür sorgen, daß kein
- Fremder Änderungen an der eigenen Datei mit öffentlichen
- Schlüsseln vornehmen kann. Man braucht physikalische Kontrolle
- sowohl über die Datei mit öffentlichen Schlüsseln wie auch über
- die Datei mit geheimen Schlüsseln. Am besten aufgehoben sie
- diese beiden Dateien auf dem eigenen PC, um einiges schlechter
- auf einem, am Ende auch noch räumlich weit entfernten Mehrplatz-
- Rechner. Auf jeden Fall sollte man Sicherheitskopien der beiden
- Schlüsseldateien haben.
-
-
-
- Nicht richtig gelöschte Dateien
- -------------------------------
-
- Ein weiteres potentielles Sicherheitsproblem entsteht dadurch,
- wie bei den meisten Betriebssystemen Dateien gelöscht werden.
- Wenn man eine Klartext-Datei verschlüsselt, und danach löscht,
- löscht das Betriebssystem die Daten nicht physikalisch. Es
- markiert nur diejenigen Datenblöcke der Festplatte oder
- Diskette als "gelöscht", die den Inhalt der "gelöschten" Datei
- enthalten, so daß sie für die Speicherung anderer Daten
- freigegeben werden. Das ist das gleiche, als würde man
- vertrauliche Papiere einfach zum Altpapier legen, anstatt sie
- von einen Reißwolf klein häckseln zu lassen. Die Blöcke auf der
- Festplatte enthalten nach wie vor die originalen vertraulichen
- Daten, und werden vielleicht unter Umständen demnächst mal
- irgendwann in naher oder ferner Zukunft durch neue Daten
- überschrieben. Wenn ein Angreifer diese "gelöschten"
- Datenblöcke kurz nach ihrer Freigabe liest, hat er einige
- Aussicht, den kompletten Klartext zu erhalten.
-
- Genau dies, die Wiederherstellung einer schon vor langem
- gelöschten Datei, kann sogar ganz zufällig passieren, wenn aus
- irgend einem Grund etwas mit der Festplatte schief geht, und
- wichtige Dateien gelöscht oder beschädigt sind. Die übliche
- "Rettungsmaßnahme" besteht darin, ein
- Dateiwiederherstellungsprogramm laufen zu lassen, um die
- Dateien zu "reparieren". Hierbei werden häufig auch alte, schon
- vor dem "Unfall" gelöschte Dateien wieder ausgegraben. Auf
- diese Art können auch vertrauliche Daten wieder ans Tageslicht
- kommen, von denen man annahm, daß sie für immer gelöscht seien.
- Folglich können diese Daten von jedem/jeder gelesen werden
- können, der/die ein solches Programm laufen läßt. Darüber
- hinaus legen die meisten Textverarbeitungsprogramme auch Backup-
- Dateien an, und erzeugen häufig auch aus technischen Gründen
- eine oder mehrere temporäre Dateien, die den gesamten Text oder
- Teile davon enthalten. Diese Dateien werden vom
- Textverarbeitungsprogramm automatisch gelöscht - aber eben nur
- in dem Sinn, daß die Blöcke auf der Festplatte / Diskette für
- ein Überschreiben freigegeben werden. Der Text selbst steht
- nach wie vor noch in diesen Blöcken.
-
- Hierzu eine wahre Horrorgeschichte: Eine Freundin von mir,
- verheiratet und Mutter kleiner Kinder, hatte eine kurze und
- nicht sehr ernstzunehmende Liebesaffaire. Sie schrieb ihrem
- Liebhaber auf dem Computer einen Brief, und nachdem sie den
- Brief abschickte, löschte sie die Datei. Nachdem die Affaire
- schon vorbei war, ging die Diskette kaputt, auf der der Brief
- gespeichert war. Weil die Diskette einige andere wichtige Daten
- enthielt, bat sie ihren Ehemann, die Diskette zu reparieren.
- Der ließ die Diskette von einem Datenwiederherstellungsprogramm
- bearbeiten, wobei neben den von seiner Frau benötigten Dateien
- auch der besagte Brief wieder zu Tage kam, was eine Kette
- tragischer Ereignisse auslöste.
-
- Um zu verhindern, daß der Klartext irgendwann mal ausgegraben
- wird, gibt es nur den einen Weg, die "gelöschten" Daten auch
- wirklich zu überschreiben. Solange man nicht wirklich sicher
- weiß, daß die freigegebenen Blöcke der Festplatte /Diskette
- sehr schnell wieder mit anderen "echten" Daten überschrieben
- werden [dieses Wissen haben bei den meisten Betriebssystemen,
- wenn überhaupt, nur ausgekochte BetriebssystemspezialistInnen
- d.Ü.], muß man selbst dafür sorgen, daß die Klartext-Datei und
- die temporären Dateien, die das Textverarbeitungsprogramm
- angelegt hat, wirklich überschrieben werden. Die Klartext-Datei
- überschreibt PGP, wenn die Option "-w" (wipe = wischen) bei der
- Verschlüsselung angegeben wird. Sämtliche Textfragmente, ob aus
- der "richtigen" Klartext-Datei oder aus temporären Dateien,
- lassen sich mit einem geeigneten Hilfsprogramm löschen, das
- alle freien Blöcke einer Festplatte/Diskette überschreibt. Für
- MSDOS sind beispielsweise die Norton Utilities geeignet.
-
- [Eine weitere Stelle, an der bei den meisten Betriebssystemen
- "Textspuren" verbleiben können, sind die "swap files" (auch
- Auslagerungsdateien genannt) bzw. Swap-Partitionen: Wenn ein
- Programm mehr Hauptspeicher benötigt, als real im Computer
- vorhanden ist, wird ein Teil des Hauptspeicherinhalts in diese
- Auslagerungsdatei bzw. -partition geschrieben, so daß der
- Hauptspeicher gewissermaßen auf die Festplatte "verlängert"
- wird. Auch in dieser "Auslagerungsdatei" können Teile eines
- Textes stehen. MSDOS kennt keine Auslagerungsdateien - endlich
- mal ein Vorteil dieses Betriebssystems, wenn auch nur im
- Hinblick auf "Spurensicherheit". Aber selbst Microsoft Windows
- benutzt eine Auslagerungsdatei. d.Ü.]
-
- Selbst wenn man den Klartext auf der Platte/Diskette
- überschreibt, kann ein technisch gut ausgestatteter Angreifer
- die Daten wiedergewinnen. Geringe magnetische Spuren der
- Originaldaten bleiben auch nach einem Überschreiben auf der
- Platte/Diskette. Diese Spuren können unter Umständen mittels
- spezieller Hardware gelesen werden.
-
-
-
- Viren und Trojanische Pferde
- ----------------------------
-
- Eine andere Angriffsmöglichkeit könnte ein speziell
- entwickelter Virus und Wurm sein, der PGP oder das
- Betriebssystem infiziert. Dieser hypothetische Virus könnte so
- entworfen sein, daß er das Mantra, den geheimen Schlüssel oder
- den entschlüsselten Klartext "mithört", und unbemerkt in eine
- Datei schreibt, oder über ein Netzwerk zum Besitzer des Virus
- schickt. Er könnte auch das Verhalten von PGP so ändern, daß
- Unterschriften nicht richtig geprüft werden. So ein Angriff ist
- einfacher und billiger als ein kryptanalytischer Angriff.
-
- Ein Schutz hiergegen fällt unter das allgemeine Thema des
- Schutzes gegen Viren. Es gibt einige relativ brauchbare
- kommerzielle Anti-Virus Produkte, und es gibt
- "Hygienemaßnahmen", deren Beachtung das Risiko einer
- Virusinfektion erheblich reduzieren kann. Eine umfassende
- Abhandlung dieses Themas würde den Rahmen dieses Handbuchs
- sprengen. PGP selbst hat keinerlei inneren Schutz gegen Viren,
- es geht davon aus, daß der PC, auf dem es benutzt wird, eine
- "vertrauenswürdige Umgebung" ist. Falls es einmal so einen
- Spezialvirus für PGP geben sollte, ist zu hoffen, daß eine
- entsprechende Warnung schnell bekannt würde und viele Leute
- erreicht.
-
- Ein ähnlicher Angriff könnte eine geschickte Imitation von PGP
- sein, die sich im Wesentlichen wie PGP verhält, aber nicht so
- arbeitet, wie anzunehmen wäre. Beispielsweise könnte diese
- Imitation absichtlich dahingehend verstümmelt sein, daß
- Unterschriften nicht mehr korrekt geprüft werden, so daß
- gefälschte Schlüssel nicht mehr erkannt werden können. Eine
- solche "Trojanisches-Pferd-Version" von PGP ist von einem
- Angreifer verhältnismäßig einfach erstellt, weil der Quellcode
- von PGP weit verbreitet ist. Deshalb ist es kein Problem, den
- Quellcode dahingehend zu manipulieren, daß eine
- gehirnamputierte Zombie-Imitation von PGP entsteht, die echt
- aussieht, jedoch nur die Anweisungen ihres teuflischen Meisters
- ausführt. Diese "Trojanisches-Pferd-Version" von PGP könnte
- breit verteilt werden, mit dem Anschein, sie käme von mir. Wie
- hinterhältig. [Die allgemeine Verfügbarkeit des Quellcodes von
- PGP hat aber auch einen anderen, vertrauensschaffenden Aspekt:
- Die entsprechenden Programmierkenntnisse vorausgesetzt, ist es
- nur noch eine Frage des Fleißes, den Quelltext auf obskure
- Stellen durchzusehen. Außerdem kann man das Programm neu
- übersetzen, und sich so eine eigene Arbeitsversion erstellen.
- Der im nächsten Absatz erwähnte Vergleich mehrerer PGP-
- Versionen aus unterschiedlichen Bezugsquellen sollte aber
- zumindest für die selbst erstellte Version vorsichtig
- interpretiert werden: Selbst wenn der gleiche Compiler
- verwendet wird, besteht immer noch die Möglichkeit, daß die
- eigene PGP-Version mit der Compiler-Version 12.34a1 übersetzt
- wird, während das Entwicklerteam Version 12.34b3 verwendet hat.
- Unterschiede in den PGP-Versionen bedeuten deshalb nicht gleich
- das Schlimmste. Auf der anderen Seite heißt das aber auch, daß
- ein neu übersetztes PGP andere BenutzerInnen verunsichern kann.
- Deshalb sollte man normalerweise besser die Originalversion
- weitergeben. d.Ü.]
-
- Man sollte sich die Mühe machen, PGP von einer zuverlässigen
- Bezugsquelle zu erhalten, was auch immer das heißen mag. Oder
- man besorgt sich PGP von mehreren unabhängigen Quellen, und
- vergleicht die einzelnen Versionen mit einem geeigneten
- Programm.
-
- Mit Hilfe digitaler Unterschriften ergeben sich weitere
- Möglichkeiten, festzustellen, ob an PGP herumgepfuscht wurde.
- Wenn eine Person, der man vertraut, eine digitale Unterschrift
- für die Datei mit dem ausführbaren PGP-Programm [welch
- komplizierte Formulierung... für MSDOS ganz schlicht: PGP.EXE
- d.Ü.] leistet, und damit garantiert, daß die Datei zum
- Zeitpunkt der Unterschrift nicht infiziert oder anderweitig
- verfälscht ist, kann man einigermaßen sicher sein, eine
- brauchbare Kopie zu haben. Mit Hilfe einer älteren,
- vertrauenswürdigen Version von PGP kann die Unterschrift für
- die neue, zunächst zweifelhafte Version kontrolliert werden.
- Dieser Test setzt natürlich voraus, daß der für die Kontrolle
- der Unterschrift verwendete öffentliche Schlüssel einen hohen
- Grad an Vertrauen hat.
-
-
-
- Lücken in der physischen Sicherheit
- -----------------------------------
-
- Die meisten bisher besprochenen Sicherheitsprobleme ergeben
- sich, auch ohne daß ein Angreifer unmittelbaren Zugang zu dem
- Computer hat, auf dem die geheim zu haltenden Daten gespeichert
- sind. Ein direkter Zugriff auf den Computer oder ausgedruckte
- Texte ist auch denkbar, durch Einbruch, Durchsuchen des Mülls,
- eine unerwartete / unbegründete Hausdurchsuchung, Bestechung,
- Erpressung, oder Bespitzelung. Von einigen dieser Angriffe
- dürften insbesondere politische Basisorganisationen (grassroots
- organizations) betroffen sein, die weitgehend auf freiwillige
- Mitarbeit angewiesen sind. Die Presse hat einiges darüber
- berichtet, daß das FBI im Rahmen seines COINTELPRO-Programms
- mit Einbruch, Infiltration und illegalen Wanzen gegen
- Antikriegs- und Bürgerrechtsgruppen gearbeitet hat. Nicht zu
- vergessen: Die Watergate-Affaire. [Für die Bundesrepublik gilt
- ähnliches - Spitzel von Verfassungsschutz und Polizei hat es
- schon häufig gegeben. Mittlerweile geht die Diskussion ihres
- legalen Einsatzes bis zu der Frage, ob verdeckt arbeitende
- Polizeibeamte mit Gesetzessegen auch Straftaten sollen begehen
- können. d.Ü.]
-
- Die Verwendung eines Verschlüsselungsprogramms kann ein
- trügerischen, einschläferndes Gefühl der Sicherheit entstehen
- lassen. Kryptographische Techniken schützen Daten aber nur
- solange, wie sie verschlüsselt sind - Löcher in der
- unmittelbaren physischen Sicherheit können nach wie vor
- Klartextdaten und geschriebene oder gesprochene Information
- offenlegen.
-
- Diese Art von Angriffen ist einfacher und billiger als ein
- kryptanalytischer Angriff auf PGP.
-
-
-
- "Sturmangriffe" (tempest attacks)
- ---------------------------------
-
- Eine andere Angriffsmöglichkeit für einen gut ausgerüsteten
- Gegner ist Auswertung der elektromagnetischen Strahlung, die
- ein Computer aussendet. Ein solcher Angriff ist zwar teuer und
- arbeitsintensiv, aber wahrscheinlich immer noch billiger als
- eine richtige Kryptanalyse. Ein entsprechend ausgerüsteter
- Kleinbus könnte in der Nähe des abzuhörenden Computer geparkt
- sein, und jeden Tastendruck und jeden Bildschirminhalt
- aufzeichnen. Das würde alle Paßworte, Nachrichten usw.
- offenlegen. Abwehren läßt sich dieser Angriff durch eine
- geeignete Abschirmung des Computers, des Zubehörs (Drucker
- usw.) und gegebenenfalls der Netzwerk-Verkabelung. Eine solche
- Abschirmung ist unter dem Begriff "sturmsicher" bekannt, und
- wird von einigen Regierungsbehörden und Rüstungsfirmen
- eingesetzt. Es gibt Firmen, die diese Abschirmungen anbieten,
- allerdings ist der Kauf möglicherweise genehmigungspflichtig.
- Woher das wohl kommt?
-
-
-
- Probleme bei Mehrplatz-Computern
- --------------------------------
-
- Ursprünglich entworfen wurde PGP für (Ein-Platz)-MSDOS-
- Computer, zu denen man unmittelbaren Zugang hat. Ich benutze
- PGP zu Hause auf meinem privaten PC, und solange niemand
- einbricht oder die elektromagnetischen Signale des PC
- auswertet, sind die Klartext-Dateien und die geheimen Schlüssel
- wahrscheinlich sicher.
-
- Aber mittlerweile gibt es PGP auch für Unix und VAX/VMS, also
- Mehrplatz-Betriebssysteme. Bei diesen Betriebssystemen besteht
- ein wesentlich höheres Risiko, daß Klartext-Dateien, Schlüssel
- oder Paßworte offengelegt werden. Der Systemverwalter oder ein
- versierter Eindringling kann die Klartext-Dateien lesen, und
- unter Umständen auch mittels spezieller Software heimlich die
- Tastatureingaben und die Bildschirmausgaben mitlesen. Unter
- Unix kann jede BenutzerIn mit dem Kommando "ps" einiges an
- Informationen über die anderen BenutzerInnen erhalten,
- beispielsweise alle Umgebungsvariablen (environment variables).
- [Wenn jemand dann auf einer Unix-Mehrplatz-Maschine noch aus
- Faulheit "pgppass" - nicht zu verwechseln mit "pgppath"! -
- setzt, legt er sein Mantra allen anderen BenutzerInnen offen.
- d.Ü.] Ähnliche Probleme gibt es für MSDOS-Rechner, die in einem
- Netzwerk arbeiten. Das aktuelle Sicherheitsrisiko hängt von der
- jeweiligen Situation ab. Ein Mehrplatz-Rechner kann sicher
- sein, wenn man allen BenutzerInnen traut, oder wenn die
- Sicherheitsmechanismen ausreichen, um den Angriffen von
- Eindringlingen standzuhalten, oder auch, wenn es ganz einfach
- keine hinreichend interessierten potentiellen Eindringlinge
- ging. Manche Unix-Systeme sind schon dadurch sicher, daß sie
- von nur einer Person benutzt werden - es gibt bereits
- Notebooks, die mit Unix arbeiten. PGP vollkommen von der
- Benutzung unter Unix auszuschließen, wäre unsinnig.
-
- PGP ist nicht dafür gedacht, Daten zu schützen, die als
- Klartext auf einem schlecht geschützten oder "aufgeflogenen"
- Rechner vorhanden sind. Ebenso wenig kann es einen Eindringling
- davon abhalten, einen geheimen Schlüssel während seiner
- Benutzung mitzulesen. Diese Risiken muß man sich gerade für
- Mehrplatz-Rechner klar machen, und die Erwartungen an PGP und
- das eigene Verhalten darauf abstimmen. Aber vielleicht hat die
- LeserIn doch die Möglichkeit, PGP auf einem "isolierten", also
- nicht an ein Netzwerk angeschlossenen, Ein-Platz-PC zu
- verwenden, der unter ihrer unmittelbaren physischen Kontrolle
- ist. So setze ich PGP ein, und dazu rate ich auch.
-
-
-
- Statistik von Nachrichtenverbindungen
- -------------------------------------
-
- Selbst wenn ein Angreifer nicht in Lage ist, den Inhalt der
- verschlüsselten Nachrichten zu lesen, hat er immer noch die
- Möglichkeit, brauchbare Informationen daraus zu gewinnen, woher
- Nachrichten kommen, an wen sie gehen, aus der Länge, aus Datum
- und Uhrzeit der Nachrichten. Dies entspricht der Auswertung,
- wann man mit wem wie lange telefoniert, ohne daß die einzelnen
- Gespräche abgehört werden. Das ist mit "Statistik von
- Nachrichtenverbindungen" gemeint. PGP schützt hiervor nicht. Um
- dies Problem zu lösen, wären speziell hierfür entworfene
- Übertragungsprotokolle nötig, die möglicherweise
- kryptographische Elemente enthalten. [Diese Art der
- Überwachung, die eigentlich auch noch das durch PGP verhinderte
- Durchsuchen der ganzen Post nach Schlüsselworten einschließt,
- ist wohl die am besten genutzte Informationsquelle, die
- Nachrichtendiensten zur Verfügung steht. d.Ü.]
-
-
-
- Kryptanalyse
- ------------
-
- Ein teurer und schwieriger kryptanalytischer Angriff könnte von
- einem Geheimdienst durchgeführt werden, der über ein
- ausreichendes Arsenal von Supercomputertechnologie verfügt.
- Dieser Geheimdienst könnte einen RSA-Schlüssel unter Verwendung
- eines bahnbrechenden neuen, geheimgehaltenen Algorithmus für
- die Primfaktorzerlegung knacken. Das ist denkbar, aber man
- sollte nicht vergessen, daß die US-Regierung dem RSA-
- Algorithmus soweit vertraut, daß mit ihm nach Aussage von Ron
- Rivest Kernwaffen gesichert werden. Und im zivilen Bereich gibt
- es seit 1978 intensive, aber erfolglose Versuche, RSA zu
- knacken.
-
- Möglicherweise hat die Regierung auch geheimgehaltene Methoden,
- um IDEA(tm) zu knacken, den bei PGP verwendeten konventionellen
- Verschlüsselungsalgorithmus. Das wäre der schlimmste Alptraum
- jedes Kryptographen. In der praktischen Kryptographie gibt es
- keine Garantie für absolute Sicherheit.
-
- Doch nach wie vor ist etwas Optimismus gerechtfertigt. Die
- Entwickler von IDEA gehören zu den besten Kryptographen
- Europas. Die besten Kryptanalytiker der nicht geheimen Welt
- haben IDEA einer ausgedehnten Analyse und eingehenden
- Überprüfung unterzogen. Einer differentiellen Kryptanalyse, mit
- der DES geknackt wurde, scheint IDEA besser standzuhalten.
-
- Aber selbst wenn IDEA die eine oder andere subtile
- Schwachstelle haben sollte, so komprimiert PGP der Klartext vor
- der Verschlüsselung, was die von einer solchen Schwachstelle
- ausgehende Gefährdung um einiges reduzieren dürfte. Der für das
- Knacken erforderliche Rechenaufwand dürfte in den meisten
- Fällen um einiges höher sein, als der Wert der entschlüsselten
- Nachricht.
-
- Wenn man in einer Situation ist, in der die Furcht vor so einem
- Angriff größten Kalibers berechtigt ist, wäre an der Zeit, die
- Dienste einer SicherheitsberaterIn in Anspruch zu nehmen, die
- auf die jeweilige Situation zugeschnittene Lösungen anbieten
- kann. Boulder Software Engineering bietet diese Leistungen an.
- Die Adresse und Telefonnummer stehen am Ende dieses Handbuchs.
-
- Kurz gesagt, kann ein Gegner mühelos, sogar routinemäßig,
- Datenkommunikation abhören, insbesondere, wenn ein Modem oder E-
- Mail benutzt wird, es sei denn, die Daten die Daten sind gut
- kryptographisch geschützt. Wenn man PGP verwendet, und die
- erforderlichen Vorsichtsmaßnahmen beachtet, muß ein Angreifer
- erheblich mehr Arbeit und Kosten aufbringen, um in die
- Privatsphäre einzubrechen.
-
- Wenn man sich von einfachen Angriffen schützt, und annehmen
- kann, daß man nicht einem entschlossenen und sehr gut
- ausgestatteten Angreifer gegenüber steht, dann dürfte die
- Verwendung von PGP sicher sein. PGP (Pretty Good Privacy) sorgt
- für Prima Geschützte Privatsphäre.
-
-
-
- Rechtsfragen
- ============
-
- [Hinweis: Der folgende Abschnitt ist - wie der Rest des
- Handbuches auch - eine Übersetzung des von Philip Zimmermann
- geschriebenen englischen Handbuches. Im Gegensatz zum Rest des
- Handbuches, das sprachunabhängig "internationale Gültigkeit"
- hat, bezieht sich der folgende Abschnitt im wesentlichen auf
- die rechtliche Lage in den USA. Eine deutschsprachige
- Ergänzung, die rechtliche Fragen für die BRD, die Schweiz oder
- Österreich behandelt, wäre zwar sinnvoll, ist aber z. Zt. nicht
- in Sicht. d.Ü.]
-
-
- Warenzeichen, Copyright, Garantie
- ---------------------------------
-
- "Pretty Good Privacy", "Phils's Pretty Good Software", und
- "Pretty Good" als Warenezeichen für Computerhardware und
- Software sind Warenzeichen von Philip Zimmermann und von Phil's
- Pretty Good Software. PGP ist (c) Copyright by Philip R.
- Zimmermann 1990-1993. Philip Zimmermann hat auch das Copyright
- für das PGP-Handbuch, und für Übersetzungen von Handbuch und
- Software in andere Sprachen.
-
- Der Autor übernimmt keine Haftung für Schäden, die aus der
- Nutzung der Software entstehen, auch dann nicht, wenn die
- Schäden aus Fehlern der Software resultieren. Der Autor macht
- keine Angaben über die Verkaufbarkeit der Software, oder ihre
- Brauchbarkeit für bestimmte Anwendungen. Die Software wird zur
- Verfügung gestellt "as is", ohne jede explizite oder implizite
- Garantie.
-
-
-
- Patentrechte auf die Algorithmen
- --------------------------------
-
- Das Verschlüsselungsverfahren RSA wurde am MIT entwickelt. Dem
- MIT wurde ein Patent auf RSA erteilt (U.S. patent #4,405,829,
- erteilt am 20. September 1983). Eine kalifornische Firma namens
- Public Key Partners besitzt die alleinigen Rechte an diesem
- Patent für den Verkauf und die Lizensierung des RSA-
- Verschlüsselungssystems.
-
- PKP hat für die Nutzung von RSA bei PGP keine Lizenz erteilt.
- Der Autor der Software stellt diese Implementierung nur für
- Lehrzwecke zur Verfügung. Die Verantwortung für die
- Lizensierung von RSA durch PKP liegt bei Ihnen als AnwenderIn,
- nicht beim Autor. Der Autor übernimmt keine Verantwortung für
- eine mögliche Verletzung von Patentrechten, die sich aus der
- Nutzung von PGP auf dem Computer einer AnwenderIn ohne eine
- Lizenz durch den Inhaber des RSA-Patents ergeben können.
-
- Für AnwenderInnen außerhalb der USA sei angemerkt, daß das US-
- Patent auf RSA nur innerhalb des USA gilt, und daß es kein RSA-
- Patent in anderen Ländern gibt. US-Bundesbehörden können RSA
- nutzen, weil die Entwicklung von RSA staatlich finanziert wurde
- durch Zuschüsse der National Science Foundation und der US-
- Marine. Firmen, die bereits eine Lizenz für die Nutzung von RSA
- haben, dürfen PGP nutzen, falls sie einen geeigneten
- Lizenzvertrag abgeschlossen haben.
-
- Ich schrieb PGP vollständig selbst, mit einer eigenständig
- entwickelten Implementierung des RSA-Algorithmus. Vor der
- Veröffentlichung von PGP erhielt ich das Rechtsgutachten eines
- Patentanwalt mit großer Erfahrung bei Softwarepatenten. Ich bin
- überzeugt, daß die Art, in der ich PGP veröffentlicht habe,
- keinen Verstoß gegen das Patentrecht darstellt.
-
- PKP erhielt nicht nur die ausschließlichen Patentrechte für
- RSA, sondern auch die ausschließlichen Rechte für drei andere
- Patente für public key Verschlüsselungssysteme, die an der
- Stanford University mit Bundeszuschüssen entwickelt wurden. Im
- Prinzip entscheidet damit in den USA eine einzige Firma über
- die Verwendung von public key Verschlüsselungssystemen. PKP
- beansprucht sogar das Patentrecht an dem grundlegenden Konzept
- der Kryptographie mit öffentlichen Schlüsseln, unabhängig
- davon, wie intelligent auch immer ein neuer Algorithmus sein
- wird, der unabhängig von PKP entwickelt werden könnte. Ich
- halte ein derart umfassendes Monopol für gefährlich, weil ich
- der Meinung bin, das Kryptographie mit öffentlichen Schlüsseln
- einen zentralen Beitrag zum Schutz der Bürgerrechte und der
- Privatsphäre in unserer immer mehr verkabelten Gesellschaft
- leisten kann. Zumindest setzt das Monopol von PKP diese
- lebenswichtige Technologie dem Risiko der Einflußnahme durch
- die Regierung aus.
-
- Es laufen Verhandlungen mit RSA Data Security Inc. (RSADSI),
- einer Schwesterfirma von PKP, über die Legalisierung von PGP in
- den USA. Dies würde abgeschlossen werden durch die Integration
- von RSAREF in PGP. RSAREF ist Softwarepaket von RSADSI, das die
- RSA-Algorithmen implementiert. Diese Routinen aus RSAREF würden
- dann die bisherigen RSA-Routinen in PGP ersetzen. Die
- Einbindung von RSAREF verursacht ein paar technische Probleme,
- aber dafür werden sich Lösungen ergeben, wenn die Verhandlungen
- mit RSADSI erfolgreich verlaufen. Wenn RSAREF in PGP integriert
- ist, wird PGP von RSADSI für den nichtkommerziellen Gebrauch in
- den USA lizensiert werden. Ausländische Versionen von PGP
- werden die schnelleren PGP-eigenen RSA-Routinen behalten.
- RSADSI verlangt möglicherweise, den Namen von PGP zu ändern.
- Halten Sie sich auf dem laufenden. [Mittlerweile ist es soweit:
- PGP wird in den USA unter dem Namen Viacrypt ganz legal
- verkauft. d.Ü.]
-
- Unabhängig davon, ob die Lizensierungsprobleme mit PKP gelöst
- werden können, wird es mit ziemlicher Sicherheit neue Versionen
- von PGP geben. Wenn PKP keine Lizenz für PGP erteilt, werden
- die neuen Versionen wahrscheinlich nicht mehr von mit kommen.
- PGP hat zahllose Fans auch außerhalb der USA, und viele von
- ihnen sind Softwareentwickler, die PGP verbessern und fördern
- wollen, unabhängig davon, was ich mache. Die zweite Version von
- PGP ist das Ergebnis gemeinsamer Arbeit eines internationalen
- Entwicklungsteams, dem unter meiner Leitung eine Reihe von
- Verbesserungen gegenüber der originalen Version gelang. Branko
- Lancaster hat diese Version in Holland veröffentlicht, Peter
- Gutmann in Neuseeland, außerhalb des Geltungsbereichs des
- amerikanischen Patentrechts. Obwohl diese Version nur in Europa
- und Neuseeland veröffentlicht wurde, verbreitete sie sich
- spontan bis in die USA, ohne daß ich oder Entwicklungsteam dazu
- irgend etwas beigetragen haben.
-
- Das bei PGP ebenfalls verwendete blockorientierte
- Verschlüsselungsverfahren IDEA unterliegt in Europa einem
- Patent, das der ETH Zürich und einer Schweizer Firma namens
- Ascom-Tech AG gehört. Die Patentnummer ist PCT/CH91/00117.
- [Nach meiner Kenntnis können Algorithmen innerhalb der EG nicht
- patentiert werden. Aber für eine endgültige Antwort wäre hier
- eine JuristIn zu fragen. d.Ü.] Internationale Patente sind
- angemeldet. Für die nichtkommenzielle Verwendung von IDEA
- werden keine Lizenzgebühren verlangt. Die Ascom-Tech AG hat
- eine Lizenz für die Nutzung von IDEA bei PGP erteilt, auch für
- den kommerziellen Einsatz von PGP. Die Verwendung der IDEA-
- Routinen aus PGP in anderen, kommerziellen Produkten ist ohne
- eine Lizenz von Ascom Tech nicht erlaubt. Kommerzielle Anwender
- von IDEA können Details zur Lizensierung bei Dieter Profoss,
- Ascom Tech AG, Solothurn Lab, Postfach 151, 4502 Solothurn,
- Switzerland, Tel +41 65 242885, Fax +41 65 235761, erfahren.
-
- Die bei PGP verwendeten ZIP-Kompressionsroutinen stammen aus
- Freeware-Quellcode und werden mit Erlaubnis des Autors
- verwendet. Mir sind keine Patente bekannt, die für die
- Kompressionsalgorithmen erteilt worden wären, aber Sie können
- diese Frage gerne selbst genauer untersuchen.
-
-
-
- Lizensierung und Vertrieb
- -------------------------
-
- In den USA kontrolliert PKP die Lizensierung von RSA auf der
- Basis des US-Patentgesetzes. Aber ich selbst habe keinerlei
- Einwände dagegen, daß jemand PGP benutzt oder weitergibt, und
- ich verlangt auch keine Nutzungsgebühren. Die Copyrightvermerke
- im Programm und in dieser Dokumentation dürfen nicht gelöscht
- oder geändert werden. Innerhalb der USA sind damit aber nicht
- unbedingt die rechtlichen Verpflichtungen erfüllt, die Sie
- möglicherweise gegenüber PKP wegen der Verwendung des RSA-
- Algorithmus haben.
-
-
- PGP ist keine Shareware, es ist Freeware. Verbotene Freeware.
- Veröffentlicht als gesellschaftliche Dienstleistung. Daß PGP
- kostenlos ist, ermutigt viele Menschen, PGP auch zu verwenden,
- und dies wird hoffentlich größere soziale Auswirkungen haben.
- Hieraus könnte sich ein großer Bekanntheitsgrad und eine weite
- Verbreitung von RSA ergeben.
-
- Der gesamte Quellcode von PGP ist frei verfügbar im Rahmen des
- "Copyleft" der General Public License der Free Software
- Foundation. Eine Kopie der General Public License der FSF
- gehört zum Programmpaket von PGP.
-
- Unabhängig von General Public License, und in manchen Punkten
- ihr unter Umständen widersprechend, gelten die folgenden
- Bedingungen:
-
- 1) Besprechungen von PGP in Zeitungen oder Büchern dürfen
- unbeschränkt Auszüge des PGP-Quellcodes und der
- Dokumentation enthalten
- 2) Die General Public License läßt zwar die Verwendung von
- Programmen oder Programmteilen für andere Produkte zu, wenn
- diese Produkte ebenfalls frei und kostenlos erhältlich sind,
- untersagt aber die Verwendung in kommerziellen Programmen.
- Abweichend von dieser Regelung bin ich im Prinzip bereit,
- eine spezielle Lizenz für die Verwendung von Teilen von PGP
- in kommerziellen Produkten zu erteilen. Ob diese Lizenz Geld
- kostet, hängt von den jeweiligen Umständen ab.
- Gegebenenfalls reicht schon ein Copyrightvermerk und ein
- Quellenhinweis. In einem Telefongespräch läßt sich das
- genauer bereden. Ich bin ziemlich leicht zufriedenzustellen.
- Eine solche Lizenz enthebt Sie aber nicht der Pflicht, die
- Rechte an den Patenten zu berücksichtigen.
-
- Scheuen Sie sich nicht, das vollständige PGP-Paket soweit wie
- möglich zu verbreiten. Geben Sie es allen Ihrem FreundInnen.
- Wenn Sie Zugang zu Mailboxen haben, stellen Sie PGP in
- möglichst allen Mailboxen öffentlich zur Verfügung. Auch den
- Quellcode können Sie beliebig verbreiten. Die ausführbare PGP-
- Version 2.3(a) für MSDOS steht zusammen mit der Dokumentation,
- einigen öffentlichen Schlüsseln, darunter mein eigener, sowie
- Unterschriften unter das Programm in einer Datei namens
- PGP23[a].ZIP. Das Paket mit Quellcode für MSDOS enthält alle C-
- und Assemblerdateien in einer PKZIP-Datei namens PGP23src.ZIP.
- Die Dateinamen ergeben sich aus der Versionsnummer.
-
- Kostenlose Kopien und Updates von PGP finden Sie weltweit in
- tausenden von Mailboxen und anderen öffentlich zugänglichen
- Archiven, wie FTP-Servern im Internet. Mich selbst brauchen Sie
- nicht nach PGP zu fragen, weil ich weitere rechtliche Probleme
- mit PKP vermeiden möchte. Woher Sie PGP bekommen können, kann
- ich Ihnen aber schon sagen.
-
- Nach all der Arbeit an PGP möchte ich noch anmerken, daß ich
- gegen Fanpost nichts einzuwenden habe, allein schon, um seine
- Popularität abschätzen zu können. Teilen Sie mir mit, was Sie
- von PGP halten, und wieviele Ihrer FreundInnen es verwenden.
- Hinweise auf Fehler und Verbesserungsvorschläge sind natürlich
- ebenfalls gerne gesehen. In künftigen PGP-Versionen werden Ihre
- Anregungen möglicherweise berücksichtigt werden.
-
- Das PGP-Projekt wurde nicht finanziell gefördert, und hat mir
- beinahe die Haare vom Kopf gefressen. Sie dürfen deshalb nicht
- mit einer Antwort auf Ihren Brief rechnen, es sei denn, Sie
- legen einen frankierten Rückumschlag bei. Lieber antworte ich
- auf E-Mail. Bitte schreiben Sie auf Englisch, weil meine
- Fremdsprachenkenntnisse begrenzt sind. Wenn Sie mich anrufen,
- und ich bin nicht da, probieren Sie am besten etwas später noch
- einmal. Rückrufe auf Ferngespräche mache ich in der Regel
- nicht, es sei denn, Sie akzeptieren ein R-Gespräch. Falls Sie
- mich für längere Zeit brauchen: Ich stehe als Berater auf
- entsprechender finanzieller Basis zu Verfügung, und antworte
- auch auf derartige Anfragen.
-
- Die ungelegenste Post, die ich bekomme, stammt von Menschen,
- die mir in der besten Absicht ein paar Dollar schicken mit
- Bitte, ihnen PGP zuzusenden. Ich mache das nicht, um
- rechtlichen Problemen mit PKP aus dem Weg zu gehen. Noch
- schlechter ist es, wenn so eine Anfrage aus dem Ausland kommt.
- In dem Fall würde ich es riskieren, die US-amerikanischen
- Gesetze über den Export von Kryptographie zu verletzen. Aber
- auch wenn es keine rechtliche Auseinandersetzung um PGP gäbe:
- Normalerweise reicht das Geld in so einem Brief nicht aus, um
- den Zeitaufwand zu rechtfertigen, den ich mit dem Versand
- hätte. Ich bin nicht darauf eingerichtet, im Nebenberuf
- preiswertes Versandhaus zu spielen. Andererseits kann ich das
- Geld auch nicht einfach behalten, weil es als Honorar für eine
- Leistung gedacht ist. Um das Geld aber zurückzuschicken, muß
- ich mich in mein Auto setzen, zum Postamt fahren, und
- Briefmarken kaufen. Normalerweise kommen diese Anfragen ohne
- frankierten Rückumschlag. Als nächstes muß ich mir die Zeit
- nehmen, eine freundliche Antwort zu schreiben, daß ich dem
- Wunsch der Absender nicht nachkommen kann. Wenn ich die
- Beantwortung zurückstelle und den Brief einfach auf meinen
- Schreibtisch lege, kann es passieren, das er innerhalb von
- Minuten unter Papierstapeln vergraben wird, und erst Monate
- später wieder ans Tageslicht kommt. Wenn Sie all diese kleinen
- Unbequemlichkeiten mit der Anzahl der Anfragen multiplizieren,
- wird Ihnen das Problem klar. Reicht es nicht, daß PGP nichts
- kostet? Wie schön wäre es, wenn diese Leute versuchen würden,
- PGP aus irgendeiner der unzähligen vorhandenen Quellen zu
- beziehen. Wenn Sie kein Modem haben, fragen Sie in Ihrem
- Bekanntenkreis. Wenn Sie keine Bezugsquelle finden, können Sie
- mich kurz anrufen.
-
- Wer immer freiwillig an der Verbesserung von PGP mitarbeiten
- möchte, möge mir das mitteilen. PGP könnte weitere Arbeit
- durchaus vertragen. Ein paar Optionen wurden zurückgestellt, um
- PGP ohne zu große Verzögerung veröffentlichen zu können. Viele
- Leute haben ihre Zeit damit verbracht, PGP auf Unix für Sun
- Sparcstations, auf Ultrix, auf VAX/VMS, auf den Amiga und auf
- den Atari ST zu portieren. Vielleicht können auch Sie dabei
- helfen, PGP auf weitere Maschinen zu portieren. Aber schreiben
- Sie mir, bevor Sie mit einer Portierung oder Verbesserung von
- PGP anfangen, um doppelte Arbeit oder die Verwendung veralteter
- Versionen der Quellcodes zu vermeiden.
-
- Es gibt so viele fremdsprachige Übersetzungen von PGP, daß die
- meisten Sprachkits nicht im Standardpaket von PGP enthalten
- sind, um Speicherplatz zu sparen. Einzelne Sprachkits können
- Sie aus einer großen Zahl unabhängiger Quellen beziehen. Häufig
- sind es die gleichen Quellen, bei denen Sie auch das
- eigentliche PGP-Paket finden. Diese Kits enthalten übersetzte
- Versionen von LANGUAGE.TXT, PGP.HLP und vom Handbuch. Falls Sie
- daran denken, PGP in Ihre Muttersprache zu übersetzen, setzen
- Sie sich mit mir in Verbindung, damit Sie die neuesten
- Informationen und Standardisierungsrichtlinien bekommen, und um
- herauszufinden, ob es bereits eine Übersetzung in Ihre Sprache
- gibt. Colin Plumb (colin@nyx.cs.du.edu) verwaltet eine
- umfangreiche Sammlung von Sprachkits.
-
- Bei künftigen Versionen von PGP kann sich unter Umständen das
- Datenformat von Nachrichten, Unterschriften, Schlüsseln oder
- Schlüsseldateien ändern, wenn dadurch wichtige neue Funktionen
- ermöglicht werden. Daraus können sich Probleme mit der
- Kompatibilität zur gegenwärtig aktuellen Version ergeben. Diese
- Versionen werden möglicherweise Konvertierungsprogramme für
- alte Schlüssel enthalten, aber Nachrichten, die mit alten PGP-
- Versionen erzeugt wurden, werden nicht unbedingt kompatibel zu
- den neuen Versionen von PGP sein.
-
- Wenn Sie Zugang zum Internet haben, achten Sie auf
- Ankündigungen neuer Versionen in "sci.crypt" und in der
- speziellen PGP newsgroup "alt.security.pgp". Es gibt eine
- mailing list namens "info-pgp", gedacht für Leute ohne Zugang
- zu "alt.security.pgp". Hugh Miller moderiert info-pgp. Mit
- einer Nachricht an info-pgp-request@lucpul.it.luc.edu können
- Sie sich von ihm in die mailing list eintragen lassen.
- Vergessen Sie nicht, Ihren Namen und Ihre Internet-Adresse
- anzugeben. Wenn Sie wissen wollen, woher Sie PGP beziehen
- könne, kann Hugh Ihnen eine Liste mit FTP-Servern im Internet
- und Telefonnummern von Mailboxen schicken. Hugh erreichen Sie
- auch unter hmiller@lucpul.it.luc.edu.
-
-
-
- Exportkontrolle [auf die USA bezogen d.Ü.]
- ------------------------------------------
-
- Die Regierung hat schon häufig den Export guter
- kryptographischer Technologie verboten, und dies Verbot kann
- auch PGP betreffen. Diese Art von Programmen wird wie
- Kriegswaffen behandelt. Die Rechtsgrundlage hierfür ist eine
- einfache Verordnung des State Departement, kein richtiges
- Gesetz. Ich selbst werde diese Art Software nicht aus den USA
- oder Kanada exportieren, für den Fall, daß dies gemäß den
- Verordnungnen des State Departement illegal ist, und ich
- übernehme keine Verantwortung für den möglichen Export durch
- andere.
-
- Wenn Sie außerhalb der USA und Kanadas leben, rate ich Ihnen,
- gegen diese Verordnungen des State Departement nicht dadurch zu
- verstoßen, daß Sie sich PGP aus den USA besorgen. Tausende von
- US-BürgerInnen haben sich PGP nach seiner ersten
- Veröffentlichung besorgt, und irgendwie ist es dann aus den USA
- herausgekommen, und hat sich dann wie Pusteblumen [xxx
- dandelion seed] von selbst weiterverbreitet. Wenn PGP bereits
- den Weg in Ihr Land gefunden hat, dann werden Sie
- wahrscheinlich keine US-Exportgesetze verletzen, wenn Sie sich
- PGP aus einer Quelle außerhalb der USA besorgen.
-
- Einige Juristen , mit denen ich sprach, haben den Eindruck, daß
- die Rahmenbedingungen der US-Exportkontrolle nicht dafür
- ausgelegt wurden, auf so etwas wie kryptographische Freeware,
- die sich ganz von allein verbreitet, angewandt zu werden. Es
- ist schwer vorstellbar, daß ein US-amerikanischer Staatsanwalt
- versucht, jemanden anzuklagen wegen des "Exportes" von
- Software, die in den USA kostenlos erhältlich ist. Ich kenne
- niemanden, der ein entsprechendes Beispiel nennen kann, obwohl
- es eine Reihe von Verstößen gegen die Exportgesetze gibt. Ich
- bin kein Jurist und gebe auch keinen juristischen Rat -- ich
- versuche nur deutlich zu machen, was der allgemeinen Auffassung
- entspricht. [Exakt wegen illegalen Exports kryptographischer
- Technologie ermittelt der US-Zoll z.Zt. gegen Philip
- Zimmermann. d.Ü.]
-
- Seit Version 2.0 wird PGP nicht mehr aus den USA heraus
- veröffentlicht, sondern über öffentlich zugängliche Computer in
- Europa. Jede neue Version wird von PGP- und Privatsphären-
- AktivistInnen in die USA geschickt, und dort auf öffentlich
- zugänglichen Computern bereitgestellt. Es gibt in den USA zwar
- auch Einschränkungen für den Import von Kriegswaffen, aber ich
- kenne keinen Fall, in dem diese Regelung auf den Import
- kryptographischer Software angewandt worden wäre. Ich denke,
- daß ein Verfahren hiergegen eine recht spektakuläre Kontroverse
- werden würde.
-
- Einige ausländische Regierungen verhängen hohe Strafen allein
- für verschlüsselte Kommunikation. In manchen Ländern kann man
- dafür sogar erschossen werden. Aber wenn man in so einem Land
- lebt, braucht man PGP vielleicht um so mehr.
-
-
-
- Computer-orientierte politische Vereinigungen [in den USA]
- ==========================================================
-
- PGP ist ein sehr politisches Programm, so daß ein Hinweis
- angebracht ist auf politische Gruppen, die sich mit EDV
- beschäftigen. Genaueres zu diesen Gruppen, und wie sie
- erreichbar sind, steht in einer eigenen Datei, die zum PGP-
- Paket gehört.
-
- Die Electronic Frontier Foundation (EFF) wurde im Juli 1990
- gegründet, mit dem Ziel, die Freiheit des Wortes in digitalen
- Medien zu verteidigen, insbesondere, um sicherzustellen, daß
- die Grundsätze der Verfassung der USA und ihrer Ergänzungen
- (Bill of Rights) auch bei computerbasierter Kommunikation zur
- Geltung kommen. Die EFF ist in Washington DC unter der
- Telefonnummer (202) 347-5400 erreichbar. Ihre Internet-Adresse
- ist eff@eff.org.
-
- Die Computer Professionals For Social Responsibility (CPSR)
- unterstützen EDV Fachleute und AnwenderInnen, die sich für
- einen verantwortungsvollen Umgang mit Informationstechnologie
- einsetzen, und fördern die breite politische Auseinandersetzung
- um die gesellschaftlichen Auswirkungen der
- Informationstechnologie. Sie sind in Palo Alto unter der
- Telefonnummer 415-322-3778 und unter der Internet-Adresse
- cpsr@csli.stanford.edu erreichbar.
-
- Die League for Programming Freedom (LPF) ist eine "grass-root"-
- Vereinigung von ProfessorInnen, Studierenden, Geschäftleuten,
- ProgrammierInnen und AnwenderInnen, die sich dem Ziel der
- uneingeschränkten Freiheit bei der Programmerstellung widmen.
- Die LPF sieht Patente auf Computeralgorithmen als schädlich für
- die US-amerikanische Computerindustrie an. Telefon: (617) 433-
- 7071. E-Mail: lpf@uunet.uu.net.
-
- Genauere Informationen zu diesen Gruppen stehen in der Datei
- "politic.doc". [Eine vergleichbare Datei über Gruppen aus dem
- deutschen Sprachraum ist nicht in Arbeit. d.Ü.]
-
-
- Empfohlene Literatur für den Einstieg in Kryptographie:
- =======================================================
-
- 1) Dorothy Denning, "Cryptography and Data Security", Addison-
- Wesley, Reading, MA 1982
- 2) Dorothy Denning, "Protecting Public Keys and Signature
- Keys", IEEE Computer, Feb 1983
- 3) Martin E. Hellman, "The Mathematics of Public-Key
- Cryptography," Scientific American, Aug 1979
- 4) Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54.
- (Ein "muß" zu PGP und verwandten Themen)
-
- Weitere Literatur
- =================
-
- 5) Ronald Rivest, "The MD5 Message Digest Algorithm", MIT
- Laboratory for Computer Science, 1991
- 6) Xuejia Lai, "On the Design and Security of Block Ciphers",
- Institute for Signal and Information Processing, ETH-
- Zentrum, Zurich, Switzerland, 1992
- 7) Xuejia Lai, James L. Massey, Sean Murphy, "Markov Ciphers
- and Differential Cryptanalysis", Advances in Cryptology-
- EUROCRYPT'91
- 8) Philip Zimmermann, "A Proposed Standard Format for RSA
- Cryptosystems", Advances in Computer Security, Vol III,
- edited by Rein Turn, Artech House, 1988
- 9) Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C", John Wiley & Sons, 1993
- (erscheint im November)
- 10) Paul Wallich, "Electronic Envelopes", Scientific American,
- Feb 1993, page 30. (Handelt von PGP)
-
-
-
- Die Adresse des Autors
- ======================
-
- Philip Zimmermann
- Boulder Software Engineering
- 3021 Eleventh Street
- Boulder, Colorado 80304 USA
- Telefon/Fax 303-541-0140 (10:00am - 7:00pm Mountain Time)
- Internet: prz@acm.org
-
-
-
- Anhang: Bezugsquellen für PGP
- ===============================
-
- [Die folgenden Angaben von Bezugsquellen stammen unmittelbar
- von Philip Zimmermann. Sie nicht unbedingt jetzt noch gültig,
- außerdem sind andere Bezugsquellen hinzugekommen. Eine ständige
- Aktualisierung einer solchen Liste würde sehr viel Arbeit
- kosten. Für aktuelle Listen sei an dieser Stelle auf die
- englischen FAQs, die regelmäßig in alt.security.pgp
- veröffentlicht werden, sowie auf die deutschen FAQs, die in
- /T-NETZ/PGP/ALLGEMEIN und in comp.security.de veröffentlicht
- werden. d.Ü]
-
- Im folgenden wird erläutert, wie man das Freeware-Programm PGP
- von einem anonymen FTP-Server im Internet und aus anderen
- Quellen bekommen kann.
-
- PGP hat eine ausgeklügelte Schlüsselverwaltung, verwendet eine
- Kombination von RSA und einer konventionellen Verschlüsselung,
- erzeugt digitale Unterschriften, komprimiert zu verschlüsselnde
- Daten, und ist sehr ergonomisch zu bedienen. PGP ist gut
- ausgestattet und schnell, und es hat ein exzellentes Handbuch.
- Der Quellcode ist kostenlos erhältlich.
-
- PGP verwendet das Verschlüsselungsverfahren RSA, das durch ein
- Patent im Besitz der Firma Public Key Partners geschützt ist.
- Für PGP-AnwenderInnen außerhalb der USA sei angemerkt, daß es
- nur in den USA ein Patent auf RSA gibt. Zu beachten ist, daß es
- allen Personen, die in den USA und Kanada leben, aufgrund der
- Exportgesetze dieser Staaten verboten ist, kryptographische
- Software dieser Art zu exportieren. Wenn Sie jedoch außerhalb
- der USA leben, begehen Sie wahrscheinlich keinen Verstoß gegen
- das US-Exportgesetz, wenn Sie sich PGP von einer Quelle
- außerhalb der USA besorgen. Beachten Sie, daß sich der Name
- "PGP" aufgrund der Verhandlungen mit den RSA-Patentinhabern
- bei zukünftigen Version möglicherweise ändern wird.
-
- Im folgenden finden Sie eine kleine Auswahl von Stellen, an
- denen Sie angeblich PGP bekommen können (Stand: Juni 1993). Für
- die Richtigkeit diese Informationen gibt es keine Garantie.
- Einige Einrichtungen in den USA haben PGP aus Angst vor
- juristischen Einschüchterungsversuchen durch die RSA-
- Patentinhaber zurückgezogen.
-
- Das Standardpaket von PGP besteht aus zwei komprimierten
- Dateien, wobei die Dateinamen die Versionsnummer enthalten. Die
- Version 2.3a steht in der Datei "PGP23A.ZIP". Diese Datei
- enthält das ausführbare Programm für MSDOS und dieses Handbuch
- [im englischen Original. d.Ü.] Außerdem gibt es die Datei
- "PGP23SRC.ZIP", die den Quellcode enthält. Diese Dateien können
- mit PKUNZIP Version 1.10 oder neuer dekomprimiert werden. Unix-
- AnwenderInnen, die keine UNZIP-Implementierung haben, können
- den Quellcode auch in der komprimierter tar-Datei
- pgp23src.tar.Z finden.
-
- Zur Erinnerung: wählen Sie Binärübertragung, wenn Sie sich die
- Dateien per FTP holen. Unter Kermit muß auf beiden Seiten die
- Betriebsart "8 Bit binär" gewählt werden. Und nun eine kleine
- Liste von anonymen FTP-Server, die PGP haben:
-
- Finnland: nic.funet.fi (128.214.6.100)
- Directory: /pub/unix/security/crypt/
-
- Italien: ghost.dsi.unimi.it (149.132.2.1)
- Directory: /pub/security/
-
- Vereinigtes UK: src.doc.ic.ac.uk
- Königreich: Directory: /computing/security/software/PGP
-
- Falls Sie FTP nicht einsetzen können: nic.funet.fi bietet auch
- "FTP-Mail-Service" an. Um PGP zu bekommen, senden Sie die
- folgende Nachricht an mailserv@nic.funet.fi:
-
- ENCODER uuencode
- SEND pub/unix/security/crypt/pgp23src.zip
- SEND pub/unix/security/crypt/pgp23a.zip
-
- [Der Name der Quellcodedatei varriert nach meiner Erfahrung
- etwas. d.Ü.]
-
- Spätestens 24 Stunden später haben Sie in Ihrem Postfach ca. 15
- UU-codierte Nachrichten, aus denen Sie mit UUDecode die beiden
- *.zip-Dateien erhalten.
-
- In den USA finden Sie PGP in unzähligen Mailboxen. Gott allein
- weiß, in wievielen. Es sind mehr, als hier aufgeführt werden
- können. Falls Sie keine Telefonnummern von Mailboxen an Ihrem
- Wohnort kennen, hier eine kleine Auswahl:
-
- GRAPEVINE BBS in Little Rock, Arkansas, hat einen speziellen
- Pseudoaccount eingerichtet, über den man kostenlos PGP "saugen"
- kann. Der Sysop ist Jim Wenzel <jim.wenzel@grapevine.lrk.ar.us>
- Die folgenden Telefonnummern sollten Sie in der Reihenfolge
- ausprobieren, in der sie aufgeführt sind (an der ersten Nummer
- ist das schnellste Modem): (501) 753-6859, (501) 753-8121,
- (501) 791-0124. Als Username geben Sie "PGP USER" an; als
- Paßwort "PGP".
-
- PGP hat auch im Fido-Netz weite Verbreitung gefunden. PGP
- werden Sie in vielen US-amerikanischen und ausländischen Fido-
- Boxen finden.
-
- In Neuseeland können Sie die folgende (wahrscheinlich kostenlos
- arbeitende) Mailbox anrufen:
-
- Kappa Crucis: +64 9 817-3714, -3725, -3324, -8424, -3094,
- -3393
-
- Quell- und Maschinencode von PGP können Sie auch von der
- öffentlich zugänglichen Bibliothek des Kanadischen Rundfunk
- (Canadian Broadcasting Corporation) bekommen. Die Bibliothek
- hat Zweigstellen in Toronto, Montreal und Vancouver. Für
- weitere Fragen können Sie sich an Max Allen, Tel. +1 416 205-
- 6017, wenden.
-
- Zu Informationen zu PGP-Implementierungen für den Apple
- Macintosh, den Commodore Amiga, den Atari ST können Sie Hugh
- Miller <hmiller@lucpul.it.luc.edu> fragen. Er kann Ihnen
- wahrscheinlich auch bei der Frage weiterhelfen, für welche
- anderen Rechner und Betriebssysteme es bereits PGP gibt.
-
- Hier die E-Mail-Adressen oder Telefonnummern einiger Personen,
- die Sie fragen können, wo es PGP in einem bestimmten Land gibt:
-
- Peter Gutmann Hugh Kennedy
- pgut1@cs.aukuni.ac.nz 70042.710@compuserve.com
- Neuseeland Deutschland
-
- Branko Lankester Miguel Angel Gallardo
- lankeste@fwi.uva.nl gallardo@batman.fi.upm.es
- +31 2159 42242 (341) 474 38 09
- Holland Spanien
-
- Hugh Miller Colin Plumb
- hmiller@lucpul.it.luc.edu colin@nyx.cs.du.edu
- (312) 508-2727 Toronto, Ontario, Canada
- USA
-
- Jean-loup Gailly
- jloup@chorus.fr
- Frankreich
-
- Drei weitere Adressen in der BRD
- Marc Aurel <4-tea-2@hit.zer.de>
- Christopher Creutzig <c.creutzig@hot.gun.de>
- Abel Deuring <a.deuring@bionic.zer.de>
-
-
-