home *** CD-ROM | disk | FTP | other *** search
/ Amiga MA Magazine 1998 #6 / amigamamagazinepolishissue1998.iso / varia / pgp / pgp_docs / doc / pgpdoc2.de < prev    next >
Text File  |  1994-12-10  |  126KB  |  2,857 lines
  1.                   Phils Pretty Good Software
  2.                          präsentiert:
  3.                                
  4.                              =====
  5.                               PGP
  6.                              =====
  7.                                
  8.                                
  9.                       Pretty Good Privacy
  10.                  Prima Geschützte Privatsphäre
  11. Chiffrierung mit öffentlichen Schlüsseln für die Allgemeinheit
  12.                                
  13.                                
  14.                                
  15.                   --------------------------
  16.                          PGP Handbuch
  17.                    Teil II: Spezielle Themen
  18.                   --------------------------
  19.                      von Philip Zimmermann
  20.                  Überarbeitet am 14. Juni 1993
  21.                                
  22.                          Übersetzt von
  23.              Christopher Creutzig und Abel Deuring
  24.                                
  25.                                
  26.                        PGP Version 2.3a
  27.                          1. Juli 1993
  28.                          Software von
  29.                        Philip Zimmermann
  30.                              sowie
  31.         Branko Lancester, Hal Finney und Peter Gutmann
  32.                                
  33.  
  34.  
  35. Zusammenfassung: PGP verwendet eine System mit öffentlichen
  36. Schlüsseln für die Verschlüsselung von E-Mail und von Dateien.
  37. Es ermöglicht eine sichere Kommunikation zwischen Personen, die
  38. nie direkt getroffen haben müssen. Ein abhörsicherer Kanal für
  39. den Austausch eines Schlüssels ist nicht erforderlich. PGP
  40. bietet viele Möglichkeiten und ist schnell. Es hat eine
  41. ausgefeilte Schlüsselverwaltung, bietet digitale
  42. Unterschriften, komprimiert die unverschlüsselten Daten, und
  43. hat eine ergonomische Oberfläche.
  44.  
  45.  
  46. Copyright (c) für Programm und Dokumentation: Philip Zimmermann.
  47. Informationen zur Lizensierung von PGP, Distribution,
  48. Copyrights, Warenzeichen, Gewährleistungen,
  49. Exportbeschränkungen enthält der Abschnitt "Rechtsfragen"
  50. Inhalt
  51. ======
  52.  
  53. Kurzbeschreibung
  54. Spezielle Themen
  55.  Auswahl eines Schlüssels über seine Schlüssel-ID
  56.  Trennung der Unterschrift von der Nachricht
  57.  Entschlüsselung einer Nachricht und Speicherung zusammen mit
  58.    einer Unterschrift
  59.  Der Austausch von ASCII-Text zwischen unterschiedlichen
  60.    Computern
  61.  Vermeidung von "Spuren des Klartextes" auf des Festplatte
  62.  Anzeige des entschlüsselten Klartextes am Bildschirm
  63.  Verschlüsseln einer Nachricht "nur für Augen der EmpfängerIn"
  64.  Beibehaltung des originalen Dateinamens des Klartextes
  65.  Ändern der BenutzerIn-ID und des Mantra
  66.  Ändern der Vertrauensparameter für einen öffentlichen
  67.    Schlüssel
  68.  Prüfen, ob eine Datei mit öffentlichen Schlüsseln intakt ist
  69.  telefonische Kontrolle eines öffentlichen Schlüssel
  70.  PGP als Filterprogramm im Unix-Stil
  71.  Unterdrückung nicht unbedingt notwendiger Fragen: BATCHMODE
  72.  "Ja" als Standardantwort bei Bestätigungsabfragen: FORCE
  73.  Der Beendigungscode (exit code) von PGP
  74.  Umgebungsvariable (environment variable) für das Mantra
  75. Einstellen der Konfigurationsparameter: CONFIG.TXT
  76.  TMP - Name des Verzeichnis für temporäre Dateien
  77.  LANGUAGE - Auswahl der Sprache für Textmeldungen von PGP
  78.  MYNAME - Standard-BenutzerIn-ID für Unterschriften
  79.  TEXTMODE - standardmäßig ASCII-Text verschlüsseln
  80.  CHARSET - Der Zeichensatz Ihres Computers
  81.  ARMOR - ASCII Darstellung einer verschlüsselten Datei
  82.  ARMORLINES - maximale Größe von ASCII-dargestellten Dateien
  83.  KEEPBINARY - verschlüsselte Binärdatei nach Entschlüsselung
  84.    nicht löschen
  85.  COMPRESS - Datenkompression ein- oder ausschalten
  86.  COMPLETES_NEEDED - Anzahl der erforderlichen voll
  87.    vertrauenswürdigen Unterschriften
  88.  MARGINALS_NEEDED - Anzahl der erforderlichen teilweise
  89.    vertrauenswürdigen Unterschriften
  90.  CERT_DEPTH - Schachtelungstiefe von Unterschriften
  91.  BAKRING - Dateiname der Sicherheitskopie der Datei mit
  92.    geheimen Schlüsseln
  93.  PAGER - Auswahl der Programms für die Textanzeige am
  94.    Bildschirm
  95.  SHOWPASS - Anzeige des Mantra während der Eingabe
  96.  TZFIX - Zeitzonenkorrektur
  97.  CLEARSIG - Nachrichten im Klartext mit ASCII-Unterschrift
  98.  VERBOSE - keine, normale oder ausführliche Meldungen
  99.  INTERACTIVE - Bestätigungsabfrage beim Hinzufügen von
  100.    öffentlichen Schlüsseln
  101. Schutz gegen gefälschte Zeitangaben
  102. Ein Blick aufs Detail
  103.  Zufallszahlen
  104.  Der konventionelle Verschlüsselungsalgorithmus bei PGP
  105.  Datenkomprimierung
  106.  Textprüfsummen (message digests) und digitale Unterschriften
  107.  Kompatibilität mit alten Versionen von PGP
  108. Angriffsmöglichkeiten
  109.  Bekannt gewordenes Mantra und bekannt gewordener geheimer
  110.    Schlüssel
  111.  Fälschung des öffentlichen Schlüssels
  112.  Nicht richtig gelöschte Dateien
  113.  Viren und Trojanische Pferde
  114.  Lücken in der physischen Sicherheit
  115.  "Sturmangriffe" (tempest attacks)
  116.  Probleme bei Mehrplatz-Computern
  117.  Statistik von Nachrichtenverbindungen
  118.  Kryptanalyse
  119. Rechtsfragen
  120.  Warenzeichen, Copyright, Garantie
  121.  Patentrechte auf die Algorithmen
  122.  Lizensierung und Vertrieb
  123.  Exportkontrolle [auf die USA bezogen d.Ü.]
  124. Computer-orientierte politische Vereinigungen [in den USA]
  125. Literatur
  126. Die Adresse des Autors
  127. Anhang: Bezugsquellen für PGP
  128.  
  129. Kurzbeschreibung
  130. ================
  131.  
  132. Pretty Good(tm) Privacy (PGP), von Phil's Pretty Good Software,
  133. ist ein sehr sicheres kryptographisches Programm für MSDOS,
  134. Unix, VAX/VMS, Commodore Amiga, Apple Macintosh und andere
  135. Computer. PGP kombiniert die Vorteile des
  136. Verschlüsselungsalgorithmus von Rivest, Shamir und Adleman
  137. (RSA), der mit öffentlichen Schlüsseln arbeitet, mit der
  138. Geschwindigkeit konventioneller Verschlüsselung, mit
  139. Textprüfsummen für digitale Unterschriften, mit guter Ergonomie
  140. und einem ausgefeilten System zur Schlüsselverwaltung.
  141.  
  142. Dieser zweite Teil des Handbuchs beinhaltet spezielle Themen,
  143. die nicht im ersten Teil "Grundlagen" enthalten sind. Das Lesen
  144. dieses Teils ohne Kenntnis des ersten ist nicht sehr sinnvoll.
  145. Andererseits ist die Kenntnis dieses zweiten Teils für die
  146. Benutzung von PGP nicht unbedingt erforderlich.
  147.  
  148.  
  149.  
  150. Spezielle Themen
  151. ================
  152.  
  153.  
  154. Auswahl eines Schlüssels über seine Schlüssel-ID
  155. ------------------------------------------------
  156.  
  157. Bei allen Kommandos, die die Angabe einer BenutzerInnen-ID oder
  158. eines Teils der BenutzerInnen-ID erfordern, kann statt dessen
  159. auch die hexadezimale Schlüssel-ID benutzt werden. In diesem
  160. Fall muß vor der Schlüssel-ID ein "0x" geschrieben werden.
  161. Beispiel:
  162.  
  163.     pgp -kv 0x67F7
  164.  
  165. listet alle Schlüssel, in denen 67F7 ein Teil der Schlüssel-ID
  166. ist.
  167.  
  168. Diese Option ist insbesondere dann praktisch, wenn es von einer
  169. Person zwei verschiedene Schlüssel mit ein und derselben
  170. BenutzerIn-ID gibt. In diesem Fall läßt sich mit Hilfe der
  171. Schlüssel-ID einer der beiden Schlüssel eindeutig auswählen.
  172.  
  173.  
  174.  
  175. Trennung der Unterschrift von der Nachricht
  176. -------------------------------------------
  177.  
  178. Normalerweise wird eine Unterschrift in der selben Datei
  179. gespeichert wie der Text, der unterschrieben wird. Dadurch ist
  180. die Prüfung einer Unterschrift in den meistens Fällen einfach
  181. und bequem möglich. Unter bestimmten Umständen ist es aber
  182. sinnvoll, die Unterschrift in einer eigenen Datei, unabhängig
  183. von der Textdatei, zu speichern. Hierfür dient die Option "b"
  184. (für "break") zusammen mit der Option "s" (für "sign").
  185. Beispiel:
  186.  
  187.     pgp -sb letter.txt
  188.  
  189. Hier wird eine Datei "letter.sig" erzeugt, die nur die
  190. Unterschrift enthält. Der Inhalt der Datei "letter.txt" wird
  191. nicht in "letter.sig" gespeichert.
  192.  
  193. Wenn die Unterschrift in einer eigenen Datei ("letter.sig" in
  194. obigem Beispiel) erzeugt wurde, werden beide Dateien (im
  195. Beispiel "letter.sig" und "letter.txt") an die EmpfängerIn
  196. geschickt. Sie benötigt beide Dateien, um die Echtheit
  197. Unterschrift zu prüfen. Wenn sie die Datei mit der Unterschrift
  198. durch PGP bearbeiten läßt, stellt das Programm fest, daß diese
  199. Datei keinen Text enthält, und fragt die BenutzerIn nach dem
  200. Namen der Textdatei. Erst danach kann PGP die Unterschrift
  201. prüfen. Wenn die EmpfängerIn bereits weiß, daß Text und
  202. Unterschrift in getrennten Dateien gespeichert sind, kann sie
  203. auch beide Dateinamen in der Kommandozeile angeben:
  204.  
  205.     pgp letter.sig letter.txt
  206. oder:
  207.     pgp letter letter.txt
  208.  
  209. In diesem Fall fragt PGP nicht nach dem Namen der Textdatei.
  210.  
  211. Die Unterschrift in einer eigenen Datei zu speichern, ist dann
  212. sinnvoll, wenn die Unterschriften unabhängig vom Text
  213. protokolliert werden sollen. Die abgetrennte Unterschrift ist
  214. auch für die Dateien mit ausführbaren Programmen (bei MSDOS:
  215. *.EXE und *.COM) sinnvoll, um eine Virusprüfung durchzuführen.
  216. Sie ist auch dann sinnvoll, wenn mehrere Personen ein Dokument
  217. (beispielsweise einen Vertrag) unterschreiben sollen, ohne daß
  218. die Unterschriften "verschachtelt" werden. Die Unterschrift
  219. jeder einzelnen Person wird unabhängig von den anderen
  220. gespeichert.
  221.  
  222. Wenn man eine verschlüsselte Nachricht erhält, bei der
  223. Unterschrift und Text in einer Datei stehen, kann die
  224. Unterschrift auch nachträglich vom Text getrennt werden. Dies
  225. geschieht mit der "-b" Option bei der Entschlüsselung:
  226.  
  227.     pgp -b letter
  228.  
  229. Hier wird "letter.pgp" entschlüsselt. Falls eine Unterschrift
  230. vorhanden ist, wird sie geprüft und in einer eigenen Datei
  231. "letter.sig" gespeichert.
  232.  
  233.  
  234. Entschlüsselung einer Nachricht und Speicherung zusammen mit
  235. -------------------------------------------------------------
  236. einer Unterschrift
  237. ------------------
  238.  
  239. Normalerweise will man eine verschlüsselte Nachricht
  240. vollständig entschlüsseln, die Unterschrift (oder mehrere
  241. verschachtelte Unterschriften) prüfen, und hierbei eine
  242. "Schicht" nach der anderen abtrennen, bis der originale
  243. Klartext übrig bleibt.
  244.  
  245. Manchmal will man aber die Nachricht nur entschlüsseln, und die
  246. Unterschriften bei der Nachricht belassen. Dies ist
  247. beispielsweise dann sinnvoll, wenn man die Kopie einer
  248. unterschriebenen Nachricht an eine dritte Person weiterleiten
  249. möchte, gegebenenfalls erneut verschlüsselt. Angenommen, es
  250. kommt eine Nachricht, die Charlie unterschrieben hat,
  251. verschlüsselt mit dem öffentlichen Schüssel der EmpfängerIn.
  252. Die Nachricht soll entschlüsselt, und zusammen mit Charlie's
  253. Unterschrift an Alice weitergeleitet werden, gegebenenfalls mit
  254. ihrem öffentlichen Schlüssel verschlüsselt. Mit PGP kein
  255. Problem.
  256.  
  257. Mit folgendem Kommando wird eine Nachricht entschlüsselt, ohne
  258. daß die Unterschriften abgetrennt werden:
  259.  
  260.     pgp -d letter
  261.  
  262. Hier wird die Datei "letter.pgp" entschlüsselt, und
  263. Unterschriften werden, falls vorhanden, zusammen mit dem
  264. entschlüsselten Klartext in der Ausgabedatei gespeichert.
  265.  
  266. Die Ausgabedatei kann archiviert werden, oder, gegebenenfalls
  267. wieder verschlüsselt, an eine andere Person weitergeleitet
  268. werden.
  269.  
  270.  
  271.  
  272. Der Austausch von ASCII-Text zwischen unterschiedlichen
  273. --------------------------------------------------------
  274. Computern.
  275. ----------
  276.  
  277. Mit PGP kann jede Art von "Klartext" verschlüsselt werden,
  278. irgendwelche Binärdaten ebenso wie ASCII-Text. Wahrscheinlich
  279. wird PGP am häufigsten für die Verschlüsselung von E-Mail
  280. benutzt, so daß der "Klartext" aus ASCII-Daten besteht.
  281.  
  282. ASCII-Text wird aus verschiedenen Computern leicht
  283. unterschiedlich dargestellt. Beispielsweise endet eine Zeile
  284. bei MSDOS mit den beiden Zeichen für "Wagenrücklauf" und
  285. "Zeilenvorschub" (carriage return / line feed). Bei Unix endet
  286. eine Zeile nur mit dem Zeichen für "Zeilenvorschub". Beim
  287. Macintosh endet eine Zeile mit dem Zeichen für "Wagenrücklauf",
  288. ohne "Zeilenvorschub". Traurig, aber wahr.
  289.  
  290. Nicht verschlüsselte ASCII-Daten werden bei E-mail-Systemen
  291. normalerweise in eine "kanonische", maschinenunabhängige Form
  292. gebracht, wenn sie zwischen zwei Computern ausgetauscht werden.
  293. Bei kanonischer Textdarstellung besteht ein Zeilenende aus den
  294. Zeichen "Wagenrücklauf" und "Zeilenvorschub". Beispielsweise
  295. konvertiert das weit verbreiteten KERMIT den ASCII-Text in
  296. diese kanonische Form, bevor der Text an einen anderen Computer
  297. gesendet wird, und das KERMIT auf dem Computer, der den Text
  298. empfängt, konvertiert ihn wieder in diejenige Form, die sein
  299. Betriebssystem braucht. Dadurch ist es einfach, Texte zwischen
  300. verschiedenen Computern auszutauschen.
  301.  
  302. Diese automatische Anpassung der Textdarstellung an das
  303. jeweilige Betriebssystem ist bei verschlüsselten Nachrichten
  304. nicht möglich, weil der Klartext durch die Verschlüsselung dem
  305. Übertragungsprogramm verborgen bleibt. Diese Aufgabe muß das
  306. Verschlüsselungsprogramm übernehmen. Deshalb kann man bei PGP
  307. angeben, ob der "Klartext" als Binärdaten oder als ASCII-Text
  308. angesehen werden soll. In letzterem Fall wird der Klartext vor
  309. der Verschlüsselung in kanonische Form gebracht. Bei der
  310. Entschlüsselung wird er dann in die Form gebracht, die für das
  311. Betriebssystem des Computers, auf dem entschlüsselt wird,
  312. geeignet ist.
  313.  
  314. Wenn die Option "t" beim Verschlüsseln und / oder
  315. Unterschreiben einer Nachricht mit angegeben wird, konvertiert
  316. PGP den Text vor der Verschlüsselung bzw. dem Unterschreiben in
  317. die kanonische Form:
  318.  
  319.     pgp -et message.txt EmpfängerIn_ID
  320.  
  321. Diese Option schaltet PGP automatisch ab, sobald es in der zu
  322. verschlüsselnden Datei Daten findet, die es nicht als Text
  323. betrachtet.
  324.  
  325. Falls der Klartext aus einem 8 Bit Zeichensatz besteht, falls
  326. er also mehr Zeichen enthält als der ASCII-Standard für den
  327. englischen Zeichensatz, verwendet PGP gegebenenfalls bei der
  328. Konvertierung in die kanonische Form den Zeichensatz LATIN1
  329. (ISO 8859-1 Latin Alphabet 1). Dies hängt davon ab, was als
  330. Parameter "CHARSET" in der PGP-Konfigurationsdatei eingetragen
  331. ist. LATIN1 ist eine Obermenge von ASCII, mit diakritischen
  332. Zeichen für viele europäische Sprachen.
  333.  
  334.  
  335.  
  336. Vermeidung von "Spuren des Klartextes" auf des Festplatte
  337. ---------------------------------------------------------
  338.  
  339. Nachdem PGP eine Datei verschlüsselt hat, kann es bei Bedarf
  340. die Klartext-Datei überschreiben und danach löschen, so daß
  341. keine "Spuren" des Klartextes auf der Festplatte verbleiben.
  342. Dies verhindert, daß der Klartext mit einem Sektor-Editor oder
  343. einem ähnlichen Programm noch gelesen werden kann. Diese Option
  344. ist sinnvoll, um zu vermeiden, daß vertrauliche Informationen
  345. unkontrolliert auf der Festplatte verbleiben.
  346.  
  347. Um den Klartext nach der Verschlüsselung und/oder dem
  348. Unterschreiben von der Festplatte zu löschen, wird die Option
  349. "w" (wipe = wischen) verwendet:
  350.  
  351.     pgp -esw message.txt EmpfängerIn_ID
  352.  
  353. Hier wird eine verschlüsselte, unterschriebene Datei
  354. "message.pgp" erzeugt, und die Klartext-Datei wird danach
  355. überschrieben und gelöscht.
  356.  
  357. Diese Option sollte mit Vorsicht benutzt werden. Zudem muß
  358. betont werden, daß hierdurch keinerlei Fragmente der Klartextes
  359. gelöscht werden, die ein Textverarbeitungsprogramm häufig auf
  360. der Festplatte ablegt, wenn man einen Text eintippt und
  361. bearbeitet. Die meisten Textverarbeitungsprogramm erzeugen
  362. Backup-Dateien und benutzen temporäre Dateien. Außerdem wird
  363. die Klartext-Datei nur einmal überschrieben. Das ist zwar
  364. ausreichend, um ein Lesen des Klartextes mit den üblichen
  365. Werkzeugen der Datenwiederherstellung zu verhindern, reicht
  366. aber nicht aus, um einen gezielten und ausgefeilten Leseversuch
  367. zu abzuwehren, bei dem eine schwache Restmagnetisierung der
  368. überschriebenen Daten mittels spezieller Hardware ausgewertet
  369. wird. [Weiteres hierzu steht weiter unten im Abschnitt "Nicht
  370. richtig gelöschte Dateien" d.Ü.]
  371.  
  372.  
  373.  
  374. Anzeige des entschlüsselten Klartextes am Bildschirm
  375. ----------------------------------------------------
  376.  
  377. Um den entschlüsselten Klartext nur am Bildschirm zu lesen
  378. (ähnlich dem Unix-Kommando "more"), ohne daß er in eine Datei
  379. geschrieben wird, kann die Option "-m" ("more") verwendet
  380. werden:
  381.  
  382.     pgp -m letter.pgp
  383.  
  384. Dieser Befehl zeigt den entschlüsselten Klartext am Bildschirm
  385. an. [Mit den Tasten "Leertaste", "Return", "b" kann im Text
  386. "geblättert" werden. Mit "q" wird das Lesen beendet. Diese
  387. Befehle gelten für die PGP-interne Textanzeigefunktion. Durch
  388. einen entsprechenden Eintrag in der Datei "config.txt" kann
  389. auch ein anderes Programm für die Textanzeige am Bildschirm
  390. gewählt werden. d.Ü.]
  391.  
  392.  
  393.  
  394. Verschlüsseln einer Nachricht "nur für Augen der EmpfängerIn"
  395. -------------------------------------------------------------
  396.  
  397. Um festzulegen, daß die EmpfängerIn den entschlüsselten
  398. Klartext NUR am Bildschirm lesen, ihn aber nicht in eine Datei
  399. schreiben kann, kann die Option "-m" bei Verschlüsseln
  400. verwendet werden:
  401.  
  402.     pgp -sem message.txt EmpfängerIn_ID
  403.  
  404. Wenn die EmpfängerIn eine so verschlüsselte Nachricht mit ihrem
  405. privaten Schlüssel und ihrem Mantra entschlüsselt, wird der
  406. Klartext nur auf ihrem Bildschirm angezeigt, aber nicht auf der
  407. Festplatte gespeichert. Die Textanzeige erfolgt auf dem
  408. Bildschirm so, wie zuvor unter "Anzeige des entschlüsselten
  409. Klartextes am Bildschirm" beschrieben. Wenn die EmpfängerIn die
  410. Nachricht ein zweites Mal lesen will, muß sie die Nachricht
  411. erneut entschlüsseln.
  412.  
  413. Diese Option ist der sicherste Weg, um zu verhindern, daß
  414. vertrauliche Nachrichten versehentlich als Klartext auf der
  415. Festplatte der EmpfängerIn "liegen bleiben". Diese Option wurde
  416. in PGP auf Anfrage eines Benutzers eingebaut, der seiner
  417. Liebsten intime Nachrichten schicken wollte, aber befürchtete,
  418. daß sie unabsichtlich eine entschlüsselte Nachricht auf dem
  419. Computer ihres Ehemanns "liegen lassen" könnte.
  420.  
  421.  
  422.  
  423. Beibehaltung des originalen Dateinamens des Klartextes
  424. -----------------------------------------------------
  425.  
  426. Normalerweise gibt PGP der Datei mit dem entschlüsselten
  427. Klartext den gleichen Namen wie der Datei mit dem
  428. verschlüsselten Text, aber ohne Suffix. Ein anderer Name für
  429. die Klartext-Datei kann mit der Option "-o" festgelegt werden.
  430. Bei den meisten E-Mail-Nachrichten ist dies sinnvoll, weil man
  431. so den Dateinamen bei der Entschlüsselung festlegen kann, und
  432. typische E-Mail-Nachrichten häufig unbrauchbare originale
  433. Dateinamen wie "to_phil.txt" oder "crypted.msg" haben.
  434.  
  435. Wenn PGP eine Klartext-Datei verschlüsselt, fügt es den
  436. originalen Dateinamen dem Klartext vor der Komprimierung bei.
  437. Normalerweise verwendet PGP diesen originalen Dateinamen bei
  438. der Entschlüsselung nicht, aber bei Bedarf kann PGP angewiesen
  439. werden, der entschlüsselte Klartext-Datei diesen Namen zu
  440. geben. Das ist sinnvoll, wenn PGP dazu benutzt wird, Dateien zu
  441. ver- und entschlüsseln, deren Name von Bedeutung ist. [Bei der
  442. Amiga-Version von PGP ist letzteres die Standard-Einstellung.
  443. d.Ü.]
  444.  
  445. Um den originalen Namen der Klartext-Datei bei der
  446. Entschlüsselung zu erhalten, kann die Option "-p" (preserve)
  447. verwendet werden:
  448.  
  449.     pgp -p verschlüsselte_datei
  450.  
  451. Ich benutze diese Option normalerweise nicht, weil andernfalls
  452. ungefähr die Hälfte der an mich gerichteten E-Mail-Nachrichten
  453. den gleichen Dateinamen wie "to_phil.txt" oder "prz.txt"
  454. hätten.
  455.  
  456.  
  457.  
  458. Ändern der BenutzerIn-ID und des Mantra
  459. ---------------------------------------
  460.  
  461. Ab und zu kann es erforderlich sein, das Mantra zu ändern,
  462. beispielsweise dann, wenn jemand beim Eintippen des Mantra
  463. zugeschaut hat.
  464.  
  465. Oder die BenutzerIn-ID muß geändert werden, wegen Heirat, oder
  466. wegen einer geänderten E-Mail-Adresse. Oder es soll dem
  467. Schlüssel eine zweite oder dritte BenutzerIn-ID hinzugefügt
  468. werden, um mehrere E-Mail-Adressen oder Berufsbezeichnungen
  469. einzutragen. Mit PGP können  einem Schlüssel mehrere BenutzerIn-
  470. IDs hinzugefügt werden, und jede dieser IDs kann für die
  471. Auswahl des Schlüssel aus der Datei mit den öffentlichen
  472. Schlüsseln (keyring) verwendet werden.
  473.  
  474. Die eigene BenutzerIn-ID und das Mantra kann mit folgendem
  475. Kommando geändert werden:
  476.  
  477.     pgp -ke BenutzerIn-ID [schlüsseldatei]
  478.  
  479. PGP fragt dann nach der neuen BenutzerIn-ID und dem neuen
  480. Mantra.
  481.  
  482. Wenn der optionale Parameter [schlüsseldatei] angegeben wird,
  483. muß es sich um eine Datei mit öffentlichen Schlüsseln sein,
  484. nicht mit geheimen.
  485.  
  486. Der Parameter "BenutzerIn-ID" muß die eigene ID sein. PGP
  487. erkennt dies daran, daß diese ID sowohl in der Datei mit
  488. öffentlichen Schlüsseln als auch in der Datei geheimen
  489. Schlüsseln auftaucht. Beide Dateien werden geändert, auch wenn
  490. ein eine Datei mit öffentlichen Schlüsseln als Parameter
  491. angegeben wurde.
  492.  
  493.  
  494.  
  495. Ändern der Vertrauensparameter für einen öffentlichen Schlüssel
  496. ---------------------------------------------------------------
  497.  
  498. Manchmal muß die Vertrauens-Einstellung für einen öffentlichen
  499. Schlüssel geändert werden. Was diese Vertrauensparameter sind,
  500. steht in Teil 1 des Handbuchs im Abschnitt "Öffentliche
  501. Schlüssel vor Manipulation schützen"
  502.  
  503. Mit folgendem Befehl können die Vertrauensparameter für einen
  504. öffentlichen Schlüssel geändert werden:
  505.  
  506.     pgp -ke BenutzerIn-ID [schlüsseldatei]
  507.  
  508. Wenn der optionale Parameter [schlüsseldatei] angegeben wird,
  509. muß es eine Datei mit öffentlichen Schlüsseln sein, keine Datei
  510. mit geheimen Schlüsseln.
  511.  
  512.  
  513.  
  514. Prüfen, ob eine Datei mit öffentlichen Schlüsseln intakt ist
  515. ------------------------------------------------------------
  516.  
  517. Normalerweise prüft PGP automatisch jeden Schlüssel und jede
  518. Unterschrift, die einer Datei mit öffentlichen Schlüssel
  519. hinzugefügt werden, und paßt automatisch die
  520. Vertrauenseinstellungen und Gültigkeitswert an. Theoretisch
  521. paßt es die Gültigkeitswerte für alle betroffenen Schlüssel an,
  522. wenn ein Schlüssel der Datei mit öffentlichen Schlüsseln
  523. hinzugefügt oder aus der Datei gelöscht wird. Manchmal möchte
  524. man aber auch dann eine umfassende Analyse haben, wenn keine
  525. Änderungen an der Datei erforderlich sind: Prüfen der
  526. Bestätigung(en) der einzelnen Schlüssel, Prüfen der
  527. Vertrauensparameter, Neuberechnung der Gültigkeitswerte, und
  528. Vergleich des eigenen, absolut vertrauenswürdigen Schlüssels
  529. mit der Sicherheitskopie auf einer schreibgeschützten Diskette.
  530. Es ist sinnvoll, diese Integritätsprüfung in regelmäßigen
  531. Abständen durchzuführen, um sicherzustellen, daß die Datei mit
  532. öffentlichen Schlüsseln wirklich intakt ist. Mit der Option
  533. "-kc" ("key ring check") führt PGP eine vollständige Analyse
  534. der Datei mit öffentlichen Schlüsseln aus:
  535.  
  536.     pgp -kc
  537.  
  538. Mit folgendem Befehl prüft PGP die Unterschriften für einen
  539. bestimmten öffentlichen Schlüssel:
  540.  
  541.     pgp -kc BenutzerIn_ID [schlüsseldatei]
  542.  
  543. Weitere Informationen darüber, wie der eigene Schlüssel mit
  544. einer Sicherheitskopie verglichen wird, stehen bei der
  545. Beschreibung des Parameters BAKRING im Abschnitt über die
  546. Konfigurationsdatei in diesem Handbuch.
  547.  
  548.  
  549.  
  550. telefonische Kontrolle eines öffentlichen Schlüssel
  551. ---------------------------------------------------
  552.  
  553. Es kann vorkommen, daß man einen öffentlichen Schlüssel
  554. bekommt, der nicht von einer anderen Person bestätigt ist, der
  555. man vertraut. Dann stellt sich die Frage, wie sich die Echtheit
  556. dieses Schlüssels feststellen läßt. Der beste Weg hierfür ist
  557. die Kontrolle des Schlüssels über einen anderen Kanal als den,
  558. über den der Schlüssel geschickt wurde. Wenn man die Person
  559. kennt, der der öffentliche Schlüssel gehört, und wenn man auch
  560. ihre Stimme am Telefon erkennt, besteht eine einfache und
  561. bequeme Lösung des Problems darin, sie anzurufen, und den
  562. Schlüssel im Gespräch zu kontrollieren. Hierzu braucht man sich
  563. nicht mühsam den ganzen - ASCII-dargestellten - Schlüssel
  564. vorzulesen. Es reicht, den verhältnismäßig kurzen "fingerprint"
  565. des Schlüssels zu vergleichen. Den "fingerprint" eines
  566. Schlüssel gibt PGP mit der Option "-kvc" aus:
  567.  
  568.     pgp -kvc BenutzerIn_ID [schlüsseldatei]
  569.  
  570. PGP zeigt die BenutzerIn_ID zusammen mit dem 16 Byte langen
  571. "fingerprint" an. Wenn beide GesprächspartnerInnen diesen PGP-
  572. Befehl ausführen, können sie den Schlüssel anhand des
  573. "fingerprint" kontrollieren.
  574.  
  575. Wenn die Echtheit sowohl des eigenen öffentlichen Schlüssel als
  576. auch des öffentlichen Schlüssels der GesprächspartnerIn
  577. überprüft ist, kann die Echtheit der Schlüssel wechselseitig
  578. durch eine Unterschrift bestätigt werden. Dies ist ein sicherer
  579. und komfortabler Weg, um mit dem Aufbau eines Netzes
  580. vertrauenswürdiger Schlüssel innerhalb eines Kreises von
  581. FreundInnen zu beginnen.
  582.  
  583.  
  584. PGP als Filterprogramm im Unix-Stil
  585. -----------------------------------
  586.  
  587. Unix-Fans sind es gewöhnt, "pipes" zu verwenden, um Daten
  588. zwischen zwei Programm auszutauschen. Der Output eines
  589. Programms kann mittels einer "pipe" als Input in ein zweites
  590. Programm gelenkt werden. Damit dies funktioniert, müssen die
  591. Programme ihre Daten aus "standard input" lesen und nach
  592. "standard output" schreiben. PGP kann in dieser Form arbeiten.
  593. Falls Ihnen schleierhaft ist, was obiges zu bedeuten hat,
  594. werden Sie diese Möglichkeit wahrscheinlich auch nicht
  595. brauchen, so daß Sie diesen Abschnitt überlesen können.
  596.  
  597. Wenn die -f Option verwendet wird, arbeitet PGP als Unix-
  598. Filter. Beispiel:
  599.  
  600.     pgp -feast BenutzerIn-ID <inputfile >outputfile
  601.  
  602. Diese Option kann die Verwendung von PGP zusammen mit E-Mail-
  603. Programmen vereinfachen.
  604.  
  605. Wenn man PGP als Unix-Filter verwendet, möglicherweise in einem
  606. Unix-Script oder in einer MSDOS-Batchdatei, kann es sinnvoll
  607. sein, die Umgebungsvariable PGPPASS zu verwenden, damit man das
  608. Mantra nicht erst dann eingeben muß, wenn PGP nach ihm fragt.
  609. PGPPASS ist weiter unten beschrieben.
  610.  
  611.  
  612.  
  613. Unterdrückung nicht unbedingt notwendiger Fragen: BATCHMODE
  614. -----------------------------------------------------------
  615.  
  616. Wird BATCHMODE in der PGP-Befehlszeile eingeschaltet, stellt
  617. PGP während des Programmlaufes keinerlei unnötige Fragen.
  618. Beispiel:
  619.  
  620.     pgp +batchmode verschlüsselte_datei
  621.  
  622. Dies ist sinnvoll, wenn PGP aus Unix Shell-Scripts oder aus
  623. einer MSDOS-Batchdatei aufgerufen wird. Manche PGP-Befehle für
  624. die Schlüsselverwaltung brauchen in jedem Fall Eingaben durch
  625. die BenutzerIn. Sie sollten deshalb in Shell-Scripten vermieden
  626. werden.
  627.  
  628. BATCHMODE kann auch bei der Prüfung der Echtheit einer
  629. Unterschrift verwendet werden. Ist die Unterschrift nicht in
  630. Ordnung, wird als Beendigungscode (exit code) 1 zurückgegeben.
  631. Bei einer intakten Unterschrift gibt PGP den Wert 0 zurück.
  632.  
  633.  
  634.  
  635. "Ja" als Standardantwort bei Bestätigungsabfragen: FORCE
  636. --------------------------------------------------------
  637.  
  638. FORCE veranlaßt PGP, "ja" als Standardantwort anzunehmen, wenn
  639. es danach fragt, ob eine bereits existierende Datei
  640. überschrieben werden soll, oder ob ein öffentlicher Schlüssel
  641. aus der Datei mit öffentlichen Schlüsseln mit "-kr" entfernt
  642. werden soll. Beispiel:
  643.  
  644.                 pgp +force verschlüsselte_datei
  645.  
  646. oder:
  647.  
  648.                 pgp -kr +force smith
  649.  
  650. FORCE kann praktisch sein, wenn PGP aus einer MSDOS-Batchdatei
  651. bzw. einem Unix-Script aufgerufen wird.
  652.  
  653.  
  654.  
  655. Der Beendigungscode (exit code) von PGP
  656. ---------------------------------------
  657.  
  658. Um der Betrieb von PGP aus Unix-Scripten oder MSDOS-
  659. Stapeldateien zu unterstützen, gibt PGP eine Statusmeldung aus
  660. die aufrufende Shell zurück. Ein Beendigungscode von Null
  661. bedeutet, daß kein Fehler auftrat; jeder andere Wert
  662. signalisiert einen Fehler. Jeder Fehler erzeugt einen anderen
  663. Code. [Näheres hierzu bitte den Quelltexten entnehmen :) d.Ü.]
  664.  
  665.  
  666.  
  667. Umgebungsvariable (environment variable) für das Mantra
  668. -------------------------------------------------------
  669.  
  670. Normalerweise fragt PGP das Mantra genau zu dem Zeitpunkt ab,
  671. wenn ein geheimer Schlüssel benötigt wird. Das Mantra kann aber
  672. auch in der Umgebungsvariablen PGPPASS gespeichert werden. Wenn
  673. PGPPASS definiert ist, versucht PGP, ihren Wert als Mantra für
  674. den Zugriff auf einen geheimen Schlüssel zu verwenden. Ist das
  675. in PGPPASS gespeicherte Mantra nicht korrekt, fragt PGP nach
  676. dem richtigen Mantra.
  677.  
  678. Unter MSDOS könnte das Mantra so gesetzt werden:
  679.  
  680.                 SET PGPPASS=Zaphod Beeblebrox wird
  681. Bundespräsident
  682.  
  683. Die Eingabe eines Mantra während des Laufes von PGP ist dann
  684. nicht mehr erforderlich, vorausgesetzt, daß "Zaphod Beeblebrox
  685. wird Bundespräsident" wirklich das richtige Mantra ist.
  686.  
  687. Die Verwendung von PGPPASS ist einerseits gefährlich, macht
  688. aber andererseits die Arbeit mit PGP wesentlich einfacher, wenn
  689. man regelmäßig größere Mengen verschlüsselter Nachrichten
  690. erhält.
  691.  
  692. Die Auswertung einer Umgebungsvariablen (eben PGPPASS) habe ich
  693. auf vielfachen Wunsch hin in PGP aufgenommen. Die Verwendung
  694. von PGPPASS ist aber gefährlich, weil das Mantra dann nicht nur
  695. in Ihrem Gedächtnis, sondern auch irgendwo im Speicher Ihres
  696. Rechner steht. Leichtsinnig wäre es, das Mantra in einer Datei
  697. auf demselben Rechner speichern, auf dem auch Ihre Datei
  698. SECRING.PGP steht. Nicht nur sehr leichtsinnig, sondern einfach
  699. dumm wäre es, das Mantra in einer Batchdatei, am Ende gar
  700. AUTOEXEC.BAT, zu speichern. Jedermann könnte sich in der
  701. Mittagspause an Ihren Rechner setzen, und sowohl Ihr Mantra als
  702. auch die Datei mit Ihren geheimen Schlüssel mitgehen lassen.
  703.  
  704. Die Gefährlichkeit von PGPPASS kann nicht stark genug betont
  705. werden. Bevor Sie sich überlegen, ob Sie PGPPASS trotzdem
  706. verwenden, sollten Sie auf jeden Fall die Abschnitte "Probleme
  707. bei Mehrplatzcomputern" und "Öffentliche Schlüssel vor
  708. Manipulation schützen" im ersten und im zweiten Teil des
  709. Handbuches genau lesen.
  710.  
  711. Falls Sie PGPPASS unbedingt brauchen, ist es am sichersten, das
  712. Kommando zum Setzen von PGPPASS unmittelbar vor der Benutzung
  713. von PGP einzutippen, und unmittelbar nach der Benutzung von PGP
  714. PGPPASS wieder zu löschen, oder den Computer auszuschalten. Sie
  715. sollten PGPPASS auf keinen Fall verwenden, wenn andere Personen
  716. Zugang  zu Ihrem Computer haben. Es könnte jemand vorbeikommen
  717. und Ihr Mantra ganz einfach durch Abfragen der
  718. Umgebungsvariablen herausfinden.
  719.  
  720.  
  721.  
  722. Einstellen der Konfigurationsparameter: CONFIG.TXT
  723. ==================================================
  724.  
  725. PGP kann über einige einstellbare Parameter
  726. anwendungsspezifisch konfiguriert werden. Diese Parameter
  727. stehen in der Textdatei "config.txt". "config.txt" muß in
  728. demjenigen Verzeichnis stehen, das durch die Umgebungsvariable
  729. PGPPATH angegeben wird. Durch die Einstellungen in "config.txt"
  730. kann PGP bequem auf die individuellen Bedürfnisse angepaßt
  731. werden, so daß es nicht erforderlich ist, bei jedem Aufruf von
  732. PGP mühsam eine größere Anzahl von Parametern in die
  733. Kommandozeile einzutippen.
  734.  
  735. Die einzelnen Konfigurationsparameter können je nach Typ als
  736. Wert ganze Zahlen, Zeichenketten (also Text), oder "on/off"
  737. ("ein/aus") haben. Eine Beispielkonfiguration, an der man sich
  738. bei der individuellen Einstellung orientieren kann, ist PGP
  739. beigelegt.
  740.  
  741. Leere Zeilen werden in "config.txt" ignoriert, ebenso alles,
  742. was in einer Zeile rechts von einem '#', der
  743. Kommentarmarkierung, steht. [Beachten Sie, daß in der
  744. Beispielkonfiguration die Zeilen für die Einstellung mancher
  745. Parameter ebenfalls mit einem '#' beginnen. Für die Aktivierung
  746. dieser Parametereinstellung muß das '#' am Zeilenanfang
  747. gelöscht werden. Die Verwendung eines '#' ist auch sinnvoll, um
  748. mehrere Parametereinstellungen auszuprobieren, ohne die Texte
  749. der einzelnen Einstellungen zu löschen. Beispiel:
  750.  
  751.                 # Die folgende Einstellung ist besser, wenn
  752. Texte zu
  753.                 # ver- oder entschlüsseln sind, die unter
  754. Windows
  755.                 # bearbeitet wurden:
  756.                 # charset = latin1
  757.                 # Für MSDOS ist das folgende besser:
  758.                 charset = cp850
  759.  
  760. Hier wertet PGP nur die Zeile "charset = cp850" aus; die Zeile
  761. "charset = latin1" wird ignoriert. Durch einfaches "Umstellen"
  762. des '#' kann die obere Einstellung aktiviert werden. d.Ü.]
  763. Bei den Parameternamen wird nicht zwischen Groß- und
  764. Kleinschreibung unterschieden.
  765.  
  766. Ein Ausschnitt aus einer typischen Konfigurationsdatei:
  767.  
  768.    # TMP is the directory for PGP scratch files, such as a RAM disk.
  769.    TMP = "e:\"    # Can be overridden by environment variable TMP.
  770.    Armor = on     # Use -a flag for ASCII armor whenever applicable.
  771.    # CERT_DEPTH is how deeply introducers may introduce introducers.
  772.    cert_depth = 3
  773.  
  774. Wenn bestimmte Parameter nicht in "config.txt" definiert sind,
  775. oder wenn diese Datei nicht existiert, oder wenn PGP die Datei
  776. nicht findet, setzt es automatisch sinnvolle Standardwerte ein.
  777.  
  778. Die Parameter aus "config.txt" können auch in der Kommandozeile
  779. angegeben werden. Dadurch ist es möglich, im Einzelfall mit
  780. anderen Parametern zu arbeiten, ohne daß "config.txt" extra
  781. hierfür geändert werden muß. Die beiden Kommandos im
  782. nachfolgenden Beispiel haben dasselbe Ergebnis:
  783.  
  784. pgp -e +armor=on brief.txt mueller
  785. pgp -ea brief.txt mueller
  786.  
  787. Zu den einzelnen Parametern in "config.txt":
  788.  
  789.  
  790.  
  791. TMP - Name des Verzeichnis für temporäre Dateien
  792. ------------------------------------------------
  793.  
  794. Standardeinstellung: TMP = ""
  795.  
  796. TMP gibt an, welches Verzeichnis PGP für temporäre Dateien
  797. verwendet. Ein sinnvoller Platz für temporäre Dateien ist -
  798. falls vorhanden - eine RAM-Disk. Bei Verwendung einer RAM-Disk
  799. wird PGP etwas schneller, zudem wird die Sicherheit ein wenig
  800. gesteigert. Wenn TMP nicht definiert ist, werden temporäre
  801. Dateien im aktuellen Verzeichnis gespeichert. Falls eine
  802. Umgebungsvariable TMP definiert ist, verwendet PGP deren Wert
  803. als Namen des Verzeichnisses für temporäre Dateien.
  804.  
  805.  
  806. LANGUAGE - Auswahl der Sprache für Textmeldungen von PGP
  807. --------------------------------------------------------
  808.  
  809. Standardeinstellung: LANGUAGE = en
  810.  
  811. PGP gibt eine Reihe von Anfragen, Warnungen und Erläuterungen
  812. am Bildschirm aus. Normalerweise erscheinen diese Texte auf
  813. englisch. PGP kann so angepaßt werden, daß es diese Meldungen
  814. in anderen Sprachen ausgibt, ohne daß die Datei mit dem
  815. ausführbaren Programm (also z.B. PGP.EXE für MSDOS) geändert
  816. werden muß.
  817.  
  818. Eine Reihe von Menschen aus verschiedenen Ländern haben die
  819. Textmeldungen von PGP in ihre Muttersprache übersetzt. Diese
  820. übersetzten Texte stehen in einer speziellen Datei namens
  821. "language.txt", die im PGP-Programmpaket enthalten ist.
  822. "language.txt" kann die Meldungen in mehreren Sprachen
  823. enthalten. Zur Zeit existieren neben den originalen englischen
  824. Texten Übersetzungen in Spanisch, Holländisch, Deutsch,
  825. Französisch, Italienisch, Russisch, Litauisch und Lettisch.
  826. Andere Sprachen können problemlos ergänzt werden.
  827.  
  828. Mit dem Parameter LANGUAGE wird festgelegt, in welcher Sprache
  829. die Meldungen anzeigt werden sollen. LANGUAGE kann folgende
  830. Werte annehmen:
  831.  
  832. "en" für Englisch      "es" für Spanisch
  833. "de" für Deutsch       "nl" für Holländisch
  834. "fr" für Französisch    "it" für Italienisch
  835. "ru" für Russisch      "lt3" für Litauisch
  836. "lv" für Lettisch      "esp" für Esperanto.
  837.  
  838. Bei der Einstellung:
  839.  
  840.                 LANGUAGE = fr
  841.  
  842. würden beispielsweise die Texte auf Französisch erscheinen -
  843. vorausgesetzt, LANGUAGE.TXT enthält französische Texte.
  844.  
  845. Wenn PGP eine Meldung am Bildschirm anzeigen muß, sucht es in
  846. "language.txt" nach dem Text in der gewählten Sprache. Falls
  847. PGP die Datei nicht findet, oder wenn Texte in der gewählten
  848. Sprache in "language.txt" nicht vorhanden sind, oder wenn eine
  849. einzelne Meldung nicht übersetzt ist, wird der englische Text
  850. ausgegeben.
  851.  
  852. Um Festplatten- und Diskettenplatz zu sparen, sind die meisten
  853. Übersetzungen nicht im Standard-PGP-Paket enthalten. Sie können
  854. aber getrennt erhältlich. [vgl. hierzu "Anhang: Bezugsquellen
  855. für PGP" am Ende dieses Textes. d.Ü.]
  856.  
  857. [Sollen auch die Hilfetexte von PGP (Kommando "pgp -h" in einer
  858. anderen Sprache als englisch ausgegeben werden, muß außerdem
  859. eine Datei namens "???.hlp" existieren, wobei "???" für einen
  860. der oben genannten Werte steht, also z.B. "de.hlp" für Deutsch.
  861. d.Ü.]
  862.  
  863.  
  864.  
  865. MYNAME - Standard-BenutzerIn-ID für Unterschriften
  866. --------------------------------------------------
  867.  
  868. Standardeinstellung: MYNAME = ""
  869.  
  870. Mit MYNAME kann ausgewählt werden, welchen geheimen Schlüssel
  871. PGP automatisch für Unterschriften wählt. Wenn MYNAME nicht
  872. definiert ist, wird der neueste geheime Schlüssel verwendet.
  873. Wenn die Option "-u BenutzerIn_ID" beim Aufruf von PGP
  874. angegeben wird, hat diese Auswahl Vorrang vor der Auswahl durch
  875. MYNAME.
  876.  
  877.  
  878. TEXTMODE - standardmäßig ASCII-Text verschlüsseln
  879. -------------------------------------------------
  880.  
  881. Standardeinstellung: TEXTMODE = off (aus)
  882.  
  883. Der Parameter TEXTMODE ist äquivalent zu der Kommandozeilen-
  884. Option "-t". Wenn "TEXTMODE=on" (ein) gewählt wird, geht PGP
  885. davon aus, daß die zu verschlüsselnden Daten kein Binärdaten,
  886. sondern ASCII-Text sind. Dann werden die Daten vor der
  887. Verschlüsselung in "kanonische Form" konvertiert. Text in
  888. kanonischer Form hat als Zeilentrennung die Zeichen
  889. "Wagenrücklauf" (carriage Return) und "Zeilenvorschub" (line
  890. feed).
  891.  
  892. PGP schaltet die Konvertierung in kanonische Form automatisch
  893. aus, wenn es Daten erkennt, die es für Binärdaten hält.
  894.  
  895. In der gegenwärtigen VAX/VMS-Implementierung ist "TEXTMODE=on"
  896. den Standardeinstellung.
  897.  
  898. Genaueres zu Fragen der Textkonvertierung steht weiter oben in
  899. diesem Handbuch im Abschnitt "Der Austausch von ASCII-Text
  900. zwischen unterschiedlichen Computern."
  901.  
  902.  
  903.  
  904. CHARSET - Der Zeichensatz Ihres Computers
  905. -----------------------------------------
  906.  
  907. Standardeinstellung: CHARSET = NOCONV
  908.  
  909. PGP kann die Sonderzeichen vieler Sprachen für die Zeichensätze
  910. verschiedener Computer konvertieren. Damit dies korrekt
  911. funktioniert, müssen Sie den Parameter CHARSET richtig
  912. einstellen. Diese Konvertierung erfolgt nur bei der
  913. Verschlüsselung von Textdateien. Falls Sie mit PGP
  914. ausschließlich Texte verschlüsseln, die nur Buchstaben des
  915. "normalen Alphabet", also keine Umlaute, Buchstaben mit
  916. Akzenten oder anderen diakritischen Zeichen, enthalten, ist der
  917. Parameter CHARSET für Sie unwichtig.
  918.  
  919. CHARSET teilt PGP mit, welchen Zeichensatz Ihr Computer
  920. verwendet. CHARSET kann folgende Werte annehmen:
  921.  
  922.                 NOCONV    - keine Konvertierung
  923.                 LATIN1    - ISO 8859-1 Lateinisches Alphabet 1
  924.                 KOI8      - verwendet auf vielen russischen
  925. Unix-Anlagen
  926.                 ALT_CODES - verwendet auf russischen MSDOS-
  927. Computern
  928.                 ASCII
  929.                 CP850   - für die meisten westeuropäischen
  930. Sprachen
  931.                  unter MSDOS
  932.  
  933. LATIN1 verwendet PGP für die interne kanonische
  934. Textdarstellung. Wenn also CHARSET = LATIN1 gewählt wird,
  935. findet keine Zeichenkonvertierung statt. Zu beachten ist, daß
  936. PGP auch KOI8 wie LATIN1 behandelt, obwohl KOI8 für einen
  937. völlig anderen Zeichensatz (kyrillisch) steht. Eine
  938. Konvertierung von KOI8 in LATIN1 oder CP850 wäre sinnlos. Die
  939. Einstellungen NOCONV, LATIN1 und KOI8 sind für PGP äquivalent.
  940.  
  941. Wenn Sie mit MSDOS arbeiten und Nachrichten verschicken oder
  942. erhalten, die in einer westeuropäischen Sprache geschrieben
  943. sind, sollten Sie "CHARSET=CP850" einstellen. Wenn Sie eine
  944. Nachricht mit der Option "-t" oder "TEXTMODE=on" verschlüsseln,
  945. konvertiert PGP Ihren CP850-Text vor der Verschlüsselung in den
  946. LATIN1-Zeichensatz. Bei der Entschlüsselung wird LATIN1 in
  947. CP850 umgewandelt.
  948.  
  949. Weiteres hierzu steht weiter oben in diesem Handbuch im
  950. Abschnitt "Der Austausch von ASCII-Text zwischen
  951. unterschiedlichen Computern."
  952.  
  953.  
  954. ARMOR - ASCII Darstellung einer verschlüsselten Datei
  955. -----------------------------------------------------
  956.  
  957. Standardeinstellung: ARMOR = off  (aus)
  958.  
  959. Der Parameter ARMOR ist äquivalent zur Kommandozeilenoption
  960. "-a". Wenn "ARMOR=on" (ein) gewählt wird, stellt PGP die
  961. verschlüsselten Daten im Radix-64-Format dar. Die Format ist
  962. für den Versand über manche E-Mail-Kanäle sinnvoll. Die von PGP
  963. erzeugten Dateien im Radix-64-Format haben das Suffix ".asc".
  964.  
  965. Wenn Sie PGP hauptsächlich für E-Mail einsetzen, kann es
  966. sinnvoll sein, "ARMOR=on" (ein) zu wählen.
  967.  
  968. Weiteres hierzu steht im ersten Teil des Handbuches im
  969. Abschnitt "Versand von Nachrichten im Radix-64 Format".
  970.  
  971.  
  972. ARMORLINES - maximale Größe von ASCII-dargestellten Dateien
  973. -----------------------------------------------------------
  974.  
  975. Standardeinstellung: ARMORLINES = 720
  976.  
  977. Wenn PGP eine sehr große Datei im Radix-64 Format erzeugen
  978. soll, teilt es diese Datei in mehrere Dateien auf, die jeweils
  979. klein genug sind, um im Internet versandt zu werden.
  980. Normalerweise lassen Mailer-Programme für das Internet keine
  981. Nachrichten zu, die mehr als ca. 50000 Byte groß sind. Eine
  982. Datei mit 720 Zeilen im Radix-64 Format liegt weit genug unter
  983. dieser Grenze, um problemlos versandt werden zu können. Die
  984. einzelnen Dateien, die PGP erzeugt, erhalten als Suffix ".as1",
  985. ".as2", ".as3" usw.
  986.  
  987. Der Parameter ARMORLINES gibt an, wieviele Zeilen eine von PGP
  988. erzeugte "*.asc"-Datei maximal enthalten darf. Wird ARMORLINES
  989. auf Null gesetzt, kann eine "*.asc"-Datei beliebig groß werden.
  990.  
  991. Im Fido-Netz dürften Nachrichten in der Regel nicht länger als
  992. 32 kB sein, so daß "ARMORLINES=450" eine sinnvolle Einstellung
  993. für Fido ist.
  994.  
  995. Weiteres hierzu steht im ersten Teil des Handbuches im
  996. Abschnitt "Versand von Nachrichten im Radix-64 Format".
  997.  
  998.  
  999. KEEPBINARY - verschlüsselte Binärdatei nach Entschlüsselung
  1000. -----------------------------------------------------------
  1001. nicht löschen
  1002. -------------
  1003.  
  1004. Standardeinstellung: KEEPBINARY = off  (aus)
  1005.  
  1006. Wenn PGP eine "*.asc"-Datei einliest, erkennt es automatisch,
  1007. daß es eine Datei im Radix-64 Format ist, und konvertiert sie
  1008. zurück in ihre binäre Form (also eine "*.pgp Datei), bevor es
  1009. mit der eigentlichen Entschlüsselung beginnt. Bei der
  1010. Entschlüsselung erzeugt PGP natürlich auch eine Datei mit dem
  1011. Klartext.
  1012.  
  1013. PGP ermöglicht die Auswahl, ob man die "*.pgp"-Datei behalten
  1014. möchte, oder ob sie nach der Entschlüsselung gelöscht werden
  1015. soll. Die "*.asc"-Datei bleibt in jedem Fall erhalten.
  1016.  
  1017. Wenn "KEEPBINARY = on" eingestellt wird, bleibt die "*.pgp"
  1018. Datei erhalten; wird "KEEPBINARY = off" eingestellt, wird die
  1019. "*.pgp" nach der Entschlüsselung gelöscht.
  1020.  
  1021. Weiteres hierzu steht im ersten Teil des Handbuches im
  1022. Abschnitt "Versand von Nachrichten im Radix-64 Format".
  1023.  
  1024.  
  1025. COMPRESS - Datenkompression ein- oder aussschalten
  1026. --------------------------------------------------
  1027.  
  1028. Standardeinstellung: COMPRESS = on
  1029.  
  1030. Mit "COMPRESS = on / off" (ein/aus) kann eingestellt werden, ob
  1031. PGP den Klartext vor der Verschlüsselung komprimiert. Die
  1032. Einstellung "off" ist im wesentlichen für das Debuggen von PGP
  1033. interessant. In der Regel sollte "COMPRESS = on" gewählt
  1034. werden, damit PGP den Klartext vor der Verschlüsselung
  1035. komprimiert. [Das reduziert Versandkosten und -zeit, und
  1036. erschwert in der Regel eine Kryptanalyse. d.Ü.]
  1037.  
  1038.  
  1039. COMPLETES_NEEDED - Anzahl der erforderlichen voll
  1040. -------------------------------------------------
  1041. vertrauenswürdigen Unterschriften
  1042. ---------------------------------
  1043.  
  1044. Standardeinstellung: COMPLETES_NEEDED = 1
  1045.  
  1046.  
  1047. Mit COMPLETES_NEEDED läßt sich einstellen, wieviele voll
  1048. vertrauenswürdige Unterschriften unter einem Schlüssel PGP
  1049. verlangt, um diesen Schlüssel als vollständig bestätigt zu
  1050. betrachten. Mit diesem Parameter hat man also die Möglichkeit,
  1051. PGP mehr oder weniger mißtrauisch einzustellen.
  1052.  
  1053. Genaueres hierüber finden Sie im Abschnitt "Öffentliche
  1054. Schlüssel vor Manipulation schützen" im ersten Teil des
  1055. Handbuches.
  1056.  
  1057.  
  1058. MARGINALS_NEEDED - Anzahl der erforderlichen teilweise
  1059. ------------------------------------------------------
  1060. vertrauenswürdigen Unterschriften
  1061. ---------------------------------
  1062.  
  1063. Standardeinstellung: MARGINALS_NEEDED = 2
  1064.  
  1065. Mit MARGINALS_NEEDED läßt sich einstellen, wieviele teilweise
  1066. vertrauenswürdige Unterschriften unter einem Schlüssel PGP
  1067. verlangt, um diesen Schlüssel als vollständig bestätigt zu
  1068. betrachten. Mit diesem Parameter hat man also die Möglichkeit,
  1069. PGP mehr oder weniger mißtrauisch einzustellen.
  1070.  
  1071. Genaueres hierüber finden Sie im Abschnitt "Öffentliche
  1072. Schlüssel vor Manipulation schützen" im ersten Teil des
  1073. Handbuches.
  1074.  
  1075.  
  1076. CERT_DEPTH - Schachtelungstiefe von Unterschriften
  1077. --------------------------------------------------
  1078.  
  1079. Standardeinstellung: CERT_DEPTH = 4
  1080.  
  1081. CERT_DEPTH gibt an, bis zu welcher Tiefe PGP Unterschriften
  1082. unter öffentliche Schlüssel prüft, d.h., wie "indirekt" die
  1083. Bestätigung der Echtheit eines Schlüssels sein darf. Wenn Sie
  1084. beispielsweise CERT_DEPTH = 1 wählen, erkennt PGP nur solche
  1085. Schlüssel als voll vertrauenswürdig an, die von einer Person
  1086. unterschrieben sind, deren öffentlichen Schlüssel Sie
  1087. persönlich mit Ihrem geheimen Schlüssel unterschrieben haben.
  1088. Setzen Sie CERT_DEPTH = 0, erkennt PGP nur die Schlüssel als
  1089. voll vertrauenswürdig, die Sie selbst unterschrieben haben.
  1090. Wenn Sie CERT_DEPTH = 2 setzen, ist für PGP auch der Schlüssel
  1091. von Carol voll trauenswüdrig, wenn Carols Schlüssel von Bob,
  1092. Bobs Schlüssel von Alice, und Alices Schlüssel von Ihnen selbst
  1093. unterschrieben ist. Der kleinste zulässige Wert für CERT_DEPTH
  1094. ist 0, der größte 8.
  1095.  
  1096. Genaueres hierüber finden Sie im Abschnitt "Öffentliche
  1097. Schlüssel vor Manipulation schützen" im ersten Teil des
  1098. Handbuches.
  1099.  
  1100.  
  1101. BAKRING - Dateiname der Sicherheitskopie der Datei mit geheimen
  1102. ---------------------------------------------------------------
  1103. Schlüsseln
  1104. ----------
  1105.  
  1106. Standardeinstellung: BAKRING = ""
  1107.  
  1108. Die Prüfung der Echtheit eines öffentlichen Schlüssels durch
  1109. Unterschriften basiert letztlich auf die Echtheit Ihres eigenen
  1110. Schlüssels, den PGP als absolut vertrauenswürdig ansieht. (Sie
  1111. können auch mehrere eigene Schlüssel haben, die PGP als voll
  1112. vertrauenswürdig anerkennt.) Um mögliche Fälschungen an Ihrer
  1113. Datei mit öffentlichen Schlüsseln erkennen zu können, muß PGP
  1114. kontrollieren, ob auch Ihr eigener Schlüssel nicht gefälscht
  1115. wurde. Hierfür vergleicht PGP Ihren öffentlichen Schlüssel mit
  1116. einer Sicherheitskopie Ihres geheimen Schlüssels, die auf einem
  1117. fälschungssicherem Medium, z.B. einer schreibgeschützten
  1118. Diskette, steht. Zusammen mit dem geheimen Schlüssel sind alle
  1119. Informationen gespeichert, die Ihr öffentlicher Schlüssel hat.
  1120. Dies bedeutet, daß PGP Ihren öffentlichen Schlüssel mit der
  1121. Sicherheitskopie Ihres geheimen Schlüssels vergleichen kann.
  1122.  
  1123. Mit dem Parameter BAKRING können Sie den Pfadnamen festlegen,
  1124. unter dem PGP die Sicherheitskopie Ihres geheimen Schlüssels
  1125. sucht. Für MSDOS können Sie z.B. "BAKRING = a:\secring.pgp"
  1126. angeben, so daß PGP die Sicherheitskopie auf einer
  1127. schreibgeschützten Diskette sucht. Den Vergleich mit der
  1128. Sicherheitskopie führt PGP nur durch, wenn Sie mit "pgp -kc"
  1129. Ihre gesamte Datei mit öffentlichen Schlüsseln prüfen.
  1130.  
  1131. Wenn BAKRING nicht definiert ist, führt PGP diese Kontrolle
  1132. Ihres eigenen öffentlichen Schlüssel nicht durch.
  1133.  
  1134. Genaueres hierüber finden Sie im Abschnitt "Öffentliche
  1135. Schlüssel vor Manipulation schützen" im ersten Teil des
  1136. Handbuches.
  1137.  
  1138.  
  1139. PAGER - Auswahl der Programms für die Textanzeige am Bildschirm
  1140. ---------------------------------------------------------------
  1141.  
  1142. Standardeinstellung: PAGER = ""
  1143.  
  1144. Wenn Sie beim Entschlüsseln die Option "-m" angeben, können Sie
  1145. den entschlüsselten Text am Bildschirm lesen, ohne daß PGP ihn
  1146. in eine Datei schreibt. Standardmäßig verwendet PGP hierzu
  1147. eigene Routinen, die ähnlich dem "more" Programm bei Unix
  1148. arbeiten.
  1149.  
  1150. Falls Sie ein anderes Programm für Textanzeige am Bildschirm
  1151. bevorzugen, können Sie es unter "PAGER =..." eintragen. Unter
  1152. MSDOS können Sie z.B. das populäre Shareware-Programm
  1153. "list.com" verwenden. In diesem Fall würde der PAGER-Eintrag so
  1154. lauten:
  1155.  
  1156.                 PAGER = list
  1157.  
  1158. Wenn jedoch die AbsenderIn einer Nachricht die Option "-m"
  1159. (Klartext nach Entschlüsseln nicht in eine Datei schreiben)
  1160. angegeben hat, verwendet PGP in jedem Fall seine eigene
  1161. Anzeigefunktion.
  1162.  
  1163. Weiteres hierzu steht im Abschnitt "Anzeige des entschlüsselten
  1164. Klartextes am Bildschirm".
  1165.  
  1166.  
  1167. SHOWPASS - Anzeige des Mantra während der Eingabe
  1168. -------------------------------------------------
  1169.  
  1170. Standardeinstellung: SHOWPASS = off (aus)
  1171.  
  1172. Normalerweise zeigt PGP das Mantra während der Eingabe nicht am
  1173. Bildschirm an. Dadurch wird es für neugierige Augen schwerer,
  1174. das Mantra mitzulesen. Es gibt aber Menschen, die
  1175. Schwierigkeiten haben, ihr Mantra korrekt einzutippen, ohne daß
  1176. sie es am Bildschirm sehen können. So entstand der Wunsch, PGP
  1177. für die Anzeige des Mantra konfigurierbar zu machen. In der
  1178. Abgeschiedenheit einer Wohnung ist es nicht allzu
  1179. problematisch, das Mantra am Bildschirm anzuzeigen.
  1180.  
  1181. Wird "SHOWPASS = on" eingestellt, zeigt PGP das Mantra beim
  1182. Eintippen am Bildschirm an.
  1183.  
  1184.  
  1185. TZFIX - Zeitzonenkorrektur
  1186. --------------------------
  1187.  
  1188. Standardeinstellung: TZFIX = 0
  1189.  
  1190. PGP versieht Schlüssel und Unterschriften mit einer Zeitmarke
  1191. in Greenwich Mean Time (GMT), oder Coordinated Unviersal Time
  1192. (UTC), was für unsere Zwecke dasselbe ist. Wenn PGP das
  1193. Betriebssystem nach Datum und Zeit fragt, nimmt es an, daß die
  1194. Zeit als GMT-Zeit zurückgegeben wird.
  1195.  
  1196. Unter Umständen wird die Zeit aber auf schlecht konfigurierten
  1197. MSDOS-Rechnern als US Pacific Standard Time plus 8 Stunden
  1198. zurückgegeben. Seltsam, nicht wahr? Vielleicht liegt es an
  1199. einer Art US-Westküsten-Chauvinismus, daß MSDOS davon ausgeht,
  1200. die lokale Zeit sei die US Pacific Time, und GMT hierauf
  1201. basierend ausrechnet. Dies wirkt sich nachteilig aus auf das
  1202. Verhalten der MSDOS-internen Funktionen, die PGP verwendet.
  1203. Wenn jedoch die MSDOS Umgebungsvariable TZ für Ihre Zeitzone
  1204. korrekt definiert ist, korrigiert dies auch irrtümliche Annahme
  1205. von MSDOS, die ganze Welt lebe an der Westküste der USA.
  1206.  
  1207. TZFIX gibt die Anzahl der Stunden an, die PGP zur
  1208. "Betriebssystemzeit" addiert, um GMT-Zeitangaben für
  1209. Unterschriften und Schlüssel zu erhalten. Wenn die MSDOS
  1210. Umgebungsvariable TZ korrekt definiert ist, kann TZFIX auf dem
  1211. Standardwert 0 bleiben. Unter Unix ist TZFIX in der Regel auch
  1212. nicht notwendig. TZFIX kann aber für irgendwelche obskuren
  1213. Betriebssysteme sinnvoll sein, die nie etwas von GMT gehört
  1214. haben.
  1215.  
  1216. Für MSDOS Systeme, bei denen TZ nicht definiert ist, sollten
  1217. Sie TZFIX auf 0 setzen in Kalifornien, auf -1 in Colorado, -2
  1218. in Chicago, -3 in New York, -8 in London, -9 in Amsterdam.
  1219. Während der Zeitumstellung im Sommer müssen Sie diese Werte um
  1220. eins verringern. Was für ein Durcheinander.
  1221.  
  1222. Die Definition der MSDOS Umgebungsvariablen TZ in AUTOEXEC.BAT
  1223. ist eine wesentlich sauberere Lösung. In diesem Fall liefert
  1224. MSDOS die korrekt GMT Zeit, und berücksichtigt auch die
  1225. Sommerzeit, abhängig von der von der jeweiligen Zeitzone:
  1226.  
  1227. In Los Angeles:  SET TZ=PST8PDT
  1228. In Denver:       SET TZ=MST7MDT
  1229. In Arizona:      SET TZ=MST7
  1230.    (In Arizona gibt es keine Sommerzeit... Zumindest wird dort
  1231.    die Uhr im Sommer nicht umgestellt,)
  1232. In Chicago:      SET TZ=CST6CDT
  1233. In New York:     SET TZ=EST5EDT
  1234. In London:       SET TZ=GMT0BST
  1235. In Amsterdam:    SET TZ=MET-1DST
  1236. In Moskau:       SET TZ=MSK-3MSD
  1237. In Aukland:      SET TZ=NZT-13
  1238.  
  1239. [Bei der Frage, wer an dem Durcheinander mit den Zeitangaben
  1240. und Zeitzonen schuld ist, bin ich anderer Meinung als Philip
  1241. Zimmermann: Dies kann man ausnahmsweise mal nicht nur Microsoft
  1242. in die Schuhe schieben - MSDOS gehört zu den "obskuren
  1243. Betriebssystemen", die nichts von GMT wissen -, sondern auch
  1244. Borland. Die MSDOS-Version von PGP ist mit Borland C übersetzt
  1245. worden. Die Funktion gmtime(...) der Laufzeitbibliothek gibt
  1246. die Zeit als GMT zurück, und benötigt hierfür eine Angabe, um
  1247. wieviel lokale Zeit und GMT differieren. Diese Angabe bezieht
  1248. gmtime() aus der Umgebungsvariablen TZ. Der oben erwähnte
  1249. "Westküstenchauvinismus" ist also meiner Meinung nach Borland
  1250. anzulasten.
  1251.  
  1252. Die ersten drei Zeichen des Wertes von TZ müssen Buchstaben
  1253. sein, danach muß eine ein- oder zweistellige Zahl, ggf. mit
  1254. einem Minuszeichen davor, stehen. Stehen hinter der Zahl noch
  1255. Buchstaben, wertet gmtime() dies als Signal, daß es eine
  1256. Sommerzeit gibt. Welche Buchstaben vor und ggf. hinter der Zahl
  1257. stehen, wertet gmtime() nicht weiter aus.
  1258.  
  1259. Bei der Sommerzeit-Option ist zu beachten, daß gmtime() als
  1260. Beginn und Ende der Sommerzeit die in den USA zutreffenden Tage
  1261. verwendet, die von den in Europa üblichen etwas abweichen. Wie
  1262. es mit der Sommerzeit in anderen Weltgegenden aussieht, weiß
  1263. ich nicht.
  1264.  
  1265. Falls Ihnen jetzt von dem ganzen Durcheinander um Zeitzonen der
  1266. Kopf raucht: Geben Sie einfach den MSDOS-Befehl
  1267.  
  1268.                 SET TZ=MET-1
  1269.  
  1270. und prüfen Sie, mit dem Befehl
  1271.  
  1272.                 pgp
  1273.  
  1274. die GMT-Zeitangabe, die PGP dann liefert. Falls die GMT-Zeit
  1275. falsch ist, wählen Sie solange einen anderen Wert für TZ, bis
  1276. GMT richtig ist. Es kommen nur 24 Werte infrage...
  1277.  
  1278. Ansonsten der Hinweis: "Zu Risiken und Nebenwirkungen lesen Sie
  1279. das Borland Referenzhandbuch und den run time source code und
  1280. fragen Sie Ihre Borland-Hotline und Ihren Borland-Händler".
  1281. d.Ü.]
  1282.  
  1283.  
  1284. CLEARSIG - Nachrichten im Klartext mit ASCII-Unterschrift
  1285. ---------------------------------------------------------
  1286.  
  1287. Standardwert: CLEARSIG = off (aus)
  1288.  
  1289. Normalerweise liegen mit PGP unterschriebene Nachrichten in
  1290. Binärform vor, auch dann, wenn sie nicht verschlüsselt werden.
  1291. Auch die Unterschrift wird in Binärform an die unterschriebenen
  1292. Daten angehängt. Um eine solche unterschriebene Nachricht über
  1293. einen 7-Bit E-Mail-Kanal zu versenden, kann die ASCII-
  1294. Darstellung im Radix-64-Format verwendet werden. (vgl. den
  1295. ARMOR Parameter) Die Daten bestehen dann zwar aus druckbaren
  1296. ASCII-Zeichen, der originale Text ist aber mit bloßen Auge
  1297. trotzdem nicht mehr zu erkennen, obwohl die Nachricht nicht
  1298. verschlüsselt ist. Die EmpfängerIn einer solchen Nachricht muß
  1299. die "ASCII-Transportverpackung" mit Hilfe von PGP wieder
  1300. "entfernen", bevor sie die Nachricht lesen kann.
  1301.  
  1302. Wenn die originale Nachricht nicht eine Binärdatei, sondern
  1303. ASCII-Text ist, besteht die Möglichkeit, eine Unterschrift so
  1304. an den Text anzufügen, daß er nicht in seiner Darstellung
  1305. geändert wird. In diesem Fall wird nur die Unterschrift im
  1306. Radix-64 Format dargestellt. Der Text bleibt also auch ohne
  1307. Hilfe von PGP für die EmpfängerIn lesbar. Für die Prüfung der
  1308. Unterschrift ist PGP natürlich trotzdem erforderlich.
  1309.  
  1310. Diese Option wird so eingeschaltet: CLEARSIG=on, ARMOR=on,
  1311. (ersatzweise die "-a" Option), TEXTMODE=on (ersatzweise die
  1312. "-t" Option). Beispiel:
  1313.  
  1314. pgp -sta +clearsig=on message.txt
  1315.  
  1316. Eine so unterschriebene Nachricht ähnelt einer "MIC-CLEAR"-
  1317. Nachricht, die mit Privacy Enhanced Mail (PEM) erzeugt wurde.
  1318.  
  1319. Wichtiger Hinweis: Eine solche Nachricht wird als Textnachricht
  1320. versandt, und unterliegt dadurch möglichen Änderungen auf dem
  1321. Versandweg. So können Zeichensatzkonvertierungen vorkommen, es
  1322. können Leerzeichen eingefügt oder gelöscht werden. Wenn dies
  1323. passiert, wird PGP die Nachricht als verändert erkennen, was zu
  1324. einem in diesem Fall unberechtigten Verdacht einer echten,
  1325. inhaltlichen Fälschung führt. Weil auch PEM dies Problem hat,
  1326. schien es sinnvoll, diese Möglichkeit des unterschriebenen
  1327. Klartextes trotz ihr Störanfälligkeit in PGP aufzunehmen.
  1328.  
  1329. Seit PGP Version 2.2 werden Blanks am Ende einer Zeile bei der
  1330. Berechnung einer Unterschrift nicht mehr berücksichtigt, wenn
  1331. CLEARSIG=on gesetzt ist.
  1332.  
  1333.  
  1334. VERBOSE - keine, normale oder ausführliche Meldungen
  1335. ----------------------------------------------------
  1336.  
  1337. Standardeinstellung: VERBOSE = 1
  1338.  
  1339. VERBOSE kann auf 0, 1, oder 2 gesetzt werden, je nachdem, wie
  1340. detaillierte Meldungen man von PGP haben möchte:
  1341.  
  1342. 0 - Meldungen werden nur ausgegeben, wenn es Probleme gibt. Das
  1343. richtige für Unix Fans.
  1344.  
  1345. 1 - Die Standardeinstellung. PGP zeigt in sinnvollem Umfang
  1346. diagnostische Meldungen und Bedienungshinweise
  1347.  
  1348. 2 - ausführliche Meldungen. Diese Option ist hauptsächlich für
  1349. die Fehlersuche gedacht. Normalerweise ist sie nicht sinnvoll.
  1350. Ach so, PGP hat doch keinerlei Probleme, oder?
  1351.  
  1352.  
  1353. INTERACTIVE - Bestätigungsabfrage beim Hinzufügen von
  1354. -----------------------------------------------------
  1355. öffentlichen Schlüsseln
  1356. -----------------------
  1357.  
  1358. Standardeinstellung: INTERACTIVE = off (aus)
  1359.  
  1360. Wenn "INTERACTIVE=on" (ein) gesetzt wird, fragt PGP beim
  1361. Bearbeiten einer Datei, die mehrere öffentliche Schlüssel
  1362. enthält, für jeden Schlüssel einzeln nach, ob er in pubring.pgp
  1363. aufgenommen werden soll.
  1364.  
  1365.  
  1366.  
  1367. Schutz gegen gefälschte Zeitangaben
  1368. ===================================
  1369.  
  1370. Eine nicht ganz leicht verständliche Angreifbarkeit von PGP
  1371. betrifft unehrliche BenutzerInnen, die gefälschte Zeitangaben
  1372. für die Bestätigung ihrer öffentlichen Schlüssel und ihre
  1373. Unterschriften verwenden. LeserInnen, die PGP nur gelegentlich
  1374. benutzen, und mit den Tücken öffentlicher Schlüssel nicht sehr
  1375. vertraut sind, können diesen Abschnitt überspringen.
  1376.  
  1377. Nichts hindert eine unehrliche BenutzerIn daran, die
  1378. Einstellung von Datum und Zeit auf ihrem Computer zu ändern,
  1379. und bei dieser falschen Datumseinstellung ihre
  1380. Schlüsselbestätigungen und Unterschriften zu erzeugen. So kann
  1381. diese unehrliche BenutzerIn es so erscheinen lassen, als habe
  1382. sie eine Unterschrift viel früher oder später geleistet, als es
  1383. tatsächlich der Fall ist, oder als habe sie ihre Paar von
  1384. öffentlichem und geheimem Schlüssel zu einem anderen Zeitpunkt
  1385. generiert. Dies kann von juristischem oder finanziellem Nutzen
  1386. sein. Beispielsweise kann dadurch ein Schlupfloch entstehen, um
  1387. eine Unterschrift nicht anerkennen zu müssen.
  1388.  
  1389. Abhilfe bieten könnte eine allgemein vertrauenswürdige
  1390. Institution oder ein Notar, der/die notariell beglaubigte
  1391. Unterschriften mit einer vertrauenswürdigen Zeitangabe machen
  1392. kann. Dies setzt nicht notwendigerweise eine zentrale
  1393. Institution voraus. Unter Umständen kann jede vertrauenswürdige
  1394. VermittlerIn oder eine unbeteiligte dritte Person diese Aufgabe
  1395. wahrnehmen, ähnlich öffentlich bestellten Notaren. Die
  1396. Bestätigung eines öffentlichen Schlüssels könnte von dem Notar
  1397. unterschrieben werden, und die Zeitmarke bei der Unterschrift
  1398. des Notars könnte juristische Bedeutung erlangen. Der Notar
  1399. könnte über solche Bestätigungen Protokoll führen. Das
  1400. Protokoll wäre öffentlich einsehbar.
  1401.  
  1402. Der Notar könnte auch die Unterschrift anderer durch seine
  1403. eigene Unterschrift bestätigen. Dies könnte als urkundliche,
  1404. beweiskräftige Unterschrift gelten, so, wie es "real
  1405. existierende Notare" mit Unterschriften auf Papierdokumenten
  1406. seit langem machen. Auch in diesem Fall würde der Notar über
  1407. die Unterschriften Protokoll führen, indem er die von dem
  1408. Textdokument abgetrennten Unterschriften archiviert. Die
  1409. Unterschrift des Notars hätte eine vertrauenswürdige
  1410. Zeitangabe, mit größerer Glaubhaftigkeit als die Zeitangabe der
  1411. originalen Unterschrift. Eine Unterschrift würde durch die
  1412. hinzukommende notarielle Unterschrift und das Protokoll des
  1413. Notars "Beweiskraft" erhalten.
  1414.  
  1415. Das Problem notariell beglaubigter Unterschriften und
  1416. glaubwürdiger Zeitmarken bedarf weiterer Diskussion. Eine gute
  1417. Abhandlung hierüber ist der Aufsatz von Denning in IEEE
  1418. Computer 1983 (s. Literaturliste). Die möglichen Verfahren für
  1419. Bestätigung und Beglaubigung müssen noch viel detaillierter
  1420. ausgearbeitet werden. Dies wird sich durch die zunehmende
  1421. Nutzung von PGP ergeben, und dadurch, daß bei anderen
  1422. Programmen, die das Prinzip öffentlicher Schlüssel verwenden,
  1423. andere Bestätigungsverfahren entwickelt werden.
  1424.  
  1425.  
  1426.  
  1427. Ein Blick aufs Detail
  1428. =====================
  1429.  
  1430.  
  1431. Zufallszahlen
  1432. -------------
  1433.  
  1434. PGP verwendet einen kryptographisch zuverlässigen
  1435. Pseudozufallszahlengenerator, um wechselnde Schlüssel für die
  1436. konventionelle Verschlüsselung einzelner Dateien zu erzeugen.
  1437. Die Datei, die den Startwert für den Zufallszahlengenerator
  1438. enthält, heißt "randseed.bin". Sie kann ebenso wie die anderen
  1439. von PGP benötigten Dateien in dem Verzeichnis stehen, das durch
  1440. die Umgebungsvariable (environmental variable) PGPPATH
  1441. angegeben wird. Falls die Datei nicht vorhanden ist, wird sie
  1442. automatisch erzeugt. Sie erhält einen Startwert aus echten
  1443. Zufallszahlen, die aus dem zeitlichen Abstanden von
  1444. Tastatureingaben abgeleitet werden.
  1445.  
  1446. In die Datei "randseed.bin" werden bei jedem Aufruf des
  1447. Zufallszahlengenerators neue Daten geschrieben, unter
  1448. Einbeziehung der aktuellen Uhrzeit und anderer echter
  1449. Zufallsdaten. Im Zufallszahlengenerator wird der konventionelle
  1450. Verschlüsselungsalgorithmus verwendet.
  1451.  
  1452. Die Datei "randseed.bin" sollte wenigstens ein bißchen vor
  1453. Mitlesen geschützt sein, um das Risiko klein zu halten, daß ein
  1454. Angreifer die nächsten Schlüssel, die PGP generieren wird, oder
  1455. die letzten Schlüssel, die PGP generiert hat, berechnet. Dieser
  1456. Angreifer hätte Schwerstarbeit zu erledigen, weil PGP die Datei
  1457. "randseed.bin" vor und nach jeder Benutzung kryptographisch "in
  1458. die Mangel nimmt". Trotzdem ist es keine unangebrachte
  1459. Vorsicht, darauf zu achten, daß die Datei nicht in die falsche
  1460. Hände gerät.
  1461.  
  1462. LeserInnen, denen diese algorithmisch abgeleiteten
  1463. Zufallszahlen unheimlich sind, sollten nicht vergessen, daß sie
  1464. der Sicherheit desselben konventionellen
  1465. Verschlüsselungsalgorithmus vertrauen, um eine Nachricht zu
  1466. verschlüsseln. Wenn der Algorithmus für die Verschlüsselung
  1467. sicher genug ist, sollte er hinreichend zuverlässig sein, um
  1468. Zufallszahlen zu erzeugen, die den konventionellen Schlüssel
  1469. bilden. Zu beachten ist noch, daß PGP zur Erzeugung eines
  1470. Paares von öffentlichem und geheimem Schlüssel, die über
  1471. längere Zeit sicher sein sollen, echte Zufallszahlen verwendet,
  1472. die im wesentlichen aus den Zeitabständen von Tastatureingaben
  1473. abgeleitet werden.
  1474.  
  1475. [Anmerkung des Übersetzers: Die Erzeugung von
  1476. Pseudozufallszahlen, also von Zahlen, die zwar "zufällig
  1477. aussehen", die aber aus einem Algorithmus abgeleitet werden,
  1478. ist eine schwierige Aufgabe. Wegen der "guten Zufallsqualität"
  1479. wird auch bei Anwendungen, die nichts mit Verschlüsselung zu
  1480. tun haben, wie Statistik oder numerischer Mathematik, gerne ein
  1481. Verschlüsselungsalgorithmus verwendet, um Zufallszahlen zu
  1482. erzeugen. Die Probleme bei Verschlüsselung und bei der
  1483. Erzeugung von Zufallszahlen sind ähnlich: In beiden Fällen geht
  1484. es darum, Bitfolgen zu erzeugen, die möglichst wenig Systematik
  1485. zeigen. Bei der Verschlüsselung sind diese Bitfolgen der
  1486. verschlüsselte Text, bei der Erzeugung von Zufallszahlen sind
  1487. die Bitfolgen eben die Zufallszahlen. LeserInnen, denen die
  1488. Verwendung der Datei "randseed.bin" trotz dieser Argumente
  1489. unheimlich bleibt, können sie immer noch vor jedem Start von
  1490. PGP einfach löschen. Allerdings müssen sie dann für die
  1491. Verschlüsselung eines Klartextes jedesmal ungefähr 90
  1492. Tastendrücke für die Erzeugung einer echten Zufallszahl
  1493. ausführen. d.Ü.]
  1494.  
  1495.  
  1496.  
  1497. Der konventionelle Verschlüsselungsalgorithmus bei PGP
  1498. ------------------------------------------------------
  1499.  
  1500. Wie weiter oben bereits erwähnt, verwendet PGP für die
  1501. Verschlüsselung des Klartextes einen schnellen konventionellen
  1502. Verschlüsselungsalgorithmus; der mit öffentlichen Schlüsseln
  1503. arbeitende Algorithmus wird nur dazu verwendet, den aktuell für
  1504. eine Nachricht verwendeten konventionellen Schlüssel zu
  1505. chiffrieren, so daß er zusammen mit der verschlüsselten
  1506. Nachricht verschickt werden kann. Im folgenden werden wir über
  1507. diesen Algorithmus sprechen. Von DES reden wir nicht.
  1508.  
  1509. Der "Federal Data Encryption Standard" (DES) ist ein guter
  1510. Algorithmus für die meisten kommerziellen Anwendungen.
  1511. Allerdings vertraut die US-Regierung nicht auf DES, um ihre
  1512. eigenen geheimen Daten zu schützen. Vielleicht liegt der Grund
  1513. darin, daß der Schlüssel bei DES nur 56 Bit lang ist, kurz
  1514. genug für einen Angriff "mit brutaler Gewalt", bei dem eine
  1515. spezielle Maschine verwendet wird, die aus einer Vielzahl von
  1516. DES-Verschlüsselungschips besteht, die einfach alle 2^56
  1517. möglichen Schlüssel "ausprobiert". Auch hatten Biham und Shamir
  1518. kürzlich einigen Erfolg beim Angriff auf eine volle 16-Runden-
  1519. DES-Verschlüsselung. ["16 Runden" bedeutet, daß der DES-
  1520. Algorithmus 16 mal hintereinander für die Verschlüsselung
  1521. desselben Datenblocks verwendet wird, also gewissermaßen eine
  1522. 16-fache Verschlüsselung. Diese 16 Runden sind Standard bei
  1523. DES; übrigens auch bei der im folgenden beschriebenen IDEA-
  1524. Verschlüsselung. d.Ü.]
  1525.  
  1526. PGP verwendet DES nicht für die konventionelle Verschlüsselung.
  1527. Statt dessen wird ein anderer blockorientierter Ein-Schlüssel
  1528. Algorithmus namens IDEA(tm) verwendet. Eine künftige Version
  1529. von PGP könnte DES optional unterstützen, falls genug
  1530. BenutzerInnen danach fragen. Aber ich nehme an, daß IDEA besser
  1531. als DES ist.
  1532.  
  1533. IDEA verwendet - kryptographisch ungewöhnlich - 64 Bit lange
  1534. Blöcke für Klartext und verschlüsselten Text, mit 128 Bits
  1535. langen Schlüsseln. Der Algorithmus basiert auf dem Konzept der
  1536. Mischung von Operationen verschiedener algebraischer Gruppen.
  1537. Eine Software-Implementierung von IDEA ist wesentlich schneller
  1538. als ein DES-Software-Implementierung. Ähnlich wie DES, kann
  1539. IDEA für "cipher feedback" (CFB, Rückführung der
  1540. verschlüsselten Textes) und für "cipher block chaining" (CBC,
  1541. Verkettung von Blöcken verschlüsselten Textes) verwendet
  1542. werden. PGP verwendet IDEA mit 64-Bit CFB.
  1543.  
  1544. Die IPES/IDEA-Verschlüsselung wurde an der ETH Zürich von James
  1545. L. Massey und Xuejia Lai entwickelt und 1990 veröffentlicht.
  1546. IDEA ist keine Entwicklung aus dem Bastelkeller. Seine
  1547. Entwickler haben unter Kryptologen einen hervorragenden Ruf. In
  1548. ihren ersten Veröffentlichungen nannten sie den Algorithmus
  1549. IPES (Improved Proposed Encryption Standard - Vorschlag für
  1550. einen verbesserten Verschlüsselungsstandard), später änderten
  1551. sie den Namen in IDEA (International Data Encryption Standard -
  1552. Internationaler Standard für Datenverschlüsselung). Bis heute
  1553. hat IDEA kryptanalytischen Angriffen wesentlich besser stand
  1554. gehalten als andere Verfahren wie FEAL, REDOC-II, LOKI, Snefru
  1555. und Khafre. Es gibt erste Anhaltspunkte dafür, daß IDEA dem
  1556. sehr erfolgreichen differentiellen kryptanalytischen Angriff
  1557. von Biham und Shamir wesentlich besser standhält als DES. Biham
  1558. und Shamir untersuchten IDEA erfolglos auf Schwachstellen.
  1559. Akademische Arbeitsgruppen von Kryptanalytikern aus Belgien,
  1560. England und Deutschland suchen Angriffsmöglichkeiten bei IDEA,
  1561. ebenso militärische Geheimdienste mehrerer europäischer Länder.
  1562. Je mehr und je länger dieser neue Algorithmus Angriffsversuche
  1563. aus den gefürchtetsten Arbeitsgruppen der kryptanalytischen
  1564. Welt auf sich zieht, desto mehr steigt das Vertrauen in ihn.
  1565.  
  1566. Ein berühmter Eishockeyspieler sagte einmal: "Ich versuche, an
  1567. die Stelle zu laufen, von der ich meine, daß der Puck dort sein
  1568. müßte." Viele Leute beginnen zu glauben, daß die Tage von DES
  1569. gezählt sind. Ich bin dabei, in Richtung IDEA zu laufen.
  1570.  
  1571. Die ausschließliche Verwendung von RSA mit langen Schlüsseln
  1572. ist wegen der langen Rechenzeit für die Ver- und
  1573. Entschlüsselung großer Datenmengen ergonomisch unsinnig. Das
  1574. macht absolut niemand im wirklichen Leben. Trotzdem liegt die
  1575. Frage nahe, ob die Kombination einer Verschlüsselung mit
  1576. öffentlichen Schlüsseln und einer zweiten, konventionell
  1577. arbeitenden Verschlüsselung die Gesamtsicherheit herabsetzt,
  1578. und das nur, um das Programm schneller zu machen. Schließlich
  1579. ist eine Kette nur so stark wie ihr schwächstes Glied. Viele
  1580. Leute, die wenig Erfahrung mit Kryptographie haben, sind der
  1581. Meinung, daß RSA vom Prinzip her sicherer sei als eine
  1582. konventionelle Verschlüsselung. Das stimmt nicht. RSA kann
  1583. durch "weiche" Schlüssel leicht angreifbar werden, andererseits
  1584. können konventionelle Verschlüsselungen bei Wahl eines guten
  1585. Algorithmus sehr sicher sein. In den meisten Fällen ist es
  1586. schwierig, genau zu sagen, wie gut eine konventionelle
  1587. Verschlüsselung ist, ohne sie wirklich zu knacken. Ein guter
  1588. konventioneller Algorithmus könnte durchaus schwerer zu knacken
  1589. sein als ein RSA-Schlüssel nach militärischem Standard. Der
  1590. Reiz einer Verschlüsselung mit öffentlichen Schlüsseln besteht
  1591. nicht darin, daß sie aus sich heraus sicherer als eine
  1592. konventionelle Verschlüsselung ist - ihr Reiz besteht in der
  1593. wesentlich bequemeren und vielseitigeren Handhabung der
  1594. Schlüssel.
  1595.  
  1596.  
  1597.  
  1598. Datenkomprimierung
  1599. ------------------
  1600.  
  1601. Normalerweise komprimiert PGP den Klartext, bevor er
  1602. verschlüsselt wird. Verschlüsselte Daten lassen sich nicht mehr
  1603. komprimieren. [Das liegt daran, daß verschlüsselte Daten sehr
  1604. "zufällig aussehen", Kompressionsalgorithmen aber darauf
  1605. basieren, eine bestimmte Systematik in den Daten zu erkennen,
  1606. und auf Grundlage dieser Systematik eine kürzere Darstellung
  1607. der Daten zu suchen. d.Ü.] Die Kompression spart
  1608. Übertragungszeit und Festplattenkapazität, und, viel wichtiger,
  1609. sie erhöht die Sicherheit der Verschlüsselung. Die meisten
  1610. kryptanalytischen Techniken gehen von der Redundanz des
  1611. Klartextes aus, um die Verschlüsselung zu knacken. Die
  1612. Datenkompression reduziert die Redundanz des Klartextes, und
  1613. erhöht dadurch wesentlich die Sicherheit vor kryptanalytischen
  1614. Angriffen. Die Datenkompression kostet zwar etwas Rechenzeit,
  1615. aber vom Standpunkt der Sicherheit aus ist das gerechtfertigt,
  1616. wenigstens nach meiner bescheidenen Meinung.
  1617.  
  1618. Dateien, die für eine Kompression zu klein sind, oder die sich
  1619. nicht gut komprimieren lassen, werden von PGP nicht
  1620. komprimiert.
  1621.  
  1622. Bei Bedarf läßt sich auch PKZIP oder ein anderes
  1623. Datenkomprimierungsprogramm verwenden, um den Klartext vor der
  1624. Verschlüsselung zu komprimieren. PKZIP ist ein weit
  1625. verbreitetes und effizient arbeitendes Kompressionsprogramm von
  1626. PKWare Inc. für MSDOS, das als Shareware vertrieben wird. Oder
  1627. man kann ZIP benutzen, ein PKZIP-kompatibles Freeware-Programm
  1628. für Unix und andere Betriebssysteme, zu erhalten bei Jean-Loup
  1629. Gailly. Die Verwendung von PKZIP oder ZIP hat unter bestimmten
  1630. Umständen Vorteile, weil diese Programme im Gegensatz zu PGP in
  1631. der Lage sind, mehrere Dateien in einer einzigen komprimierten
  1632. Datei zusammenzufassen. Bei der Dekompression werden natürlich
  1633. wieder die einzelnen Originaldateien erzeugt. PGP versucht
  1634. nicht, eine bereits komprimiert vorliegende Klartext-Datei
  1635. erneut zu komprimieren. Die EmpfängerIn einer so komprimierten
  1636. Datei muß sie nach der Entschlüsselung mit PKUNZIP
  1637. dekomprimieren. Wenn der entschlüsselte Klartext eine PKZIP-
  1638. komprimierte Datei ist, erkennt PGP das automatisch, und weist
  1639. die EmpfängerIn darauf hin, das es sich wahrscheinlich um eine
  1640. PKZIP-Datei handelt.
  1641.  
  1642. Für die technisch interessierten LeserInnen sei noch erwähnt,
  1643. daß die aktuelle Version von PGP die Freeware-Kompressions-
  1644. Routinen enthält, die Jean-Loup Gailly, Mark Adler und Richard
  1645. B. Wales geschrieben haben. Diese ZIP-Routinen verwenden
  1646. Algorithmen, die funktionsäquivalent zu denjenigen von PKZIP
  1647. 2.0 von PKWare sind. Diese ZIP-Routinen wurde im wesentlichen
  1648. deshalb in PGP eingebaut, weil sie als gut portierbarer C-
  1649. Quellcode zu Verfügung stehen, weil sie wirklich gut
  1650. komprimieren, und weil sie schnell sind.
  1651.  
  1652. Peter Gutmann hat ein schönes Kompressions- und
  1653. Archivierungsprogramm namens HPACK geschrieben, das von vielen
  1654. FTP-Servern im Internet zu beziehen ist. HPACK verschlüsselt
  1655. komprimierte Dateien, unter Verwendung des PGP-Dateiformats und
  1656. der PGP-Schlüsseldateien. Es bat mich, hier auf HPACK
  1657. aufmerksam zu machen.
  1658.  
  1659.  
  1660.  
  1661. Textprüfsummen (message digests) und digitale Unterschriften
  1662. ------------------------------------------------------------
  1663.  
  1664. Um eine digitale Unterschrift zu erzeugen, verwendet PGP den
  1665. geheimen Schlüssel, jedoch nicht für die "Verschlüsselung" des
  1666. gesamten Textes - das würde zuviel Rechenzeit kosten. Statt
  1667. dessen "verschlüsselt" PGP eine "Textprüfsumme" mit dem
  1668. geheimen Schlüssel.
  1669.  
  1670. Diese Textprüfsumme ist ein kleines (128 Bit langes)
  1671. "Destillat" einer Nachricht, von der Idee her ähnlich einer
  1672. Quersumme oder eine CRC-Summe. Man kann sich die Textprüfsumme
  1673. auch als eine Art Fingerabdruck der Nachricht vorstellen. Die
  1674. Textprüfsumme "repräsentiert" die Nachricht in dem Sinn, daß
  1675. sich bei jeder Änderung an der Nachricht eine andere
  1676. Textprüfsumme für die Nachricht ergibt. An der Textprüfsumme
  1677. läßt sich also erkennen, ob sich ein Fälscher an der Nachricht
  1678. zu schaffen gemacht hat. Die Textprüfsumme wird durch eine
  1679. kryptographisch zuverlässige Einweg-Hash-Funktion berechnet.
  1680. [Eine Einwegfunktion ist eine Funktion, bei der es keine
  1681. Möglichkeit gibt - oder keine Möglichkeit bekannt ist -, aus
  1682. dem Funktionswert auf das Funktionsargument zurückzuschließen.
  1683. Eine Hashfunktion ist eine Funktion, die eine große Menge von
  1684. Funktionsargumenten möglichst gleichmäßig auf eine
  1685. vergleichsweise kleine Menge von Funktionswerten abbildet.
  1686. d.Ü.] Ein Fälscher kann wegen des immensen erforderlichen
  1687. Rechenaufwands keine zweite Nachricht produzieren, die dieselbe
  1688. Textprüfsumme wie die Originalnachricht hat. In dieser Hinsicht
  1689. ist das bei PGP verwendete Verfahren zur Berechnung der
  1690. Textprüfsumme wesentlich besser als die üblichen Quersummen
  1691. oder CRC-Summen, bei denen es einfach ist, zu einer gegebenen
  1692. Nachricht eine zweite Nachricht zu finden, die die identische
  1693. Quer- oder CRC-Summe hat. Andererseits kann aus der
  1694. Textprüfsumme ebenso wenig wie aus einer Quer- oder CRC-Summe
  1695. die Originalnachricht berechnet werden.
  1696.  
  1697. Die Textprüfsumme alleine reicht nicht aus, um die Echtheit
  1698. einer Nachricht zu kontrollieren. Der Algorithmus für ihre
  1699. Berechnung ist allgemein bekannt, und er verwendet keinen
  1700. geheimen Schlüssel. Wenn man die Textprüfsumme einfach so zur
  1701. Nachricht hinzufügte, könnte ein Fälscher die Nachricht ändern
  1702. und die Prüfsumme für die geänderte Nachricht neu berechnen.
  1703. Für eine zuverlässige Kontrolle der Echtheit einer Nachricht
  1704. muß die AbsenderIn die Prüfsumme mit ihrem geheimen Schlüssel
  1705. "verschlüsseln". Erst hierdurch entsteht eine authentische
  1706. Unterschrift.
  1707.  
  1708. Die Textprüfsumme wird von dem PGP-Programm der AbsenderIn
  1709. einer Nachricht berechnet. Die digitale Unterschrift entsteht
  1710. dadurch, daß die AbsenderIn die Textprüfsumme und die Zeitmarke
  1711. mit ihrem geheimen Schlüssel "verschlüsselt". Die AbsenderIn
  1712. verschickt Nachricht und digitale Unterschrift. Die EmpfängerIn
  1713. erhält Nachricht und digitale Unterschrift; ihr PGP-Programm
  1714. ermittelt die Textprüfsumme, indem es die digitale Unterschrift
  1715. mit dem öffentlichen Schlüssel der AbsenderIn "entschlüsselt".
  1716. Zur Kontrolle wird die Textprüfsumme aus der erhaltenen
  1717. Nachricht berechnet. Wenn die aus der Nachricht berechnete
  1718. Textprüfsumme und die in der Unterschrift enthaltene
  1719. Textprüfsumme übereinstimmen, ist gewährleistet, daß die
  1720. Nachricht nicht geändert wurde, und daß sie von derjenigen
  1721. Person stammt, deren öffentlicher Schlüssel für die Kontrolle
  1722. der Unterschrift verwendet wurde.
  1723.  
  1724. Ein Fälscher müßte die Nachricht entweder so ändern, daß die
  1725. Textprüfsumme gleich bleibt - was unmöglich ist, oder er müßte
  1726. mit der geänderten Textprüfsumme eine neue digitale
  1727. Unterschrift erzeugen - was ohne den geheimen Schlüssel der
  1728. AbsenderIn auch nicht möglich ist.
  1729.  
  1730. Eine digitale Unterschrift beweist, wer eine Nachricht
  1731. abgeschickt hat, und ob die Nachricht aufgrund eines
  1732. technischen Fehlers oder absichtlich geändert wurde. Ebenso
  1733. verhindern sie, daß eine AbsenderIn die Unterschrift unter
  1734. einer Nachricht ableugnen kann.
  1735.  
  1736. Die Verwendung der Textprüfsumme für die digitale Unterschrift
  1737. hat neben der Geschwindigkeit noch weitere Vorteile im
  1738. Vergleich zur "Verschlüsselung" der gesamten Nachricht mit dem
  1739. geheimen Schlüssel. Die Unterschriften haben alle die gleiche
  1740. geringe Länge, unabhängig von der Größe der jeweiligen
  1741. Nachricht. Sie ermöglichen der Software eine automatische
  1742. Kontrolle der Korrektheit einer Nachricht, ähnlich wie Quer-
  1743. oder CRC-Summen. Die Unterschrift kann getrennt von der
  1744. Nachricht gespeichert werden, bei Bedarf sogar in einem
  1745. öffentlich zugänglichen Archiv, ohne daß vertrauliche
  1746. Informationen aus der Nachricht offengelegt werden, weil es
  1747. unmöglich ist, aus der Kenntnis der Textprüfsumme irgend etwas
  1748. über den Inhalt der Nachricht zu ermitteln.
  1749.  
  1750. De bei PGP verwendet Algorithmus für die Berechnung der
  1751. Textprüfsumme ist MD5 (Message Digest 5), von der RSA Data
  1752. Security Inc. für Public Domain Verwendung freigegeben. Ronald
  1753. Rivest, der Entwickler von MD5, schreibt darüber:
  1754.  
  1755. "Es ist zu vermuten, daß der Rechenaufwand, zwei Nachrichten
  1756. mit derselben Textprüfsumme zu erhalten, in der Größenordnung
  1757. von 2^64 Rechenoperationen liegt, und daß der Rechenaufwand,
  1758. eine Nachricht mit einer vorgegebenen Prüfsumme zu erzeugen, in
  1759. der Größenordnung von 2^128 Operationen liegt. Der MD5-
  1760. Algorithmus ist sorgfältig auf Schwachstellen untersucht.
  1761. Andererseits ist er verhältnismäßig neu, so daß eine weitere
  1762. Analyse seiner Sicherheit natürlich gerechtfertigt ist, wie bei
  1763. jedem neuen Vorhaben dieser Art. Der Grad von Sicherheit, den
  1764. MD5 bietet, dürfte ausreichen, um zusammen mit RSA hochgradig
  1765. sichere Systeme für digitale Unterschriften zu implementieren."
  1766.  
  1767.  
  1768.  
  1769. Kompatibilität mit alten Versionen von PGP
  1770. ==========================================
  1771.  
  1772. Es tut mir leid, aber Version 2.x von PGP ist nicht kompatibel
  1773. zu Version 1.0. Für Version 1.0 generierte Schlüssel müssen
  1774. durch neue ersetzt werden. Ab Version 2.0 verwendet PGP andere
  1775. Algorithmen für die konventionelle Verschlüsselung, für die
  1776. Datenkompression und für die Berechnung der Textprüfsummen.
  1777. Außerdem gibt es ab Version 2.0 ein wesentlich besseres Konzept
  1778. für die Verwaltung der Schlüssel. Die Änderungen sind zu
  1779. umfangreich, um eine Kompatibilität mit Version 1.0 aufrecht zu
  1780. erhalten. Vielleicht hätten wir ein Konvertierungsprogramm für
  1781. die Schlüssel von Version 1.0 schreiben können oder sollen,
  1782. aber wir alle waren nach Fertigstellung von PGP 2.0 erschöpft,
  1783. und wir wollten endlich die neue Version auf die Menschheit
  1784. loslassen und hinter dem Projekt die Tür zu machen. Außerdem
  1785. könnte die Konvertierung der alten in neue Schlüssel
  1786. möglicherweise mehr Probleme schaffen als Probleme zu lösen,
  1787. weil wir einen neuen einheitlichen Stil für die BenutzerIn-ID
  1788. empfehlen, die den vollen Namen und die E-Mail-Adresse in einer
  1789. speziellen Syntax umfaßt.
  1790.  
  1791.  
  1792. Version 2.0 ist weitgehend kompatibel mit neueren Versionen.
  1793. Weil neue Versionen von PGP auch neue Möglichkeiten bieten,
  1794. können die älteren Versionen manche Dateien, die mit neueren
  1795. erzeugt wurden, nicht in jedem Fall bearbeiten.
  1796.  
  1797. Wir haben uns Mühe gegeben, die internen Datenstrukturen dieser
  1798. Version von PGP so zu entwerfen, daß sie an künftige Änderungen
  1799. angepaßt werden können, so daß hoffentlich niemand noch einmal
  1800. bei einer kommenden Version von PGP die alten Schlüssel
  1801. wegschmeißen und neue Schlüssel generieren muß.
  1802.  
  1803.  
  1804.  
  1805. Angriffsmöglichkeiten
  1806. =====================
  1807.  
  1808. Kein Datensicherheitssystem ist unangreifbar. Die Sicherheit
  1809. von PGP kann auf vielerlei Art ausgehebelt werden. Bei jedem
  1810. Datensicherheitssystem müssen AnwenderInnen beurteilen, ob die
  1811. Daten, die geschützt werden sollen, für den Angreifer so viel
  1812. Wert haben, daß sich für ihn der Aufwand eines Angriffs lohnt.
  1813. Dies kann durchaus zu der Entscheidung führen, sich nur von
  1814. simplen Angriffen zu schützen, ohne sich um aufwendige Angriffe
  1815. Gedanken zu machen.
  1816.  
  1817. Die folgende Diskussion mag manchmal maßlos paranoid
  1818. erscheinen, aber so eine Einstellung ist für eine fundierte
  1819. Auseinandersetzung mit möglichen Angriffen durchaus angemessen.
  1820.  
  1821.  
  1822.  
  1823. Bekannt gewordenes Mantra und bekannt gewordener geheimer
  1824. ---------------------------------------------------------
  1825. Schlüssel
  1826. ---------
  1827.  
  1828. Die wahrscheinlich einfachste Angriffsmöglichkeit ergibt sich,
  1829. wenn man das Mantra für den geheimen Schlüssel irgendwo
  1830. aufschreibt. Falls jemand dies Mantra lesen kann und ihm/ihr
  1831. dann noch die Datei mit dem geheimen Schlüssel in die Hände
  1832. fällt, kann er/sie alle verschlüsselten Nachrichten lesen und
  1833. mit dem geheimen Schlüssel gefälschte digitale Unterschriften
  1834. erzeugen.
  1835.  
  1836. Offensichtliche Paßworte, die einfach zu raten sind, sind
  1837. ungeeignet, wie die Namen von Kindern oder der PartnerIn. Ein
  1838. einzelnes Wort als Mantra kann ebenfalls leicht geraten werden,
  1839. wenn ein Computer die Wörter eines Lexikons solange als Paßwort
  1840. ausprobiert, bis das richtige gefunden ist. Deshalb ist eine
  1841. Paß-Phrase, [also eine Kombination mehrerer Worte - von uns
  1842. "Mantra" genannt d.Ü.] wesentlich besser als ein einfaches
  1843. Paßwort. Ein verfeinerter Angriff könnte darin bestehen, einen
  1844. Computer ein Lexikon mit berühmten Zitaten durcharbeiten zu
  1845. lassen, um das Mantra zu finden. Eine leicht zu merkendes, aber
  1846. schwer erratbares Mantra läßt bequem aus ein paar kreativ
  1847. sinnlosen Sprüchen oder weithin unbekannten literarischen
  1848. Zitaten zusammenstellen.
  1849.  
  1850. Weiteres hierzu steht im Abschnitt "Private Schlüssel vor
  1851. Diebstahl schützen" in Teil 1 des Handbuchs.
  1852.  
  1853.  
  1854.  
  1855. Fälschung des öffentlichen Schlüssels
  1856. -------------------------------------
  1857.  
  1858. Eine der gefährlichsten Angriffsmöglichkeiten besteht darin,
  1859. daß der öffentliche Schlüssel gefälscht werden kann. Dies ist
  1860. der ernsteste, wichtigste Ansatzpunkt für das Knacken einer
  1861. Verschlüsselung mit öffentlichen Schlüsseln, unter anderem,
  1862. weil die meisten Neulinge die Gefahr nicht sofort erkennen. Die
  1863. Bedeutung der Fälschbarkeit eines Schlüssels und geeignete
  1864. Gegenmaßnahmen sind detailliert im Abschnitt "Öffentliche
  1865. Schlüssel vor Manipulation schützen" in Teil 1 des Handbuchs
  1866. beschrieben.
  1867.  
  1868. Zusammengefaßt: Wenn man einen öffentlichen Schlüssel für die
  1869. Verschlüsselung einer Nachricht oder für die Prüfung einer
  1870. Unterschrift verwenden will, muß sichergestellt sein, das er
  1871. nicht gefälscht ist. Der Echtheit eines neu erhaltenen
  1872. öffentlichen Schlüssels sollte man nur dann vertrauen, wenn man
  1873. ihn unmittelbar, auf sicherem Weg, von seiner BesitzerIn
  1874. erhalten hat, oder wenn seine Echtheit von jemandem bestätigt
  1875. ist, dem/der man vertraut. Man muß auch dafür sorgen, daß kein
  1876. Fremder Änderungen an der eigenen Datei mit öffentlichen
  1877. Schlüsseln vornehmen kann. Man braucht physikalische Kontrolle
  1878. sowohl über die Datei mit öffentlichen Schlüsseln wie auch über
  1879. die Datei mit geheimen Schlüsseln. Am besten aufgehoben sie
  1880. diese beiden Dateien auf dem eigenen PC, um einiges schlechter
  1881. auf einem, am Ende auch noch räumlich weit entfernten Mehrplatz-
  1882. Rechner. Auf jeden Fall sollte man Sicherheitskopien der beiden
  1883. Schlüsseldateien haben.
  1884.  
  1885.  
  1886.  
  1887. Nicht richtig gelöschte Dateien
  1888. -------------------------------
  1889.  
  1890. Ein weiteres potentielles Sicherheitsproblem entsteht dadurch,
  1891. wie bei den meisten Betriebssystemen Dateien gelöscht werden.
  1892. Wenn man eine Klartext-Datei verschlüsselt, und danach löscht,
  1893. löscht das Betriebssystem die Daten nicht physikalisch. Es
  1894. markiert nur diejenigen Datenblöcke der Festplatte oder
  1895. Diskette als "gelöscht", die den Inhalt der "gelöschten" Datei
  1896. enthalten, so daß sie für die Speicherung anderer Daten
  1897. freigegeben werden. Das ist das gleiche, als würde man
  1898. vertrauliche Papiere einfach zum Altpapier legen, anstatt sie
  1899. von einen Reißwolf klein häckseln zu lassen. Die Blöcke auf der
  1900. Festplatte enthalten nach wie vor die originalen vertraulichen
  1901. Daten, und werden vielleicht unter Umständen demnächst mal
  1902. irgendwann in naher oder ferner Zukunft durch neue Daten
  1903. überschrieben. Wenn ein Angreifer diese "gelöschten"
  1904. Datenblöcke kurz nach ihrer Freigabe liest, hat er einige
  1905. Aussicht, den kompletten Klartext zu erhalten.
  1906.  
  1907. Genau dies, die Wiederherstellung einer schon vor langem
  1908. gelöschten Datei, kann sogar ganz zufällig passieren, wenn aus
  1909. irgend einem Grund etwas mit der Festplatte schief geht, und
  1910. wichtige Dateien gelöscht oder beschädigt sind. Die übliche
  1911. "Rettungsmaßnahme" besteht darin, ein
  1912. Dateiwiederherstellungsprogramm laufen zu lassen, um die
  1913. Dateien zu "reparieren". Hierbei werden häufig auch alte, schon
  1914. vor dem "Unfall" gelöschte Dateien wieder ausgegraben. Auf
  1915. diese Art können auch vertrauliche Daten wieder ans Tageslicht
  1916. kommen, von denen man annahm, daß sie für immer gelöscht seien.
  1917. Folglich können diese Daten von jedem/jeder gelesen werden
  1918. können, der/die ein solches Programm laufen läßt. Darüber
  1919. hinaus legen die meisten Textverarbeitungsprogramme auch Backup-
  1920. Dateien an, und erzeugen häufig auch aus technischen Gründen
  1921. eine oder mehrere temporäre Dateien, die den gesamten Text oder
  1922. Teile davon enthalten. Diese Dateien werden vom
  1923. Textverarbeitungsprogramm automatisch gelöscht - aber eben nur
  1924. in dem Sinn, daß die Blöcke auf der Festplatte / Diskette für
  1925. ein Überschreiben freigegeben werden. Der Text selbst steht
  1926. nach wie vor noch in diesen Blöcken.
  1927.  
  1928. Hierzu eine wahre Horrorgeschichte: Eine Freundin von mir,
  1929. verheiratet und Mutter kleiner Kinder, hatte eine kurze und
  1930. nicht sehr ernstzunehmende Liebesaffaire. Sie schrieb ihrem
  1931. Liebhaber auf dem Computer einen Brief, und nachdem sie den
  1932. Brief abschickte, löschte sie die Datei. Nachdem die Affaire
  1933. schon vorbei war, ging die Diskette kaputt, auf der der Brief
  1934. gespeichert war. Weil die Diskette einige andere wichtige Daten
  1935. enthielt, bat sie ihren Ehemann, die Diskette zu reparieren.
  1936. Der ließ die Diskette von einem Datenwiederherstellungsprogramm
  1937. bearbeiten, wobei neben den von seiner Frau benötigten Dateien
  1938. auch der besagte Brief wieder zu Tage kam, was eine Kette
  1939. tragischer Ereignisse auslöste.
  1940.  
  1941. Um zu verhindern, daß der Klartext irgendwann mal ausgegraben
  1942. wird, gibt es nur den einen Weg, die "gelöschten" Daten auch
  1943. wirklich zu überschreiben. Solange man nicht wirklich sicher
  1944. weiß, daß die freigegebenen Blöcke der Festplatte /Diskette
  1945. sehr schnell wieder mit anderen "echten" Daten überschrieben
  1946. werden [dieses Wissen haben bei den meisten Betriebssystemen,
  1947. wenn überhaupt, nur ausgekochte BetriebssystemspezialistInnen
  1948. d.Ü.], muß man selbst dafür sorgen, daß die Klartext-Datei und
  1949. die temporären Dateien, die das Textverarbeitungsprogramm
  1950. angelegt hat, wirklich überschrieben werden. Die Klartext-Datei
  1951. überschreibt PGP, wenn die Option "-w" (wipe = wischen) bei der
  1952. Verschlüsselung angegeben wird. Sämtliche Textfragmente, ob aus
  1953. der "richtigen" Klartext-Datei oder aus temporären Dateien,
  1954. lassen sich mit einem geeigneten Hilfsprogramm löschen, das
  1955. alle freien Blöcke einer Festplatte/Diskette überschreibt. Für
  1956. MSDOS sind beispielsweise die Norton Utilities geeignet.
  1957.  
  1958. [Eine weitere Stelle, an der bei den meisten Betriebssystemen
  1959. "Textspuren" verbleiben können, sind die "swap files" (auch
  1960. Auslagerungsdateien genannt) bzw. Swap-Partitionen: Wenn ein
  1961. Programm mehr Hauptspeicher benötigt, als real im Computer
  1962. vorhanden ist, wird ein Teil des Hauptspeicherinhalts in diese
  1963. Auslagerungsdatei bzw. -partition geschrieben, so daß der
  1964. Hauptspeicher gewissermaßen auf die Festplatte "verlängert"
  1965. wird. Auch in dieser "Auslagerungsdatei" können Teile eines
  1966. Textes stehen. MSDOS kennt keine Auslagerungsdateien - endlich
  1967. mal ein Vorteil dieses Betriebssystems, wenn auch nur im
  1968. Hinblick auf "Spurensicherheit". Aber selbst Microsoft Windows
  1969. benutzt eine Auslagerungsdatei. d.Ü.]
  1970.  
  1971. Selbst wenn man den Klartext auf der Platte/Diskette
  1972. überschreibt, kann ein technisch gut ausgestatteter Angreifer
  1973. die Daten wiedergewinnen. Geringe magnetische Spuren der
  1974. Originaldaten bleiben auch nach einem Überschreiben auf der
  1975. Platte/Diskette. Diese Spuren können unter Umständen mittels
  1976. spezieller Hardware gelesen werden.
  1977.  
  1978.  
  1979.  
  1980. Viren und Trojanische Pferde
  1981. ----------------------------
  1982.  
  1983. Eine andere Angriffsmöglichkeit könnte ein speziell
  1984. entwickelter Virus und Wurm sein, der PGP oder das
  1985. Betriebssystem infiziert. Dieser hypothetische Virus könnte so
  1986. entworfen sein, daß er das Mantra, den geheimen Schlüssel oder
  1987. den entschlüsselten Klartext "mithört", und unbemerkt in eine
  1988. Datei schreibt, oder über ein Netzwerk zum Besitzer des Virus
  1989. schickt. Er könnte auch das Verhalten von PGP so ändern, daß
  1990. Unterschriften nicht richtig geprüft werden. So ein Angriff ist
  1991. einfacher und billiger als ein kryptanalytischer Angriff.
  1992.  
  1993. Ein Schutz hiergegen fällt unter das allgemeine Thema des
  1994. Schutzes gegen Viren. Es gibt einige relativ brauchbare
  1995. kommerzielle Anti-Virus Produkte, und es gibt
  1996. "Hygienemaßnahmen", deren Beachtung das Risiko einer
  1997. Virusinfektion erheblich reduzieren kann. Eine umfassende
  1998. Abhandlung dieses Themas würde den Rahmen dieses Handbuchs
  1999. sprengen. PGP selbst hat keinerlei inneren Schutz gegen Viren,
  2000. es geht davon aus, daß der PC, auf dem es benutzt wird, eine
  2001. "vertrauenswürdige Umgebung" ist. Falls es einmal so einen
  2002. Spezialvirus für PGP geben sollte, ist zu hoffen, daß eine
  2003. entsprechende Warnung schnell bekannt würde und viele Leute
  2004. erreicht.
  2005.  
  2006. Ein ähnlicher Angriff könnte eine geschickte Imitation von PGP
  2007. sein, die sich im Wesentlichen wie PGP verhält, aber nicht so
  2008. arbeitet, wie anzunehmen wäre. Beispielsweise könnte diese
  2009. Imitation absichtlich dahingehend verstümmelt sein, daß
  2010. Unterschriften nicht mehr korrekt geprüft werden, so daß
  2011. gefälschte Schlüssel nicht mehr erkannt werden können. Eine
  2012. solche "Trojanisches-Pferd-Version" von PGP ist von einem
  2013. Angreifer verhältnismäßig einfach erstellt, weil der Quellcode
  2014. von PGP weit verbreitet ist. Deshalb ist es kein Problem, den
  2015. Quellcode dahingehend zu manipulieren, daß eine
  2016. gehirnamputierte Zombie-Imitation von PGP entsteht, die echt
  2017. aussieht, jedoch nur die Anweisungen ihres teuflischen Meisters
  2018. ausführt. Diese "Trojanisches-Pferd-Version" von PGP könnte
  2019. breit verteilt werden, mit dem Anschein, sie käme von mir. Wie
  2020. hinterhältig. [Die allgemeine Verfügbarkeit des Quellcodes von
  2021. PGP hat aber auch einen anderen, vertrauensschaffenden Aspekt:
  2022. Die entsprechenden Programmierkenntnisse vorausgesetzt, ist es
  2023. nur noch eine Frage des Fleißes, den Quelltext auf obskure
  2024. Stellen durchzusehen. Außerdem kann man das Programm neu
  2025. übersetzen, und sich so eine eigene Arbeitsversion erstellen.
  2026. Der im nächsten Absatz erwähnte Vergleich mehrerer PGP-
  2027. Versionen aus unterschiedlichen Bezugsquellen sollte aber
  2028. zumindest für die selbst erstellte Version vorsichtig
  2029. interpretiert werden: Selbst wenn der gleiche Compiler
  2030. verwendet wird, besteht immer noch die Möglichkeit, daß die
  2031. eigene PGP-Version mit der Compiler-Version 12.34a1 übersetzt
  2032. wird, während das Entwicklerteam Version 12.34b3 verwendet hat.
  2033. Unterschiede in den PGP-Versionen bedeuten deshalb nicht gleich
  2034. das Schlimmste. Auf der anderen Seite heißt das aber auch, daß
  2035. ein neu übersetztes PGP andere BenutzerInnen verunsichern kann.
  2036. Deshalb sollte man normalerweise besser die Originalversion
  2037. weitergeben. d.Ü.]
  2038.  
  2039. Man sollte sich die Mühe machen, PGP von einer zuverlässigen
  2040. Bezugsquelle zu erhalten, was auch immer das heißen mag. Oder
  2041. man besorgt sich PGP von mehreren unabhängigen Quellen, und
  2042. vergleicht die einzelnen Versionen mit einem geeigneten
  2043. Programm.
  2044.  
  2045. Mit Hilfe digitaler Unterschriften ergeben sich weitere
  2046. Möglichkeiten, festzustellen, ob an PGP herumgepfuscht wurde.
  2047. Wenn eine Person, der man vertraut, eine digitale Unterschrift
  2048. für die Datei mit dem ausführbaren PGP-Programm [welch
  2049. komplizierte Formulierung... für MSDOS ganz schlicht: PGP.EXE
  2050. d.Ü.] leistet, und damit garantiert, daß die Datei zum
  2051. Zeitpunkt der Unterschrift nicht infiziert oder anderweitig
  2052. verfälscht ist, kann man einigermaßen sicher sein, eine
  2053. brauchbare Kopie zu haben. Mit Hilfe einer älteren,
  2054. vertrauenswürdigen Version von PGP kann die Unterschrift für
  2055. die neue, zunächst zweifelhafte Version kontrolliert werden.
  2056. Dieser Test setzt natürlich voraus, daß der für die Kontrolle
  2057. der Unterschrift verwendete öffentliche Schlüssel einen hohen
  2058. Grad an Vertrauen hat.
  2059.  
  2060.  
  2061.  
  2062. Lücken in der physischen Sicherheit
  2063. -----------------------------------
  2064.  
  2065. Die meisten bisher besprochenen Sicherheitsprobleme ergeben
  2066. sich, auch ohne daß ein Angreifer unmittelbaren Zugang zu dem
  2067. Computer hat, auf dem die geheim zu haltenden Daten gespeichert
  2068. sind. Ein direkter Zugriff auf den Computer oder ausgedruckte
  2069. Texte ist auch denkbar, durch Einbruch, Durchsuchen des Mülls,
  2070. eine unerwartete / unbegründete Hausdurchsuchung, Bestechung,
  2071. Erpressung, oder Bespitzelung. Von einigen dieser Angriffe
  2072. dürften insbesondere politische Basisorganisationen (grassroots
  2073. organizations) betroffen sein, die weitgehend auf freiwillige
  2074. Mitarbeit angewiesen sind. Die Presse hat einiges darüber
  2075. berichtet, daß das FBI im Rahmen seines COINTELPRO-Programms
  2076. mit Einbruch, Infiltration und illegalen Wanzen gegen
  2077. Antikriegs- und Bürgerrechtsgruppen gearbeitet hat. Nicht zu
  2078. vergessen: Die Watergate-Affaire. [Für die Bundesrepublik gilt
  2079. ähnliches - Spitzel von Verfassungsschutz und Polizei hat es
  2080. schon häufig gegeben. Mittlerweile geht die Diskussion ihres
  2081. legalen Einsatzes bis zu der Frage, ob verdeckt arbeitende
  2082. Polizeibeamte mit Gesetzessegen auch Straftaten sollen begehen
  2083. können. d.Ü.]
  2084.  
  2085. Die Verwendung eines Verschlüsselungsprogramms kann ein
  2086. trügerischen, einschläferndes Gefühl der Sicherheit entstehen
  2087. lassen. Kryptographische Techniken schützen Daten aber nur
  2088. solange, wie sie verschlüsselt sind - Löcher in der
  2089. unmittelbaren physischen Sicherheit können nach wie vor
  2090. Klartextdaten und geschriebene oder gesprochene Information
  2091. offenlegen.
  2092.  
  2093. Diese Art von Angriffen ist einfacher und billiger als ein
  2094. kryptanalytischer Angriff auf PGP.
  2095.  
  2096.  
  2097.  
  2098. "Sturmangriffe" (tempest attacks)
  2099. ---------------------------------
  2100.  
  2101. Eine andere Angriffsmöglichkeit für einen gut ausgerüsteten
  2102. Gegner ist Auswertung der elektromagnetischen Strahlung, die
  2103. ein Computer aussendet. Ein solcher Angriff ist zwar teuer und
  2104. arbeitsintensiv, aber wahrscheinlich immer noch billiger als
  2105. eine richtige Kryptanalyse. Ein entsprechend ausgerüsteter
  2106. Kleinbus könnte in der Nähe des abzuhörenden Computer geparkt
  2107. sein, und jeden Tastendruck und jeden Bildschirminhalt
  2108. aufzeichnen. Das würde alle Paßworte, Nachrichten usw.
  2109. offenlegen. Abwehren läßt sich dieser Angriff durch eine
  2110. geeignete Abschirmung des Computers, des Zubehörs (Drucker
  2111. usw.) und gegebenenfalls der Netzwerk-Verkabelung. Eine solche
  2112. Abschirmung ist unter dem Begriff "sturmsicher" bekannt, und
  2113. wird von einigen Regierungsbehörden und Rüstungsfirmen
  2114. eingesetzt. Es gibt Firmen, die diese Abschirmungen anbieten,
  2115. allerdings ist der Kauf möglicherweise genehmigungspflichtig.
  2116. Woher das wohl kommt?
  2117.  
  2118.  
  2119.  
  2120. Probleme bei Mehrplatz-Computern
  2121. --------------------------------
  2122.  
  2123. Ursprünglich entworfen wurde PGP für (Ein-Platz)-MSDOS-
  2124. Computer, zu denen man unmittelbaren Zugang hat. Ich benutze
  2125. PGP zu Hause auf meinem privaten PC, und solange niemand
  2126. einbricht oder die elektromagnetischen Signale des PC
  2127. auswertet, sind die Klartext-Dateien und die geheimen Schlüssel
  2128. wahrscheinlich sicher.
  2129.  
  2130. Aber mittlerweile gibt es PGP auch für Unix und VAX/VMS, also
  2131. Mehrplatz-Betriebssysteme. Bei diesen Betriebssystemen besteht
  2132. ein wesentlich höheres Risiko, daß Klartext-Dateien, Schlüssel
  2133. oder Paßworte offengelegt werden. Der Systemverwalter oder ein
  2134. versierter Eindringling kann die Klartext-Dateien lesen, und
  2135. unter Umständen auch mittels spezieller Software heimlich die
  2136. Tastatureingaben und die Bildschirmausgaben mitlesen. Unter
  2137. Unix kann jede BenutzerIn mit dem Kommando "ps" einiges an
  2138. Informationen über die anderen BenutzerInnen erhalten,
  2139. beispielsweise alle Umgebungsvariablen (environment variables).
  2140. [Wenn jemand dann auf einer Unix-Mehrplatz-Maschine noch aus
  2141. Faulheit "pgppass" - nicht zu verwechseln mit "pgppath"! -
  2142. setzt, legt er sein Mantra allen anderen BenutzerInnen offen.
  2143. d.Ü.] Ähnliche Probleme gibt es für MSDOS-Rechner, die in einem
  2144. Netzwerk arbeiten. Das aktuelle Sicherheitsrisiko hängt von der
  2145. jeweiligen Situation ab. Ein Mehrplatz-Rechner kann sicher
  2146. sein, wenn man allen BenutzerInnen traut, oder wenn die
  2147. Sicherheitsmechanismen ausreichen, um den Angriffen von
  2148. Eindringlingen standzuhalten, oder auch, wenn es ganz einfach
  2149. keine hinreichend interessierten potentiellen Eindringlinge
  2150. ging. Manche Unix-Systeme sind schon dadurch sicher, daß sie
  2151. von nur einer Person benutzt werden - es gibt bereits
  2152. Notebooks, die mit Unix arbeiten. PGP vollkommen von der
  2153. Benutzung unter Unix auszuschließen, wäre unsinnig.
  2154.  
  2155. PGP ist nicht dafür gedacht, Daten zu schützen, die als
  2156. Klartext auf einem schlecht geschützten oder "aufgeflogenen"
  2157. Rechner vorhanden sind. Ebenso wenig kann es einen Eindringling
  2158. davon abhalten, einen geheimen Schlüssel während seiner
  2159. Benutzung mitzulesen. Diese Risiken muß man sich gerade für
  2160. Mehrplatz-Rechner klar machen, und die Erwartungen an PGP und
  2161. das eigene Verhalten darauf abstimmen. Aber vielleicht hat die
  2162. LeserIn doch die Möglichkeit, PGP auf einem "isolierten", also
  2163. nicht an ein Netzwerk angeschlossenen, Ein-Platz-PC zu
  2164. verwenden, der unter ihrer unmittelbaren physischen Kontrolle
  2165. ist. So setze ich PGP ein, und dazu rate ich auch.
  2166.  
  2167.  
  2168.  
  2169. Statistik von Nachrichtenverbindungen
  2170. -------------------------------------
  2171.  
  2172. Selbst wenn ein Angreifer nicht in Lage ist, den Inhalt der
  2173. verschlüsselten Nachrichten zu lesen, hat er immer noch die
  2174. Möglichkeit, brauchbare Informationen daraus zu gewinnen, woher
  2175. Nachrichten kommen, an wen sie gehen, aus der Länge, aus Datum
  2176. und Uhrzeit der Nachrichten. Dies entspricht der Auswertung,
  2177. wann man mit wem wie lange telefoniert, ohne daß die einzelnen
  2178. Gespräche abgehört werden. Das ist mit "Statistik von
  2179. Nachrichtenverbindungen" gemeint. PGP schützt hiervor nicht. Um
  2180. dies Problem zu lösen, wären speziell hierfür entworfene
  2181. Übertragungsprotokolle nötig, die möglicherweise
  2182. kryptographische Elemente enthalten. [Diese Art der
  2183. Überwachung, die eigentlich auch noch das durch PGP verhinderte
  2184. Durchsuchen der ganzen Post nach Schlüsselworten einschließt,
  2185. ist wohl die am besten genutzte Informationsquelle, die
  2186. Nachrichtendiensten zur Verfügung steht. d.Ü.]
  2187.  
  2188.  
  2189.  
  2190. Kryptanalyse
  2191. ------------
  2192.  
  2193. Ein teurer und schwieriger kryptanalytischer Angriff könnte von
  2194. einem Geheimdienst durchgeführt werden, der über ein
  2195. ausreichendes Arsenal von Supercomputertechnologie verfügt.
  2196. Dieser Geheimdienst könnte einen RSA-Schlüssel unter Verwendung
  2197. eines bahnbrechenden neuen, geheimgehaltenen Algorithmus für
  2198. die Primfaktorzerlegung knacken. Das ist denkbar, aber man
  2199. sollte nicht vergessen, daß die US-Regierung dem RSA-
  2200. Algorithmus soweit vertraut, daß mit ihm nach Aussage von Ron
  2201. Rivest Kernwaffen gesichert werden. Und im zivilen Bereich gibt
  2202. es seit 1978 intensive, aber erfolglose Versuche, RSA zu
  2203. knacken.
  2204.  
  2205. Möglicherweise hat die Regierung auch geheimgehaltene Methoden,
  2206. um IDEA(tm) zu knacken, den bei PGP verwendeten konventionellen
  2207. Verschlüsselungsalgorithmus. Das wäre der schlimmste Alptraum
  2208. jedes Kryptographen. In der praktischen Kryptographie gibt es
  2209. keine Garantie für absolute Sicherheit.
  2210.  
  2211. Doch nach wie vor ist etwas Optimismus gerechtfertigt. Die
  2212. Entwickler von IDEA gehören zu den besten Kryptographen
  2213. Europas. Die besten Kryptanalytiker der nicht geheimen Welt
  2214. haben IDEA einer ausgedehnten Analyse und eingehenden
  2215. Überprüfung unterzogen. Einer differentiellen Kryptanalyse, mit
  2216. der DES geknackt wurde, scheint IDEA besser standzuhalten.
  2217.  
  2218. Aber selbst wenn IDEA die eine oder andere subtile
  2219. Schwachstelle haben sollte, so komprimiert PGP der Klartext vor
  2220. der Verschlüsselung, was die von einer solchen Schwachstelle
  2221. ausgehende Gefährdung um einiges reduzieren dürfte. Der für das
  2222. Knacken erforderliche Rechenaufwand dürfte in den meisten
  2223. Fällen um einiges höher sein, als der Wert der entschlüsselten
  2224. Nachricht.
  2225.  
  2226. Wenn man in einer Situation ist, in der die Furcht vor so einem
  2227. Angriff größten Kalibers berechtigt ist, wäre an der Zeit, die
  2228. Dienste einer SicherheitsberaterIn in Anspruch zu nehmen, die
  2229. auf die jeweilige Situation zugeschnittene Lösungen anbieten
  2230. kann. Boulder Software Engineering bietet diese Leistungen an.
  2231. Die Adresse und Telefonnummer stehen am Ende dieses Handbuchs.
  2232.  
  2233. Kurz gesagt, kann ein Gegner mühelos, sogar routinemäßig,
  2234. Datenkommunikation abhören, insbesondere, wenn ein Modem oder E-
  2235. Mail benutzt wird, es sei denn, die Daten die Daten sind gut
  2236. kryptographisch geschützt. Wenn man PGP verwendet, und die
  2237. erforderlichen Vorsichtsmaßnahmen beachtet, muß ein Angreifer
  2238. erheblich mehr Arbeit und Kosten aufbringen, um in die
  2239. Privatsphäre einzubrechen.
  2240.  
  2241. Wenn man sich von einfachen Angriffen schützt, und annehmen
  2242. kann, daß man nicht einem entschlossenen und sehr gut
  2243. ausgestatteten Angreifer gegenüber steht, dann dürfte die
  2244. Verwendung von PGP sicher sein. PGP (Pretty Good Privacy) sorgt
  2245. für Prima Geschützte Privatsphäre.
  2246.  
  2247.  
  2248.  
  2249. Rechtsfragen
  2250. ============
  2251.  
  2252. [Hinweis: Der folgende Abschnitt ist - wie der Rest des
  2253. Handbuches auch - eine Übersetzung des von Philip Zimmermann
  2254. geschriebenen englischen Handbuches. Im Gegensatz zum Rest des
  2255. Handbuches, das sprachunabhängig "internationale Gültigkeit"
  2256. hat, bezieht sich der folgende Abschnitt im wesentlichen auf
  2257. die rechtliche Lage in den USA. Eine deutschsprachige
  2258. Ergänzung, die rechtliche Fragen für die BRD, die Schweiz oder
  2259. Österreich behandelt, wäre zwar sinnvoll, ist aber z. Zt. nicht
  2260. in Sicht. d.Ü.]
  2261.  
  2262.  
  2263. Warenzeichen, Copyright, Garantie
  2264. ---------------------------------
  2265.  
  2266. "Pretty Good Privacy", "Phils's Pretty Good Software", und
  2267. "Pretty Good" als Warenezeichen für Computerhardware und
  2268. Software sind Warenzeichen von Philip Zimmermann und von Phil's
  2269. Pretty Good Software. PGP ist (c) Copyright by Philip R.
  2270. Zimmermann 1990-1993. Philip Zimmermann hat auch das Copyright
  2271. für das PGP-Handbuch, und für Übersetzungen von Handbuch und
  2272. Software in andere Sprachen.
  2273.  
  2274. Der Autor übernimmt keine Haftung für Schäden, die aus der
  2275. Nutzung der Software entstehen, auch dann nicht, wenn die
  2276. Schäden aus Fehlern der Software resultieren. Der Autor macht
  2277. keine Angaben über die Verkaufbarkeit der Software, oder ihre
  2278. Brauchbarkeit für bestimmte Anwendungen. Die Software wird zur
  2279. Verfügung gestellt "as is", ohne jede explizite oder implizite
  2280. Garantie.
  2281.  
  2282.  
  2283.  
  2284. Patentrechte auf die Algorithmen
  2285. --------------------------------
  2286.  
  2287. Das Verschlüsselungsverfahren RSA wurde am MIT entwickelt. Dem
  2288. MIT wurde ein Patent auf RSA erteilt (U.S. patent #4,405,829,
  2289. erteilt am 20. September 1983). Eine kalifornische Firma namens
  2290. Public Key Partners besitzt die alleinigen Rechte an diesem
  2291. Patent für den Verkauf und die Lizensierung des RSA-
  2292. Verschlüsselungssystems.
  2293.  
  2294. PKP hat für die Nutzung von RSA bei PGP keine Lizenz erteilt.
  2295. Der Autor der Software stellt diese Implementierung nur für
  2296. Lehrzwecke zur Verfügung. Die Verantwortung für die
  2297. Lizensierung von RSA durch PKP liegt bei Ihnen als AnwenderIn,
  2298. nicht beim Autor. Der Autor übernimmt keine Verantwortung für
  2299. eine mögliche Verletzung von Patentrechten, die sich aus der
  2300. Nutzung von PGP auf dem Computer einer AnwenderIn ohne eine
  2301. Lizenz durch den Inhaber des RSA-Patents ergeben können.
  2302.  
  2303. Für AnwenderInnen außerhalb der USA sei angemerkt, daß das US-
  2304. Patent auf RSA nur innerhalb des USA gilt, und daß es kein RSA-
  2305. Patent in anderen Ländern gibt. US-Bundesbehörden können RSA
  2306. nutzen, weil die Entwicklung von RSA staatlich finanziert wurde
  2307. durch Zuschüsse der National Science Foundation und der US-
  2308. Marine. Firmen, die bereits eine Lizenz für die Nutzung von RSA
  2309. haben, dürfen PGP nutzen, falls sie einen geeigneten
  2310. Lizenzvertrag abgeschlossen haben.
  2311.  
  2312. Ich schrieb PGP vollständig selbst, mit einer eigenständig
  2313. entwickelten Implementierung des RSA-Algorithmus. Vor der
  2314. Veröffentlichung von PGP erhielt ich das Rechtsgutachten eines
  2315. Patentanwalt mit großer Erfahrung bei Softwarepatenten. Ich bin
  2316. überzeugt, daß die Art, in der ich PGP veröffentlicht habe,
  2317. keinen Verstoß gegen das Patentrecht darstellt.
  2318.  
  2319. PKP erhielt nicht nur die ausschließlichen Patentrechte für
  2320. RSA, sondern auch die ausschließlichen Rechte für drei andere
  2321. Patente für public key Verschlüsselungssysteme, die an der
  2322. Stanford University mit Bundeszuschüssen entwickelt wurden. Im
  2323. Prinzip entscheidet damit in den USA eine einzige Firma über
  2324. die Verwendung von public key Verschlüsselungssystemen. PKP
  2325. beansprucht sogar das Patentrecht an dem grundlegenden Konzept
  2326. der Kryptographie mit öffentlichen Schlüsseln, unabhängig
  2327. davon, wie intelligent auch immer ein neuer Algorithmus sein
  2328. wird, der unabhängig von PKP entwickelt werden könnte. Ich
  2329. halte ein derart umfassendes Monopol für gefährlich, weil ich
  2330. der Meinung bin, das Kryptographie mit öffentlichen Schlüsseln
  2331. einen zentralen Beitrag zum Schutz der Bürgerrechte und der
  2332. Privatsphäre in unserer immer mehr verkabelten Gesellschaft
  2333. leisten kann. Zumindest setzt das Monopol von PKP diese
  2334. lebenswichtige Technologie dem Risiko der Einflußnahme durch
  2335. die Regierung aus.
  2336.  
  2337. Es laufen Verhandlungen mit RSA Data Security Inc. (RSADSI),
  2338. einer Schwesterfirma von PKP, über die Legalisierung von PGP in
  2339. den USA. Dies würde abgeschlossen werden durch die Integration
  2340. von RSAREF in PGP. RSAREF ist Softwarepaket von RSADSI, das die
  2341. RSA-Algorithmen implementiert. Diese Routinen aus RSAREF würden
  2342. dann die bisherigen RSA-Routinen in PGP ersetzen. Die
  2343. Einbindung von RSAREF verursacht ein paar technische Probleme,
  2344. aber dafür werden sich Lösungen ergeben, wenn die Verhandlungen
  2345. mit RSADSI erfolgreich verlaufen. Wenn RSAREF in PGP integriert
  2346. ist, wird PGP von RSADSI für den nichtkommerziellen Gebrauch in
  2347. den USA lizensiert werden. Ausländische Versionen von PGP
  2348. werden die schnelleren PGP-eigenen RSA-Routinen behalten.
  2349. RSADSI verlangt möglicherweise, den Namen von PGP zu ändern.
  2350. Halten Sie sich auf dem laufenden. [Mittlerweile ist es soweit:
  2351. PGP wird in den USA unter dem Namen Viacrypt ganz legal
  2352. verkauft. d.Ü.]
  2353.  
  2354. Unabhängig davon, ob die Lizensierungsprobleme mit PKP gelöst
  2355. werden können, wird es mit ziemlicher Sicherheit neue Versionen
  2356. von PGP geben. Wenn PKP keine Lizenz für PGP erteilt, werden
  2357. die neuen Versionen wahrscheinlich nicht mehr von mit kommen.
  2358. PGP hat zahllose Fans auch außerhalb der USA, und viele von
  2359. ihnen sind Softwareentwickler, die PGP verbessern und fördern
  2360. wollen, unabhängig davon, was ich mache. Die zweite Version von
  2361. PGP ist das Ergebnis gemeinsamer Arbeit eines internationalen
  2362. Entwicklungsteams, dem unter meiner Leitung eine Reihe von
  2363. Verbesserungen gegenüber der originalen Version gelang. Branko
  2364. Lancaster hat diese Version in Holland veröffentlicht, Peter
  2365. Gutmann in Neuseeland, außerhalb des Geltungsbereichs des
  2366. amerikanischen Patentrechts. Obwohl diese Version nur in Europa
  2367. und Neuseeland veröffentlicht wurde, verbreitete sie sich
  2368. spontan bis in die USA, ohne daß ich oder Entwicklungsteam dazu
  2369. irgend etwas beigetragen haben.
  2370.  
  2371. Das bei PGP ebenfalls verwendete blockorientierte
  2372. Verschlüsselungsverfahren IDEA unterliegt in Europa einem
  2373. Patent, das der ETH Zürich und einer Schweizer Firma namens
  2374. Ascom-Tech AG gehört. Die Patentnummer ist PCT/CH91/00117.
  2375. [Nach meiner Kenntnis können Algorithmen innerhalb der EG nicht
  2376. patentiert werden. Aber für eine endgültige Antwort wäre hier
  2377. eine JuristIn zu fragen. d.Ü.] Internationale Patente sind
  2378. angemeldet. Für die nichtkommenzielle Verwendung von IDEA
  2379. werden keine Lizenzgebühren verlangt. Die Ascom-Tech AG hat
  2380. eine Lizenz für die Nutzung von IDEA bei PGP erteilt, auch für
  2381. den kommerziellen Einsatz von PGP. Die Verwendung der IDEA-
  2382. Routinen aus PGP in anderen, kommerziellen Produkten ist ohne
  2383. eine Lizenz von Ascom Tech nicht erlaubt. Kommerzielle Anwender
  2384. von IDEA können Details zur Lizensierung bei Dieter Profoss,
  2385. Ascom Tech AG, Solothurn Lab, Postfach 151, 4502 Solothurn,
  2386. Switzerland, Tel +41 65 242885, Fax +41 65 235761, erfahren.
  2387.  
  2388. Die bei PGP verwendeten ZIP-Kompressionsroutinen stammen aus
  2389. Freeware-Quellcode und werden mit Erlaubnis des Autors
  2390. verwendet. Mir sind keine Patente bekannt, die für die
  2391. Kompressionsalgorithmen erteilt worden wären, aber Sie können
  2392. diese Frage gerne selbst genauer untersuchen.
  2393.  
  2394.  
  2395.  
  2396. Lizensierung und Vertrieb
  2397. -------------------------
  2398.  
  2399. In den USA kontrolliert PKP die Lizensierung von RSA auf der
  2400. Basis des US-Patentgesetzes. Aber ich selbst habe keinerlei
  2401. Einwände dagegen, daß jemand PGP benutzt oder weitergibt, und
  2402. ich verlangt auch keine Nutzungsgebühren. Die Copyrightvermerke
  2403. im Programm und in dieser Dokumentation dürfen nicht gelöscht
  2404. oder geändert werden. Innerhalb der USA sind damit aber nicht
  2405. unbedingt die rechtlichen Verpflichtungen erfüllt, die Sie
  2406. möglicherweise gegenüber PKP wegen der Verwendung des RSA-
  2407. Algorithmus haben.
  2408.  
  2409.  
  2410. PGP ist keine Shareware, es ist Freeware. Verbotene Freeware.
  2411. Veröffentlicht als gesellschaftliche Dienstleistung. Daß PGP
  2412. kostenlos ist, ermutigt viele Menschen, PGP auch zu verwenden,
  2413. und dies wird hoffentlich größere soziale Auswirkungen haben.
  2414. Hieraus könnte sich ein großer Bekanntheitsgrad und eine weite
  2415. Verbreitung von RSA ergeben.
  2416.  
  2417. Der gesamte Quellcode von PGP ist frei verfügbar im Rahmen des
  2418. "Copyleft" der General Public License der Free Software
  2419. Foundation. Eine Kopie der General Public License der FSF
  2420. gehört zum Programmpaket von PGP.
  2421.  
  2422. Unabhängig von General Public License, und in manchen Punkten
  2423. ihr unter Umständen widersprechend, gelten die folgenden
  2424. Bedingungen:
  2425.  
  2426. 1) Besprechungen von PGP in Zeitungen oder Büchern dürfen
  2427.   unbeschränkt Auszüge des PGP-Quellcodes und der
  2428.   Dokumentation enthalten
  2429. 2) Die General Public License läßt zwar die Verwendung von
  2430.   Programmen oder Programmteilen für andere Produkte zu, wenn
  2431.   diese Produkte ebenfalls frei und kostenlos erhältlich sind,
  2432.   untersagt aber die Verwendung in kommerziellen Programmen.
  2433.   Abweichend von dieser Regelung bin ich im Prinzip bereit,
  2434.   eine spezielle Lizenz für die Verwendung von Teilen von PGP
  2435.   in kommerziellen Produkten zu erteilen. Ob diese Lizenz Geld
  2436.   kostet, hängt von den jeweiligen Umständen ab.
  2437.   Gegebenenfalls reicht schon ein Copyrightvermerk und ein
  2438.   Quellenhinweis. In einem Telefongespräch läßt sich das
  2439.   genauer bereden. Ich bin ziemlich leicht zufriedenzustellen.
  2440.   Eine solche Lizenz enthebt Sie aber nicht der Pflicht, die
  2441.   Rechte an den Patenten zu berücksichtigen.
  2442.  
  2443. Scheuen Sie sich nicht, das vollständige PGP-Paket soweit wie
  2444. möglich zu verbreiten. Geben Sie es allen Ihrem FreundInnen.
  2445. Wenn Sie Zugang zu Mailboxen haben, stellen Sie PGP in
  2446. möglichst allen Mailboxen öffentlich zur Verfügung. Auch den
  2447. Quellcode können Sie beliebig verbreiten. Die ausführbare PGP-
  2448. Version 2.3(a) für MSDOS steht zusammen mit der Dokumentation,
  2449. einigen öffentlichen Schlüsseln, darunter mein eigener, sowie
  2450. Unterschriften unter das Programm in einer Datei namens
  2451. PGP23[a].ZIP. Das Paket mit Quellcode für MSDOS enthält alle C-
  2452. und Assemblerdateien in einer PKZIP-Datei namens PGP23src.ZIP.
  2453. Die Dateinamen ergeben sich aus der Versionsnummer.
  2454.  
  2455. Kostenlose Kopien und Updates von PGP finden Sie weltweit in
  2456. tausenden von Mailboxen und anderen öffentlich zugänglichen
  2457. Archiven, wie FTP-Servern im Internet. Mich selbst brauchen Sie
  2458. nicht nach PGP zu fragen, weil ich weitere rechtliche Probleme
  2459. mit PKP vermeiden möchte. Woher Sie PGP bekommen können, kann
  2460. ich Ihnen aber schon sagen.
  2461.  
  2462. Nach all der Arbeit an PGP möchte ich noch anmerken, daß ich
  2463. gegen Fanpost nichts einzuwenden habe, allein schon, um seine
  2464. Popularität abschätzen zu können. Teilen Sie mir mit, was Sie
  2465. von PGP halten, und wieviele Ihrer FreundInnen es verwenden.
  2466. Hinweise auf Fehler und Verbesserungsvorschläge sind natürlich
  2467. ebenfalls gerne gesehen. In künftigen PGP-Versionen werden Ihre
  2468. Anregungen möglicherweise berücksichtigt werden.
  2469.  
  2470. Das PGP-Projekt wurde nicht finanziell gefördert, und hat mir
  2471. beinahe die Haare vom Kopf gefressen. Sie dürfen deshalb nicht
  2472. mit einer Antwort auf Ihren Brief rechnen, es sei denn, Sie
  2473. legen einen frankierten Rückumschlag bei. Lieber antworte ich
  2474. auf E-Mail. Bitte schreiben Sie auf Englisch, weil meine
  2475. Fremdsprachenkenntnisse begrenzt sind. Wenn Sie mich anrufen,
  2476. und ich bin nicht da, probieren Sie am besten etwas später noch
  2477. einmal. Rückrufe auf Ferngespräche mache ich in der Regel
  2478. nicht, es sei denn, Sie akzeptieren ein R-Gespräch. Falls Sie
  2479. mich für längere Zeit brauchen: Ich stehe als Berater auf
  2480. entsprechender finanzieller Basis zu Verfügung, und antworte
  2481. auch auf derartige Anfragen.
  2482.  
  2483. Die ungelegenste Post, die ich bekomme, stammt von Menschen,
  2484. die mir in der besten Absicht ein paar Dollar schicken mit
  2485. Bitte, ihnen PGP zuzusenden. Ich mache das nicht, um
  2486. rechtlichen Problemen mit PKP aus dem Weg zu gehen. Noch
  2487. schlechter ist es, wenn so eine Anfrage aus dem Ausland kommt.
  2488. In dem Fall würde ich es riskieren, die US-amerikanischen
  2489. Gesetze über den Export von Kryptographie zu verletzen. Aber
  2490. auch wenn es keine rechtliche Auseinandersetzung um PGP gäbe:
  2491. Normalerweise reicht das Geld in so einem Brief nicht aus, um
  2492. den Zeitaufwand zu rechtfertigen, den ich mit dem Versand
  2493. hätte. Ich bin nicht darauf eingerichtet, im Nebenberuf
  2494. preiswertes Versandhaus zu spielen. Andererseits kann ich das
  2495. Geld auch nicht einfach behalten, weil es als Honorar für eine
  2496. Leistung gedacht ist. Um das Geld aber zurückzuschicken, muß
  2497. ich mich in mein Auto setzen, zum Postamt fahren, und
  2498. Briefmarken kaufen. Normalerweise kommen diese Anfragen ohne
  2499. frankierten Rückumschlag. Als nächstes muß ich mir die Zeit
  2500. nehmen, eine freundliche Antwort zu schreiben, daß ich dem
  2501. Wunsch der Absender nicht nachkommen kann. Wenn ich die
  2502. Beantwortung zurückstelle und den Brief einfach auf meinen
  2503. Schreibtisch lege, kann es passieren, das er innerhalb von
  2504. Minuten unter Papierstapeln vergraben wird, und erst Monate
  2505. später wieder ans Tageslicht kommt. Wenn Sie all diese kleinen
  2506. Unbequemlichkeiten mit der Anzahl der Anfragen multiplizieren,
  2507. wird Ihnen das Problem klar. Reicht es nicht, daß PGP nichts
  2508. kostet? Wie schön wäre es, wenn diese Leute versuchen würden,
  2509. PGP aus irgendeiner der unzähligen vorhandenen Quellen zu
  2510. beziehen. Wenn Sie kein Modem haben, fragen Sie in Ihrem
  2511. Bekanntenkreis. Wenn Sie keine Bezugsquelle finden, können Sie
  2512. mich kurz anrufen.
  2513.  
  2514. Wer immer freiwillig an der Verbesserung von PGP mitarbeiten
  2515. möchte, möge mir das mitteilen. PGP könnte weitere Arbeit
  2516. durchaus vertragen. Ein paar Optionen wurden zurückgestellt, um
  2517. PGP ohne zu große Verzögerung veröffentlichen zu können. Viele
  2518. Leute haben ihre Zeit damit verbracht, PGP auf Unix für Sun
  2519. Sparcstations, auf Ultrix, auf VAX/VMS, auf den Amiga und auf
  2520. den Atari ST zu portieren. Vielleicht können auch Sie dabei
  2521. helfen, PGP auf weitere Maschinen zu portieren. Aber schreiben
  2522. Sie mir, bevor Sie mit einer Portierung oder Verbesserung von
  2523. PGP anfangen, um doppelte Arbeit oder die Verwendung veralteter
  2524. Versionen der Quellcodes zu vermeiden.
  2525.  
  2526. Es gibt so viele fremdsprachige Übersetzungen von PGP, daß die
  2527. meisten Sprachkits nicht im Standardpaket von PGP enthalten
  2528. sind, um Speicherplatz zu sparen. Einzelne Sprachkits können
  2529. Sie aus einer großen Zahl unabhängiger Quellen beziehen. Häufig
  2530. sind es die gleichen Quellen, bei denen Sie auch das
  2531. eigentliche PGP-Paket finden. Diese Kits enthalten übersetzte
  2532. Versionen von LANGUAGE.TXT, PGP.HLP und vom Handbuch. Falls Sie
  2533. daran denken, PGP in Ihre Muttersprache zu übersetzen, setzen
  2534. Sie sich mit mir in Verbindung, damit Sie die neuesten
  2535. Informationen und Standardisierungsrichtlinien bekommen, und um
  2536. herauszufinden, ob es bereits eine Übersetzung in Ihre Sprache
  2537. gibt. Colin Plumb (colin@nyx.cs.du.edu) verwaltet eine
  2538. umfangreiche Sammlung von Sprachkits.
  2539.  
  2540. Bei künftigen Versionen von PGP kann sich unter Umständen das
  2541. Datenformat von Nachrichten, Unterschriften, Schlüsseln oder
  2542. Schlüsseldateien ändern, wenn dadurch wichtige neue Funktionen
  2543. ermöglicht werden. Daraus können sich Probleme mit der
  2544. Kompatibilität zur gegenwärtig aktuellen Version ergeben. Diese
  2545. Versionen werden möglicherweise Konvertierungsprogramme für
  2546. alte Schlüssel enthalten, aber Nachrichten, die mit alten PGP-
  2547. Versionen erzeugt wurden, werden nicht unbedingt kompatibel zu
  2548. den neuen Versionen von PGP sein.
  2549.  
  2550. Wenn Sie Zugang zum Internet haben, achten Sie auf
  2551. Ankündigungen neuer Versionen in "sci.crypt" und in der
  2552. speziellen PGP newsgroup "alt.security.pgp". Es gibt eine
  2553. mailing list namens "info-pgp", gedacht für Leute ohne Zugang
  2554. zu "alt.security.pgp". Hugh Miller moderiert info-pgp. Mit
  2555. einer Nachricht an info-pgp-request@lucpul.it.luc.edu können
  2556. Sie sich von ihm in die mailing list eintragen lassen.
  2557. Vergessen Sie nicht, Ihren Namen und Ihre Internet-Adresse
  2558. anzugeben. Wenn Sie wissen wollen, woher Sie PGP beziehen
  2559. könne, kann Hugh Ihnen eine Liste mit FTP-Servern im Internet
  2560. und Telefonnummern von Mailboxen schicken. Hugh erreichen Sie
  2561. auch unter hmiller@lucpul.it.luc.edu.
  2562.  
  2563.  
  2564.  
  2565. Exportkontrolle [auf die USA bezogen d.Ü.]
  2566. ------------------------------------------
  2567.  
  2568. Die Regierung hat schon häufig den Export guter
  2569. kryptographischer Technologie verboten, und dies Verbot kann
  2570. auch PGP betreffen. Diese Art von Programmen wird wie
  2571. Kriegswaffen behandelt. Die Rechtsgrundlage hierfür ist eine
  2572. einfache Verordnung des State Departement, kein richtiges
  2573. Gesetz. Ich selbst werde diese Art Software nicht aus den USA
  2574. oder Kanada exportieren, für den Fall, daß dies gemäß den
  2575. Verordnungnen des State Departement illegal ist, und ich
  2576. übernehme keine Verantwortung für den möglichen Export durch
  2577. andere.
  2578.  
  2579. Wenn Sie außerhalb der USA und Kanadas leben, rate ich Ihnen,
  2580. gegen diese Verordnungen des State Departement nicht dadurch zu
  2581. verstoßen, daß Sie sich PGP aus den USA besorgen. Tausende von
  2582. US-BürgerInnen haben sich PGP nach seiner ersten
  2583. Veröffentlichung besorgt, und irgendwie ist es dann aus den USA
  2584. herausgekommen, und hat sich dann wie Pusteblumen [xxx
  2585. dandelion seed] von selbst weiterverbreitet. Wenn PGP bereits
  2586. den Weg in Ihr Land gefunden hat, dann werden Sie
  2587. wahrscheinlich keine US-Exportgesetze verletzen, wenn Sie sich
  2588. PGP aus einer Quelle außerhalb der USA besorgen.
  2589.  
  2590. Einige Juristen , mit denen ich sprach, haben den Eindruck, daß
  2591. die Rahmenbedingungen der US-Exportkontrolle nicht dafür
  2592. ausgelegt wurden, auf so etwas wie kryptographische Freeware,
  2593. die sich ganz von allein verbreitet, angewandt zu werden. Es
  2594. ist schwer vorstellbar, daß ein US-amerikanischer Staatsanwalt
  2595. versucht, jemanden anzuklagen wegen des "Exportes" von
  2596. Software, die in den USA kostenlos erhältlich ist. Ich kenne
  2597. niemanden, der ein entsprechendes Beispiel nennen kann, obwohl
  2598. es eine Reihe von Verstößen gegen die Exportgesetze gibt. Ich
  2599. bin kein Jurist und gebe auch keinen juristischen Rat -- ich
  2600. versuche nur deutlich zu machen, was der allgemeinen Auffassung
  2601. entspricht. [Exakt wegen illegalen Exports kryptographischer
  2602. Technologie ermittelt der US-Zoll z.Zt. gegen Philip
  2603. Zimmermann. d.Ü.]
  2604.  
  2605. Seit Version 2.0 wird PGP nicht mehr aus den USA heraus
  2606. veröffentlicht, sondern über öffentlich zugängliche Computer in
  2607. Europa. Jede neue Version wird von PGP- und Privatsphären-
  2608. AktivistInnen in die USA geschickt, und dort auf öffentlich
  2609. zugänglichen Computern bereitgestellt. Es gibt in den USA zwar
  2610. auch Einschränkungen für den Import von Kriegswaffen, aber ich
  2611. kenne keinen Fall, in dem diese Regelung auf den Import
  2612. kryptographischer Software angewandt worden wäre. Ich denke,
  2613. daß ein Verfahren hiergegen eine recht spektakuläre Kontroverse
  2614. werden würde.
  2615.  
  2616. Einige ausländische Regierungen verhängen hohe Strafen allein
  2617. für verschlüsselte Kommunikation. In manchen Ländern kann man
  2618. dafür sogar erschossen werden. Aber wenn man in so einem Land
  2619. lebt, braucht man PGP vielleicht um so mehr.
  2620.  
  2621.  
  2622.  
  2623. Computer-orientierte politische Vereinigungen [in den USA]
  2624. ==========================================================
  2625.  
  2626. PGP ist ein sehr politisches Programm, so daß ein Hinweis
  2627. angebracht ist auf politische Gruppen, die sich mit EDV
  2628. beschäftigen. Genaueres zu diesen Gruppen, und wie sie
  2629. erreichbar sind, steht in einer eigenen Datei, die zum PGP-
  2630. Paket gehört.
  2631.  
  2632. Die Electronic Frontier Foundation (EFF) wurde im Juli 1990
  2633. gegründet, mit dem Ziel, die Freiheit des Wortes in digitalen
  2634. Medien zu verteidigen, insbesondere, um sicherzustellen, daß
  2635. die Grundsätze der Verfassung der USA und ihrer Ergänzungen
  2636. (Bill of Rights) auch bei computerbasierter Kommunikation zur
  2637. Geltung kommen. Die EFF ist in Washington DC unter der
  2638. Telefonnummer (202) 347-5400 erreichbar. Ihre Internet-Adresse
  2639. ist eff@eff.org.
  2640.  
  2641. Die Computer Professionals For Social Responsibility (CPSR)
  2642. unterstützen EDV Fachleute und AnwenderInnen, die sich für
  2643. einen verantwortungsvollen Umgang mit Informationstechnologie
  2644. einsetzen, und fördern die breite politische Auseinandersetzung
  2645. um die gesellschaftlichen Auswirkungen der
  2646. Informationstechnologie. Sie sind in Palo Alto unter der
  2647. Telefonnummer 415-322-3778 und unter der Internet-Adresse
  2648. cpsr@csli.stanford.edu erreichbar.
  2649.  
  2650. Die League for Programming Freedom (LPF) ist eine "grass-root"-
  2651. Vereinigung von ProfessorInnen, Studierenden, Geschäftleuten,
  2652. ProgrammierInnen und AnwenderInnen, die sich dem Ziel der
  2653. uneingeschränkten Freiheit bei der Programmerstellung widmen.
  2654. Die LPF sieht Patente auf Computeralgorithmen als schädlich für
  2655. die US-amerikanische Computerindustrie an. Telefon: (617) 433-
  2656. 7071. E-Mail: lpf@uunet.uu.net.
  2657.  
  2658. Genauere Informationen zu diesen Gruppen stehen in der Datei
  2659. "politic.doc". [Eine vergleichbare Datei über Gruppen aus dem
  2660. deutschen Sprachraum ist nicht in Arbeit. d.Ü.]
  2661.  
  2662.  
  2663. Empfohlene Literatur für den Einstieg in Kryptographie:
  2664. =======================================================
  2665.  
  2666. 1)  Dorothy Denning, "Cryptography and Data Security", Addison-
  2667.    Wesley, Reading, MA 1982
  2668. 2)  Dorothy Denning, "Protecting Public Keys and Signature
  2669.    Keys", IEEE Computer, Feb 1983
  2670. 3)  Martin E. Hellman, "The Mathematics of Public-Key
  2671.    Cryptography," Scientific American, Aug 1979
  2672. 4)  Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54.
  2673.    (Ein "muß" zu PGP und verwandten Themen)
  2674.  
  2675. Weitere Literatur
  2676. =================
  2677.  
  2678. 5)  Ronald Rivest, "The MD5 Message Digest Algorithm", MIT
  2679.    Laboratory for Computer Science, 1991
  2680. 6)  Xuejia Lai, "On the Design and Security of Block Ciphers",
  2681.     Institute for Signal and Information Processing, ETH-
  2682.    Zentrum, Zurich, Switzerland, 1992
  2683. 7)  Xuejia Lai, James L. Massey, Sean Murphy, "Markov Ciphers
  2684.    and Differential Cryptanalysis", Advances in Cryptology-
  2685.    EUROCRYPT'91
  2686. 8)  Philip Zimmermann, "A Proposed Standard Format for RSA
  2687.    Cryptosystems", Advances in Computer Security, Vol III,
  2688.    edited by Rein Turn, Artech House, 1988
  2689. 9)  Bruce Schneier, "Applied Cryptography: Protocols,
  2690.    Algorithms, and Source Code in C", John Wiley & Sons, 1993
  2691.    (erscheint im November)
  2692. 10) Paul Wallich, "Electronic Envelopes", Scientific American,
  2693.    Feb 1993, page 30.  (Handelt von PGP)
  2694.  
  2695.  
  2696.  
  2697. Die Adresse des Autors
  2698. ======================
  2699.  
  2700. Philip Zimmermann
  2701. Boulder Software Engineering
  2702. 3021 Eleventh Street
  2703. Boulder, Colorado 80304  USA
  2704. Telefon/Fax 303-541-0140 (10:00am - 7:00pm Mountain Time)
  2705. Internet:  prz@acm.org
  2706.  
  2707.  
  2708.  
  2709. Anhang: Bezugsquellen für PGP
  2710. ===============================
  2711.  
  2712. [Die folgenden Angaben von Bezugsquellen stammen unmittelbar
  2713. von Philip Zimmermann. Sie nicht unbedingt jetzt noch gültig,
  2714. außerdem sind andere Bezugsquellen hinzugekommen. Eine ständige
  2715. Aktualisierung einer solchen Liste würde sehr viel Arbeit
  2716. kosten. Für aktuelle Listen sei an dieser Stelle auf die
  2717. englischen FAQs, die regelmäßig in alt.security.pgp
  2718. veröffentlicht werden, sowie auf die deutschen FAQs, die in
  2719. /T-NETZ/PGP/ALLGEMEIN und in comp.security.de veröffentlicht
  2720. werden. d.Ü]
  2721.  
  2722. Im folgenden wird erläutert, wie man das Freeware-Programm PGP
  2723. von einem anonymen FTP-Server im Internet und aus anderen
  2724. Quellen bekommen kann.
  2725.  
  2726. PGP hat eine ausgeklügelte Schlüsselverwaltung, verwendet eine
  2727. Kombination von RSA und einer konventionellen Verschlüsselung,
  2728. erzeugt digitale Unterschriften, komprimiert zu verschlüsselnde
  2729. Daten, und ist sehr ergonomisch zu bedienen. PGP ist gut
  2730. ausgestattet und schnell, und es hat ein exzellentes Handbuch.
  2731. Der Quellcode ist kostenlos erhältlich.
  2732.  
  2733. PGP verwendet das Verschlüsselungsverfahren RSA, das durch ein
  2734. Patent im Besitz der Firma Public Key Partners geschützt ist.
  2735. Für PGP-AnwenderInnen außerhalb der USA sei angemerkt, daß es
  2736. nur in den USA ein Patent auf RSA gibt. Zu beachten ist, daß es
  2737. allen Personen, die in den USA und Kanada leben, aufgrund der
  2738. Exportgesetze dieser Staaten verboten ist, kryptographische
  2739. Software dieser Art zu exportieren. Wenn Sie jedoch außerhalb
  2740. der USA leben, begehen Sie wahrscheinlich keinen Verstoß gegen
  2741. das US-Exportgesetz, wenn Sie sich PGP von einer Quelle
  2742. außerhalb der USA besorgen. Beachten Sie, daß sich der Name
  2743. "PGP" aufgrund der Verhandlungen mit den RSA-Patentinhabern
  2744. bei zukünftigen Version möglicherweise ändern wird.
  2745.  
  2746. Im folgenden finden Sie eine kleine Auswahl von Stellen, an
  2747. denen Sie angeblich PGP bekommen können (Stand: Juni 1993). Für
  2748. die Richtigkeit diese Informationen gibt es keine Garantie.
  2749. Einige Einrichtungen in den USA haben PGP aus Angst vor
  2750. juristischen Einschüchterungsversuchen durch die RSA-
  2751. Patentinhaber zurückgezogen.
  2752.  
  2753. Das Standardpaket von PGP besteht aus zwei komprimierten
  2754. Dateien, wobei die Dateinamen die Versionsnummer enthalten. Die
  2755. Version 2.3a steht in der Datei "PGP23A.ZIP". Diese Datei
  2756. enthält das ausführbare Programm für MSDOS und dieses Handbuch
  2757. [im englischen Original. d.Ü.] Außerdem gibt es die Datei
  2758. "PGP23SRC.ZIP", die den Quellcode enthält. Diese Dateien können
  2759. mit PKUNZIP Version 1.10 oder neuer dekomprimiert werden. Unix-
  2760. AnwenderInnen, die keine UNZIP-Implementierung haben, können
  2761. den Quellcode auch in der komprimierter tar-Datei
  2762. pgp23src.tar.Z finden.
  2763.  
  2764. Zur Erinnerung: wählen Sie Binärübertragung, wenn Sie sich die
  2765. Dateien per FTP holen. Unter Kermit muß auf beiden Seiten die
  2766. Betriebsart "8 Bit binär" gewählt werden. Und nun eine kleine
  2767. Liste von anonymen FTP-Server, die PGP haben:
  2768.  
  2769. Finnland:        nic.funet.fi  (128.214.6.100)
  2770.                  Directory: /pub/unix/security/crypt/
  2771.  
  2772. Italien:         ghost.dsi.unimi.it  (149.132.2.1)
  2773.                  Directory: /pub/security/
  2774.  
  2775. Vereinigtes UK:  src.doc.ic.ac.uk
  2776. Königreich:      Directory: /computing/security/software/PGP
  2777.  
  2778. Falls Sie FTP nicht einsetzen können: nic.funet.fi bietet auch
  2779. "FTP-Mail-Service" an. Um PGP zu bekommen, senden Sie die
  2780. folgende Nachricht an mailserv@nic.funet.fi:
  2781.  
  2782.     ENCODER uuencode
  2783.     SEND pub/unix/security/crypt/pgp23src.zip
  2784.     SEND pub/unix/security/crypt/pgp23a.zip
  2785.  
  2786. [Der Name der Quellcodedatei varriert nach meiner Erfahrung
  2787. etwas. d.Ü.]
  2788.  
  2789. Spätestens 24 Stunden später haben Sie in Ihrem Postfach ca. 15
  2790. UU-codierte Nachrichten, aus denen Sie mit UUDecode die beiden
  2791. *.zip-Dateien erhalten.
  2792.  
  2793. In den USA finden Sie PGP in unzähligen Mailboxen. Gott allein
  2794. weiß, in wievielen. Es sind mehr, als hier aufgeführt werden
  2795. können. Falls Sie keine Telefonnummern von Mailboxen an Ihrem
  2796. Wohnort kennen, hier eine kleine Auswahl:
  2797.  
  2798. GRAPEVINE BBS in Little Rock, Arkansas, hat einen speziellen
  2799. Pseudoaccount eingerichtet, über den man kostenlos PGP "saugen"
  2800. kann. Der Sysop ist Jim Wenzel <jim.wenzel@grapevine.lrk.ar.us>
  2801. Die folgenden Telefonnummern sollten Sie in der Reihenfolge
  2802. ausprobieren, in der sie aufgeführt sind (an der ersten Nummer
  2803. ist das schnellste Modem): (501) 753-6859, (501) 753-8121,
  2804. (501) 791-0124. Als Username geben Sie "PGP USER" an; als
  2805. Paßwort "PGP".
  2806.  
  2807. PGP hat auch im Fido-Netz weite Verbreitung gefunden. PGP
  2808. werden Sie in vielen US-amerikanischen und ausländischen Fido-
  2809. Boxen finden.
  2810.  
  2811. In Neuseeland können Sie die folgende (wahrscheinlich kostenlos
  2812. arbeitende) Mailbox anrufen:
  2813.  
  2814. Kappa Crucis:  +64 9 817-3714, -3725, -3324, -8424, -3094,
  2815. -3393
  2816.  
  2817. Quell- und Maschinencode von PGP können Sie auch von der
  2818. öffentlich zugänglichen Bibliothek des Kanadischen Rundfunk
  2819. (Canadian Broadcasting Corporation) bekommen. Die Bibliothek
  2820. hat Zweigstellen in Toronto, Montreal und Vancouver. Für
  2821. weitere Fragen können Sie sich an Max Allen, Tel. +1 416 205-
  2822. 6017, wenden.
  2823.  
  2824. Zu Informationen zu PGP-Implementierungen für den Apple
  2825. Macintosh, den Commodore Amiga, den Atari ST können Sie Hugh
  2826. Miller <hmiller@lucpul.it.luc.edu> fragen. Er kann Ihnen
  2827. wahrscheinlich auch bei der Frage weiterhelfen, für welche
  2828. anderen Rechner und Betriebssysteme es bereits PGP gibt.
  2829.  
  2830. Hier die E-Mail-Adressen oder Telefonnummern einiger Personen,
  2831. die Sie fragen können, wo es PGP in einem bestimmten Land gibt:
  2832.  
  2833. Peter Gutmann                 Hugh Kennedy
  2834. pgut1@cs.aukuni.ac.nz         70042.710@compuserve.com
  2835. Neuseeland                    Deutschland
  2836.  
  2837. Branko Lankester              Miguel Angel Gallardo
  2838. lankeste@fwi.uva.nl           gallardo@batman.fi.upm.es
  2839. +31 2159 42242                (341) 474 38 09
  2840. Holland                       Spanien
  2841.  
  2842. Hugh Miller                   Colin Plumb
  2843. hmiller@lucpul.it.luc.edu     colin@nyx.cs.du.edu
  2844. (312) 508-2727                Toronto, Ontario, Canada
  2845. USA
  2846.  
  2847. Jean-loup Gailly
  2848. jloup@chorus.fr
  2849. Frankreich
  2850.  
  2851. Drei weitere Adressen in der BRD
  2852. Marc Aurel <4-tea-2@hit.zer.de>
  2853. Christopher Creutzig <c.creutzig@hot.gun.de>
  2854. Abel Deuring <a.deuring@bionic.zer.de>
  2855.  
  2856.  
  2857.