-----BEGIN PGP SIGNED MESSAGE----- *** PGP-FAQ.de Version v0.9a vom 1. Juni 1994 FAQ-Verwalter Marc Aurel <4-tea-2@HIT.zer.de> FAQ-Stammbrett /T-NETZ/PGP/ALLGEMEIN Mit "(*)" markierte Abschnitte sind neu oder seit der letzten Ausgabe der FAQ verändert worden. *** Wichtiger Hinweis: Diese FAQ kann und will nicht die PGP-Anleitung ersetzen. Wer PGP sinnvoll, richtig und *verantwortungsvoll* einsetzen will, wird nicht um das Durcharbeiten der Anleitung herumkommen. Oder, mit den Worten aus "README.DE": >>> DIES ZUERST LESEN Pretty Good Privacy Version 2.3a Anmerkungen von Perry Metzger Überarbeitet für Version 2.3a von Colin Plumb Übersetzt von Abel Deuring Dies ist die README-Datei für PGP 2.3a. PGP (Pretty Good Privacy - Prima Geschützte Privatsphäre) ist ein Verschlüsselungsprogramm, das mit öffentlichen Schlüsseln arbeitet. Mit PGP können Sie Nachrichten, die Sie mit E-Mail oder Diskette versenden, vor unerlaubtem oder unerwünschtem Mitlesen schützen, und Sie können Nachrichten unterschreiben, so daß die EmpfängerInnen dieser Nachrichten sicher sein können, daß Sie der/die AbsenderIn sind. Die Dateien "pgpdoc1.doc" und "pgpdoc2.doc" enthalten das englische Original des Handbuches; die Dateien "pgpdoc1.de" und "pgpdoc2.de" die deutsche Übersetzung. Bevor Sie PGP verwenden, LESEN SIE BITTE DIESE HANDBÜCHER! Immer mehr Menschen benutzen ein Programm, ohne vorher das Handbuch zu lesen. Bei Verschlüsselungsprogrammen schleichen sich aber sehr leicht Bedienungsfehler ein, die zu einem hohen Verlust von Sicherheit führen können! Eine Kette ist nur so stark wie ihr schwächstes Glied. Die bei PGP verwendeten sicherheitsrelevanten Algorithmen gehören zu den sichersten, die öffentlich bekannt sind. Es gibt aber einige Sicherheitsaspekte, die PGP ebensowenig alleine lösen kann, wie auch ein guter Tresor sicher ist, wenn man vergißt, die Tür zu schließen oder zu verriegeln. Auch wenn Sie schon das Prinzip öffentlicher Schlüssel kennen, sollten Sie das Handbuch lesen, um mit den Mechanismen vertraut zu werden, die PGP für die Sicherung des Nachrichtenaustausches bietet. <<< Die deutsche Übersetzung der Anleitung stammt von Abel Deuring und Christopher Creutzig . Zusammen mit der Hilfedatei de.hlp von Helmut Fligge und dem deutschen language.txt sollte die Anleitung als komplettes "Language-Kit" in Kürze überall dort verfügbar sein, wo auch PGP als solches vorhanden ist. Siehe auch: "Wo bekomme ich PGP?". *** Was ist PGP? PGP ist ein Verschlüsselungsprogramm, das auf vielen verschiedenen Plattformen (z.B. DOS, verschiedenste Unixe, VAX/VMS, IBM Mainframes, Macintosh, AMIGA, Archimedes) implementiert und auf diversen Computernetzen zum de-facto-Standard geworden ist. Auch auf dem Z-Netz laufen Bestrebungen, PGP zum Standard werden zu lassen. Die von PGP verwendeten Verschlüsselungsverfahren erlauben einen *extrem* sicheren Nachrichtenverkehr. So sicher, daß niemand es bisher geschafft hat, ein Verfahren zu entwickeln, mit dem man die Nachrichten entschlüsseln kann, jedenfalls niemand, der davon erzählen dürfte. Das besondere an PGP ist, daß man den Empfänger der Nachricht niemals getroffen haben muß, um ihm verschlüsselte Nachrichten schicken zu können. Traditionelle Verschlüsselungstechniken benutzen einen einzigen Schlüssel. Zwei Leute treffen sich und vereinbaren diesen Schlüssel, beide benutzen ihn sowohl zum Kodieren, als auch zum Dekodieren. PGP beherrscht die konventionelle Verschlüsselung mit *einem* Paßwort, aber außerdem auch das ,Public Key-Verfahren', bei dem *jeder* Absender Nachrichten mit dem öffentlich verfügbaren ,Public Key' des Empfängers verschlüsseln, aber *nur* *dieser* sie (mit Hilfe seines privaten Schlüssels) wieder entschlüsseln kann. Nur er, niemand sonst. Nicht einmal der Absender. Die Verwaltung eingehender öffentlicher Schlüssel in einer Schlüsseldatei übernimmt PGP selbständig. Ein kleine Hürde stellt dabei der Teil der Schlüsselpflege dar, den PGP nicht alleine erledigen kann. Darunter fallen Fragen wie: Bei welchem Schlüssel kann ich *wirklich* 100% sicher sein, daß er zum angegebenen Besitzer gehört, weil ich ihn persönlich kenne und seinen Schlüssel mit ihm verglichen habe? Welchem Benutzer vertraue ich soweit, daß ich von ihm beglaubigte Schlüssel ohne eigene Prüfung als echt akzeptiere? *** Warum sollte man überhaupt verschlüsseln? Aus dem gleichen Grund, aus dem man nicht die ganze Schneckenpost auf Postkarten verschickt, sondern auch mal einen verschlossenen Umschlag benutzt. * "Ich habe nichts zu verbergen." Wer einige Zeit am Netzleben teilnimmt, stellt oft fest, daß er verblüffend intensive Beziehungen zu Menschen aufnimmt, die er nie gesehen hat. Während einer längeren Unterhaltung per PM entwickelt sich in der Regel eine gewisse Vertrautheit, möglicherweise bis zu einem Grad, wo man dem Gegenüber Informationen geben will, die man nicht ,jedermann' geben würde. Dabei muß es sich nicht um sexuelle oder kriminelle Geständnisse handeln, schon das eigene monatliche Einkommen wird von vielen als ,vertrauliche Information' angesehen. In vielen Mailboxen ist daher die Verschlüsselung von PMs innerhalb des Systems üblich. Pointpuffer z.B. landen dagegen vollkommen ,ungeschützt' auf der Festplatte des Mailboxbetreibers. * "Mir spioniert doch niemand hinterher!" Verschlüsselung schützt nicht nur vor dem absichtlichen Ausspähen von Daten, sondern auch vor ,Mißgeschicken'. Der ,böse Sysop', der sich alle privaten Nachrichten, die durch sein System laufen, in eine Extradatei kopiert und diese (masturbierend) nach Intimitäten durchforstet ist hoffentlich nur ein Gedankenspiel. Nachrichten, die beim falschen Empfänger ankommen oder als ,unzustellbar' in einem Extrabrett landen, von wo aus sie oft vom Sysop manuell weitergeleitet werden, sind dagegen ein alltägliches Phänomen. Denkbar sind Horror-Szenarien wie: - eine Mailbox wird von staatlicher Seite aus irgendwelchen Gründen geschlossen, der Rechner beschlagnahmt, vorhandene Netzpuffer ausgewertet. Jeder überlege für sich selbst, ob er wirklich noch nie eine PM geschrieben hat, die - in den Augen eines ,Belastungsmaterial prüfenden' Gesetzeshüters - einen falschen oder gar zutreffenden Verdacht auf ihn lenken könnte... Schließlich leben wir in einem Land, in dem Benutzer von High-Speed-Modems genauso gern verfolgt werden wie Falschparker oder Konsumenten weicher Drogen. - eine Mailbox-Festplatte wird verkauft, aber nicht so gelöscht, daß die Teile der darauf enthaltenen Daten nicht restauriert werden können. - ein Sysop kann seine Telefonrechnung nicht mehr bezahlen, die Beitreibungsstelle pfändet seinen Computer und versteigert ihn. All dies sind Möglichkeiten, wie Daten, die wir bei genauem Nachdenken durchaus als ,vertraulich' einstufen würden, in falsche Hände geraten könnten. Aber es gibt auch einen politischen Aspekt: in den Vereinigten Staaten ist eine heiße Diskussion über ein staatlich verordnetes Verschlüsselungsverfahren (,Clipper') ausgebrochen, das als besonderes ,Feature' die Entschlüsselung _jeder_ Datei durch Regierungsbehörden zuläßt. Mit PGP haben wir die Möglichkeit, in den Netzen Europas Fakten zu schaffen, bevor die Regierungen auf die Idee kommen, uns mit Restriktionen zu belegen. *** Was kostet PGP? PGP ist Freeware, kostet also keinen Pfennig. Wenn wir über den großen Teich schauen, stellt sich die Situation etwas anders dar: in den USA (und in Mexiko, evtl. in Kanada, ganz sicher nicht in Europa!) ist ein Teil von PGP, nämlich das RSA- Verfahren, durch nationales Patentrecht geschützt. *** Was ist RSA? Was ist ein Public Key-Verfahren? Beim RSA-Verfahren, benannt nach den Entwicklern Rivest, Shamir und Adleman, wird pro Benutzer ein Schlüsselpaar generiert, bei dem die eine Hälfte praktisch nicht aus der anderen Hälfte errechnet werden kann. Trotzdem kann eine Information, die mit einer Hälfte verschlüsselt wurde, ausschließlich mit der anderen Hälfte wieder entschlüsselt werden. Der Vorteil dieses Verfahrens liegt darin, daß man eine Hälfte des Schlüssels als Private Key unter Verschluß halten, die andere als Public Key jedoch unter die Leute bringen kann. Jeder, der Deinen Public Key hat, kann Dir eine verschlüsselte Nachricht schicken, ohne vorher mit Dir auf einem abhörsicheren Weg einen gemeinsamen Schlüssel zu vereinbaren. * Wie funktioniert RSA? >>> Christopher Creutzig : Zur Frage ,,wie funktioniert RSA'' kann ich etwas beitragen. :-)) \def\Hinweis{mathematisch und eigentlich unwichtig :-)} phi(x) sei die Eulersche Phi-Funktion, die die Anzahl der n aus N bezeichnet, die kleiner als x und mit x teilerfremd sind. Ist nicht weiter wichtig, Interessant ist nur, daß für zwei Primzahlen p und q gilt: phi(p*q)=(p-1)*(q-1). Es gilt _ _ a^(phi(z)) = 1 (mod z) [ = bedeutet: ,kongruent modulo' ] (Primzahltheorie, Beweis habe ich nicht da.) also auch: _ a^(phi(z)+1) = a (mod z) (a>> Peter Simons : I uploaded the archive containing the german full documentation to the 'Aminet'. You can get a copy via anonymous FTP from one of these servers: USA (MO) ftp.wustl.edu 128.252.135.4 pub/aminet/ USA (TX) ftp.etsu.edu 192.43.199.20 pub/aminet/ USA (CA) ftp.cdrom.com 192.153.46.2 pub/aminet/ Scandinavia ftp.luth.se 130.240.18.2 pub/aminet/ Germany ftp.uni-kl.de 131.246.9.95 pub/aminet/ Germany ftp.uni-erlangen.de 131.188.1.43 pub/aminet/ Germany ftp.cs.tu-berlin.de 130.149.17.7 pub/aminet/ Germany ftp.th-darmstadt.de 130.83.55.75 pub/aminet/ Germany ftp.uni-paderborn.de 131.234.2.32 pub/aminet/ Germany ftp.uni-oldenburg.de 134.106.40.9 pub/aminet/ Switzerland ftp.eunet.ch changing pub/aminet/ UK src.doc.ic.ac.uk 146.169.2.1 pub/aminet/ as pub/aminet/util/crypt/PGP_german_docs.lha. * Oder per Download: OS Server Telefon Login Pfad diverse BIONIC 0521-68000 Username: PGP PM DOS HIT 0681-399426 Username: SAUGER /BINAER/SAUGER diverse IUS 0203-871666 ? /!US-LOKAL/RECHNER/IBM/SOFTWARE/ PGP * Oder per Fido-File-Request: Node Netz Telefon Dateiname Beschreibung 2:247/175 Classic 06131-625630 PGP23A.ZIP PGP für Dos 2:243/4801 Light 02335-73800 PGP20OS2.ZIP PGP für OS/2 2:2490/1836 Light 0911-262539 PGP23AD.ZIP PGP für DOS PGP23OS2.ZIP PGP für OS/2 PGP23A.TAZ PGP-Sourcen * //FoeBuD-Werbefläche: >>> //padeluun : Zu Philip Zimmermann und PGP noch drei Anmerkungen: 1.) Der FoeBuD e.V. hat eine deutschsprachige PGP-Anleitung verlegt, die als 'Betaversion' für 20 DM zu erhalten ist (bitte angeben ob DOS- oder AMIGA-Diskette gewünscht ist) bei: FoeBuD e.V. Marktstr. 18 33602 Bielefeld bitte Scheck über 20 DM beilegen (Bargeld geht natürlich auch). Übersetzt wurde die Anleitung von PGP von Christopher Creutzig und Abel Deuring. 2.) Der FoeBuD hat auch ein Spendenkonto eingerichtet, auf dem Spenden für den Anwalt Philip Zimmermanns in Deutschland gesammelt werden, die dann in jeweils einer Überweisung in die USA geschickt werden. Kontoinhaber : FoeBuD e.V. Bank : Sparkasse Bielefeld Kontonummer : 2134187 Bankleitzahl : BLZ 480 501 61 Ein Zahlungsgrund braucht nicht angegeben werden, weil dieses Konto ausschließlich für diesen Zweck eingerichtet worden ist. 3.) In der BIONIC existiert ein Account namens 'PGP' , über den PGP 'gesaugt' werden kann. Telefonnummer: 0521-68000 (ISDN 0521-9680869) Einfach im Postfach INHALT * eingeben. Es gibt dort auch Zusatzprogramme und Anleitungen, wie PGP einfach in CrossPoint eingebunden werden kann. <<< >>> Abel Deuring : - - Terminalprogramm starten. - - Das Modem die Nummer 0521-68000 wählen lassen und den Verbindungsaufbau abwarten - - Einloggen als User "PGP". Ein Paßwort wird nicht abgefragt. - - aktuelle Inhaltsangabe des Postfachs mit dem Befehl "i *" lesen z.Zt. vorhanden; Nr. ST Kb Typ Kost Datum AbsenderIn Betreff 15 EG 9 >TE 0 17.04 A.DEURING PGP in XP (Hilfestellung) 14 EG 3 >TE 0 15.03 A.DEURING zu PGP23de.zip 13 EG 111 >BI 0 15.03 A.DEURING PGP23DE.ZIP deutscher Sprachkit für 12 EG 3 TE 0 03.03 FOEBUD Unterstützen Sie unsere Messe-Präsen 11 EG 1 >TE 0 18.01 A.DEURING Zu XP-PGP01.ARJ 10 EG 16 >BI 0 18.01 A.DEURING XP-PGP.ARJ - automatisches Einbinden 9 EG 67 >BI 0 09.01 PADELUUN@B SECDRV10.ZIP (Partitionen verschlüss 8 EG 1 TE 0 08.01 ST.KURTZ zu pgpAmiga 7 EG 335 BI 0 08.01 ST.KURTZ pgpAmiga2_3a.lha 6 EG 56 >BI 0 01.01 C.CARSTENS PWF11.ZIP - PGP WinFront (Frontend f 5 EG 19 >TE 0 20.11 4-TEA-2@HI PGP-OAQ 4 EG 535 BI 0 02.11 RENA PGP23aSR.zip 3 EG 1 TE 0 02.11 RENA pgpkurz.doc 2 EG 64 BI 0 02.11 RENA pgpshe22.zip 1 EG 217 >BI 0 02.11 PADELUUN@B pgp23a.zip (Public Key Verschlüsselu Für den Download der deutschen Doku (z.Zt. Nachricht Nr. 13) gibt man den Befehl: "lesen 13". Danach fragt die Box nach dem gewünschten Übertragungsprotokoll. Zur Auswahl stehen u.a. XModem und ZModem. Ein Protokoll auswählen, das auch beim Terminalprogramm implementiert ist, danach bei Terminalprogramm das Übertragungsprotokoll starten. (das machen manche Programme auch automatisch - zumindest bei ZModem.) Nach Ende der Übertragung findet man die Daten in einer Datei namens "pgp23de.zip" auf dem eigenen Rechner. Der Dateiname wird während der Übertragung von den meisten Terminalprogrammen auch am Bildschirm angezeigt - ggf. aufschreiben! In welchem Verzeichnis die Datei liegt, hängt von Terminalprogramm, Rechnertyp, Betriebssystem und diversen Einstellungen von Rechner und Betriebssystem ab - Bei Schwierigkeiten muß man die Doku über die verwendete Software lesen. Im Prinzip ist es bei einem Terminalprogramm auch denkbar, daß man den Dateinamen, unter dem die übertragenen Daten abgelegt werden, auch festlegen kann oder muß. Befragt hierzu die Dokumentation Eures Terminalprogramms. Wenn man alle gewünschten Daten übertragen hat, mit dem Befehl "logout" von der Box "verabschieden". Obige Anleitung gilt für Binärnachrichten (erkennbar an den Zeichen "BI" hinter der Längenangabe). Textnachrichten (erkennbar an den Zeichen "TE" hinter der Längenangabe) werden nach dem Befehl "lesen 5" direkt von der Box an den eigenen Rechner übertragen und auf dem Bildschirm ausgegeben. Wenn man diese Daten speichern möchte, muß man die "Log-Option" des Terminalprogramms, also das Protokollieren der Daten, die über den Bildschirm laufen, beim eben diesem Terminalprogramm einschalten. <<< *** Hey! Wieso schrieb //padeluun etwas von einem Spendenkonto? >>> Abel Deuring (als Übersetzer): Spendenaufruf ============= Am 14. September 1993 erhielt die Firma LEMCOM Systems (ViaCrypt) aus Phoenix, Arizona, eine Vorladung des Distriktsgerichts von Nordkalifornien. LEMCOM Systems wurde darin aufgefordert, vor einer "Grand Jury" eine Zeugenaussage zu machen, und Dokumente herauszugeben, die "ViaCrypt, PGP, Philip Zimmermann, und jede andere Person oder Institution, die im Interesse von Philip Zimmermann in der Zeit von 1. Juni 1991 bis heute arbeiteten herauszugeben." Philip Zimmermann wurde mitgeteilt, daß er der Hauptverdächtige in einem Ermittlungsverfahren ist, das vom US-Zollamt in San Jose durchgeführt wird. Ob es weitere Verdächtigte gibt, ist nicht bekannt. Die entstehenden Kosten für Philip Zimmermann werden astronomisch sein, unabhängig davon, ob es nun zu eine Anklage kommt oder nicht. Falls es zu einem Prozeß kommt, wird dies einer der wichtigsten Prozesse sein, die in letzter Zeit um Kryptographie, um den effizienten Schutz des Briefgeheimnisses und um den freien Fluß von Informationen und Ideen im Cyberspace nach Ende des kalten Krieges geführt wurden. Dieser Prozeß wird von großer Bedeutung sein, sowohl für diejenigen von uns, die sich für die Idee des effektiven Schutzes der Privatsphäre im Kommunikationsbereich einsetzen, als auch für Philip, dem eine Haftstrafe droht für seine uneigennützige und erfolgreiche Entwicklung von "Kryptographie für die Allgemeinheit", auch als PGP bekannt. Exportbeschränkungen müssen dafür herhalten, die Verfügbarkeit von effektiver kryptographischer Technologie zu beschneiden: Der Zoll vertritt die Auffassung, daß die Veröffentlichung eines kryptographischen Programms im Internet mit seinem Export gleichzusetzen ist. Philip hat als erster keine Risiken und Mühen gescheut, wirklich effektive Werkzeuge zu entwickeln, die unserer Kommunikation den Schutz vor neugierigen Augen geben, und das in einer politischen Situation, in der dieser Schutz immer größeren Anfeindungen ausgesetzt ist, in einer Situation, in der die US- Regierung mit Clipper Chips und Gesetzentwürfen zum digitalen Telefon auf unsere Sorgen und Befürchtungen antwortet. [Der Clipper Chip dient der Verschlüsselung von Daten und Telefongesprächen. Er ist so konstruiert, daß Regierungsbehörden in der Lage sind, alle clipper- verschlüsselten Daten zu entschlüsseln. d.Ü.] Die Zeit ist gekommen, daß wir alle die Last mit Philip teilen. Philip baut ein Verteidigungsteam auf, um sich auf einen Prozeß vorzubereiten, und er braucht dazu Ihre Hilfe. Der Prozeß wird eine teure Angelegenheit werden, und die Zeit läuft schon. Ich rufe alle, in den USA und anderswo, auf, Philips Verteidigung zu unterstützen und vielleicht einen bahnbrechenden Präzedenzfall zu schaffen. Philips Anwalt in Boulder hat einen Verteidigungsfond eingerichtet. Spenden werden in jeder Form (Scheck, Zahlungsanweisung, telegrafischer Transfer) und in jeder Währung angenommen. Schecks und Zahlungsanweisungen sollten NICHT für Philip Zimmermann ausgestellt werden, sondern für seinen Anwalt, Philip Dubois. Seine Adresse ist: Philip Dubois 2305 Broadway Boulder, CO USA 80304 (Phone #: 303-444-3885) Überweisungen können auf folgendes Konto erfolgen: Bank: VectraBank Routing #: 107004365 Account #: 0113830 Account Name: "Philip L. Dubois, Attorney Trust Account" Falls nach Abschluß des Verfahrens Geld übrig bleibt, wird es an die SpenderInnen entsprechend ihrem Beitrag zum Fond anteilig zurückgezahlt. Sie können anonym spenden, oder auch aber, aber BITTE - spenden Sie reichlich. Wenn Sie die Ziele, für die PGP steht, und die Ideen, die seine Entwicklung anregten, bewundern, drücken Sie Ihre Unterstützung durch einen Beitrag zu diesem Fond aus. Hugh Miller Anmerkung der Übersetzer: PGP ist ein hoch professionell geschriebenes Programm, das kostenlos ist. Freeware von vergleichbarer Qualität und vergleichbarem Verbreitungsgrad ist sehr selten. Wir möchten deshalb alle NutzerInnen von PGP auffordern, zu überlegen, was sie für die Registrierung eines Sharewareprogramms vergleichbarer Qualität zahlen würden, oder wieviel Geld sie für ein vergleichbares Produkt, das es nur gegen Geld gibt, zahlen würden. Diesen Betrag sollten sie dann Philips Anwalt überweisen. (Wobei mehr Geld natürlich auch nicht falsch ist...) [Die Anregung für diese "Bemessungsgrundlage" stand irgendwann mal in /T-NETZ/PGP/ALLGEMEIN. Leider erinnern wir uns nicht mehr, von wem sie stammt...] [von mir, glaub ich ;) ] Auslandsüberweisungen sind sehr teuer. Der FoeBuD e.V. (Verein zur Förderung des beweglichen und unbeweglichen Datenverkehrs, Bielefeld, Marktstr. 18) hat deshalb ein Spendenkonto zur Unterstützung von Philip Zimmermann eingerichtet. Überweisungen, die auf diesem Konto eingehen, werden in regelmäßigen Abständen auf das oben genannte Konto von Philip Dubois weitergeleitet. Die Daten des Konto: FoeBuD e.V. Sparkasse Bielefeld Kontonummer 2134187 BLZ 48050161 <<< [Man kann's gar nicht oft genug erwähnen...] *** Was sollen die kryptischen Datenpakete in Brettern? >>> Hauke Lampe : Geek-Code. So eine Art einzeilige Personenbeschreibung. <<< [War nur ein Witz! Aber tatsächlich fragen in /T-NETZ/PGP/ ALLGEMEIN überdurchschnittlich viele Leute nach den Geek-Code-Zeilen in den Signatures mancher Autoren, möglicherweise weil sie sie für mutierte Unterschriften oder Fingerabdrücke (s.u.) halten. ;) ] In allgemein zugänglichen Brettern (newsgroups / areas) machen verschlüsselte Texte wenig Sinn. In diesem Fall handelt es sich in der Regel um öffentliche Schlüssel oder Unterschriften unter Nachrichten. Ein Schlüssel sieht etwa so aus (ohne ,>'-Quotezeichen): > ----BEGIN PGP PUBLIC KEY BLOCK---- > Version: 2.3a > > FQUtPiP9EfSASAPDEKifNIF2UN244R518X264K051G6F8HT/As30Q5rYSB22/tOR > ALBcTSNkG4vAgDi5ZzwgurkogiUHm8XwgaroZZniuZSALiWf1EUzj5t9wG23Fq4C > SgIP4C42ly/ffbVWwwAFEbQhTWFyYyBBdXJlbCA8NC10ZFuhukBib25nLnNhYXIu > ZGU+iQB1AgUQLNzCrzaXL666tVbDAQGUjwL8DyJ32h+Ym4+6L9FEz2t64YaHozna > ZT4= > ----END PGP PUBLIC KEY BLOCK---- * Wozu sind ,Unterschriften' gut? >>> Abel Deuring : Der Austausch verschlüsselter Nachrichten soll Sicherheit bieten, insbesondere natürlich Sicherheit davor, daß außer AbsenderIn und EmpfängerIn noch andere die Nachricht lesen können. Ebenso sollte aber auch für die EmpfängerIn sichergestellt sein, daß eine Nachricht wirklich "echt" ist, daß sie also wirklich von der Person stammt, die als AbsenderIn angegeben ist. Bei einer Verschlüsselung, die mit Paßworten arbeitet, ist diese Sicherheit dadurch gegeben, daß (hoffentlich) nur AbsenderIn und EmpfängerIn das vereinbarte Paßwort kennen. Wenn aber ein PGP-Schlüssel öffentlich bekannt gegeben wird, kann (und soll!) er von allen Personen benutzt werden, die der BesitzerIn des Schlüssels Nachrichten schicken möchten. Dann kann es aber passieren, daß jemand eine falsche Absenderangabe erzeugt, und mit dieser gefälschten Angabe eine PGP-verschlüsselte Nachricht verschickt. Die EmpfängerIn einer Nachricht kann die Echtheit einer Nachricht kontrollieren, wenn die Nachricht "unterschrieben" wird: <<< Eine Unterschrift unter einer Nachricht kann nur vom Besitzer des privaten Schlüssels erzeugt, aber von jedem, der den passenden öffentlichen Schlüssel in seiner Schlüsseldatei hat, überprüft werden. Weil es praktisch unmöglich ist, die digitalen Unterschriften, die PGP erzeugt, zu fälschen, kann damit sichergestellt werden, daß eine Nachricht wirklich von dem angegebenen Absender stammt und nicht manipuliert wurde. * Wie lasse ich den Klartext beim Unterschreiben im Klartext? Wenn PGP eine Nachricht unterschreibt, packt es sie ganz in eine Versandhülle ein. Der Vorteil: es besteht keine Gefahr, daß Umlautwandlungen o.ä. die Unterschrift ungültig werden lassen und so eventuell ungerechtfertigt den Verdacht erwecken, daß sie manipuliert worden sei. Der Nachteil: ohne PGP ist sie nicht lesbar. Die Lösung: die abgetrennte Unterschrift (,Clearsig'). Unterzeichnete Nachrichten beginnen damit mit einer Zeile, die so aussieht: ----BEGIN PGP SIGNED MESSAGE---- Es folgt der Klartext (für jeden lesbar), die Unterschrift findet man in einem Extraabschnitt unter der Nachricht. Um diese abgesetzte Unterschrift zu erzeugen, sollte im CONFIG.TXT des Absenders ClearSig = on erscheinen oder, alternativ, die zum Unterschreiben verwendeten Befehlszeile so lauten: pgp -sat +clearsig=on blafasel.txt * Warum sind meine abgetrennten Unterschriften immer ,bad'? Wahrscheinlich benutzt Du PGP v2.3 für DOS. Diese Version hat mehrere Fehler, es wäre sinnvoll, wenn Du Dir v2.3a besorgen würdest. *** Warum stürzt PGP manchmal aus unerklärlichen Gründen ab? * DOS-Version: s.o. * AMIGA-Version: >>> Peter Klein : Große Programme wie PGP können auf Amigas abstürzen, wenn die Stackgröße für das Programm zu klein gewählt wird. Die Stackgröße sollte mindestens 20000 Byte sein (System-Voreinstellung sind 4096 Bytes). Das geschieht mit dem Befehl "stack 20000" (wer hätte das gedacht :-)) <<< *** Die Liste der wichtigsten PGP-Befehle: * Schlüsselmanagement: PGP -kg Erzeugen eines eigenen Schlüsselpaares Diesen Befehl braucht man hoffentlich nur ein einziges Mal. Siehe auch: "Wie gehe ich mit Schlüsseln um?" PGP -ka Öffentlichen Schlüssel aus Datei zur eigenen Schlüsseldatei hinzufügen PGP -kv Anzeigen der öffentlichen Schlüssel, die ID entsprechen PGP -kv Anzeigen aller öffentlichen Schlüssel der Schlüsseldatei PGP -kvv Anzeigen der Schlüssel samt Unterschriften PGP -kxa Extrahieren des öffentlichen Schlüssels von ID in Datei Dieser Befehl wird benötigt, um einen einzelnen Schlüssel an andere weiterzugeben. Der Schlüssel kann der eigene sein, oder auch ein fremder, den man eventuell mit er eigenen Unterschrift als echt beglaubigt hat. * Ver-/Entschlüsselungsfunktionen: PGP Datei entschlüsseln und/oder Unterschrift überprüfen PGP -sta +clearsig=on Klartext-Nachricht unterschreiben PGP -esa Datei unterschreiben und an ID verschlüsseln Für muß nicht die volle Benutzer-ID angegeben werden. PGP sucht nach Schlüsseln, deren Benutzer-IDs den als angegebenen Text enthalten. Bei kv und kxa benutzt PGP alle passenden Schlüssel. Beim Verschlüsseln oder Unterschreiben benutzt PGP den ersten passenden Schlüssel, man muß also selbst sicherstellen, daß man den Empfänger eindeutig angibt. Schlüssel können auch über ihre Schlüssel-ID ausgewählt werden. Dabei gibt man die (hexadezimale) ID (oder einen Teil davon) nach dem Präfix '0x' an. Beispiel: PGP -kv 0xB556C3 * Undokumentierte Funktionen: PGP [...] -z"" Angabe des Mantras auf der Befehlszeile PGP -km "Maintainance pass" PGP [...] -l Ausführliche Ausgabe anschalten (verbose=2) *** Was ist bei der Schlüsselerzeugung zu beachten? Ein eigenes Schlüsselpaar generiert man mit: PGP -kg * Länge: Die meisten PGP-Benutzer wählen einen 1024-bit-Schlüssel (military grade), auch wenn die Verschlüsselung abhängig vom verwendeten Rechner spürbar länger dauern kann. Von einem 384-bit-Schlüssel (casual grade) sollte man absehen. * Pass Phrase: Die ,Pass Phrase', die PGP während der Schlüsselerzeugung abfragt, soll den privaten Schlüssel vor fremdem Zugriff schützen. Wie für die meisten Paßwörter gilt auch für dieses, daß es nicht leicht zu raten sein sollte. Im Gegensatz zu vielen anderen Paßwörtern gibt es bei diesem Paß-*Satz* praktisch keine Längenbeschränkung. Berühmte Zitate eignen sich weniger, statt dessen sollte man eine Mischung aus Sonderzeichen, Ziffern und Text und wählen, z.B.: $Clark42Kent--Fuppes(FloedelDoe( Aber selbst bei der aller-aller-sichersten ,Pass Phrase' muß man immer noch darauf achten, daß möglichst niemand auf die Datei Zugriff hat, in der der private Schlüssel steht. * Benutzer-ID: PGP-Schlüssel werden in der Regel weiterverteilt und landen u.U. auf einem Internet-Keyserver. Man sollte deshalb darauf achten, eine eindeutige Benutzer-ID zu verwenden, die außerdem die Mail-Adresse enthält. Es reicht nicht aus, wenn die Benutzer-ID "Helmut in der LINK- MZ" lautet. In eine Benutzer-ID gehört der Name des Schlüsselinhabers und eine so weit wie möglich erreichbare Mail-Adresse, z.B.: Helmut Kohl Ein weiterer Grund für die Angabe der Mail-Adresse ist die Angewohnheit mancher PGP-Benutzer, ihre Schlüsseldatei als Adreßbuch zu mißbrauchen. ;) * Generierung: PGP wird voraussichtlich um Eingaben auf der Tastatur bitten. Die Zeitspannen zwischen den Anschlägen werden als Zufallsdaten verwendet. Computer können zwar Pseudo-Zufallszahlen ,errechnen', aber *wirklich* zufällige Werte sind auf *Rechnern* sehr schwer zu bekommen. Das Abtippen von Text z.B. aus einem Buch ergibt für diesen Zweck übrigens einen breitere Verteilung der Daten, als das schnelle ,Wegtippen' der Anschläge. Das Berechnen eines 1024-bit-Schlüssels kann je nach Rechenleistung einige Minuten dauern, in dieser Zeit zeigt PGP mehrmals abwechselnd Gruppen von Punkten ,.' und Pluszeichen ,+' an. Rechner / Betriebssystem Beispielzeiten für die Erzeugung eines 1024-bit-Schlüssels Archimedes ARM3 180 s DOS: 486DX2/66 25-140 s 486/33 3 min 386DX40 155 s 286/12 ca. 30 min Linux: 486DX33 GCC2.5.7 27-73 CPU-Sekunden AMIGA: A500 > 40 min A3000 4 min >>> ms1207@cd4680fs.rrze.uni-erlangen.de: Die Berechnung eines 9000bitigen Keys hat auf einem 486DX-33 ca. 51 Stunden gedauert. Das Signen mit diesem Key dauert ungefähr 16 Minuten. (PGP unter Linux mit GCC2.5.7 (-O2 -m486) kompiliert.) Das Signen mit einer Borland C++ 3.1 (386, optimize speed) kompilierten Version dauert 45 Minuten. [...] Das Decrypten (check signature) geht etwa quadratisch mit der Keygröße, das Encrypten (sign) geht etwa hoch drei und das Keygenerieren etwa hoch vier. <<< Diese Angaben sind nur ungefähre Werte: PGP braucht zwei große Primzahlen. Um diese zu ermitteln, wählt es zufällig Zahlen aus und überprüft mit Hilfe einiger Tests, ob diese Primzahlen sind; d.h. die ermittelten Zeitangaben sind mehr oder weniger zufällig. Mit der Geschwindigkeit des eigentlichen Verschlüsselns haben die Zeiten nicht viel zu tun, d.h. auch auf einem A500 ist das Arbeiten mit einem 1024bit-Schlüssel recht bequem möglich. Wenn das Erzeugen des Schlüsselpaares abgeschlossen ist, liegt im %PGPPATH eine private und eine öffentliche Schlüsseldatei: SECRING.PGP und PUBRING.PGP, jeweils mit der entsprechenden Hälfte des Paares. Bevor Du irgend etwas anderes machst, solltest Du jetzt unbedingt die Benutzer-ID mit Deiner Unterschrift beglaubigen: PGP -ks Damit ist sie vor Manipulationen geschützt (s.u.: "Warum soll ich meine eigenen Benutzer-IDs unterschreiben?") *** HAST DU EINE SICHERHEITSKOPIE DEINES SCHLÜSSELS?* Auch wenn man sicherstellen muß, daß kein Fremder Zugriff auf ,SECRING.PGP', die private Schlüsseldatei, bekommt, muß man auf der anderen Seite darauf achten, daß man selbst nicht durch einen Festplattencrash oder einen simplen Dateifehler plötzlich ohne den eigenen Schlüssel da steht. Wenn der private Schlüssel verloren gegangen ist, kann man Nachrichten, die andere Leute mit dem öffentlichen Schlüssel verschlüsselt haben, nicht mehr entschlüsseln. Und wenn man mit ,PGP -kg' ein neues Schlüsselpaar erzeugt, ist dieses mit Sicherheit nicht mit dem verlorenen identisch. Deshalb sollte man das Schlüsselpaar auf eine Diskette kopieren und diese an einem *sicheren* Ort verwahren. *** Wie kann ich meine Benutzer-ID ändern? Wenn ein Benutzer unter mehreren Adressen erreichbar ist, sollte er erwägen, zusätzliche Benutzer-IDs zu seinem Schlüssel hinzuzufügen. Wenn er z.B. über sowohl über das PM-Netz als auch über Internet erreichbar ist, wäre folgendes sinnvoll: Helmut Kohl Kanzler Helmut Kohl Der Text von Benutzer-IDs kann nicht _geändert_ werden. Statt dessen muß man die neue Benutzer-ID mit "PGP -ke" hinzufügen, dann die alte mit "PGP -kr" entfernen. Beglaubigungen der alten Benutzer-ID gehen dabei verloren (wie es sich gehört). Wenn man eine Mail-Adresse aus irgendwelchen Gründen nicht mehr benutzen kann, kann man die zugehörige Benutzer-ID mit der aktuellen PGP-Version leider nicht 'automatisch' aus dem Verkehr ziehen. Man kann sie zwar aus der eigenen Schlüsseldatei löschen, in den Schlüsseldateien der anderen bleibt sie aber erhalten, weil PGP neue Benutzer-IDs einfach zu bestehenden hinzufügt. Als einzige Lösung ergibt sich zur Zeit das Hinzufügen einer weiteren Benutzer-ID in dieser Form: Helmut Kohl *NICHT mehr gültig* * Gibt es irgendwelche sinnvollen Richtlinien, welche Adressen man in den Key aufnehmen soll? Von Richtlinien will ich nicht sprechen, eher Orientierungshilfen. Frag Dich für jede Benutzer-ID: - Bin ich unter dieser Adresse von vielen Leuten zu erreichen, die mich unter den anderen Adressen nicht oder nur sehr umständlich erreichen können? - Werde ich unter dieser Adresse dauerhaft erreichbar und aktiv sein? - Ist der Einsatz von PGP unter dieser Adresse erlaubt, technisch möglich und sinnvoll? - Wie unbeliebt mache ich mich, wenn ich diese ID *auch noch* übernehme? >>> Kim : Pro Netzformat/Pollformat nur einen würde ich sagen, und zwar dann den mit dem du die meisten PM's abhandelst, außerdem für jede Box nur eine und zwar die gültige Domain, die von wo aus eh kein PM Verkehr stattfindet kann auch weggelassen werden. <<< *** Wie verteile oder bekomme ich öffentliche Schlüssel? Die private Hälfte des Schlüssels wird benötigt, um Nachrichten zu unterschreiben oder zu entschlüsseln; die öffentliche Hälfte kann mit PGP -kxa in eine Datei extrahiert und auf beliebige Art und Weise an andere PGP- Benutzer verteilt werden: Sie können per Mail verschickt werden. Sie können in einem dafür vorgesehenen Brett (z.B. /T-NETZ/PGP/ SCHLUESSEL) veröffentlicht werden. Viele PGP-Benutzer fügen in ihre ,sig' eine Bemerkung ein wie ,PGP- Schlüssel auf Anfrage', andere verschicken ihn automatisch mit Empfangsbestätigungen. Auf dem Internet stehen ,Keyserver' zur Verfügung, die neue Schlüssel in ihre Schlüsseldatei aufnehmen und auf Anfrage automatisch weitergeben. Wenn man eine Datei mit einem Schlüssel erhalten hat, kann man ihn mit PGP -ka in die eigene öffentliche Schlüsseldatei übernehmen. Ab diesem Augenblick steht er zum Verschlüsseln von Nachrichten zur Verfügung. Wenn PGP fragt, ob dieser Schlüssel beglaubigt (,certified') werden soll, *mußt* Du sehr genau prüfen, ob Du die Echtheit dieses Schlüssels wirklich 100%ig bestätigen kannst. Stell Dir dazu folgende Frage: ,Könnte ich vor Gericht unter Eid beschwören, daß dieser Schlüssel wirklich zu einer Person gehört, die diesen Namen trägt und unter dieser Mail-Adresse zu erreichen ist?' * Wo ist der nächste Internet/UUCP-Keyserver? Der nächste Internet/UUCP-Keyserver ist: --- --- pgp-public-keys@informatik.uni-hamburg.de Vesselin V. Bontchev FTP: ftp.informatik.uni-hamburg.de:/pub/virus/misc/pubkring.pgp Verified: 12/24/93 --- --- Er sollte aus dem ganzen Z-Netz erreichbar sein, aber fragt mich nicht, wie. ;) Für ZConnect-Systeme mit .zer.de ist's trivial. Diese Keyserver sind keine Institutionen, die Schlüssel vergeben, sondern sie nehmen sie von überall in Empfang und verteilen sie auf Anfrage weiter. Es sollte klar sein, daß Schlüssel, die man von einem Keyserver erhält, von diesem in keiner Weise überprüft wurden. Es gibt mehrere Keyserver, die ihre Schlüsseldateien regelmäßig austauschen, d.h. es genügt, einen neuen Schlüssel an *einen* Keyserver zu senden, er wird von dort aus in die Welt verteilt. >>> Ralf Muschall Nach jüngsten Äußerungen [auf Usenet in alt.security.pgp] gilt es als unfein, fremde public-keys ohne explizite Erlaubnis des Eigentümers an Keyserver zu senden. <<< Keyserver bearbeiten Anfragen, die sie als Mail erhalten. Die Befehle werden im Betreff gegeben. EMP: pgp-public-keys@informatik.uni-hamburg.de BET: help Um Deinen Schlüssel über die Keyserver verteilen zu lassen, schickst Du eine Nachricht wie diese an einen Keyserver: EMP: pgp-public-keys@informatik.uni-hamburg.de BET: add -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a -----END PGP PUBLIC KEY BLOCK----- Gültige Befehle sind: Betreff Funktion ADD Hinzufügen eines öffentlichen PGP-Schlüssels INDEX Liste aller Schlüssel in der Keyserver- Schlüsseldatei (pgp -kv) VERBOSE INDEX Liste aller Schlüssel im langen Format (pgp -kvv) GET Anfordern der *kompletten* Keyserver- Schlüsseldatei (evtl. mehrere MB!) GET Anfordern *eines* bestimmten Schlüssels MGET Anfordern aller Schlüssel, die auf /regexp/ passen, z.B. MGET michael Anfordern aller Schlüssel, die "michael" enthalten MGET F605A5|3A738B Anfordern dieser beiden Schlüssel-IDs *** Wie gehe ich mit Schlüsseln um? Sehr, sehr sorgfältig. Insbesondere mit der privaten Schlüsseldatei. Man sollte niemals die eigene private Schlüsseldatei auf einem fremden Rechner benutzen, um damit z.B. einen Schlüssel zu beglaubigen. Die verwendete PGP-Version könnte modifiziert sein, den privaten Schlüssel kopieren und das Mantra (die 'Pass Phrase') abfangen! Man sollte niemals einen Schlüssel beglaubigen, wenn man nicht... ...absolut sicher ist, daß der Besitzer wirklich der ist, der er zu sein behauptet. ...die Schlüssel persönlich ausgetauscht hat. Messen, Usertreffen oder Stammtische sind gute Gelegenheiten, um Schlüssel persönlich auszutauschen. ...überprüft hat, daß die in der Benutzer-ID angegebene Mail-Adresse richtig ist (indem man verschlüsselte und unterschriebene Mail über diese Adresse austauscht). Man darf den Schlüssel von X nicht einfach deshalb beglaubigen, weil Y ihn auch beglaubigt hat. DEINE Unterschrift ist DEIN Ehrenwort, daß Du sicher bist, daß dieser Schlüssel gültig ist. Wer zu lässig mit seinen Beglaubigungen umgeht, spielt mit dem Vertrauen in seine Unterschrift. PGP warnt davor, Schlüssel zu benutzen, die nicht verifiziert sind. In gewissem Maße ist das richtig, weil z.B. jemand einen gefälschten Schlüssel verbreiten könnte. Wenn er zusätzlich noch die Möglichkeit hätte, die eingehenden Nachrichten des betroffenen PGP-Benutzers abzufangen, könnte er sie entschlüsseln, lesen, mit dem gültigen Schlüssel verpacken und an den rechtmäßigen Empfänger weiterschicken. Das ist in der Praxis recht schwierig zu arrangieren, aber nicht unmöglich. Das bedeutet aber nicht, daß man einen unbeglaubigten Schlüssel nicht für die üblichen Nachrichten verwenden kann (quasi als 'Umschlag' für die Nachricht). Das wäre auf keinen Fall schlechter als Klartext. Andererseits sollte man den Schlüssel nicht zum Transport von Top- Secret-Material verwenden, aber wer Top-Secret-Material austauscht, hat sich vorher vermutlich schon mal persönlich getroffen. * Wenn ich den Key von jemand anders signiere, soll ich auch alle IDs signieren oder nicht? Du darfst nur die Benutzer-IDs unterschreiben, bei denen Du *absolut* sicher bist, daß sie zu der betreffenden Person gehören - und das läuft darauf hinaus, daß Du sie selbst getestet und mit dem Inhaber des Schlüssels über diese Adressen erfolgreich PGP-verschlüsselte Nachrichten ausgetauscht hast. *** Was ist ein Fingerprint (Fingerabdruck)? Der Fingerabdruck ist eine mit dem Algorithmus MD5 (s.u.) berechnete "Quersumme" über die einzelnen Bits, aus denen der öffentliche Schlüssel zusammengesetzt ist. Wenn der Fingerabdruck eines Schlüssels entsprechend weit verbreitet ist, ist der Schlüssel sicher davor, unbemerkt von einem auf dem Nachrichtenweg lauernden Bösewicht ausgetauscht zu werden, weil es praktisch unmöglich ist, einen zu einem vorgegebenen Fingerabdruck passenden Schlüssel zu generieren. Wenn man eine Person, deren Schlüssel nicht verifiziert ist, gut genug kennt, um ihre Stimme am Telefon zu erkennen, kann man sie anrufen und bitten, den 'Fingerabdruck' des Schlüssels vorzulesen, denn man mit PGP -kvc erhält. Es ist Dir überlassen, ob Du aufgrund dieser Überprüfung einen Schlüssel unterschreibst. Das sollte man IMHO wirklich nur tun, wenn es sich um jemanden handelt, den man *gut* kennt. Je mehr öffentliche Schlüssel Deine eigene Schlüsseldatei enthält, desto größer wird die Wahrscheinlichkeit, daß PGP eine 'Beglaubigungskette' von Dir zum beabsichtigten Empfänger ziehen kann. * Was ist MD5? >>> Abel Deuring MD5 (Message Digest 5) ist ein Algorithmus, der eine Art "Quersumme" über einen Datenblock beliebiger Länge berechnet. Im Gegensatz zu einfachen Quersummen oder CRC-Summen ist aber kein Verfahren bekannt, das es ermöglicht, einen Datenblock gezielt so zu verändern, daß der geänderte Datenblock die gleiche MD5-Summe hat wie der originale Datenblock. MD5 kann deshalb für die Kontrolle der "Echtheit" einen Datenblocks verwendet werden. PGP verwendet MD5 an zwei Stellen: Für die digitale Unterschrift und für den Fingerabdruck eines öffentlichen Schlüssels. <<< *** Warum soll ich meine eigenen Benutzer-IDs unterschreiben? Damit man sicher sein kann, daß sie nicht nachträglich manipuliert wurden. Mit entsprechender Kenntnis des Aufbaus von PGP Schlüsseln läßt sich aus: Helmut Kohl folgendes machen: Helmut Kohl Und schon bekomme ich einen Teil der Post unseres Kanzlers (nämlich den der Leute, die ihre Schlüsseldatei als Adreßbuch verwenden, s.o.). Ich kann sie zwar nicht lesen, dafür fehlt mir ja der private Birnen- Schlüssel, aber er bekommt diese Nachrichten nie zu sehen. Daher bezeichnet man das als 'Denial of Service-Attack'. Jede Benutzer-ID sollte einzeln unterschrieben werden, eine Schlüssel, der folgendes Bild trägt, ist fast schon verdächtig: Helmut Kohl (beglaubigt von Helmut Kohl ) Kanzler Helmut Kohl und diese Version sollte bei jedem PGP-Benutzer eine Warnlampe aufleuchten lassen: Helmut Kohl (beglaubigt von Helmut Kohl ) Kanzler Helmut Kohl (beglaubigt von Helmut Kohl ) GEÄNDERTE BENUTZER-ID! BITTE *ALLES* NUR NOCH AN: Mr Helmuth Kohl *** Was ist pmCrypt? Vorwort (aus der XPOINT.DOC von Peter Mandrella): - --- --- _ pmCrypt pmCrypt ist ein von Christian Mock entwickeltes Verfahren, um beliebige Codierprogramme in beliebige Z-Netz-kompatible Pointprogramme einzubinden. CrossPoint erweitert die Verwendung von pmCrypt auf sämtliche anderen Netztypen. Sofern die Nachrichten nach dem Codieren ASCII-Format haben, funktioniert es sogar netzübergreifend. - --- --- pmCrypt fungiert in CrossPoint, The Answer und anderen Pointprogrammen als Schnittstelle zwischen Pointware und Verschlüsselungsprogramm. Und so funktioniert pmCrypt (netzunabhängig): Die Nachricht wird ins Netcall-Format Z3.8 umgewandelt, das heutzutage eigentlich niemand mehr benutzen sollte, ;) aber das irgendwie immer noch den kleinsten gemeinsamen Nenner darstellt. Sie besteht dann aus acht Zeilen Z3.8-Header, gefolgt von dem Nachrichtentext: | | --- --- Empfänger DUMMY@FUPPES.ZER Betreff Dies ist der Betreff der Nachricht Absender 4-TEA-2@HIT.ZER Datum/Zeit 9404031458 Pfad MsgID 5MBWU_E_Q1B@hit68.hit.zer.de Typ T Länge 172 Text... High there, Dummy! -- Zappa isn't dead. He only smells funny. G101: GO -d+(---) p-- c++ l u e* m(FZ+) s+/+ n+ h--(*) f* [...] ReligClass: 1J4Z'80A --- --- | | Diese Datei wird mit dem als pmCrypt-Codierer eingetragenen Befehl verschlüsselt. Das Ergebnis dieser Verschlüsselung erhält einen neuen Header, abhängig vom verwendeten Netztyp, d.h. in der Regel nicht Z3.8, bei dem die Betreffzeile mit "*crypted*" anfängt - der Rest der Zeile kann vom Programmierer der jeweiligen pmCrypt-Routine nach eigenem Belieben zusammengestellt werden. Per pmCrypt verschlüsselte Nachrichten sind per Definition als Binärnachrichten zu verschicken. "Seit PGP" macht das keinen Sinn mehr, da PGP mit der Option (Befehlszeile:) "-a" oder (Konfigurationsdatei:) "Armor = On" die Nachrichten automatisch so einpackt, daß sie als Textnachricht über alle Gateways hinweg und durch alle Netze hindurch problemlos verschickt werden können. >>> Peter Mandrella Wer pmCrypt-Nachrichten mit THE-ANSWER-Usern austauscht, muß weiterhin binäre pmCrypt-Nachrichten erzeugen lassen. Für den Austausch zwischen CrossPoint-Usern empfehle ich dagegen, für PGP den Binärschalter generell zu deaktivieren. Damit läßt sich die PGP-pmCrypt-Codierung dann bequem über alle Gateways hinweg in allen von XP unterstützten Netzen verwenden. <<< Was ZConnect betrifft, ist pmCrypt ist eine Art 'Übergangslösung' bis zur 'Einsatzreife' (und entsprechenden Verbreitung) von ZC3.1, in dem PGP dann integraler Bestandteil sein wird. * Wie bindet man PGP mit pmCrypt in ein Pointprogramm ein? pmCrypt braucht drei Angaben, um ein Verschlüsselungsprogramm benutzen zu können: die Bezeichnung, die Befehlszeile zum Verschlüsseln und die zum Entschlüsseln. Für PGP könnten Angaben so lauten: Bezeichnung: PGP Codierer: PGP -et "" -o Decodierer: PGP -o Die Befehlszeilen für CrossPoint lauten also: Codierer: PGP -et $INFILE "$KEY" -o $OUTFILE Decodierer: PGP $INFILE -o $OUTFILE Wenn man die Nachrichten außerdem noch automatisch mit einer Unterschrift versehen möchte, braucht der Codierer den Befehl '-s': Codierer: PGP -set "" -o und für XP: PGP -set $INFILE "$KEY" -o $OUTFILE Wer automatische, unbeaufsichtigte Netcalls durchführt, wird zu schätzen wissen, daß man PGP auch anweisen kann, keine Eingaben von Tastatur zu verlangen, da pmCrypt-Nachrichten in der Regel unmittelbar nach dem Netcall beim Einsortieren der Nachrichten entschlüsselt werden. Dazu gibt man auf der Befehlszeile '+BATCHMODE' an, also: Decodierer: PGP +BATCHMODE -o und für XP: PGP +BATCHMODE $INFILE -o $OUTFILE * Was soll ich bei pmCrypt als 'Paßwort' eintragen? PGP verwendet das RSA-Public Keys, braucht also kein Paßwort, sondern die Benutzer-ID des Empfängers, mit deren Hilfe es sich den Schlüssel selbständig aus der öffentlichen Schlüsseldatei heraussucht. Beispiele: Paßwort: Marc Das reicht sicher nicht aus. Auch wenn es zu Anfang ausreichen mag, eine ID kurz und prägnant anzugeben, so sollte man doch bedenken, daß sie auch eindeutig bleiben muß, wenn weitere Schlüssel zur Schlüsseldatei dazukommen. Sicherer wären: Paßwort: 4-tea-2@HIT oder: Paßwort: Marc Aurel Letzteres klappt, weil die Benutzer-ID im o.a. Codierer-Aufruf in Anführungszeichen eingeschlossen ist. Und schließlich gibt es die Möglichkeit, den Schlüssel direkt über die Schlüssel-ID auszuwählen, was am sichersten und schnellsten ist, dabei stellt man als Kennung '0x' vor die ID: Paßwort: 0xB556C3 * Was ist in CONFIG.TXT zu ändern? --- --- [ Wichtige Änderungen in CONFIG.TXT (Vorschlag) ] --- Language = de # war: en # Natürlich wird diese Einstellung erst aktiv, wenn auch die # entsprechende LANGUAGE.TXT-Datei vorliegt. # für DOS (und Atari?): CharSet = cp850 # Zeichensatz-Einstellung, alle Konvertierungen übernimmt PGP. # für AMIGA und andere ISO-Systeme: CharSet = LATIN1 # Da mag es Probleme geben, wenn die Pointprogramme Umlaute vor dem # Verschlüsseln in den Z-Netz-üblichen PC-Zeichensatz umwandeln. Müßte # man ausprobieren... >>> Christopher Creutzig : Bitte bitte, liebe TA-User: Benutzt einen Aufruf a la "pgp -set +charset=cp850...", sonst kommen Eure Umlaute nur bei den DOS-Usern und bei anderen TA-Usern korrekt an, und das auch eher zufällig. <<< # Vom korrekten Setzen von CharSet ist auch abhängig, ob die Umlaute # der Sprachdateien (LANGUAGE.TXT) richtig angezeigt werden können! # für pmCrypt (und in der Regel auch anderswo): Armorlines = 0 # Diese Einstellung verhindert, daß PGP überlange Nachrichten # selbständig in mehrere Happen zerlegt (denn das versteht pmCrypt # nicht). # für pmCrypt (jetzt): Armor = off # Mit dieser Einstellung enthält die von PGP verschlüsselte Datei # Binärdaten, kann also nur als Binärnachricht verschickt werden. # für pmCrypt (hoffentlich in Zukunft) und andere: Armor = on # Wo keine Binärnachrichten verschickt werden können, kann PGP mit # dieser Einstellung den verschlüsselten Text selbst in eine Datei # ,verpacken', die nur durch alle Netze transportierbare ASCII-Zeichen # enthält und zusätzlich mit einer Start- und Endzeile versehen ist. TextMode = on # In diesem Modus werden die Umlaute und Zeilenende richtig ins # konvertiert (sofern CharSet richtig gesetzt ist). PGP erkennt trotzdem, # wenn eine Binärdatei verschlüsselt werden soll und schaltet den # TextMode dann selbständig aus. --- --- *** Welche Environment-Variablen müssen/sollen gesetzt werden? [ Bitte berücksichtigt die system-üblichen Konventionen der SET- Befehle, benutzt also ggf. "setenv " oder sonstwas statt dem von mir verwendeten DOS-mäßigen "SET =". ] * SET pgppath= Im angegebenen Verzeichnis befinden sich die Schlüsseldateien und diverse Hilfsdateien, die PGP benötigt. * SET tz= >>> Hagen Kliemann In SETUP.DOC für MSDOS steht: For Amsterdam: SET TZ=MET-1DST Ich denke dieser Eintrag ist auch für uns relevant. Dazu will ich ergänzen: Der Zeitzoneneintrag bezieht sich auf die Umrechnung der intern von C verwendeten Zeit und hat immer folgenden Aufbau: TZ=xxx[-]dyyy wobei xxx der Name der Zeitzone ist, [-]d die Anzahl der Stunden ist, die zur Lokalzeit hinzugerechnet werden müssen, um die GMT zu erhalten, und yyy bezeichnet die optionale Angabe der Sommerzeit. Nach meinen Erfahrungen werden die Bezeichnungen der Zonen nirgendwo ausgewertet (Vielleicht ist das aber auch vom verwendeten C-Compiler abhängig ??). Deshalb besteht bei der Sommerzeit das Problem, daß angenommen wird (wie in Amerika üblich), daß die Umstellung von Sommer- auf Winterzeit am 1.Sonntag im Oktober und die Umstellung von Sommer- auf Winterzeit am 1. Sonntag im April stattfindet. Will sagen mit dem Sommerzeiteintrag können wir wahrscheinlich nichts anfangen und müssen statt dessen im Sommer SET TZ=MES-2 und im Winter SET TZ=MET-1 benutzen. <<< >>> Abel Deuring Der einfachste Ausweg ist übrigens: Kümmer Dich einfach nicht um das Problem :) Der einzige Nachteil ist, daß alle PGP-Zeitangaben bei Dir um sechs Stunden (hoffentlich richtig gerechnet :) in die Zukunft verschoben sind. Wenn ich die älteren Diskussionen um falsche Zeitangaben richtig verstanden habe, ist dann das einzige Problem, daß Daten, die Du mit PGP bearbeitet hast, erst sechs Stunden später von der PGP-Implementierung bei anderen Leuten akzeptiert werden, weil PGP Zeitangaben "aus der Zukunft" nicht mag. Aber wenn Deine KorrespondenzpartnerInnen dies Problem kennen, sollten sie auch damit umgehen können. <<< * SET pgppass= Das Zugangspaßwort zum privaten Schlüssel in die AUTOEXEC.BAT zu setzen - um das automatische Entschlüsseln von pmCrypt-Nachrichten bei automatisierten Schaltuhr-Netcalls zu ermöglichen - sollte man nur riskieren, wenn man hundertprozentige Kontrolle über den verwendeten Rechner hat. Unter Umständen mag es in diesem Zusammenhang besser sein, ganz auf eine ,Pass Phrase' für den geheimen Schlüssel zu verzichten, um keine Unnötige Aufmerksamkeit zu erregen. Für alle, die das Pollen von Hand starten, bietet sich an, XP mit einer kleinen Batchdatei zu starten, die das Mantra mit Hilfe eines Tools wie 'ASK' oder 'INPUT' abfrägt, etwa: --- --- [ Beispiel für XP.BAT ] --- INPUT "Mantra? " %%PGPPASS c:\xp\xp %1 %2 %3 %4 %5 %6 %7 %8 %9 SET PGPPASS= --- --- (4DOS/NDOS - Keine Ahnung, wie 'INPUT' mit DOS geht...) *** Wie kann ich eingehende PGP-Schlüssel automatisch übernehmen? [CrossPoint-Version] Nicht ganz automatisch, aber halbautomatisch: Das Hinzufügen von Schlüsseln zu Deiner PGP-Schlüsseldatei ('Key Ring') läßt sich z.B. mit folgendem F-Tasten- oder Zusatz-Menü-Makro 'halbautomatisieren': --- Menüanzeige PGP-Schlüssel Programmname PGP -ka +BATCHMODE $FILE $FILE-Nachr. ohne Kopf [ ] aus Betreff [ ] Warten [ ] Vollbild Speicher: 500 KByte [x] Ausgabe an Lister [ ] AUTOEXEC-Verzeichnis bearbeiten --- Die einfachste Methode, alle Schlüssel automatisch einzulesen, ist folgender Befehl als Eingangsfilter: PGP -ka +batchmode $PUFFER *** Was mache ich, wenn mir das alles zu kompliziert ist? [CrossPoint-Version] Du besorgst Dir das Programm XP-PGP von Matthias Jordan , das die Installation von PGP im CrossPoint automagisch vornimmt. [AMIGA-Version] Du besorgst Dir das Installations-Script von Christopher Creutzig . *** Wie muß man beim Zurückziehen eines PGP-Schlüssels vorgehen? >>> Henning Hucke >>> Peter Simons Einfach mit '-kd' Deinen Key revoken. Wenn Du Deinen Key dann mit '- kx' extrahierst, dann ist dies das sogenannte Revokation-Zertifikat. Jeder der dieses 'Ding' zu seinem Keyring hinzufügt, bekommt Deinen Key als ungültig markiert. Also: PGP -kd revokation und beim Empfänger Deines Keys dann PGP -ka revokation.pgp und fertig. Wenn Du Deinen neuen Key gleich mit rein packen willst, dann kannst Du einen neuen generieren und dann mit pgp -kx revokation dem File hinzufügen. Der Empfänger bekommt dann Revokation und neuen Key in einem Rutsch. Wenn Du das ganze als ASCII-armored haben willst, kannst Du das mit folgenden Kommandos machen: pgp -fkx >revokation.asc pgp -kg pgp -fkx >>revokation.asc <<< *** Disclaimer: ZConnect gehört der Zerberus GmbH. Sorry an die LINK-MZ, der ich den Beispiel-Benutzer angedichtet habe. Bis jetzt hat sich noch niemand bei mir beschwert; ich nehme an, die LINK-MZ bekommt /T-NETZ/PGP/ ALLGEMEIN gar nicht. ;) *** Credits: Ein großer Teil der FAQ basiert auf der Archimedes-PGP-FAQ von Paul L. Allen . Weitere Beiträge stammen von: Ansgar Spiertz Boris Mogwitz Garry Glendown Hagen Kliemann Henning Hucke Jan Groth Jürgen Gebneda Hauke Lampe Kim Martin Emmerich ms1207@cd4680fs.rrze.uni-erlangen.de //padeluun Peter Simons Peter Klein Ralf Muschall Robin Wöhler Rolf-Dieter Lucius Toni YOOBOO@SUNBURN.zer.sub.org ...und aus /T-NETZ/PGP/ALLGEMEIN. Und ein *besonderer* Dank an: Abel Deuring Christopher Creutzig Matthias Jordan * Nachwort: Ich weiß, ich hab die Hälfte der Änderungsvorschläge, die seit dem letzten Posting bei mir eintrafen, verschlampt. Habt Geduld mit mir, danke. ;) -----BEGIN PGP SIGNATURE----- Version: 2.3a iQB1AgUBLewJZTaXL999tVbDAQGh5wMAn28r6fnMLbFc8LMvLFBdhTk9td/MB5az exTdXCEwE9PDGRADB48f8xoU3xNQxtYI66F8Wvzy9vSE9vVMe9g1sQc5dxdz81ca 3IcM4k73YP9+UqRxEIM/25Tif6NCxC0h =SVBx -----END PGP SIGNATURE-----