🚀 go-pugleaf

Hallo, 

pf@artcom0.north.de (Peter Funk) writes:
>Ausserdem interessiert mich, ob sich schon jemand Gedanken darueber
>gemacht hat, wie man diese Public-Key-Encryption eventuell transparent
>in einen MUA (z.B. elm) einbauen koennte.  Ich stell mir das so vor:
Ja. Das ist Thema meiner Diplom-Arbeit, die seit 1.12.1992 laeuft. 
Allerdings kommt das aus diversen Gruenden in den MTA. 

>Beim Abschicken der Mail wird im Public-Key-Ring nachgeschaut,
>ob der Addressat dort schon enthalten ist.  Oder man definiert
>irgendeine Konvention, mit der man seinen eigenen Public-Key (z.B.
>in der .signature) versenden kann.
Es wird eine Schluesselverwaltung geben. Entweder ueber News oder
ueber Mail. Das wird noch untersucht. :-)

Terra
-- 
-----------------------------------------------------------------------------
!   Frank Simon (Terra), Ammerlaender Heerstr. 389, D-2900 Oldenburg, FRG   !
! terra@sol.ccc.de, terra@sol.zer, ext/simon@kmx.gmd.dbp.de, +49 441 76206  !
! Es gibt 2 absolute Wahrheiten: OSI ist Fortschritt, die Erde eine Scheibe !
-----------------------------------------------------------------------------

terra@sol.ccc.de (Frank Simon) writes:

>>Beim Abschicken der Mail wird im Public-Key-Ring nachgeschaut,
>>ob der Addressat dort schon enthalten ist.  Oder man definiert
>>irgendeine Konvention, mit der man seinen eigenen Public-Key (z.B.
>>in der .signature) versenden kann.
>Es wird eine Schluesselverwaltung geben. Entweder ueber News oder
>ueber Mail. Das wird noch untersucht. :-)

ZCONNECT 3.1 macht es dezentral:
In jeder oeffentlichen Nachricht wird ein PGP: Header eingefuegt, der 
den oeffentlichen Schluessel enthaelt. Das Point-Programm sucht nun fuer
alle Adressen die im Adressbuch verzeichnet sind beim Eintreffen von News
nach oeffentlichen Schluesseln und speichert die in einer eigenen Datenebank.

Trifft eine verschluesselte Nachricht ein (durch einen Header "STAT: PGP"
markiert) kann der oeffentliche Schluessel aus der Datenbank geholt werden.

Das klappt in ZCONNECT sehr einfach, da wir die Transport Agents nich in
News und Mail getrennt haben. 


Gruss


Martin
-- 
1994 ist nah!

Hallo,

martin@sisyphos.owl.de (Martin Husemann) writes:
>terra@sol.ccc.de (Frank Simon) writes:
>>Es wird eine Schluesselverwaltung geben. Entweder ueber News oder
>>ueber Mail. Das wird noch untersucht. :-)
>ZCONNECT 3.1 macht es dezentral:
>In jeder oeffentlichen Nachricht wird ein PGP: Header eingefuegt, der 
>den oeffentlichen Schluessel enthaelt. Das Point-Programm sucht nun fuer
>alle Adressen die im Adressbuch verzeichnet sind beim Eintreffen von News
>nach oeffentlichen Schluesseln und speichert die in einer eigenen Datenebank.
Anmerkung: Die Verbreitung und Verwaltung der oeffentlichen Schluessel
ist sicherheitsrelevant. Das heisst, dass ein wie von dir beschriebenen
Verfahren mehrere Angriffsmoeglichkeiten bietet. Damit kann mensch es aber
auch gleich bleiben lassen. :-)

Tatsaechlich hat sich im Laufe meiner DA bis jetzt folgendes gezeigt:

Erstmal muss die Kommunikation zwischen den Rechnern geschuetzt werden.
Die Kommunikation zwischen User und UA bzw. UA und MTA ist eh angreif-
bar (durch den SysOp). Es wird also erstmal die Annahme gemacht, dass
mein SysOp eine vertrauenswuerdige Person ist. Diese Annahme gilt
natuerlich bei Points/Einzelsystemen erst recht: Mit selbst vertraue
ich in der Regel. :-)

So. Wenn wir soweit sind, nehmen wir also erstmal die Kommunikation 
in Store-and-Foreward Netzen (Z-Netz, UUCP, etc). Dort laufen Mails
ueber mehrere Knoten. Jeder SysOp jedes Knotens kann meine Mails
lesen. Davor ist zu schuetzen. Ein kombiniertes RSA/DES Verfahren
ist da das einzig praktische. Ob ich z.B. in meiner Implementation
PGP einsetze haengt stark davon ab, wie PGP arbeitet. Von der
Funktionalitaet hat PGP (genau wie PEM) noch nicht das was gebraucht
wird. Die Frage ist dann wie gut konkret PGP dokumentiert und
einbindbar ist. (PS. Vor 2-3 Jahren hat mal ein Subnetter ein
Programm fuer Unix gepostet, welches einen TExt mit DES verschluesselt
und das Passwort mit RSA verschluesselt - hat das noch jemand ???)

Ist auch egal: Die Verschluesselung ist wirklich das triviale
(wenn mensch eine Loesung hat oder Kryptograph ist). Problematisch 
wird wirklich die Schluesselverwaltung und die Benutzung des ganzen. 
Tatsaechlich wurde mal in einer Untersuchung festgestellt, dass ein 
nicht vertrauenswuerdiges Medium fuer private/persoenliche/interne 
Nachricht erst garnicht verwendet wird. 
(Allgemein: Gilt natuerlich weniger fuer Computer-Freaks, Techniker, 
etc - da kommt ja das "technisch-faszinierende" noch dazu).

Nun gut. Ergebnis: Die Kommunikation muss PRINZIPIELL und OHNE
EINGREIFEN des Benutzer geschuetzt werden. Erst dann aendert sich
auch das Kommunikationsverhalten insgesamt.

>Das klappt in ZCONNECT sehr einfach, da wir die Transport Agents nich in
>News und Mail getrennt haben. 
Wenn eine Verwaltungsstruktur fuer die Authentifikation der oeffentlichen
Schluessel steht, ist es ein geringes Problem, dies auf andere Dienste
auszuweiten. Mein Anspruch an die Verwaltung ist nur, dass sie "netz-
uebergreifend" erstmal funktioniert. Das heisst Verfahren wie X.500 oder 
DNS (was eh dafuer nicht einsetzbar ist) fallen raus. Die Basis muss also 
Mail oder News sein.

Terra
-- 
-----------------------------------------------------------------------------
!   Frank Simon (Terra), Ammerlaender Heerstr. 389, D-2900 Oldenburg, FRG   !
! terra@sol.ccc.de, terra@sol.zer, ext/simon@kmx.gmd.dbp.de, +49 441 76206  !
! Es gibt 2 absolute Wahrheiten: OSI ist Fortschritt, die Erde eine Scheibe !
-----------------------------------------------------------------------------

Hallo,

Peter.Bruells@arbi.informatik.uni-oldenburg.de (Peter Bruells) writes:
>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.  
Sicher nicht. :-)

>Ausserdem ist mir nicht ganz klar geworden, wie Du die
>generelle Verschluesselung ohne Mitwirkung des Benutzers erreichen
>willst.  
Die Details kannst du im Mai in meiner Diplom-Arbeit und in der
Implementation nachlesen. :-)

>Wenn man von boesartigen Systemverwaltern ausgeht, musst du mindestens
>eine Node-zu-Node Verschluessung und einigen vertrauenswuerdigen
>Schluesselvergabestellen ausgehen.  
Das habe ich ja gesagt. Du machst eine Userabhaengige Node-to-Node-
Verschluesselung. Die Schluesselvergabe selbst muss nicht umbedingt
vertrauenswuerdig sein (wir wollen ja kein 2. TeleTrust :-) ). Aber
die dezentrale Verteilung und Verwaltung muss geschuetzt ablaufen.
Mein Wunsch ueber News wird sich daher kaum realisieren lassen. Mensch
kann aber mehrere vertrauenswuerdige Listserver sich vorstellen.
Ausserdem sollen in gewissen Umfang ja auch nicht die Verkehrsdaten
geschuetzt werden. Das ganze wird zwar zum Schluss wenig damit zu tun 
haben, aber die Basis ist "DAtenschutzgarantierende Kommunikations-
netze" von Dr. Pfitzmann und die Ergebnisse des TeleTrust-Projektes der
GMD.

Terra
-- 
-----------------------------------------------------------------------------
!   Frank Simon (Terra), Ammerlaender Heerstr. 389, D-2900 Oldenburg, FRG   !
! terra@sol.ccc.de, terra@sol.zer, ext/simon@kmx.gmd.dbp.de, +49 441 76206  !
! Es gibt 2 absolute Wahrheiten: OSI ist Fortschritt, die Erde eine Scheibe !
-----------------------------------------------------------------------------

>>>>> 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.

Peter.Bruells@arbi.informatik.uni-oldenburg.de (Peter Bruells) writes:

>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.

Genau das - und zwar ohne jede Benutzerinteraktion, einfach durch das
vorhandensein geeigneter Programme auf beiden Seiten - ist das Ziel,
das ich beschrieb. Das Problem mit der Schluesselverwaltung sehe ich
nicht, da sie (in Z-NETZ Terminologie) auf dem lokalen Point vollautomatisch
geschieht, also 

  a) auf einem vertrauenswuerdigem System (meinem eigenen)
  b) ohne Eingriff des "Sysops" (der ja nicht mal auf mein System zugreifen
     kann).

Schlimmste Manipulation die mir spontan einfaellt ist die Faelschung der
oeffentlichen Schluessel, die aber (soweit ich das verstanden habe) nur
zu unentschluesselbaren Mails fuehren kann, also sicher auch schnell
erkannt wird.



Gruss


Martin
P.S.: Im Z-NETZ wird eine sicherheitsrelevante Mail nicht ueber andere
      Systeme geroutet, daher ist das Problem vielleicht etwas entschaerft.
-- 
1994 ist nah!

Hallo,

martin@sisyphos.owl.de (Martin Husemann) writes:
>das ich beschrieb. Das Problem mit der Schluesselverwaltung sehe ich
>nicht, da sie (in Z-NETZ Terminologie) auf dem lokalen Point vollautomatisch
>geschieht, also 
>  a) auf einem vertrauenswuerdigem System (meinem eigenen)
>  b) ohne Eingriff des "Sysops" (der ja nicht mal auf mein System zugreifen
>     kann).
Aehm. Und wie teilst du der Welt mit, wie dein oeffentlicher Schluessel
ist ?  Da ja das verschluesselt automatisch gehen soll, muss auch die
Schluesselverteilung automatisch geschehen. Wie willst du da sicherstellen,
dass niemand unter deinen Namen einen (anderen) oeffentlichen Schluessel
postet, entsprechende Mails abfaengt, sie entschluesselt, veraendert/liesst
und mit deinen oeffentlichen Schluessel wieder verschluesselt und dir
dann zustellt ?  Zum Beispiel waere das fuer den SysOp deines Servers
ein Klacks. Und merken tust du davon nix. Selbst sowas waere automisch
machbar. Zusammen mit paar Filtern koennte der SysOp gezielt nach 
Beleidigungen ueber den Sysop@server.zer suchen. :-)

Gaengige Verfahren wie Authentifikation gegenueber dem Schluesselserver
ist schlecht machbar. TimeStamps auch nicht umbedingt. 

Entweder musst du das verhindern (wuenschenswert) oder 100%ig sicherstellen , 
dass ein solcher Angriff erkannt wird. (die "schwaechere Alternative", die
aber auch ausrecht um zu sagen: Das ganze ist sicher).

Terra
-- 
-----------------------------------------------------------------------------
!   Frank Simon (Terra), Ammerlaender Heerstr. 389, D-2900 Oldenburg, FRG   !
! terra@sol.ccc.de, terra@sol.zer, ext/simon@kmx.gmd.dbp.de, +49 441 76206  !
! Es gibt 2 absolute Wahrheiten: OSI ist Fortschritt, die Erde eine Scheibe !
-----------------------------------------------------------------------------