Article View: de.comp.security
Article #36Re: PGP (Public Key Encryption)
From: Peter Bruells
Date: Sun, 10 Jan 1993 19:27
Date: Sun, 10 Jan 1993 19:27
49 lines
2858 bytes
2858 bytes
>>>>> On 10 Jan 93 12:58:10 +0100, terra@sol.ccc.de (Frank Simon) said: FS> Article-I.D.: sol.2679 [..] FS> So. Wenn wir soweit sind, nehmen wir also erstmal die Kommunikation FS> in Store-and-Foreward Netzen (Z-Netz, UUCP, etc). Dort laufen Mails FS> ueber mehrere Knoten. Jeder SysOp jedes Knotens kann meine Mails FS> lesen. Davor ist zu schuetzen. Ein kombiniertes RSA/DES Verfahren FS> ist da das einzig praktische. Ob ich z.B. in meiner Implementation FS> PGP einsetze haengt stark davon ab, wie PGP arbeitet. Von der FS> Funktionalitaet hat PGP (genau wie PEM) noch nicht das was gebraucht FS> wird. Die Frage ist dann wie gut konkret PGP dokumentiert und FS> einbindbar ist. (PS. Vor 2-3 Jahren hat mal ein Subnetter ein FS> Programm fuer Unix gepostet, welches einen TExt mit DES verschluesselt FS> und das Passwort mit RSA verschluesselt - hat das noch jemand ???) Der PGP hat ein paar ernstzunehmende Schwaechen, mal abgesehen davon, dass er urspruenglich auf MS-DOS entwickelt wurde (schlechter Einsatz als Filter, etc). Unter anderem stammt von der Moskauer Universitaet eine Liste der groesseren Schachstellen. (alt.security.pgp, vor ein paar Tagen) [..] FS> Nun gut. Ergebnis: Die Kommunikation muss PRINZIPIELL und OHNE FS> EINGREIFEN des Benutzer geschuetzt werden. Erst dann aendert sich FS> auch das Kommunikationsverhalten insgesamt. Das die Kommunikation des Benutzer geschuetzt werden muss, ist klar, aber ich fuerchte du stellst dir eine Implementation dieser Dienste zu einfach vor. Ausserdem ist mir nicht ganz klar geworden, wie Du die generelle Verschluesselung ohne Mitwirkung des Benutzers erreichen willst. Wenn man von boesartigen Systemverwaltern ausgeht, musst du mindestens eine Node-zu-Node Verschluessung und einigen vertrauenswuerdigen Schluesselvergabestellen ausgehen. Die End-zu-End Verschluesselung duerfte in der Beziehung bis auf weiteres das einzige sein, was dem Benutzern wirklich Beruhigung verschaffen kann - aber ohne seine Mithilfe in Bezug auf Schluesselverwaltung, -vergabe und auf Sicherung seiner Schluessel wird man wohl kaum auskommen koennen.
Technical Details
Message-ID:
<1993Jan10.192711.12105@arbi.Informatik.Uni-Oldenburg.DE>Path:
arc1-ca.pugleaf.net!sparky!uunet!europa.asd.contel.com!howland.reston.ans.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!Germany.EU.net!uniol!Peter.BruellsReferences:
<5500@artcom0.north.de> <2673@sol.ccc.de> <C0M6LI.68I@sisyphos.owl.de> <2679@sol.ccc.de>Show Full Headers
Complete Article Headers
Newsgroups: de.comp.security Path: arc1-ca.pugleaf.net!sparky!uunet!europa.asd.contel.com!howland.reston.ans.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!Germany.EU.net!uniol!Peter.Bruells From: Peter.Bruells@arbi.informatik.uni-oldenburg.de (Peter Bruells) Subject: Re: PGP (Public Key Encryption) Organization: University of Oldenburg, Germany Date: Sun, 10 Jan 1993 19:27:11 GMT Message-ID: <1993Jan10.192711.12105@arbi.Informatik.Uni-Oldenburg.DE> In-Reply-To: terra@sol.ccc.de's message of 10 Jan 93 12:58:10 +0100 References: <5500@artcom0.north.de> <2673@sol.ccc.de> <C0M6LI.68I@sisyphos.owl.de> <2679@sol.ccc.de> Sender: news@arbi.Informatik.Uni-Oldenburg.DE Lines: 51