allgemeine Frage zur Nutzung von openPGP - S/MIME

[Ante Auber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo alle,

immer wieder liest man unter e-mails, die von Firmen kommen, sinngemäß
den Zusatz: "Wenn Sie diese e-mail unrechtmäßig erhalten haben,
löschen Sie diese und informieren Sie den Absender."

Warum eigentlich ist die Verwendung von Verschlüsselung des
e-mail-Verkehrs allgemein und vor allem im kommerziellen Umfeld
relativ wenig verbreitet?

Viele Grüße.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRNmWcAAoJEHYsEd/xLG39YuUIALwo3Qg2+7otpaw0VzF8X3/r
sQWWtKQFg5+5rXCq9RNw7ffxk7NCZHoRgFrNusbwfuM71nR+BmIBShF6DCP59c4f
jHWq0p3dL8IT3m0kCJx8B89vTkCZAYiPl2nxTCnJTVV2ZKTY7sq5GsYM9kY+ZC3z
fqeC32VJ8zTqGtgXYorp0Gt6DDWtFnTw+TMGtEANTqvqz2K8aN7LwHTJyCQEbFuA
xrD+2ry1qQbHWyGIWB3bcvc21nuSusHqWswhyY0b6655jaxe6JESiRmnRM1c68bS
tDTSCw577THG+k1VZnz0/rPBXyU1MXR0fYrQf6WsQRqabCXc9H6WQkdmFANYmQQ=
=AEvO
-----END PGP SIGNATURE-----

[Ansgar -59cobalt- Wiechers]

Ante Auber <an...@inbox.lt> wrote:
> immer wieder liest man unter e-mails, die von Firmen kommen, sinngemäß
> den Zusatz: "Wenn Sie diese e-mail unrechtmäßig erhalten haben,
> löschen Sie diese und informieren Sie den Absender."
>
> Warum eigentlich ist die Verwendung von Verschlüsselung des
> e-mail-Verkehrs allgemein und vor allem im kommerziellen Umfeld
> relativ wenig verbreitet?

Weil a) das Handling des Schlüsselaustauschs für die meisten User zu
umständlich ist und b) in vielen Fällen auch kein Bedarf für
verschlüsselte Kommunikation gesehen wird.

cu
59cobalt
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq

[Ante Auber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 05.03.2013 22:49, schrieb Ansgar -59cobalt- Wiechers:
> Ante Auber <an...@inbox.lt> wrote:
>> immer wieder liest man unter e-mails, die von Firmen kommen,
>> sinngemäß den Zusatz: "Wenn Sie diese e-mail unrechtmäßig
>> erhalten haben, löschen Sie diese und informieren Sie den
>> Absender."
>>
>> Warum eigentlich ist die Verwendung von Verschlüsselung des
>> e-mail-Verkehrs allgemein und vor allem im kommerziellen Umfeld
>> relativ wenig verbreitet?
>
> Weil a) das Handling des Schlüsselaustauschs für die meisten User
> zu umständlich ist und b) in vielen Fällen auch kein Bedarf für
> verschlüsselte Kommunikation gesehen wird.
>
> cu 59cobalt
>

zu a) Schlüsselaustausch? Einen öffentlichen Schlüssel zu erstellen
dauert wenige Minuten, ein Zertifikat hochladen ebenso kurze Zeit. Man
muss keinen Schlüssel austauschen ...

zu b) kein Bedarf? Dann könnten doch alle Unternehmer und
Privatpersonen alle postalischen Informationen auf Postkarten
versenden und nicht kuvertiert; man könnte einen Haufen Porto sparen ...

Ich habe da meine leisen Zweifel an der Sinnhaftigkeit des derzeitigen
allgemeinen Procederes. In Zeiten von Facebook, Twitter, Google+,
Dropbox und Co. wird man wohl denken, man hätte sowieso nichts zu
verbergen, also braucht es auch keine private Kommunikation. Meiner
Meinung nach ein Irrweg! Es gibt Dinge im Leben, die tritt man nicht
in aller Öffentlichkeit breit! Vor allem nicht im kommerziellen Umfeld.

Viele Grüße.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRNm9hAAoJEHYsEd/xLG39ZXkH/28aXCByJR0JoksHunyg8xYU
+rNT9DFjW8ZAmLcnWFVuIhXfjy4hjORFpDGS9toP2l5ckWmSTMfaDli7bptcAGMO
faZZFSyIXj98JkvhPEEjNf64entB8E9ugzdjUKe2wzZ1GCSMQsnPGhZ6yFFezQyx
7hU6f2fX4obPDH7t7JvrVaBrwCcB2456/2mFE9lmF4Cu8Zp5FUMo1+56wnj3nR2D
JUu0b+IidioARMhP1UO9oHptW/8NEWMVhVVGdBvQ1/1s36/myDARDwZLZMgTQfvM
XBzTIy8yfUfLR9Jm4L2tVwJUSgLyIzB+zxT9SaQC0YroA3SOa0u1cXg0sD6Tv10=
=3D/o
-----END PGP SIGNATURE-----

[Burkhard Ott]

On Tue, 05 Mar 2013 23:19:13 +0100, Ante Auber wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 05.03.2013 22:49, schrieb Ansgar -59cobalt- Wiechers:
>> Ante Auber <an...@inbox.lt> wrote:
>>> Warum eigentlich ist die Verwendung von Verschlüsselung des
>>> e-mail-Verkehrs allgemein und vor allem im kommerziellen Umfeld
>>> relativ wenig verbreitet?
>>
>> Weil a) das Handling des Schlüsselaustauschs für die meisten User zu
>> umständlich ist und b) in vielen Fällen auch kein Bedarf für
>> verschlüsselte Kommunikation gesehen wird.
>>
>> cu 59cobalt
>>
>>
> zu a) Schlüsselaustausch? Einen öffentlichen Schlüssel zu erstellen
> dauert wenige Minuten, ein Zertifikat hochladen ebenso kurze Zeit. Man
> muss keinen Schlüssel austauschen ...

Naja, irgendwoher musst Du dir schon den offentlichen Teil des
Schluessles besorgen.

> zu b) kein Bedarf? Dann könnten doch alle Unternehmer und Privatpersonen
> alle postalischen Informationen auf Postkarten versenden und nicht
> kuvertiert; man könnte einen Haufen Porto sparen ...

Die digitalen 'Postkarten' sehen die nicht, aus den Augen aus dem Sinn
sozusagen.

> Ich habe da meine leisen Zweifel an der Sinnhaftigkeit des derzeitigen
> allgemeinen Procederes. In Zeiten von Facebook, Twitter, Google+,
> Dropbox und Co. wird man wohl denken, man hätte sowieso nichts zu
> verbergen, also braucht es auch keine private Kommunikation. Meiner
> Meinung nach ein Irrweg! Es gibt Dinge im Leben, die tritt man nicht in
> aller Öffentlichkeit breit! Vor allem nicht im kommerziellen Umfeld.

Da hast Du volkommen Recht, es hindert Dich ja keiner drann trotzdem zu
verschluesseln. Ich erinnere mich Ende der 90'er gab es dahingehend
massive Kampangnen welche die ganzen Clicki encryption tools
hervorbrachte, allerdings aenderte das am Verhalten generell sehr wenig,
was sehr schade war/ist.

cheers

[Ante Auber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 05.03.2013 23:31, schrieb Burkhard Ott:
> On Tue, 05 Mar 2013 23:19:13 +0100, Ante Auber wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> Am 05.03.2013 22:49, schrieb Ansgar -59cobalt- Wiechers:
>>> Ante Auber <an...@inbox.lt> wrote:
>>>> Warum eigentlich ist die Verwendung von Verschlüsselung des
>>>> e-mail-Verkehrs allgemein und vor allem im kommerziellen
>>>> Umfeld relativ wenig verbreitet?
>>>
>>> Weil a) das Handling des Schlüsselaustauschs für die meisten
>>> User zu umständlich ist und b) in vielen Fällen auch kein
>>> Bedarf für verschlüsselte Kommunikation gesehen wird.
>>>
>>> cu 59cobalt
>>>
>>>
>> zu a) Schlüsselaustausch? Einen öffentlichen Schlüssel zu
>> erstellen dauert wenige Minuten, ein Zertifikat hochladen ebenso
>> kurze Zeit. Man muss keinen Schlüssel austauschen ...
>
> Naja, irgendwoher musst Du dir schon den offentlichen Teil des
> Schluessles besorgen.

Gut, den öffentlichen Teil des Schlüssels könnte man als e-mail-Anhang
eines Erstkontakts mitschicken, oder eine Quelle dessen als Link. Da
gäbe es schon Möglichkeiten.

>
>> zu b) kein Bedarf? Dann könnten doch alle Unternehmer und
>> Privatpersonen alle postalischen Informationen auf Postkarten
>> versenden und nicht kuvertiert; man könnte einen Haufen Porto
>> sparen ...
>
> Die digitalen 'Postkarten' sehen die nicht, aus den Augen aus dem
> Sinn sozusagen.

In der Firma, für die ich gearbeitet habe, gab und gibt es
IT-Administratoren, die sowas von "auf Sicherheit achten" erpicht
waren, dass es für die "normalen" Benutzer kaum noch erträglich war.
Aber offene (geschäftliche) e-mails sind für diese Leute vollkommen
normal.

>
>> Ich habe da meine leisen Zweifel an der Sinnhaftigkeit des
>> derzeitigen allgemeinen Procederes. In Zeiten von Facebook,
>> Twitter, Google+, Dropbox und Co. wird man wohl denken, man hätte
>> sowieso nichts zu verbergen, also braucht es auch keine private
>> Kommunikation. Meiner Meinung nach ein Irrweg! Es gibt Dinge im
>> Leben, die tritt man nicht in aller Öffentlichkeit breit! Vor
>> allem nicht im kommerziellen Umfeld.
>
> Da hast Du volkommen Recht, es hindert Dich ja keiner drann
> trotzdem zu verschluesseln. Ich erinnere mich Ende der 90'er gab es
> dahingehend massive Kampangnen welche die ganzen Clicki encryption
> tools hervorbrachte, allerdings aenderte das am Verhalten generell
> sehr wenig, was sehr schade war/ist.
>
> cheers
>

Ja, das ist wirklich sehr schade, denn so geht ein großes Stück Kultur
und Privatsphäre den Bach runter. Ich denke, es ist einfach viel
zuwenig bekannt, dass es relativ einfache Möglichkeiten der
e-mail-Verschlüsselung gibt. Warum kümmert sich da nicht mal eine der
großen PC-Zeitungen drum? Computer-Bild, Chip, PC-Welt und Konsorten?
Ich denke, dass das politisch wenig opportun ist. Lieber sollen doch
die e-mail-Versender weiter Echelon und die NSA füttern ... um es
wirklich überspitzt zu formulieren.

Viele Grüße.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRNnY6AAoJEHYsEd/xLG39b7QH/0c7cnMGf+cNDRFdFBoRQvTk
/ikKfFVJcekUTDwwqppkihBX9IHeszlNLz8uhd76oZyVXkp43JSbGy3qrZiQoWbd
7qurTE31JwjwaA/yCZDk2KXO5yjXnQ7/v6Oce0pZH95i0cHLLh1pQX+B4/8HQe6b
o1h32Tv2gdeGMJ4jMpTOJXUNBF2lkU7+NAr1VNeloPqh2750z1TUqQXyXsM8c669
m9no0I2A3scUjR+dnfxUfpwIDy8LTYLksklwlRu4Uk69GAOEQMVbCWX4XkMk+tZc
ge0ZOzmL8AaaqTZzdTLh1unCTk+J7dWZTgTBvTk3cNoECsckSxhMiaWursWjBuc=
=c8+m
-----END PGP SIGNATURE-----

[Philipp Schneider]

On Tue, 05 Mar 2013 23:48:26 +0100, Ante Auber wrote:

> Ja, das ist wirklich sehr schade, denn so geht ein großes Stück Kultur
> und Privatsphäre den Bach runter. Ich denke, es ist einfach viel zuwenig
> bekannt, dass es relativ einfache Möglichkeiten der
> e-mail-Verschlüsselung gibt. Warum kümmert sich da nicht mal eine der
> großen PC-Zeitungen drum? Computer-Bild, Chip, PC-Welt und Konsorten?

Die Leser dieser Zeitschriften kümmern sich doch eher um das Optimieren
der Ladezeiten ihrer Windowssysteme.

E-Mail-Verschlüsselung ist technisch seit vielen Jahren möglich, die
Benutzer müssen es wollen... Es ist schwierig, Bekannte und Freunde zur
Verschlüsselung von Mails zu bewegen.

[Ante Auber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 05.03.2013 23:58, schrieb Philipp Schneider:
>
>
> E-Mail-Verschlüsselung ist technisch seit vielen Jahren möglich,
> die Benutzer müssen es wollen... Es ist schwierig, Bekannte und
> Freunde zur Verschlüsselung von Mails zu bewegen.
>

Richtig, das stimmt. Aber wo liegt die Ursache für das Nichtwollen?
Ist es Unkenntnis der relativ einfachen Möglichkeiten oder ist es
Desinteresse an einer Privatsphäre; ist es einfach Faulkeit oder vll.
ein Konglomerat von allem hier genanntem? Oder evtl. doch das
"Nichtwollen" der Provider? Es wäre doch einfach, bei der Einrichtung
eines e-mail-Accounts bei einem Freemailer, wie web.de, gmx.net oder
t-online den Benutzer auf eine einfache Möglichkeit hinzuweisen, einen
öffentlichen Schlüssel zu erstellen und zu veröffentlichen sowie
seinen privaten Schlüssel zu sichern. Ist das denen alles wirklich zu
kompliziert? Ich kann es fast nicht glauben.

Viele Grüße.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRNnsGAAoJEHYsEd/xLG39u98H+wfAvRHDNTJ1oJQ6ALcILQgV
IqrrMSk+IMH3nqSZVf1oeDTJvwy6N/WMVLJecZZWOuc3keNRYoeF3oQpzORqoCU0
HziGJuFudIPvn347q8TmULSaqZyTD82NQZvH5POGFngvT+D9tmn7ton0ecHNmRf8
Y8+saYf0IG5PNfAV1B8GYpAYHDfed7jMm0xqk9WMNaAwEkk9HoeMw7fA8VtrPXLm
Up5uaTr7f4L4Yn10wBg18KxznqbUCm25pNtK2i6ffdoDOKGuX/0SBRsPp0c0fiQE
18ckVJka084emJzym5qaMVeyP1ICjg+iAGJxOXGPWugr40dfHmh2qYoZM7DIRO0=
=3/u9
-----END PGP SIGNATURE-----

[Burkhard Ott]

On Tue, 05 Mar 2013 23:48:26 +0100, Ante Auber wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 05.03.2013 23:31, schrieb Burkhard Ott:
>> On Tue, 05 Mar 2013 23:19:13 +0100, Ante Auber wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Am 05.03.2013 22:49, schrieb Ansgar -59cobalt- Wiechers:
>>>> Ante Auber <an...@inbox.lt> wrote:
>>>>> Warum eigentlich ist die Verwendung von Verschlüsselung des
>>>>> e-mail-Verkehrs allgemein und vor allem im kommerziellen Umfeld
>>>>> relativ wenig verbreitet?
>>>>
>>>> Weil a) das Handling des Schlüsselaustauschs für die meisten User zu
>>>> umständlich ist und b) in vielen Fällen auch kein Bedarf für
>>>> verschlüsselte Kommunikation gesehen wird.

>>> zu a) Schlüsselaustausch? Einen öffentlichen Schlüssel zu erstellen
>>> dauert wenige Minuten, ein Zertifikat hochladen ebenso kurze Zeit. Man
>>> muss keinen Schlüssel austauschen ...
>>
>> Naja, irgendwoher musst Du dir schon den offentlichen Teil des
>> Schluessles besorgen.
>
> Gut, den öffentlichen Teil des Schlüssels könnte man als e-mail-Anhang
> eines Erstkontakts mitschicken, oder eine Quelle dessen als Link. Da
> gäbe es schon Möglichkeiten.
>

Ja da waere eine und ich denke der Empfaenger der sensible damit umgeht
wird auch an Dich zurueckverschluesseln, leider ist das aber nicht die
Mehrheit.

> In der Firma, für die ich gearbeitet habe, gab und gibt es
> IT-Administratoren, die sowas von "auf Sicherheit achten" erpicht waren,
> dass es für die "normalen" Benutzer kaum noch erträglich war. Aber
> offene (geschäftliche) e-mails sind für diese Leute vollkommen normal.

Kommt drauf an was ertraeglich ist und wie sensible Deine Daten sind, es
gibt einige Moeglichkeiten Daten sicher zu uebertragen. Leider ist es
jedoch so das auch grosse Unternehmen sich schon bei trivialer
Verschluessung schwer tuen. Was meine ich damit? Zum Beispiel smtp ueber
TLS/SSL, Anwender muss da ja gar nichts machen und wenn das Zielsystem
das ebenfalls unterstuetzt ist es zumindest waehrend der Uebertragung
verschluesselt.
Sollte eigentlich ueberall so sein, ist es aber leider nicht. Beispiel
Salesforce, selbst auf Anfrage nicht moeglich, hatte erst vor ein paar
Wochen einen Monatelangen Disput aufgegeben. Man rennt selbst bei
einfachsten Sachen an dieser Stelle teilweise nur gegen Waende.

>>> Ich habe da meine leisen Zweifel an der Sinnhaftigkeit des derzeitigen
>>> allgemeinen Procederes. In Zeiten von Facebook, Twitter, Google+,
>>> Dropbox und Co. wird man wohl denken, man hätte sowieso nichts zu
>>> verbergen, also braucht es auch keine private Kommunikation. Meiner
>>> Meinung nach ein Irrweg! Es gibt Dinge im Leben, die tritt man nicht
>>> in aller Öffentlichkeit breit! Vor allem nicht im kommerziellen
>>> Umfeld.
>>
>> Da hast Du volkommen Recht, es hindert Dich ja keiner drann trotzdem zu
>> verschluesseln. Ich erinnere mich Ende der 90'er gab es dahingehend
>> massive Kampangnen welche die ganzen Clicki encryption tools
>> hervorbrachte, allerdings aenderte das am Verhalten generell sehr
>> wenig, was sehr schade war/ist.
>>

> Ja, das ist wirklich sehr schade, denn so geht ein großes Stück Kultur
> und Privatsphäre den Bach runter. Ich denke, es ist einfach viel zuwenig
> bekannt, dass es relativ einfache Möglichkeiten der
> e-mail-Verschlüsselung gibt.

Stimmt aufallend, selbst unbedarfte Anwender koennen das ganz einfach
handhaben, sind aber offensichtlich nicht daran interessiert.

> Warum kümmert sich da nicht mal eine der
> großen PC-Zeitungen drum? Computer-Bild, Chip, PC-Welt und Konsorten?
> Ich denke, dass das politisch wenig opportun ist. Lieber sollen doch die
> e-mail-Versender weiter Echelon und die NSA füttern ... um es wirklich
> überspitzt zu formulieren.

Ich denke es ist mehr oder minder aus dem Focus der Oeffentlichkeit
gerueckt, gerade die o.g. Blaettchen haben bessere Verkaufszahlen wenn
andere Themen wie Facebook Integration etc. beschrieben wird.
Ich sehe es einfach als eine Entwicklung gegen die man machtlos ist, man
muss ja an dieser Entwicklung nicht teilhaben, ich blende das einfach
aus, fertig.

cheers

[Burkhard Ott]

On Wed, 06 Mar 2013 00:08:54 +0100, Ante Auber wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 05.03.2013 23:58, schrieb Philipp Schneider:
>>
>>
>> E-Mail-Verschlüsselung ist technisch seit vielen Jahren möglich, die
>> Benutzer müssen es wollen... Es ist schwierig, Bekannte und Freunde zur
>> Verschlüsselung von Mails zu bewegen.
>>
> Richtig, das stimmt. Aber wo liegt die Ursache für das Nichtwollen? Ist
> es Unkenntnis der relativ einfachen Möglichkeiten oder ist es
> Desinteresse an einer Privatsphäre; ist es einfach Faulkeit oder vll.
> ein Konglomerat von allem hier genanntem? Oder evtl. doch das
> "Nichtwollen" der Provider? Es wäre doch einfach, bei der Einrichtung
> eines e-mail-Accounts bei einem Freemailer, wie web.de, gmx.net oder
> t-online den Benutzer auf eine einfache Möglichkeit hinzuweisen, einen
> öffentlichen Schlüssel zu erstellen und zu veröffentlichen sowie seinen
> privaten Schlüssel zu sichern. Ist das denen alles wirklich zu
> kompliziert? Ich kann es fast nicht glauben.

Dann ist ja der private Schluessel nicht mehr geheim wenn Du den beim
Provider generierst.

cheers

[Ansgar -59cobalt- Wiechers]

Ante Auber <an...@inbox.lt> wrote:
> Am 05.03.2013 22:49, schrieb Ansgar -59cobalt- Wiechers:
>> Ante Auber <an...@inbox.lt> wrote:
>>> immer wieder liest man unter e-mails, die von Firmen kommen,
>>> sinngemäß den Zusatz: "Wenn Sie diese e-mail unrechtmäßig
>>> erhalten haben, löschen Sie diese und informieren Sie den
>>> Absender."
>>>
>>> Warum eigentlich ist die Verwendung von Verschlüsselung des
>>> e-mail-Verkehrs allgemein und vor allem im kommerziellen Umfeld
>>> relativ wenig verbreitet?
>>
>> Weil a) das Handling des Schlüsselaustauschs für die meisten User
>> zu umständlich ist und b) in vielen Fällen auch kein Bedarf für
>> verschlüsselte Kommunikation gesehen wird.

^^^^^^^^^^^^

> zu a) Schlüsselaustausch? Einen öffentlichen Schlüssel zu erstellen
> dauert wenige Minuten, ein Zertifikat hochladen ebenso kurze Zeit. Man
> muss keinen Schlüssel austauschen ...

Woher weiss derjenige, der deinen öffentlichen Schlüssel verwenden soll
bzw. will, dass dieser Schlüssel tatsächlich von dir stammt? Wie genau
verifiziert er das IYHO?

> zu b) kein Bedarf?

Ich hab' dir die entscheidende Stelle oben mal unterstrichen.

> Dann könnten doch alle Unternehmer und Privatpersonen alle
> postalischen Informationen auf Postkarten versenden und nicht
> kuvertiert; man könnte einen Haufen Porto sparen ...

Nicht alles, was hinkt, ist ein Vergleich.

> Ich habe da meine leisen Zweifel an der Sinnhaftigkeit des derzeitigen
> allgemeinen Procederes.

Das ist dir unbenommen.

[Ansgar -59cobalt- Wiechers]

Ante Auber <an...@inbox.lt> wrote:
> Am 05.03.2013 23:31, schrieb Burkhard Ott:
>> On Tue, 05 Mar 2013 23:19:13 +0100, Ante Auber wrote:
>>> Am 05.03.2013 22:49, schrieb Ansgar -59cobalt- Wiechers:
>>>> Ante Auber <an...@inbox.lt> wrote:
>>>>> Warum eigentlich ist die Verwendung von Verschlüsselung des
>>>>> e-mail-Verkehrs allgemein und vor allem im kommerziellen
>>>>> Umfeld relativ wenig verbreitet?
>>>>
>>>> Weil a) das Handling des Schlüsselaustauschs für die meisten
>>>> User zu umständlich ist und b) in vielen Fällen auch kein
>>>> Bedarf für verschlüsselte Kommunikation gesehen wird.
>>>

>>> zu a) Schlüsselaustausch? Einen öffentlichen Schlüssel zu
>>> erstellen dauert wenige Minuten, ein Zertifikat hochladen ebenso
>>> kurze Zeit. Man muss keinen Schlüssel austauschen ...
>>
>> Naja, irgendwoher musst Du dir schon den offentlichen Teil des
>> Schluessles besorgen.
>
> Gut, den öffentlichen Teil des Schlüssels könnte man als e-mail-Anhang
> eines Erstkontakts mitschicken, oder eine Quelle dessen als Link. Da
> gäbe es schon Möglichkeiten.

Beschreibe eine, die das Authentizitätsproblem löst und nicht auf
persönlichen Vergleich von Fingerprints hinausläuft.

[Volker Birk]

Ante Auber <an...@inbox.lt> wrote:
> immer wieder liest man unter e-mails, die von Firmen kommen, sinngemäß
> den Zusatz: "Wenn Sie diese e-mail unrechtmäßig erhalten haben,
> löschen Sie diese und informieren Sie den Absender."

Ja, das ist eine Mode. Der Text ist völlig unsinnig, und solche
Disclaimer haben auch juristisch keinerlei Relevanz.

> Warum eigentlich ist die Verwendung von Verschlüsselung des
> e-mail-Verkehrs allgemein und vor allem im kommerziellen Umfeld
> relativ wenig verbreitet?

Meiner Interpretation nach, weil solche Verschlüsselungssysteme
aufwändig in der Handhabung sind, und weder das Know-How in den Firmen
da ist, noch sind die Nutzer in der Lage, das Keymanagement zu
übernehmen.

Insofern bin ich übrigens mit den De-Mail-Leuten einer Meinung. Nur kann
die Lösung dieses Problems nicht sein, dass man die Sicherheit in der
Verschlüsselung aufgibt, denn dann ist sie sinnlos geworden. Die Lösung
müsste sein, einfach zu handhabende Verschlüsselungssysteme zu
implementieren und zu verbreiten.

Dem stehen jedoch die Interessen der “berechtigten Stellen” (so nennt
man in der Telekommunikationsüberwachungsverordnung TKÜV die abhörenden
Geheimdienste und Polizeien) entgegen. Es ist ja kein Zufall, wie
beispielsweise De-Mail ausgestaltet ist. Was dabei leider nicht mit
beachtet wird, ist dass auch unberechtigte Stellen sich solche Probleme
zunutze machen können und werden. Und damit kann man's dann auch gleich
lassen.

Viele Grüsse,
VB.
--
“Wohltätigkeit ist das Ersäufen des Rechts im Mistloch der Gnade.”

Johann Heinrich Pestalozzi

[Michael Mendelsohn]

Am 06.03.2013 01:13, schrieb Ansgar -59cobalt- Wiechers:
> Ante Auber <an...@inbox.lt> wrote:
>> Gut, den öffentlichen Teil des Schlüssels könnte man als e-mail-Anhang
>> eines Erstkontakts mitschicken, oder eine Quelle dessen als Link. Da
>> gäbe es schon Möglichkeiten.

Und das dann automatisiert im MUA: wenn eine Email reinkommt mit einem
Schlüssel im Anhang, wird der in die Datenbank aufgenommen, und der
authetifiziert dann alle weiteren Emails von dieser Adresse. Das
authetifiziert dann zwar nicht absolut, stellt aber immerhin sicher,
dass alle Emails vom selben Absender kommen - wenn's ein Angreifer ist,
muss er somit *alle* Emails abfangen, kommt eine unverwandelt durch,
fällt das auf. Der Vorteil ist, dass der User genau gar nichts machen
muss, wenn der MUA seinen Schlüssel beim Installationsvorgang generiert.
(Ich beschreibe hier die "Anfängerkonfiguration", für
sicherheitsbewusstere Anwender können wir uns alle die noch dazu nötigen
Optionen vorstellen.)

> Beschreibe eine, die das Authentizitätsproblem löst und nicht auf
> persönlichen Vergleich von Fingerprints hinausläuft.

Fingerprint als QR-Code auf dem Briefpapier oder der Rückseite der
Visitenkarte? Zugriff auf den Key über einen öffentlichen Server via
Fingerprint?

Viele Grüße
--mendel
--
"Michael" ist kein Name, sondern eine Bevölkerungsgruppe.
http://fiff.de/ Forum InformatikerInnen für Frieden und
gesellschaftliche Verantwortung e.V.

[Michael Mendelsohn]

Am 06.03.2013 07:48, schrieb Michael Mendelsohn:
> Am 06.03.2013 01:13, schrieb Ansgar -59cobalt- Wiechers:
>> Beschreibe eine, die das Authentizitätsproblem löst und nicht auf
>> persönlichen Vergleich von Fingerprints hinausläuft.

Gibt es eigentlich einen Standard, der es regelt, wie der MX als public
key server funktionieren kann? Ich stelle mir das so vor, dass der MUA
bei dem MX des Empfängers mit der Emailadresse des Empfängers nachfragt,
ob ein public key hinterlegt ist, und den dann abholt. (Um Spammern
keine Hinweise auf genutzte Adressen zu geben, würde bei nicht
vorhandenen Adressen mit der Wahrscheinlichkeit der tatsächlichen
Userbase entweder "kein Key" oder ein zufälliger Key ausgegeben.) Das
würde dann zu meinem im vorigen Post beschriebenen vollautomatischen
System passen: der MUA würde dem Server automatisch den Erstkey
übermitteln (ist ja durch die Logindaten authentifiziert), und Emails an
unbekannte Absender könnten gleich mit deren Public Key verschlüsselt
werden.

Auch hier gilt natürlich, dass das Verfahren gegenüber MITM-Angriff bei
der Schlüsselabfrage anfällig wäre, das wäre herkömmliche Email aber
auch, insofern ist das zumindest keine Verschlechterung.

[Ansgar -59cobalt- Wiechers]

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:
> Am 06.03.2013 01:13, schrieb Ansgar -59cobalt- Wiechers:
>> Ante Auber <an...@inbox.lt> wrote:
>>> Gut, den öffentlichen Teil des Schlüssels könnte man als e-mail-
>>> Anhang eines Erstkontakts mitschicken, oder eine Quelle dessen als
>>> Link. Da gäbe es schon Möglichkeiten.

[...]

>> Beschreibe eine, die das Authentizitätsproblem löst und nicht auf
>> persönlichen Vergleich von Fingerprints hinausläuft.
>
> Fingerprint als QR-Code auf dem Briefpapier oder der Rückseite der
> Visitenkarte?

Briefpapier löst das Problem nicht, weil es ebenfalls untergeschoben
werden kann. Visitenkarte würde - persönliche Übergabe vorausgesetzt -
das Problem lösen, nur setzt das wieder persönlicher Kontakt voraus.
Lediglich das Handling des Fingerprint-Vergleichs würde möglicherweise
etwas vereinfacht.

> Zugriff auf den Key über einen öffentlichen Server via Fingerprint?

Das ist der Status Quo, der das Authentizitätsproblem *nicht* löst.

Versuch's nochmal.

[Lars Gebauer]

* Ante Auber:

> Ich habe da meine leisen Zweifel an der Sinnhaftigkeit des
> derzeitigen allgemeinen Procederes.

Für die meisten Anwender funktioniert das gegenwärtige Procedere
allerdings gut genug. Insofern sehen die dann keinerlei Grund, sich
zusätzliche Probleme an's Bein zu binden.

> In Zeiten von Facebook, Twitter, Google+, Dropbox und Co. wird man
> wohl denken, man hätte sowieso nichts zu verbergen, also braucht es
> auch keine private Kommunikation. Meiner Meinung nach ein Irrweg!

Die allermeisten Menschen haben online tatsächlich weit weniger zu
verbergen, als wie gemeinhin angenommen wird. Die sog. "Datenschützer'
haben hier einen verheerenden Flurschaden angerichtet. Deren "Wirken"
führt nicht zu Aufklärung und rationalem Umgang mit dem Problem sondern
zu Verdummung und Paranoia.

Tatsächlich sind es die Menschen aus Deiner unmittelbaren Umgebung, die,
mit denen Du häufiger Kontakt hast, die weit mehr über Dich wissen, als
Du vielleicht ahnst. Häufig sind es die Menschen, denen Du gar nicht aus
dem Weg gehen kannst, die auch in der Lage sind, ihr Wissen gegen Dich
einzusetzen und Dir damit einen maximalen Schaden zuzufügen.

Wenn da nun irgendein $ESKIMO theoretisch in der Lage ist, einen
Liebesbrief abzufangen, so ist das vergleichsweise vollkommen uninteressant.

> Es gibt Dinge im Leben, die tritt man nicht in aller Öffentlichkeit
> breit!

Es gibt Dinge, die tritt man *überhaupt* *nicht* breit.

[Volker Birk]

Lars Gebauer <lgeb...@arcor.de> wrote:
> Die allermeisten Menschen haben online tatsächlich weit weniger zu
> verbergen, als wie gemeinhin angenommen wird. Die sog. "Datenschützer'
> haben hier einen verheerenden Flurschaden angerichtet. Deren "Wirken"
> führt nicht zu Aufklärung und rationalem Umgang mit dem Problem sondern
> zu Verdummung und Paranoia.

Was für eine unreflektierte Dumpfbacken-Polemik! Die Datenschützer sind
an der mangelnden Aufklärung schuld, natürlich. Wer auch sonst?

Du hast schon glaubwürdiger getrollt.

[Lars Gebauer]

* Volker Birk:

> Lars Gebauer <lgeb...@arcor.de> wrote:
>> Die allermeisten Menschen haben online tatsächlich weit weniger zu
>> verbergen, als wie gemeinhin angenommen wird. Die sog. "Datenschützer'
>> haben hier einen verheerenden Flurschaden angerichtet. Deren "Wirken"
>> führt nicht zu Aufklärung und rationalem Umgang mit dem Problem sondern
>> zu Verdummung und Paranoia.
>
> Was für eine unreflektierte Dumpfbacken-Polemik! Die Datenschützer sind
> an der mangelnden Aufklärung schuld,

... sowie an der systematischen Verdummung! Was auf gar keinen Fall
vergessen werden sollte.

> natürlich. Wer auch sonst?

Allerdings. Permanent den Focus auf Irrelevantes legen und dann
systematische Hetzkampagnen fahren, das sind "Datenschützer".

Datenschützer sind vermutlich rausgeschmissene Verfassungsschützer.

[Volker Birk]

Lars Gebauer <lgeb...@arcor.de> wrote:
> * Volker Birk:
>> Lars Gebauer <lgeb...@arcor.de> wrote:
>>> Die allermeisten Menschen haben online tatsächlich weit weniger zu
>>> verbergen, als wie gemeinhin angenommen wird. Die sog. "Datenschützer'
>>> haben hier einen verheerenden Flurschaden angerichtet. Deren "Wirken"
>>> führt nicht zu Aufklärung und rationalem Umgang mit dem Problem sondern
>>> zu Verdummung und Paranoia.
>> Was für eine unreflektierte Dumpfbacken-Polemik! Die Datenschützer sind
>> an der mangelnden Aufklärung schuld,
> ... sowie an der systematischen Verdummung! Was auf gar keinen Fall
> vergessen werden sollte.

Natürlich. Quelle: Lars Gebauers eigene Analyse. Oder warte, Analyse ist
vielleicht etwas viel gesagt. Sagen wir mal: “Meinung”. In dem Sinne,
dass ja jeder eine Meinung hat, das ist wie mit den Arschlöchern, da hat
auch jeder eins.

>> natürlich. Wer auch sonst?
> Allerdings. Permanent den Focus auf Irrelevantes legen und dann
> systematische Hetzkampagnen fahren, das sind "Datenschützer".

Jetzt wirst Du wieder etwas unterhaltsamer. Dein Narrenkäpplein klingelt
dabei so schön, dass man Dich als Gruppentroll wieder fast gern hat ;-)

> Datenschützer sind vermutlich rausgeschmissene Verfassungsschützer.

*G* Der ist nett. Ich werd's im Club mal aufhängen. Oder vielleicht
schicke ich Thilo Weichert eine Kopie, der lacht ja auch gerne über
Volltrottel.

[Michael Mendelsohn]

Am 06.03.2013 08:56, schrieb Ansgar -59cobalt- Wiechers:
> Das ist der Status Quo, der das Authentizitätsproblem *nicht* löst.

Ich will das Authentizitätsproblem nicht lösen.
Eine 100%ige Lösung würde so viel Aufwand erfordern, dass es keiner
macht (das ist der Status quo), von Ausnahmen abgesehen.

Ich will die gegenwärtige Lage verbessern, ohne einer 100%igen Lösung im
Wege zu stehen.

Die Frage ist also nicht, "ist das 100%ig", sondern, "ist es
praktikabel" und "ist es eine wesentliche Verbesserung".

[Volker Birk]

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:
> Ich will das Authentizitätsproblem nicht lösen.
> Eine 100%ige Lösung würde so viel Aufwand erfordern, dass es keiner
> macht (das ist der Status quo), von Ausnahmen abgesehen.

Wir sind wieder bei den Prozenten angelangt. Erste Frage dazu: was
setzt Du hier zu was ins Verhältnis, bitte?

[Lars Gebauer]

* Volker Birk:
> Lars Gebauer <lgeb...@arcor.de> wrote:
>> * Volker Birk:
>>> Lars Gebauer <lgeb...@arcor.de> wrote:
>>>> Die allermeisten Menschen haben online tatsächlich weit weniger
>>>> zu verbergen, als wie gemeinhin angenommen wird. Die sog.
>>>> "Datenschützer' haben hier einen verheerenden Flurschaden
>>>> angerichtet. Deren "Wirken" führt nicht zu Aufklärung und
>>>> rationalem Umgang mit dem Problem sondern zu Verdummung und
>>>> Paranoia.
>>> Was für eine unreflektierte Dumpfbacken-Polemik! Die
>>> Datenschützer sind an der mangelnden Aufklärung schuld,
>> ... sowie an der systematischen Verdummung! Was auf gar keinen
>> Fall vergessen werden sollte.
>
> Natürlich.

Allerdings. Oder wie willst Du das Geschwalle über die
Personenbezogenheit dynamischer IPs (bspw.) sonst nennen?

Entweder die haben selber nichts kapiert oder sie haben systematische
Verdummungskampagnen gefahren.

Oder das Geplärre wegen Streetview?

Oder das alberne Gezerre um FB-Like-Buttons?

[Volker Birk]

Lars Gebauer <lgeb...@arcor.de> wrote:
> Oder das Geplärre wegen Streetview?
> Oder das alberne Gezerre um FB-Like-Buttons?

Schon dass Du die beiden in einen Topf wirfst, zeigt, dass Du völlig
ahnungslos bist.

[Lars Gebauer]

* Volker Birk:

> Lars Gebauer <lgeb...@arcor.de> wrote:
>> Oder das Geplärre wegen Streetview?
>> Oder das alberne Gezerre um FB-Like-Buttons?
>
> Schon dass Du die beiden in einen Topf wirfst, zeigt, dass Du völlig
> ahnungslos bist.

Na bitte! Du meinst also, daß diese beiden Dinge nichts miteinander zu
tun haben? Geht doch! Dann erzähle doch mal, in welchem von beiden
Fällen diese "Datenschützer" ganz grandios ins Klo gegriffen haben. Was
die allerdings überhaupt nicht gehindert hat, systematische Hetze zu
betreiben.

(Daß Du die Geschichte mit den dynamischen IPs ausklammerst spricht auch
für sich.)

[Volker Birk]

Lars Gebauer <lgeb...@arcor.de> wrote:
> * Volker Birk:
>> Lars Gebauer <lgeb...@arcor.de> wrote:
>>> Oder das Geplärre wegen Streetview?
>>> Oder das alberne Gezerre um FB-Like-Buttons?
>> Schon dass Du die beiden in einen Topf wirfst, zeigt, dass Du völlig
>> ahnungslos bist.
> Na bitte! Du meinst also, daß diese beiden Dinge nichts miteinander zu
> tun haben?

Allerdings. Denn das eine ist ein Datenschutzthema, das andere ist gar
keines. Wenn Du das nicht erkennst, ist Dir nicht einmal die gängige
Definition von Datenschutz bekannt.

> (Daß Du die Geschichte mit den dynamischen IPs ausklammerst spricht auch
> für sich.)

Was auch immer Du damit meinst.

[Ansgar -59cobalt- Wiechers]

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:
> Am 06.03.2013 08:56, schrieb Ansgar -59cobalt- Wiechers:
>> Das ist der Status Quo, der das Authentizitätsproblem *nicht* löst.
>
> Ich will das Authentizitätsproblem nicht lösen.

Blöderweise war genau das die Fragestellung.

> Eine 100%ige Lösung würde so viel Aufwand erfordern, dass es keiner
> macht (das ist der Status quo), von Ausnahmen abgesehen.
>
> Ich will die gegenwärtige Lage verbessern, ohne einer 100%igen Lösung im
> Wege zu stehen.
>
> Die Frage ist also nicht, "ist das 100%ig", sondern, "ist es
> praktikabel" und "ist es eine wesentliche Verbesserung".

Eine Nicht-Änderung des Status Quo ist keine Verbesserung.

[Michael Mendelsohn]

Am 06.03.2013 11:01, schrieb Volker Birk:
> Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:
>> Ich will das Authentizitätsproblem nicht lösen.
>> Eine 100%ige Lösung würde so viel Aufwand erfordern, dass es keiner
>> macht (das ist der Status quo), von Ausnahmen abgesehen.
>
> Wir sind wieder bei den Prozenten angelangt. Erste Frage dazu: was
> setzt Du hier zu was ins Verhältnis, bitte?

"100%" ist Ansgars "löst das Problem" Authentifizierung, d.h. ich
verstehe ihn so, dass die Zuordnung Schlüssel-Kommunikationspartner
unangreifbar übermittelt werden soll.

(Damit ist noch nichts darüber gesagt, ob z.B. der private Schlüssel
beim Kommunikationspartner oder bei mir ausgespäht wird - in diesem Fall
kann ein Angreifer immer noch eine falsche Zuorndnug herbeiführen, es
lag dann aber nicht am Übermittlungsweg.)

Wogegen schützt eine Implementierung mit Keyserver auf der MX nicht?

Wenn A mit B in Kommunkation treten möchte, zieht der MUA von A sich B's
public key von dessen Mailserver (Angriffspunkt 1). MUA A verschlüsselt
mit As privatem und Bs öffentlichem Schlüssel, verschickt die Email, und
MUA B entschlüsselt mit Bs privatem und As öffentlichem Schlüssel, den
er von As Mailserver hat (Angriffspunkt 2).

Zudem könnte der Angreifer auf dem Versandwege Emails abfangen und
einschleusen (Angriffspunkt 3).

Damit ein Angreifer sich gegenüber B als A ausgeben kann, muss er
Angriff 2 durchführen, d.h. B seinen eigenen Schlüssel anstelle von As
Schlüssel unterjubeln, und per Angriff 3 sicherstellen, dass nie eine
Email von B tatsächlich A erreicht, sonst fliegt die Sache auf, da A die
angeblich mit seinem Schlüssel kodierte Nachricht nicht entschlüsseln
kann. Außerdem dürfen A und B natürlich nie out-of-band in Kontakt treten.

Genauso kann sich ein Angreifer gegenüber B als A ausgeben, mit
derselben Einschränkung.


Um die Kommunikation zwischen A und B mitlesen zu können, erfordert es
einen Angriff an allen 3 Punkten, bevor A und B die ersten Schlüssel
austauschen, und das Aufrechterhalten dieser Angriffe für solange, wie
die Kompromittierung unerkannt bleiben soll. Dieser Angriff ist durch
out-of-Band Übermittlung der Schlüssel (oder Fingerprints - QR-Code?)
aufdeckbar, oder falls einer der Partner mal ein System oder eine
Verbindung benutzt, die nicht unter der Kontrolle des Angreifers steht.

Gegenüber dem Status quo erschwert das Angriffe bereits erheblich, da
bei normaler, unverschlüsselter Email bereits ein temporärer Angriff auf
die Emailübermittlung ausreicht, um mitzulesen oder Emails zu
verfälschen, ohne dass es in der Folge zu Warnzeichen für
Kompromittierung käme. Im Verschlüsselungsszenario hingegen würden die
Teilnehmer beim Nachlassen des Angriffs feststellen, im Besitz
gefälschter Schlüssel zu sein, und wüssten damit, dass ein Angriff
stattgefunden hat, und welche archivierten Emails davon betroffen waren.

[Lars Gebauer]

* Volker Birk:
> Lars Gebauer <lgeb...@arcor.de> wrote:
>> * Volker Birk:
>>> Lars Gebauer <lgeb...@arcor.de> wrote:
>>>> Oder das Geplärre wegen Streetview?
>>>> Oder das alberne Gezerre um FB-Like-Buttons?
>>> Schon dass Du die beiden in einen Topf wirfst, zeigt, dass Du völlig
>>> ahnungslos bist.
>> Na bitte! Du meinst also, daß diese beiden Dinge nichts miteinander zu
>> tun haben?
>
> Allerdings. Denn das eine ist ein Datenschutzthema, das andere ist gar
> keines.

Sehr schön. Wir kommen der Sache immer näher: Du bestätigst also auch,
daß diese "Datenschützer" wegen Dingen herumtrollen, die sie überhaupt
nichts angehen?

[Volker Birk]

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:
> Wogegen schützt eine Implementierung mit Keyserver auf der MX nicht?

Die Frage kann ich Dir beantworten: sie schützt alleine nicht vor dem
Fälschen von Mails, noch schützt sie vor dem Aufdecken der Mailinhalte.

> Wenn A mit B in Kommunkation treten möchte, zieht der MUA von A sich B's
> public key von dessen Mailserver (Angriffspunkt 1). MUA A verschlüsselt
> mit As privatem und Bs öffentlichem Schlüssel, verschickt die Email, und
> MUA B entschlüsselt mit Bs privatem und As öffentlichem Schlüssel, den
> er von As Mailserver hat (Angriffspunkt 2).

Wie weisst Du, dass der Mailserver der richtige ist, und niemand gerade
das DNS gefälscht hat (dasselbe Spiel gibt es ja z.B. auch bei HTTPS)?

Wie weisst Du, dass niemand zwischen Dir und dem Mailserver sitzt?

Wie weisst Du, dass Du tatsächlich mit diesem Mailserver kommunizierst,
dessen IP-Adresse Du angegeben hast?

Wie weiss der Mailserver, woher der Schlüssel wirklich stammt?

Diese Fragen lassen sich sicher beantworten: mit DNSSec, dadurch, dass
Du das Zertifikat des Mailservers überprüfst, dadurch, dass der
Mailserver eine kryptografisch sichere Einlieferungsprüfung vornimmt.

Ohne dass das alles sicher ist, ist auch das Verfahren nicht sicher.

[Volker Birk]

“Diese Datenschützer” ;-)

Ich bestätige, dass Du herumtrollst.

[Juergen Ilse]

Hallo,

Ante Auber <an...@inbox.lt> wrote:
> In der Firma, für die ich gearbeitet habe, gab und gibt es
> IT-Administratoren, die sowas von "auf Sicherheit achten" erpicht
> waren, dass es für die "normalen" Benutzer kaum noch erträglich war.

Wenn man "Sicherheit" sagt, muss man auch sagen, *wovor* man denn sicher
sein will. Sicherheit gegen Kompromittierung der Firmenrechner ist z.B.
etwas ganz anderes wie Sicherheit vor Denial of Service, Sicherheit vor
mitlauschen von Kommunikation, Sicherheit vor unberechtigtem Zugriff
auf interne Daten, Sicherheit vor ...

> Aber offene (geschäftliche) e-mails sind für diese Leute vollkommen
> normal.

Siehe oben: es kommt darauf an, *wovor* die Sicherheitsmassnahmen
schuetzen sollen, es kommt im Falle von Mail auch auf die verwendete
Infrastruktur an: liegt die Empfaenger-Mailbox auf dem Server, an
den die Mail auch per SMTP zugestellt wird, und ist dieser ueber die
eigene Netzwerkinfrastruktur (die man entsprechend abgesichert hat)
erreichbar, dann ist Verschluesselung u.U. auch nicht notwendig, weil
sie keine zusaetzliche Sicherheit bringt. In anderen Faellen koennte
Verschluesselung zusaetzliche Sicherheit bringen, aber wird evt. vom
Kommunikationspartner nicht akzeptiert. Es gibt diverse Gruende fuer
oder gen die einsatz von E-Mail-Verschluesslung an der einen oder
anderen stelle mit anderen Sicherheitsmassnahmen, die voellig andere
Szenarien betreffen, hat das aber so ziemlich *gar* *nichts* zu tun.

> Ja, das ist wirklich sehr schade, denn so geht ein großes Stück Kultur
> und Privatsphäre den Bach runter. Ich denke, es ist einfach viel
> zuwenig bekannt, dass es relativ einfache Möglichkeiten der
> e-mail-Verschlüsselung gibt.

Was willst du damit erreichen? Damit du wirklich Vertraulichkeit erreichst,
musst du auch sicher sein, den Schluessel des "korrekten Kommunikations-
Partners" zu verwenden. Damit waere *zwingend* ein vertrauenswuerdiger
Weg fuer den Tuaxch der oeffentlichen Schluessel notwendig, und der von
dir vorgeschlagene Weg "bei der ersten Mail" erfuellt diese Bedingung
*nicht*. S/MIME Zertifikate *koennen* dies erfuellen, sofern man der
ausstellenden CA vertraut (und sicher ist, dass sie die Daten vor Aus-
stellung des Zertifikats gruendlich und gewissenhaft geprueft haben),
aber kann man da immer sicher sein? Die sinnvolle Verwaltung von z.B.
einem eigenen "Web of Trust" ist aufwendig (je zuverlaessiger das ganze
sein soll, desto aufwendiger). Ich kann verstehen, wenn da mancher
diesen Aufwand scheut.

> Warum kümmert sich da nicht mal eine der großen PC-Zeitungen drum?

Weil wirklich sinnvoller einsatz davon nicht immer so ganz trivial ist ...

> Computer-Bild, Chip, PC-Welt und Konsorten?
> Ich denke, dass das politisch wenig opportun ist.

Ich glaube nicht, dass da politische Gruende eine rolle spielen.
Es ist schlicht so, dass man den Aufwand nur dann treibt, wenn man
ihn wirklich fuer notwendig haelt, und das ist oftmals eben nicht
unbedingt immer der Fall.

> -----BEGIN PGP SIGNATURE-----

Deine Inline-PGP-Signatur in deinem Posting ist auch eher nervig als
hilfreich. Ich halte das fuer absolut sinnlos.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

[Juergen Ilse]

Hallo,

Ante Auber <an...@inbox.lt> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Am 05.03.2013 23:58, schrieb Philipp Schneider:
>> E-Mail-Verschlï¿œsselung ist technisch seit vielen Jahren mï¿œglich,
>> die Benutzer mï¿œssen es wollen... Es ist schwierig, Bekannte und
>> Freunde zur Verschlï¿œsselung von Mails zu bewegen.
> Richtig, das stimmt. Aber wo liegt die Ursache fï¿œr das Nichtwollen?

Damit das ganze wirklich sinnvoll wird, gehoert eine sinnvolle Verwaltung
der Schluessel dazu. Das ist aufwendig (je sinnvoller das ganze werden soll,
desto aufwendiger). In einem Web of Trust muss man die Vertrauenswuerdigkeit
von Schluesseln beurteilen und die entsprechend eintragen. tut man das nicht,
ist die ganze Geschichte witzlos. Und der Grossteil der heutigen "Netizens"
wuesste noch nicht einmal, wie sie eine solche Beurteilung sinnvoll durch-
fuehren sollte ...

> "Nichtwollen" der Provider?

Die haben damit schlicht *gar* *nichts* zu tun.

> Es wï¿œre doch einfach, bei der Einrichtung eines e-mail-Accounts bei
> einem Freemailer, wie web.de, gmx.net oder t-online den Benutzer auf
> eine einfache Mï¿œglichkeit hinzuweisen, einen ï¿œffentlichen Schlï¿œssel
> zu erstellen und zu verï¿œffentlichen sowie seinen privaten Schlï¿œssel
> zu sichern.

Das erzeugt zusaetzliche (ueberfluessige) Support-Anfragen, deren
Beantwortung Resourcen bindet und damit Geld kostet ("wozu ist das
denn gut? Wozu brauche ich das? Was mache ich, wenn ich vom Empfaenger
keinen oeffentlichen Schluessel habe? Was muss ich machen, wenn mein
privater Schluessel in fremde Haende gekommen ist? Wie beurteile ich,
ob ein Schluessel vertrauenswuerdig ist oder wirklich einer bestimmten
Person gehoert? ...). Viele der Leute, die so leidenschaftlich Mail-
vershcluesselung propagieren, koennten noch nicht einmal alle Fragen
des von mir genannten (alles andere als vollstaendigen) Fragenkatalogs
beantworten.

[Juergen Ilse]

Hallo,

Burkhard Ott <news...@derith.de> wrote:
> Leider ist es jedoch so das auch grosse Unternehmen sich schon bei trivialer
> Verschluessung schwer tuen. Was meine ich damit? Zum Beispiel smtp ueber
> TLS/SSL, Anwender muss da ja gar nichts machen und wenn das Zielsystem
> das ebenfalls unterstuetzt ist es zumindest waehrend der Uebertragung
> verschluesselt.

Der Nutzen davon liegt nahe 0. Zum einen sind die Mails damit auf jedem
Mailserver ueber den die Mail laueft, trotzdem unverschluesselt abgreifbar
(da es eben nur eine Transport-Verschluesselung ist), zum anderen muesste
man dann *sinnvollerweise* auch die vom Mailserver der Gegenstelle vor-
gelegten Zertifikate pruefen, um eine "man in the middle Attacke" aus-
schliessen zu koennen. Damit haette man aber ein Problem, weil dann die
verschluesselte Kommunikation zu mehr als 2/3 der Mailserver, die das
unterstuetzen, nicht mehr sinnvol waere (weil die Zertifikatspruefung
fehlschlaegt, weil entweder self-signed oder von einer nicht unbedingt
per Default als vertrauenswuerdig beurteilten CA ausgestellte Zertifikate
zum Einsatz kommen). Sinnvoller als Transportverschluesselung waere Ende-
zu-Ende-Verschluesselung, was aber wieder fuer Sender und empfaenger einen
mehr oder weniger grossen Mehraufwand bedeutet, wenn es wirklich sinnvoll
sein soll.

> Sollte eigentlich ueberall so sein, ist es aber leider nicht.

Sinnvoll waere das nur, wenn man die Identitaet des Kommunikationspartners
pruefen wuerde, und das ost oftmals *nicht* moeglich. FDamit ist der Sinn
der reinen Transportverschluesselung i.a. eher --> Tonne.

> Beispiel
> Salesforce, selbst auf Anfrage nicht moeglich, hatte erst vor ein paar
> Wochen einen Monatelangen Disput aufgegeben. Man rennt selbst bei
> einfachsten Sachen an dieser Stelle teilweise nur gegen Waende.

Was willst du im einzelfall mit welcher Massnahme erreichen? Sind deine
Kommunikationspartner auch bereit, deine Massnahmen zu unterstuetzen?
Welchen Sinn haben diese Massnahmen und welchen Mehraufwand bedeuten
sie an welcher Stelle? Nach gruendlicher Abwaegung aller Details bleibt
in vielen faellen einfach ein "nicht noetig, daher nicht erwuenscht:
Aufwand und Nutzen stehen nicht in einem sinnvollen Verhaeltnis" dabei
heraus. Du magst das bedauern, aber so ist es nun einmal.

[Juergen Ilse]

Hallo,

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:
> Am 06.03.2013 01:13, schrieb Ansgar -59cobalt- Wiechers:
>> Ante Auber <an...@inbox.lt> wrote:
>>> Gut, den öffentlichen Teil des Schlüssels könnte man als e-mail-Anhang
>>> eines Erstkontakts mitschicken, oder eine Quelle dessen als Link. Da
>>> gäbe es schon Möglichkeiten.

> Und das dann automatisiert im MUA: wenn eine Email reinkommt mit einem
> Schlüssel im Anhang, wird der in die Datenbank aufgenommen, und der
> authetifiziert dann alle weiteren Emails von dieser Adresse.

TOLLE IDEE!!!!1ELF
Eine einzige Mail mit gefaketem Absender und angehaengtem Schluessel
macht die verschluesselte Kommunikation mit dem wahren Inhaber der
Mailadresse unmoeglich. Und wie gehst du mit "ungueltig gewordenen
Schluesseln" um? Automatisches ersetzen in der Datenbank, sobald dir
ein neuer Schluessel zugesandt wird, der angeblich von diesem Absender
stammt? Dann kannst du dir die ganze Verschluesselung auch komplett
sparen.

> Das authetifiziert dann zwar nicht absolut, stellt aber immerhin sicher,
> dass alle Emails vom selben Absender kommen

Das garantiert dir exakt gar nichts, solange es einfache Moeglichkeiten
gibt, den Absender einer Mail zu faken (und die gibt es).

>> Beschreibe eine, die das Authentizitätsproblem löst und nicht auf
>> persönlichen Vergleich von Fingerprints hinausläuft.
> Fingerprint als QR-Code auf dem Briefpapier oder der Rückseite der

> Visitenkarte? Zugriff auf den Key über einen öffentlichen Server via
> Fingerprint?

Wenn du mehrere Schluessel zur selben Mailadresse auf dem Server hast,
welchem vertraust du dann? Wer hindert einen "Stoerer" (um ihn nicht
gleich "Angreifer" zu nennen), einfach zusaetzliche Schluessel zur
selben Mailadresse auf den Key-Server hochzuladen?

[Juergen Ilse]

Hallo,

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:

> Gibt es eigentlich einen Standard, der es regelt, wie der MX als public
> key server funktionieren kann? Ich stelle mir das so vor, dass der MUA
> bei dem MX des Empfï¿œngers mit der Emailadresse des Empfï¿œngers nachfragt,
> ob ein public key hinterlegt ist, und den dann abholt. (Um Spammern
> keine Hinweise auf genutzte Adressen zu geben, wï¿œrde bei nicht
> vorhandenen Adressen mit der Wahrscheinlichkeit der tatsï¿œchlichen
> Userbase entweder "kein Key" oder ein zufï¿œlliger Key ausgegeben.)

Dir ist aber schon klar, dass der MUA des endusers nur mit dem "Post-
ausgangsserver seines Mailproviders" und nicht mit dem "Posteingangs-
server des Empfaengers" redet, oder? Und dass sich Mailserver unter-
einander in aller Regel *gar* *nicht* zwingend authentifizieren?
Wenn du einen Ersatz fuer SMTP erfinden moechtest, wirst du vermutlich
wenig erfolgreich sein, denn SMTP ist zu weit verbreitet, um es mal
eben komplett und flaechendeckend ersetzen zu koennen oder zu wollen.

[Juergen Ilse]

Hallo,

Heiko Schlenker <hsc...@gmx.de> wrote:
> Der Absender braucht doch bloß öffentlich zugängliche Keyserver zu
> konsultieren, um an den öffentlichen Schlüssel des Empfängers zu
> gelangen. Die Echtheit des öffentlichen Schlüssels lässt sich mit
> digitalen Signaturen nachweisen (Stichworte: Web of Trust
> <http://de.wikipedia.org/wiki/Web_of_Trust>).

Diese Pruefung setzt voraus, dass jemand, dem *DU* vertraust, die
Echtheit des Schluessels bestaetigt hat (indem er den Schluessel
bei einem persoenlichen Kontakt mit dem Schluesselinhaber geprueft
hat, oder mit dem Scvhluesselinhaber auf *sicherem* Wege den
Schluessel getauscht hat). Diese Randbedingungen sind nicht immer
gegeben (das ist auch die Schwaeche des Web of Trust). Und wenn
du auch die Pruefung des Schluessels durch jemanden, der von jemandem
gekannt wird, den du kennst, oder sogar ueber noch mehr Stufen
akzeptierst, bekommst du zusaetzliche Unsicherheit in dein Web of
Trust hinein ... Ein wirklich sinnvoller Umgang damit ist IMHO
*nicht* automatisierbar und nicht immer wirklich trivial.

[Juergen Ilse]

Hallo,

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:

> Am 06.03.2013 11:01, schrieb Volker Birk:
>> Wir sind wieder bei den Prozenten angelangt. Erste Frage dazu: was

>> setzt Du hier zu was ins Verhï¿œltnis, bitte?
> "100%" ist Ansgars "lï¿œst das Problem" Authentifizierung, d.h. ich
> verstehe ihn so, dass die Zuordnung Schlï¿œssel-Kommunikationspartner
> unangreifbar ï¿œbermittelt werden soll.

Zumindest nicht "trivialst faelschbar". Und das ist nur *ein* Aspekt
des angesprochenen Problems.

> (Damit ist noch nichts darï¿œber gesagt, ob z.B. der private Schlï¿œssel
> beim Kommunikationspartner oder bei mir ausgespï¿œht wird - in diesem Fall
> kann ein Angreifer immer noch eine falsche Zuorndnug herbeifï¿œhren, es
> lag dann aber nicht am ï¿œbermittlungsweg.)

Das ist ein anderer Apsekt des selben Problems: die Erkennung kompromit-
tierter Schluessel (die dann sinnvollerweise vom Inhaber zurueckgezogen
bzw. als ungueltig erklaert werden muessen). Mit dem Uebermittlungsweg
hat das ganze auch ueberhaupt nichts zu tun.

> Wogegen schï¿œtzt eine Implementierung mit Keyserver auf der MX nicht?

Sie ist voellig undurchdacht (siehe meine andere Mail).

> Wenn A mit B in Kommunkation treten mï¿œchte, zieht der MUA von A sich B's

> public key von dessen Mailserver (Angriffspunkt 1).

Es kann mehr als einen MX fuer eine Domain geben. Wie wird der MX fuer die
Domain ermittelt? Durch DNS? Solange sich DNSSEC nicht wirklich flaechen-
deckend fuer *ALLE* Domains *UND* alle Resolver auf allen Hosts etabliert
hat, ist das *NICHT* vertrauenswuerdig (zumindest nicht vertrauenswuerdig
genug). Ausserdem bedeutet so etwas wie du dir vorstellst einen *erheblichen*
Mehraufwand in der Implementierung von Mailserver und Mailclients (denn du
muesstest SMTP um diese Funktionaliatet des Schluesseltauschs erweitern,
und diese Kommunikation muesste *verschluesselt* ablaufen, um das ein-
schleusen fremder Schluessel durch einen MitM zu verhindern, und ...
Die Etablierung eines komplett neuen Netzwerkprotokolls fuer dann *sicheren*
*verschluesselten* Mail-Versand waere vermutlilch einfacher zu etablieren.
Der aktuelle Status Quo ist, dass im allgemeinen Fall keiner deiner Vor-
schlaege einen wirklich positives Verhaeltnis zwischen Aufwand und Nutzen
aufweist.

[Stefan Kanthak]

"Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:

> Hallo,
>
> Burkhard Ott <news...@derith.de> wrote:
>> Leider ist es jedoch so das auch grosse Unternehmen sich schon bei trivialer
>> Verschluessung schwer tuen. Was meine ich damit? Zum Beispiel smtp ueber
>> TLS/SSL, Anwender muss da ja gar nichts machen und wenn das Zielsystem
>> das ebenfalls unterstuetzt ist es zumindest waehrend der Uebertragung
>> verschluesselt.
>
> Der Nutzen davon liegt nahe 0.

Falsch.
Der Sinn von TLS/SSL fuer SMTP, POP3 und IMAP4 liegt in der verschluesselten
Uebermittlung der zur Authentifizierung noetigen Daten.

Setzt Dich in einen ICE, einen McDonalds oder einen anderen Ort, an dem
ein oeffentliches WLAN verfuegbar ist, und schneide SMTP, POP3 und IMAP4
mit.

> Sinnvoll waere das nur, wenn man die Identitaet des Kommunikationspartners
> pruefen wuerde, und das ost oftmals *nicht* moeglich. FDamit ist der Sinn
> der reinen Transportverschluesselung i.a. eher --> Tonne.

Schon ohne Identitaetspruefung entziehst Du mit TLS/SSL Deine Anmeldedaten
dem Zugriff der Mitlauscher.

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)

[Juergen Ilse]

Hallo,

Heiko Schlenker <hsc...@gmx.de> wrote:

> * Kai Bojens <k...@kbojens.de> schrieb:
>> Ante Auber <an...@inbox.lt> wrote:
>>> Gut, den ï¿œffentlichen Teil des Schlï¿œssels kï¿œnnte man als e-mail-Anhang

>>> eines Erstkontakts mitschicken, oder eine Quelle dessen als Link. Da

>>> gï¿œbe es schon Mï¿œglichkeiten.
>> Nein. Um Verschlï¿œsselung korrekt zu benutzen, mï¿œssen die Schlï¿œssel auf
>> einem gesicherten Weg ausgetauscht werden, der beiden Seiten den
>> korrekten Erhalt garantiert.
> Der Witz bei asymmetrischen Verfahren ist ja insbesondere, dass der
> ï¿œffentliche Schlï¿œssel ï¿œber unsichere Kommunikationskanï¿œle ausgetauscht
> werden kann.

... nur laesst sich auf diesem Wege dann die Echtheit des Schluessels
nicht ueberpruefen, und das ist ein *wesentlicher* Teil der hier disku-
tierten Probleme.

> Die Authentifizierung, die Bestï¿œtigung der Echtheit des
> Schlï¿œssels, muss ggf. ï¿œber einen anderen Kanal erfolgen.

Entweder die Uebermittlung der Schluessel oder die Pruefung der Schluessel
(oder beides) muss ueber einen sicheren Kanal erfolgen. Die Pruefung reicht
aus, ja, aber auch dafuer wurden hier in der Diskussion keine einfach zu
handhabenden und *funktionierenden* Loesungen aufgezeigt.

Tschuess,
Juergen Ilse (juer...@usenet-verwaltung.de)

[Volker Birk]

Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> wrote:
> Der Sinn von TLS/SSL fuer SMTP, POP3 und IMAP4 liegt in der verschluesselten
> Uebermittlung der zur Authentifizierung noetigen Daten.

Dafür braucht man's nicht, das geht auch ohne. Ich würde schon sagen, da
geht es um Transportverschlüsselung.

> Setzt Dich in einen ICE, einen McDonalds oder einen anderen Ort, an dem
> ein oeffentliches WLAN verfuegbar ist, und schneide SMTP, POP3 und IMAP4
> mit.

Jo.

> Schon ohne Identitaetspruefung entziehst Du mit TLS/SSL Deine Anmeldedaten
> dem Zugriff der Mitlauscher.

Falls man das Zertifikat kennt und prüft...

[Burkhard Ott]

On Wed, 06 Mar 2013 13:32:08 +0000, Kai Bojens wrote:

> Ante Auber <an...@inbox.lt> wrote:
> Nein. Um Verschlüsselung korrekt zu benutzen, müssen die Schlüssel auf

> einem gesicherten Weg ausgetauscht werden, der beiden Seiten den
> korrekten Erhalt garantiert.

Guten Morgen lieber Kai, wir sprechen hier von asynchroner
Verschluesselung. Du kannst Deine offentlichen Schluessel gerne auch in
der Zeitung drucken lassen, gar kein Problem.


> Dazu kommen die Verwaltung der Schlüssel (Laufzeiten!) und Probleme,
> wenn Mitarbeiter ausscheiden (Nachschlüssel, Recovery, Revoken) und
> ähnliches.

Das hat ja nun nichts mit der Schluesseluebergabe zu tuen und ein
Verfallsdatum kann gesetzt werden. Mit dem revoken das ist so eine Sache,
was nuetzt es Dir wenn keiner abfragt ob ein bestimmer Schluessel noch
gueltig ist.

> Das kan man alles lösen — allerdings ist der zu betreibende Aufwand
> immens.

2 Schluessel server (+n) (falls mal einer ausfaellt) ist hoher Aufwand?

cheers

[Juergen Ilse]

Hallo,

Lars Gebauer <lgeb...@arcor.de> wrote:
> * Volker Birk:
>> Lars Gebauer <lgeb...@arcor.de> wrote:

>>> Die allermeisten Menschen haben online tatsï¿œchlich weit weniger zu
>>> verbergen, als wie gemeinhin angenommen wird. Die sog. "Datenschï¿œtzer'

>>> haben hier einen verheerenden Flurschaden angerichtet. Deren "Wirken"

>>> fï¿œhrt nicht zu Aufklï¿œrung und rationalem Umgang mit dem Problem sondern
>>> zu Verdummung und Paranoia.
>> Was fï¿œr eine unreflektierte Dumpfbacken-Polemik! Die Datenschï¿œtzer sind
>> an der mangelnden Aufklï¿œrung schuld,

> ... sowie an der systematischen Verdummung! Was auf gar keinen Fall
> vergessen werden sollte.

Deine Argumentation ist voellig bescheuert. Sie weisen auf Probleme oder
moegliche Probleme hin (nicht bei der Verbreitung von Daten, sondern bzgl.
der Zusammenfuehrung und systematischen auswertung von Daten, die dann
zu teils erheblichen Problemen fuehren koennen). Wenn ich z.B. im Artikel
ueber den Polizeikongress im Heise-Newsticker lese:
-----------------
Palantir Technologies, eine Firma des Silicon Valley-Tycoons Peter Thiel,
die nach eigenen Angaben Datenbanksoftware fï¿œr Nachrichtendienste und
Militï¿œrs entwickelt, konnte zum zweiten Mal auf einem Polizeikongress
vortragen. Inzwischen hat die Firma ein Berliner Bï¿œro. Deutschland-Chefin
Meline von Brentano pries die Software als Ideal fï¿œr die Zusammenarbeit
von Polizei und Nachrichtendiensten an. ï¿œberall dort, wo bestimmte Daten
per Gesetz nicht zusammengefï¿œhrt werden dï¿œrften, kï¿œnne Palantir eine
"Integrationsebene" ï¿œber die Daten legen. Wï¿œhrend die Daten blieben, wo
sie sind, wï¿œrden Metadaten produziert, die eine einheitliche Sicht
garantierten. Als neuestes Produkt stellte die Firma ihr "Nexus Peering"
vor, mit dem laut Prï¿œsentationsfolie Daten des US-amerikanischen
Nachrichtendienst CIA direkt mit denen des National Counterterrorism
Centers (NCTC) und des Special Operations Command (SOCOM) der US-Armee
verbunden sind.
------------------
Dann zweifle ich manchmal an der geistigen Gesundheit der Firmenvertreter:
Was genau hat denn dieser Firmenvertreter an "Daten duerfen nicht zusammen-
gefuehrt werden" nicht verstanden? Wenn ich die Daten geringfuegig um-
schreibe, sollen es ploetzlich andere Daten sein, die problemlos wieder
zusammengefuehrt werden duerfen? Geht's noch??? Wenn Datenschuetzer
solchen UNFUG als eben das entlarven, was es ist, dann haben sie ihren
Job voellig zu recht.

>> natï¿œrlich. Wer auch sonst?
> Allerdings. Permanent den Focus auf Irrelevantes legen und dann
> systematische Hetzkampagnen fahren, das sind "Datenschï¿œtzer".

Das kann man sehr wohl *erheblich* anders sehen, und ich moechte nicht
wissen, wie die heutige digitale Welt *ohne* die staendige Einmischung
der Datenschuetzer aussehen wuerde (ich *WILL* es mir nicht vorstellen).

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Ante Auber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 06.03.2013 16:46, schrieb Volker Delf:
> Ante Auber schrieb:
>
>> zu a) Schl�sselaustausch? Einen �ffentlichen Schl�ssel zu
>> erstellen dauert wenige Minuten, ein Zertifikat hochladen ebenso
>> kurze Zeit. Man muss keinen Schl�ssel austauschen ...
>
> Wo ist denn beispielsweise dein �ffentlicher Schl�ssel zu finden?
> Die Schl�ssel-ID: 0xF12C6DFD wird auf
> http://pool.sks-keyservers.net nicht gefunden, sagt mein PGP8.
>
> mfg Volker
>

Hallo Volker,

ganz lieben Dank f�r Deinen Hinweis. Ich habe bereits einige Tage
versucht einen Partner zu finden, der mir meine Fehler bei der
Verschl�sselung aufzeigt. Ich habe ganz sicher einen Haufen Fehler
gemacht.

Ich �ffne unter Windows das Programm Kleopatra -> Zertifikate auf
Server suchen, gebe dort meinen Namen (Ante Auber) ein und finde ...
nat�rlich nichts, wie du schon richtig bemerkt hast.
Wenn ich unter Windows Kleopatra auf "Meine Zertifikate" klicke, wird
mir das Zertifikat von Ante Auber mit dem Fingerprint F12C6DFD
(OpenPGP) angezeigt. Der Zertifikatsserver ist keys.gnupg.net, dessen
Protokol hkp.

Irgendwas habe ich grunds�tzlich falsch gemacht und bitte Dich um Rat.
Auch f�r weiterf�hrende Links, m�glichst auf deutsche Seiten, bin ich
sehr dankbar. Ich habe mir einschl�gige Literatur beschafft, aber dort
scheint der Wissensstand etwa bei 1990 stehengeblieben zu sein. Google
ist auch nicht sehr hilfreich.

Viele Gr��e.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRN3jAAAoJEHYsEd/xLG39g/IIAL+xLQBMr59Ur10Z7j/C7OSw
KrFlWgTeFb7xvnHRQNMWtxEJtAMlU055XgHxqZK79OoXT5YiVIfbS/LDYND+c+w/
2zWNPjSn7sEYiXU4qXStffvv6C7WHnbD7vX5coYkeA9ASqAJqzKFQx8XPzw7ymPd
L+kTe3BloYmWrbDI4cl+7PpCgQfWZ/EjEegh2I8BvKsf3k0cexjaq8H2xdAyabJX
1zUUGZ1awM/6jCsst+5j9U0IhAhe86gkWZZd6yKC2gd7I/Jn5sQS9jCKoZGlp7/Y
td94Ud4SWQs7BfInXZ3+gvnYFgkQ1xsswS9fFWvPxIJHHAVW6XKdGe/0ZA7JeXI=
=lP4h
-----END PGP SIGNATURE-----

[Juergen Ilse]

Hallo,

Lars Gebauer <lgeb...@arcor.de> wrote:
> * Volker Birk:
>> Lars Gebauer <lgeb...@arcor.de> wrote:
>>> * Volker Birk:
>>>> Lars Gebauer <lgeb...@arcor.de> wrote:

>>>>> Oder das Geplï¿œrre wegen Streetview?

>>>>> Oder das alberne Gezerre um FB-Like-Buttons?

>>>> Schon dass Du die beiden in einen Topf wirfst, zeigt, dass Du vï¿œllig
>>>> ahnungslos bist.
>>> Na bitte! Du meinst also, daￜ diese beiden Dinge nichts miteinander zu

>>> tun haben?
>> Allerdings. Denn das eine ist ein Datenschutzthema, das andere ist gar
>> keines.

> Sehr schï¿œn. Wir kommen der Sache immer nï¿œher: Du bestï¿œtigst also auch,
> daￜ diese "Datenschￜtzer" wegen Dingen herumtrollen, die sie ￜberhaupt
> nichts angehen?

Wenn die dynamischen IP-Adressen mit den einwahldaten der Provider (welche
IP-Adresse wurde wann welchem Anschluss zugewiesen) kombiniert werden, dann
werden aus der Gesamtdatenmenge evt. personenbezogene Daten (zumindest dann,
wenn ein Anschluss nur von einer Person benutzt wird) ...
Meinst du mit deinen Anspielungen evt. ein solches Szenario?

[Juergen Ilse]

Hallo,

Ante Auber <an...@inbox.lt> wrote:

> zu a) Schlï¿œsselaustausch? Einen ï¿œffentlichen Schlï¿œssel zu erstellen

> dauert wenige Minuten, ein Zertifikat hochladen ebenso kurze Zeit. Man

> muss keinen Schlï¿œssel austauschen ...

Damit die Verschluesselung wirklich sinnvoll wird, muss auch gewaehrleistet
sein, dass die Schluessel korrekt und noch gueltig sind. Es haengt ein ge-
waltiger Rattenschwanz an Schluesselverwaltung dran, und wenn man das
wirklich sinnvoll machen will, ist das eine nicht unbedingt triviale
Angelegenheit. Deine Vorstellungen kratzen IMHO viel zu weit an der
Oberflaeche. Wenn man sich auf das beschraenkt, was du hier an Vorstel-
lungen praesentiert hast, ist E-Mailverschluesselung sinnlos, denn sie
garantiert dann genau genommen *gar* *nichts* (ausser vielleicht einem
wohligen Gefuehl beim Benutzer, bei dem irrigen Glauben nun "sicher
kommuniziert" zu haben).

[Michael Mendelsohn]

Am 06.03.2013 13:37, schrieb Heiko Schlenker:
> * Michael Mendelsohn <fern...@news.mendelsohn.de> schrieb:

>> Am 06.03.2013 07:48, schrieb Michael Mendelsohn:
>>> Am 06.03.2013 01:13, schrieb Ansgar -59cobalt- Wiechers:
>>>> Beschreibe eine, die das Authentizitätsproblem löst und nicht auf
>>>> persönlichen Vergleich von Fingerprints hinausläuft.
>>

>> Gibt es eigentlich einen Standard, der es regelt, wie der MX als public
>> key server funktionieren kann? Ich stelle mir das so vor, dass der MUA

>> bei dem MX des Empfängers mit der Emailadresse des Empfängers nachfragt,

>> ob ein public key hinterlegt ist, und den dann abholt.
>

> Der Absender braucht doch bloß öffentlich zugängliche Keyserver zu
> konsultieren, um an den öffentlichen Schlüssel des Empfängers zu
> gelangen. Die Echtheit des öffentlichen Schlüssels lässt sich mit
> digitalen Signaturen nachweisen (Stichworte: Web of Trust
> <http://de.wikipedia.org/wiki/Web_of_Trust>).

Der Vorteil meiner Lösung ist, dass der Mailserverbetreiber die Echtheit
bestätigt - das "Web of Trust" hat sozusagen nur eine Kante. Bei
unverschlüsselter Email vertraue ich meinem Mailserverbertreiber bzw.
dem des Empfängers ohnehin, insofern ist das jetzt kein Rückschritt.

Bei einem Schlüssel auf einem öffentlichen Server ist ohne ein
Nachvollziehen des Web of Trust unsicher, wer den da nun platziert hat -
und dieses Nachvollziehen ist Teil des Aufwands, den ich elimieren
möchte. Natürlich können Anwender weiterhin ihre Schlüssel so
austauschen, das funktioniert ja wunderbar parallel zu meinem Vorschlag.
Ich hoffe ja auch, dass die Benutzer sich fragen, meine Email wird jetzt
verschlüsselt, wie sicher ist das denn, und dann Schritt für Schritt die
Sicherheit erhöhen, z.B. über Keyserver mit Web of Trust. Dazu soll aber
als Vorbedingung die Einstiegsschwelle mitminimalem Aufwand genommen werden.

[Stefan Kanthak]

"Michael Mendelsohn" <fern...@news.mendelsohn.de> schrieb:

> Am 06.03.2013 11:01, schrieb Volker Birk:
>> Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:

>>> Ich will das Authentizit�tsproblem nicht l�sen.
>>> Eine 100%ige L�sung w�rde so viel Aufwand erfordern, dass es keiner

>>> macht (das ist der Status quo), von Ausnahmen abgesehen.
>>
>> Wir sind wieder bei den Prozenten angelangt. Erste Frage dazu: was

>> setzt Du hier zu was ins Verh�ltnis, bitte?
>
> "100%" ist Ansgars "l�st das Problem" Authentifizierung, d.h. ich
> verstehe ihn so, dass die Zuordnung Schl�ssel-Kommunikationspartner
> unangreifbar �bermittelt werden soll.

Das Problem mit der Verschluesselung ist, fuer WEN Du verschluesselst.
Es genuegt nicht, einen irgendwie irgendwoher beschafften Schluessel im
MUA zu verwenden!

> (Damit ist noch nichts dar�ber gesagt, ob z.B. der private Schl�ssel
> beim Kommunikationspartner oder bei mir ausgesp�ht wird - in diesem Fall
> kann ein Angreifer immer noch eine falsche Zuorndnug herbeif�hren, es
> lag dann aber nicht am �bermittlungsweg.)
>
> Wogegen sch�tzt eine Implementierung mit Keyserver auf der MX nicht?

Gegen DNS-Spoofing und MitM-Angriffe.
Du verlagerst gerade Dein Problem der Authentifizierung von den
Kommunikationspartnern auf die von diesen verwendete Infrastruktur!
Wie identifizierst Du den "richtigen" MX, und wie identifiziert der
Dich?

[Juergen Ilse]

Hallo,

Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> wrote:
> "Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:

>> Burkhard Ott <news...@derith.de> wrote:
>>> Leider ist es jedoch so das auch grosse Unternehmen sich schon bei trivialer
>>> Verschluessung schwer tuen. Was meine ich damit? Zum Beispiel smtp ueber
>>> TLS/SSL, Anwender muss da ja gar nichts machen und wenn das Zielsystem
>>> das ebenfalls unterstuetzt ist es zumindest waehrend der Uebertragung
>>> verschluesselt.
>> Der Nutzen davon liegt nahe 0.
> Falsch.
> Der Sinn von TLS/SSL fuer SMTP, POP3 und IMAP4 liegt in der verschluesselten
> Uebermittlung der zur Authentifizierung noetigen Daten.

Dafuer benoetigt man kein TLS, das bekommt man z.B. auch durch geeignete
Authentifizierungsmethoden (z.B. bei pop3 CRM/MD5) hin.

>> Sinnvoll waere das nur, wenn man die Identitaet des Kommunikationspartners
>> pruefen wuerde, und das ost oftmals *nicht* moeglich. FDamit ist der Sinn
>> der reinen Transportverschluesselung i.a. eher --> Tonne.
> Schon ohne Identitaetspruefung entziehst Du mit TLS/SSL Deine Anmeldedaten
> dem Zugriff der Mitlauscher.

... solange dieser nicht eine "MitM Attacke" gegen die Kommunikation
faehrt ... Deswegen ist es fuer sichere Kommunikation *notwendig*,
auch die Identitaet des Kommunikationspartners pruefen zu koennen
(das gibt SMTP nicht her, solange man nicht *zusaetzlich* zu TLS auch
eine Pruefung der Zertifikate einbezieht, was aber heutzutage in den
meisten Faellen bei Mailservern nicht zuverlaessig moeglich ist, selbst
wenn diese TLS unterstuetzen).

In der *heutigen* *realen* Welt ist TLS bei SMTP im allgemeinen eher
sinnlos. In speziellen Faellen (Kommunikation mit einem Mailserver,
dessen Zertifikat man auf anderem Wege pruefen konnte, und den man
anhand dessen sicher identifizieren kann) *kann* es sinnvoll sein.
Das ist aber alles andere als der allgemeine Fall.

[Juergen Ilse]

Hallo,

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:

> Der Vorteil meiner Lösung ist, dass der Mailserverbetreiber die Echtheit
> bestätigt - das "Web of Trust" hat sozusagen nur eine Kante. Bei
> unverschlüsselter Email vertraue ich meinem Mailserverbertreiber bzw.
> dem des Empfängers ohnehin, insofern ist das jetzt kein Rückschritt.
> Bei einem Schlüssel auf einem öffentlichen Server ist ohne ein
> Nachvollziehen des Web of Trust unsicher, wer den da nun platziert hat -
> und dieses Nachvollziehen ist Teil des Aufwands, den ich elimieren
> möchte.

Du eliminierst ihn nicht, du schiebst ihn auf den Mailserverbetreiber (der
aber den aufwand nicht treiben wird, da er ihn nicht bezahlt bekommt) ...

[Michael Mendelsohn]

Am 06.03.2013 17:32, schrieb Juergen Ilse:
> Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:
>> Gibt es eigentlich einen Standard, der es regelt, wie der MX als public
>> key server funktionieren kann? Ich stelle mir das so vor, dass der MUA

>> bei dem MX des Empfängers mit der Emailadresse des Empfängers nachfragt,

>> ob ein public key hinterlegt ist, und den dann abholt. (Um Spammern

>> keine Hinweise auf genutzte Adressen zu geben, würde bei nicht
>> vorhandenen Adressen mit der Wahrscheinlichkeit der tatsächlichen
>> Userbase entweder "kein Key" oder ein zufälliger Key ausgegeben.)

>
> Dir ist aber schon klar, dass der MUA des endusers nur mit dem "Post-
> ausgangsserver seines Mailproviders" und nicht mit dem "Posteingangs-
> server des Empfaengers" redet, oder?

Ja.
Er könnte es aber tun, und es würde oft genug auch funktionieren.

> Und dass sich Mailserver unter-
> einander in aller Regel *gar* *nicht* zwingend authentifizieren?
> Wenn du einen Ersatz fuer SMTP erfinden moechtest, wirst du vermutlich
> wenig erfolgreich sein, denn SMTP ist zu weit verbreitet, um es mal
> eben komplett und flaechendeckend ersetzen zu koennen oder zu wollen.

Die Authentifizierung der Mailserver untereinander ist ja schon
erfunden. Ich möchte end-to-end-Verschlüsselung.

Technisch ist es sicher möglich, SMTP um eine Anfrage nach dem Schlüssel
zu erweitern - Server, die das noch nicht können, geben dann ja einen
stinknormalen Fehler zurück. Man könnte auch spezifizieren, dass die MX
auf einem anderen Port diesen Dienst anbietet - dann gäb's aber Probleme
mit Firewalls etc.

[Michael Mendelsohn]

Am 06.03.2013 14:11, schrieb Volker Birk:
> Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:

>> Wogegen schützt eine Implementierung mit Keyserver auf der MX nicht?
>
> Die Frage kann ich Dir beantworten: sie schützt alleine nicht vor dem
> Fälschen von Mails, noch schützt sie vor dem Aufdecken der Mailinhalte.
>
>> Wenn A mit B in Kommunkation treten möchte, zieht der MUA von A sich B's
>> public key von dessen Mailserver (Angriffspunkt 1). MUA A verschlüsselt
>> mit As privatem und Bs öffentlichem Schlüssel, verschickt die Email, und
>> MUA B entschlüsselt mit Bs privatem und As öffentlichem Schlüssel, den
>> er von As Mailserver hat (Angriffspunkt 2).
>
> Wie weisst Du, dass der Mailserver der richtige ist, und niemand gerade
> das DNS gefälscht hat (dasselbe Spiel gibt es ja z.B. auch bei HTTPS)?
>
> Wie weisst Du, dass niemand zwischen Dir und dem Mailserver sitzt?
>
> Wie weisst Du, dass Du tatsächlich mit diesem Mailserver kommunizierst,
> dessen IP-Adresse Du angegeben hast?
>
> Wie weiss der Mailserver, woher der Schlüssel wirklich stammt?
>
> Diese Fragen lassen sich sicher beantworten: mit DNSSec, dadurch, dass
> Du das Zertifikat des Mailservers überprüfst, dadurch, dass der
> Mailserver eine kryptografisch sichere Einlieferungsprüfung vornimmt.
>
> Ohne dass das alles sicher ist, ist auch das Verfahren nicht sicher.

Da sind wir uns ja einig: genau das habe ich mir unter Angriffspunkt 1
und 2 vorgestellt.

Wobei du es jetzt bist, der "sicher" absolut gebraucht.


Der Mailserver weiß, woher der Schlüssel stammt, weil er weiß, von wem
die Email stammt - weil der Kunde die Zugangsdaten hat. Dass der Kunde
natürlich von par...@web.dk statt par...@web.de angeschrieben werden
kann, verhindert dieses Verfahren nicht - dazu braucht es wieder den
Verifizierungskanal, der aber ja offensteht, wenn der Aufwand sich lohnt.

[Juergen Ilse]

Hallo,

Burkhard Ott <news...@derith.de> wrote:

> On Wed, 06 Mar 2013 13:32:08 +0000, Kai Bojens wrote:
>> Ante Auber <an...@inbox.lt> wrote:

>> Nein. Um Verschlï¿œsselung korrekt zu benutzen, mï¿œssen die Schlï¿œssel auf

>> einem gesicherten Weg ausgetauscht werden, der beiden Seiten den
>> korrekten Erhalt garantiert.
> Guten Morgen lieber Kai, wir sprechen hier von asynchroner
> Verschluesselung.

Das Wort was du (erfolglos) suchtest, war nicht "asynchron" sondern
"asymmetrisch". Abgesehen davon hat Kai recht: der empfanger benoetigt
den oeffentlichen Schluessel des Absenders, um die Signatur (und damit
die echtheit) der Mail priefen zu koennen, der Absender braucht den
oeffentlichenm Schluessel des Empfaengers, um die Mail an den Empfaenger
verschluesseln zu koennen. *Beide* Kommunikationspartner benoetigen den
oeffentlichen Schluessel des jeweils anderen, *beide* muessen pruefen
koennen, ob der angebliche Schluessel des Kommunikationspartners *echt*
ist, sonst ist die Sicherheit nicht gewaehrleistet.

> Du kannst Deine offentlichen Schluessel gerne auch in
> der Zeitung drucken lassen, gar kein Problem.

Du musst aber auf sicherem Wege eine *ECHTHEITSBESTAETIGUNG* des Schluessels
bekommen. Du verschiebst das Problem lediglich vom sicheren Schluesseltausch
auf die sichere Verifizierung, und fuer letztere lieferst du keine Loesung.
Damit hast du das Problem nicht geloest sondern nur verschoben.

> Das hat ja nun nichts mit der Schluesseluebergabe zu tuen und ein
> Verfallsdatum kann gesetzt werden. Mit dem revoken das ist so eine Sache,
> was nuetzt es Dir wenn keiner abfragt ob ein bestimmer Schluessel noch
> gueltig ist.

Es hat niemand behauptet, dass sicheres Key-Handling trivial waere ...

>> Das kan man alles lï¿œsen ??? allerdings ist der zu betreibende Aufwand

>> immens.
> 2 Schluessel server (+n) (falls mal einer ausfaellt) ist hoher Aufwand?

Es haengt noch mehr dran.

[Ansgar -59cobalt- Wiechers]

Burkhard Ott <news...@derith.de> wrote:
> On Wed, 06 Mar 2013 13:32:08 +0000, Kai Bojens wrote:
>> Nein. Um Verschlüsselung korrekt zu benutzen, müssen die Schlüssel
>> auf einem gesicherten Weg ausgetauscht werden, der beiden Seiten den
>> korrekten Erhalt garantiert.
>
> Guten Morgen lieber Kai, wir sprechen hier von asynchroner
> Verschluesselung.

Eigentlich sprechen wir hier eher von asymmetrischer Verschlüsselung.
Aber auch diese befreit nicht von der Notwendigkeit der Verifikation des
öffentlichen Schlüssels. Ausser, man möchte Vertraulichkeit nicht
garantiert haben. Dann kann man sich die Verschlüsselung allerdings auch
gleich ganz schenken.

cu
59cobalt
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq

[Stefan Kanthak]

"Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:

> Hallo,
>
> Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> wrote:
> > "Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb:
> >> Burkhard Ott <news...@derith.de> wrote:
> >>> Leider ist es jedoch so das auch grosse Unternehmen sich schon bei trivialer
> >>> Verschluessung schwer tuen. Was meine ich damit? Zum Beispiel smtp ueber
> >>> TLS/SSL, Anwender muss da ja gar nichts machen und wenn das Zielsystem
> >>> das ebenfalls unterstuetzt ist es zumindest waehrend der Uebertragung
> >>> verschluesselt.
> >> Der Nutzen davon liegt nahe 0.
> > Falsch.
> > Der Sinn von TLS/SSL fuer SMTP, POP3 und IMAP4 liegt in der verschluesselten
> > Uebermittlung der zur Authentifizierung noetigen Daten.
>
> Dafuer benoetigt man kein TLS, das bekommt man z.B. auch durch geeignete
> Authentifizierungsmethoden (z.B. bei pop3 CRM/MD5) hin.

| telnet smtpmail.t-online.de 25
| 220 fwd02.t-online.de T-Online ESMTP receiver fmsad1725 ready. / T-Online ESMTP receiver smtpmail.t-online.de ready.
| EHLO .
| 250-fwd02.t-online.de ready.
| 250-SIZE 52428800
| 250-8BITMIME
| 250-AUTH=LOGIN PLAIN
| 250-AUTH LOGIN PLAIN
| 250-ENHANCEDSTATUSCODES
| 250 HELP
| QUIT
| 221 2.0.0 fwd54.t-online.de closing. / Closing.

oder

| telnet mail.arcor.de 25
| 220 mail-in-02.arcor-online.net ESMTP arcor.de Mailservices usermail
| EHLO .
| 250-mail-in-02.arcor-online.net
| 250-PIPELINING
| 250-SIZE 48000000
| 250-ETRN
| 250-STARTTLS
| 250-AUTH PLAIN LOGIN
| 250-AUTH=PLAIN LOGIN
| 250-ENHANCEDSTATUSCODES
| 250-8BITMIME
| 250 DSN
| QUIT
| 221 2.0.0 Bye

oder

| telnet smtp.web.de 25
| 220 web.de (mrweb103) Nemesis ESMTP Service ready
| EHLO .
| 250-web.de Hello . [84.153.199.1]
| 250-SIZE 69920427
| 250-AUTH LOGIN PLAIN
| 250 STARTTLS

| QUIT
| 221 web.de Service closing transmission channel

oder

| telnet smtp.gmx.de 25
| 220 mail.gmx.net GMX Mailservices ESMTP {mp029}
| EHLO .
| 250-mail.gmx.net GMX Mailservices
| 250-8BITMIME
| 250-ENHANCEDSTATUSCODES
| 250-SIZE
| 250-AUTH=LOGIN PLAIN
| 250-AUTH LOGIN PLAIN
| 250 STARTTLS
| QUIT
| 221 2.0.0 GMX Mailservices {mp029}

oder

| telnet smtp.outlook.com 25
| 220 pod51013.outlook.com Microsoft ESMTP MAIL Service ready at Wed, 6 Mar 2013 18:31:56 +0000
| EHLO 84.153.199.1
| 250-pod51013.outlook.com Hello [84.153.199.1]
| 250-SIZE 36700160
| 250-PIPELINING
| 250-DSN
| 250-ENHANCEDSTATUSCODES
| 250-STARTTLS
| 250-AUTH
| 250-8BITMIME
| 250-BINARYMIME
| 250 CHUNKING
| QUIT
| 221 2.0.0 Service closing transmission channel

ICH sehe dort nur "AUTH LOGIN PLAIN", kein "AUTH LOGIN CRAM-MD5"!


| telnet smtp.gmail.com 25
| 220 mx.google.com ESMTP fs20sm8658022bkc.8 - gsmtp
| EHLO .
| 250-mx.google.com at your service, [84.153.199.1]
| 250-SIZE 35882577
| 250-8BITMIME
| 250-STARTTLS
| 250 ENHANCEDSTATUSCODES
| QUIT
| 221 2.0.0 closing connection fs20sm8658022bkc.8 - gsmtp

Und dort noch nicht mal "AUTH LOGIN PLAIN".

Dummerweise geht's auch anders:

| telnet smtp.live.com 25
| 220 BLU0-SMTP200.phx.gbl Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at Wed, 6 Mar 2013 10:27:32 -0800
| EHLO .
| 501 5.5.4 Invalid Address
| EHLO myself
| 530 5.7.0 Must issue a STARTTLS command first
| QUIT
| 221 2.0.0 BLU0-SMTP200.phx.gbl Service closing transmission channel

oder

| telnet post.strato.de 25
| 220 smtp.strato.de [jored mo33] ESMTP RZmta 31.19 ready
| EHLO .
| 250-smtp.strato.de [jored mo33] greets 84.153.199.1
| 250-ENHANCEDSTATUSCODES
| 250-8BITMIME
| 250-PIPELINING
| 250-DELIVERBY
| 250-SIZE 104857600
| 250-AUTH SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
| 250 HELP
| QUIT
| 221 2.0.0 closing connection

> In der *heutigen* *realen* Welt ist TLS bei SMTP im allgemeinen eher
> sinnlos.

Aha. S.o.!
Soll ich Dich zur Benutzung meines WLANs ueberreden?

[Lars Gebauer]

* Juergen Ilse:

> Wenn die dynamischen IP-Adressen mit den einwahldaten der Provider (welche
> IP-Adresse wurde wann welchem Anschluss zugewiesen) kombiniert werden, dann
> werden aus der Gesamtdatenmenge evt. personenbezogene Daten (zumindest dann,
> wenn ein Anschluss nur von einer Person benutzt wird) ...

Wenn, wenn, wenn.

Wenn meine Katze ein Pferd wäre, dann könnte sie auf die Bäume galoppieren.

Fakt ist ganz einfach, daß der normale Webseitenbetreiber keine legale
Möglichkeit hat, die dynamischen IPs mit den Providerlogs abzugleichen.

Infolgedessen kann er die IPs keinem Anschluß und erst recht keiner
Person zuordnen.

Diese "Datenschützer" verbreiten da eindeutig FUD.

> Meinst du mit deinen Anspielungen evt. ein solches Szenario?

Nicht nur.

[Lars Gebauer]

* Juergen Ilse:

> Lars Gebauer <lgeb...@arcor.de> wrote:
>> * Volker Birk:
>>> Lars Gebauer <lgeb...@arcor.de> wrote:

>>>> Die allermeisten Menschen haben online tatsächlich weit weniger zu
>>>> verbergen, als wie gemeinhin angenommen wird. Die sog. "Datenschützer'

>>>> haben hier einen verheerenden Flurschaden angerichtet. Deren "Wirken"

>>>> führt nicht zu Aufklärung und rationalem Umgang mit dem Problem sondern
>>>> zu Verdummung und Paranoia.
>>> Was für eine unreflektierte Dumpfbacken-Polemik! Die Datenschützer sind
>>> an der mangelnden Aufklärung schuld,

>> ... sowie an der systematischen Verdummung! Was auf gar keinen Fall
>> vergessen werden sollte.
>
> Deine Argumentation ist voellig bescheuert.

Das sagen "alle". Ich halte mich an E. A. Poe und schließe daraus, daß
meine Argumentation vielleicht bescheuert aber jedenfalls nicht falsch ist.

> Sie weisen auf Probleme oder
> moegliche Probleme hin (nicht bei der Verbreitung von Daten, sondern bzgl.
> der Zusammenfuehrung und systematischen auswertung von Daten, die dann
> zu teils erheblichen Problemen fuehren koennen).

Dieses ewige Lamento, zu oft wegen nichts und wieder nichts, nennst Du
"hinweisen"?

> Wenn ich z.B. im Artikel
> ueber den Polizeikongress im Heise-Newsticker lese:
> -----------------
> Palantir Technologies, eine Firma des Silicon Valley-Tycoons Peter Thiel,

> die nach eigenen Angaben Datenbanksoftware für Nachrichtendienste und
> Militärs entwickelt, konnte zum zweiten Mal auf einem Polizeikongress
> vortragen. Inzwischen hat die Firma ein Berliner Büro. Deutschland-Chefin
> Meline von Brentano pries die Software als Ideal für die Zusammenarbeit
> von Polizei und Nachrichtendiensten an. Überall dort, wo bestimmte Daten
> per Gesetz nicht zusammengeführt werden dürften, könne Palantir eine
> "Integrationsebene" über die Daten legen. Während die Daten blieben, wo
> sie sind, würden Metadaten produziert, die eine einheitliche Sicht

> garantierten. Als neuestes Produkt stellte die Firma ihr "Nexus Peering"

> vor, mit dem laut Präsentationsfolie Daten des US-amerikanischen

> Nachrichtendienst CIA direkt mit denen des National Counterterrorism
> Centers (NCTC) und des Special Operations Command (SOCOM) der US-Armee
> verbunden sind.
> ------------------
> Dann zweifle ich manchmal an der geistigen Gesundheit der Firmenvertreter:
> Was genau hat denn dieser Firmenvertreter an "Daten duerfen nicht zusammen-
> gefuehrt werden" nicht verstanden?

Er hat das sehr wohl verstanden. Und er hat mitgeteilt, daß ihn das
nicht so richtig interessiert. Für diese Ehrlichkeit sollte man dankbar
sein; findet sich nämlich nicht allzu häufig!

> Wenn ich die Daten geringfuegig um-
> schreibe, sollen es ploetzlich andere Daten sein, die problemlos wieder
> zusammengefuehrt werden duerfen? Geht's noch??? Wenn Datenschuetzer
> solchen UNFUG als eben das entlarven, was es ist, dann haben sie ihren
> Job voellig zu recht.

ROTFL - Du tust gerade so, als ob die schon mal was verhindert hätten.

>>> natürlich. Wer auch sonst?

>> Allerdings. Permanent den Focus auf Irrelevantes legen und dann

>> systematische Hetzkampagnen fahren, das sind "Datenschützer".

>
> Das kann man sehr wohl *erheblich* anders sehen, und ich moechte nicht
> wissen, wie die heutige digitale Welt *ohne* die staendige Einmischung
> der Datenschuetzer aussehen wuerde (ich *WILL* es mir nicht vorstellen).

Ich hätte nichts dagegen, wenn diese plärrende Bande verschwindet.

[Michael Mendelsohn]

Am 06.03.2013 18:58, schrieb Juergen Ilse:
> Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:

>> Der Vorteil meiner Lï¿œsung ist, dass der Mailserverbetreiber die Echtheit
>> bestï¿œtigt - das "Web of Trust" hat sozusagen nur eine Kante. Bei
>> unverschlï¿œsselter Email vertraue ich meinem Mailserverbertreiber bzw.
>> dem des Empfï¿œngers ohnehin, insofern ist das jetzt kein Rï¿œckschritt.
>> Bei einem Schlï¿œssel auf einem ï¿œffentlichen Server ist ohne ein

>> Nachvollziehen des Web of Trust unsicher, wer den da nun platziert hat -
>> und dieses Nachvollziehen ist Teil des Aufwands, den ich elimieren

>> mï¿œchte.

>
> Du eliminierst ihn nicht, du schiebst ihn auf den Mailserverbetreiber (der
> aber den aufwand nicht treiben wird, da er ihn nicht bezahlt bekommt) ...

Der Mailserverbetreiber gibt normalerweise einem Kunden die Mï¿œglichkeit,
sich gegenï¿œber dem Server auszuweisen. Dieser Kunde ist Inhaber der
Emailadresse. Einen Realnamen/Adresse/Geburtsdatum hat er nicht. Was der
Mailserverbetreiber also ohne Zusatzaufwand kann, ist, von dem so
ausgewiesenen Kunden den ï¿œffentlichen Schlï¿œssel entgegenzunehmen und
bereitzuhalten. Soooo viel Zusatzaufwand ist das nicht, das wï¿œrde sich
eher im Rahmen eines Softwareupdate und im Vergleich zum mail store
vernachlï¿œssigbar kleinen Speicherplatz bewegen. Plus/minus sichere
Aufbewahrung der Schlï¿œssel (Unterschieben von Fakes auf dem Server muss
verhindert werden) - aber immerhin ist es einfacher, Schlï¿œssel sicher
aufzubewahren, als Emails, oder?

Die Zuornung email-Adresse <-> realperson kriegen die Anwender heute
auch "so" hin, das ist also wiederum kein Rï¿œckschritt, wenn das System
das erstmal nicht kann. Man kann ja fï¿œr Zusatzdienste (e-post, de-mail)
das Tor aufhalten, dass da die Email-Adresse auch fï¿œr eine Realperson
steht, wenn das extra bezahlt wird. Das wird sicher mehr nachgefragt,
wenn die "verschlï¿œsselung light" erst einmal gebrï¿œuchlich ist.

Viele Grￜￜe
--mendel

--
"Michael" ist kein Name, sondern eine Bevï¿œlkerungsgruppe.
http://fiff.de/ Forum InformatikerInnen fï¿œr Frieden und
gesellschaftliche Verantwortung e.V.

[Michael Mendelsohn]

Am 06.03.2013 17:51, schrieb Juergen Ilse:
> Es kann mehr als einen MX fuer eine Domain geben. Wie wird der MX fuer die
> Domain ermittelt?

Diese Nachteiel hast du bei Email im Moment auch schon, das ist also
nicht wirklich ein Rückschritt.

> Durch DNS? Solange sich DNSSEC nicht wirklich flaechen-

> Mehraufwand in der Implementierung von Mailserver und Mailclients (denn du
> muesstest SMTP um diese Funktionaliatet des Schluesseltauschs erweitern,
> und diese Kommunikation muesste *verschluesselt* ablaufen, um das ein-
> schleusen fremder Schluessel durch einen MitM zu verhindern, und ...
> Die Etablierung eines komplett neuen Netzwerkprotokolls fuer dann *sicheren*
> *verschluesselten* Mail-Versand waere vermutlilch einfacher zu etablieren.

Mailserver können bisher per SMTP einliefernde MUAs nicht über ein
verschlüsseltes Protokoll auth'en? Sachen gibts...

Aber du kannst das sicher besser beurteilen als ich, wieviel Aufwand das
wäre. Ich denke, der Aufwand liegt eher darin, auf dem Server einen
manipulationssicheren key store einzurichten.

Viele Grüße
--mendel

--

"Michael" ist kein Name, sondern eine Bevölkerungsgruppe.

http://fiff.de/ Forum InformatikerInnen für Frieden und
gesellschaftliche Verantwortung e.V.

[Michael Mendelsohn]

Am 06.03.2013 18:32, schrieb Stefan Kanthak:
> Das Problem mit der Verschluesselung ist, fuer WEN Du verschluesselst.
> Es genuegt nicht, einen irgendwie irgendwoher beschafften Schluessel im
> MUA zu verwenden!

Im Oment benutze ich irgendwie irgendwoher beschaffte Emailadressen im
MUA. Der irgendwie irgendwoher beschaffte Schl�ssel schr�nkt den
Angriffszeitraum von "jederzeit" auf "durchg�ngig ab dem ersten
Schl�sseltausch" ein und macht es Nichtangreifern unm�glich, die Emails
mitzulesen. Weil man Briefe leicht aus den meisten Briefk�sten klauen
kann, ist es dennoch nicht sibnnvoll, alles auf Postkarten zu schrieben,
nur weil's billiger ist und Sicherheit eh' nur eine Illusion ist.

> Du verlagerst gerade Dein Problem der Authentifizierung von den
> Kommunikationspartnern auf die von diesen verwendete Infrastruktur!

Siehst du darin einen Nachteil? Was dabei herauskommt, wenn man Endusern
die Sicherheit �berl�sst, wissen wir doch.

Dazu erlaubt es das System den Kommuniklationspartnern, die
Sicherheitsstufe zu erh�hen, notfalls auch einseitig: ich kann mich
darum k�mmern, einen echten Schl�ssel meines Kommunikationspartners zu
erhalten, w�hrend dieser meinen Schl�ssel "einfach so" entgegennehmen
kann. Dann kann ein Angreifer Mails von meinem Partner nicht f�lschen
k�nnen (weil er sie nicht richtig verschl�sseln kann) und auch nicht
"still" mitlesen k�nnen (aus demsleben Grund) - die Emails an mich
k�nnen nur noch abgefangen werden (falls mein Kommunikationspartner
einen gef�lschten Schl�ssel untergeschoben bekommen hat). Was sich mit
der ersten korrekten Email, die ich erhalte, erledigt hat.

> Wie identifizierst Du den "richtigen" MX, und wie identifiziert der
> Dich?

Das Problem habe ich beim Verschicken von "normaler" Email auch. Oder
muss ich bei meinem System den entfernten Mailserver �ber meinen eigenen
Einlieferungsserver kontaktieren, um von der Infrastruktursicherheit
(soweit vorhanden) zu profitieren?

Viele Gr��e
--mendel

--
"Michael" ist kein Name, sondern eine Bev�lkerungsgruppe.
http://fiff.de/ Forum InformatikerInnen f�r Frieden und
gesellschaftliche Verantwortung e.V.

[Michael Mendelsohn]

Am 06.03.2013 17:28, schrieb Juergen Ilse:
> Hallo,
>
> Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:

>> Am 06.03.2013 01:13, schrieb Ansgar -59cobalt- Wiechers:

>>> Ante Auber <an...@inbox.lt> wrote:
>>>> Gut, den öffentlichen Teil des Schlüssels könnte man als e-mail-Anhang

>>>> eines Erstkontakts mitschicken, oder eine Quelle dessen als Link. Da

>>>> gäbe es schon Möglichkeiten.
>> Und das dann automatisiert im MUA: wenn eine Email reinkommt mit einem
>> Schlüssel im Anhang, wird der in die Datenbank aufgenommen, und der
>> authetifiziert dann alle weiteren Emails von dieser Adresse.
>
> TOLLE IDEE!!!!1ELF
> Eine einzige Mail mit gefaketem Absender und angehaengtem Schluessel
> macht die verschluesselte Kommunikation mit dem wahren Inhaber der
> Mailadresse unmoeglich.

Ok, die Automatisierung lassen wir lieber. We nn ich sehe, was hier bei
mir für Spam reinkommt, würde das auch die Datenbank unnötig aufblähen.
Dann schon eher halbautomatisch - beim Lesen der Email auf Nachfrage den
Schlüssel in die DB aufnehmen oder so, ob die gefakt ist oder nicht muss
ich dann halt mit dem gesunden Menschenverstand beurteilen, wie sonst auch.

Bei der Kommunikation mit dem wahren Inhaber würde es dann auch
"knallen", d.h. dann fällt der Fake halt am Schlüssel mismatch auf. Wenn
sonstwie eine gefakte Email käme, fiele das gar nicht auf!

> Und wie gehst du mit "ungueltig gewordenen
> Schluesseln" um? Automatisches ersetzen in der Datenbank, sobald dir
> ein neuer Schluessel zugesandt wird, der angeblich von diesem Absender
> stammt? Dann kannst du dir die ganze Verschluesselung auch komplett
> sparen.

Interessanter Punkt. Szenario: User hatte den private key auf dem
Smartphone, das ins Klo gefallen ist. Muss der Empfänger dann halt
wieder halbautomatisch mit gesundem Menschenverstand beurteilen.


>> Das authetifiziert dann zwar nicht absolut, stellt aber immerhin sicher,
>> dass alle Emails vom selben Absender kommen
>
> Das garantiert dir exakt gar nichts, solange es einfache Moeglichkeiten
> gibt, den Absender einer Mail zu faken (und die gibt es).

Wie? Der Absender ist der einzige, der den private key hat.

>>> Beschreibe eine, die das Authentizitätsproblem löst und nicht auf
>>> persönlichen Vergleich von Fingerprints hinausläuft.

>> Fingerprint als QR-Code auf dem Briefpapier oder der Rückseite der
>> Visitenkarte? Zugriff auf den Key über einen öffentlichen Server via
>> Fingerprint?
>
> Wenn du mehrere Schluessel zur selben Mailadresse auf dem Server hast,
> welchem vertraust du dann? Wer hindert einen "Stoerer" (um ihn nicht
> gleich "Angreifer" zu nennen), einfach zusaetzliche Schluessel zur
> selben Mailadresse auf den Key-Server hochzuladen?

Die Absicherung des Servers und des Anwenderzugangs zu dem Server: also
genau dieselben Mechanismen, die einen Angreifer jetzt daran hindern,
eine normale Email in meinem Namen zu verbreiten.

Wenn ich über meinen Email-Zugang Schlüssel hochlade, muss der Angreifer
meinen Email-Zugang ausspähen oder den Server kompromittieren können,
wenn er das auch tun will. Das führt im Fall von Email auch heute schon
zum Supergau - würde aber mit meinem vorgeschlagenen System immerhin dem
Angreifer keinen uneingeschränkten Zugriff auf bestehende
Kommunikationsverbindungen oder auf dem Server liegende verschlüsselte
Emails erlauben.


Viele Grüße
--mendel

--

"Michael" ist kein Name, sondern eine Bevölkerungsgruppe.

http://fiff.de/ Forum InformatikerInnen für Frieden und
gesellschaftliche Verantwortung e.V.

[Michael Mendelsohn]

Am 06.03.2013 20:01, schrieb Lars Gebauer:
> Fakt ist ganz einfach, daß der normale Webseitenbetreiber keine legale
> Möglichkeit hat, die dynamischen IPs mit den Providerlogs abzugleichen.
>
> Infolgedessen kann er die IPs keinem Anschluß und erst recht keiner
> Person zuordnen.
>
> Diese "Datenschützer" verbreiten da eindeutig FUD.

"Diese Datenschützer" machen eine Unterschied zwischen personenbezogenen
und personenbeziehbaren Daten. Um nicht personenbezogen Daten auf dich
beziehen zu können, reicht deinem Supermarkt in Kenntnis deiner
Kaufgewohnheiten oft schon dein Kassenzettel. Da man nicht absehen kann,
wer wann in der Lage ist, diese Beziehung herzustellen, müssen auch
personenbeziehbare Daten geschützt werden - sonst ließe sich jeder
Schutz personenbeozogener Daten trivial unterlaufen.

[Ante Auber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 06.03.2013 21:32, schrieb Volker Delf:

...

> Vermutlich ist dein öffentlicher Schlüssel mit der Schlüssel-ID:
> 0xF12C6DFD (kein Fingerprint!) noch nicht auf den Keyserver
> http://keys.gnupg.net:11371 hochgeladen worden. Er liegt nur lokal
> im Zertifikatsspeicher "Meine Zertifikate" zusammen mit dem
> privaten Schlüssel vor.
>
> mfg Volker
>

Danke Volker, das war es. Ich habe jetzt diesen Schlüssel hochgeladen
und kann ihn auch auf dem Keyserver finden.

Jetzt müsste doch eigentlich jeder, der diesen öffentlichen Schlüssel
benutzt, mir eine verschlüsselte Nachricht senden können, die ich dann
mit meinem privaten Schlüssel dechiffrieren kann.

Nun gut, wenn dem so ist, werde ich mal meiner Frau ein Schlüsselpaar
generieren und sie bitten, mir eine verschlüsselte e-mail zu schicken.
Wenn das funktioniert, hat sie mir nicht ganz umsonst zu Weihnachten
ein dickes Buch über Verschlüsselungstechniken von alten
Babylon-Kartuschen über Enigma und DES resp. RSA bis zur
Quantenkryptographie geschenkt ...

Viele Grüße.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRN66lAAoJEHYsEd/xLG39+88IALQLudEKHy0By91bgBazfgi0
tsNDYEVOE4gaLWJXCrJpUvJhJReG5ZValfj7SJvLyEJagtnNAq9c0N+eManiiZYS
RvGZ/lyfu4TvSBpYqpxUSY66PEp/+2gEYjWnvrgVhJBYMFzamYqBicK8U/yfA6Gc
HfgR8GY0IUcW/EiS55HVKq+SkscgKBKXP+IIt72ijEEPWUxxKkEiPwk4KXcHRAQ/
0kQs6gr4kwYxbAp1TobAEDV06BVBuJ1U73nnYTq1XUb4G14ydNiBdlECzYlGWSCn
+h6hvo02U0I7pmBxenagrerX0/ra1KDIWNMRDKulEoXCKZDRQpwTGp3RUQcRsB4=
=sun9
-----END PGP SIGNATURE-----

[Kai Bojens]

Burkhard Ott <news...@derith.de> wrote:

>> Dazu kommen die Verwaltung der Schlüssel (Laufzeiten!) und Probleme,
>> wenn Mitarbeiter ausscheiden (Nachschlüssel, Recovery, Revoken) und
>> ähnliches.

> Das hat ja nun nichts mit der Schluesseluebergabe zu tuen und ein
> Verfallsdatum kann gesetzt werden. Mit dem revoken das ist so eine Sache,
> was nuetzt es Dir wenn keiner abfragt ob ein bestimmer Schluessel noch
> gueltig ist.

Das Prüfen des Schlüssels gegen eine aktuelle Liste mit zurückgezogenen
Zertifikaten gehört auch mit zu dem Aufwand, der betrieben werden muss.
Grundsätzlich müsste diese Abfrage vor jeder Prüfung des öffentlichen
Schlüssels eines Kommunikationspartners erfolgen.

>> Das kan man alles lösen — allerdings ist der zu betreibende Aufwand
>> immens.

> 2 Schluessel server (+n) (falls mal einer ausfaellt) ist hoher Aufwand?

Du hast jede Menge, der von mir angeführten Probleme ausgelassen. Was
ist zum Beispiel mit dem Vier-Augen Prinzip? Oder die Tatsache, dass
verschlüsselte Dokumente von ausgeschiedenen Mitarbeitern lesbar bleiben
müssen? Wohlgemerkt: Beide Probleme kann man lösen und je nach Verfahren
auch sehr sauber gestalten. Das ist nur eben mit einem relativ hohen
Aufwand verbunden, und das sind eben: Kosten.

[Juergen Ilse]

Hallo,

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:

> Die Authentifizierung der Mailserver untereinander ist ja schon

> erfunden. Ich mï¿œchte end-to-end-Verschlï¿œsselung.

Theoretisch, wenn denn bei TLS auch jeweils zwingend die Zertifikate der
Kommunikationspartner geprueft wuerden. Wenn du selbst einen Mailserver
betreibst, dann konfigzriere ihn doch mal spasseshalber so, dass er Mails
nur noch an Mailserver ausliefert, die TLS unterstuetzen *und* deren Zer-
tifikate er *sicher* pruefen kannm und dann sieh dir an, wem du dann
darueber ueberhaupt noch Mail senden kannst ...

> Technisch ist es sicher mï¿œglich, SMTP um eine Anfrage nach dem Schlï¿œssel
> zu erweitern - Server, die das noch nicht kï¿œnnen, geben dann ja einen
> stinknormalen Fehler zurï¿œck. Man kï¿œnnte auch spezifizieren, dass die MX
> auf einem anderen Port diesen Dienst anbietet - dann gï¿œb's aber Probleme
> mit Firewalls etc.

Dir ist bekannt, dass Firewalls auch manchmal ESMTP-Inspevtion beherrschen
und "non standard SMTP Kommandos" nicht durchlassen? Oftmals wird noch nicht
einmal STARTTLS durchgelassen, weil die Firewall dann den restlichen ESMTP
Dialog nicht mehr mizï¿œesen und auf Standardkonformitaet pruefen koennte ...
Beispiele duer solche Geraete sind (neben *sehr* *vielen* *anderen*)
Cisco PIX & ASA ...

Probleme mit Firewalls wird es also nicht erst dann geben, wenn man
fuer deine Erweiterung einen anderen Port verwendet ...

Tschuess,
Juergen Ilse (jue...@isenet-verwaltung.de)

[Juergen Ilse]

Hallo,

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:

> Am 06.03.2013 17:51, schrieb Juergen Ilse:
>> Es kann mehr als einen MX fuer eine Domain geben. Wie wird der MX fuer die
>> Domain ermittelt?
> Diese Nachteiel hast du bei Email im Moment auch schon, das ist also

> nicht wirklich ein Rï¿œckschritt.

>> Durch DNS? Solange sich DNSSEC nicht wirklich flaechen-
>> Mehraufwand in der Implementierung von Mailserver und Mailclients (denn du
>> muesstest SMTP um diese Funktionaliatet des Schluesseltauschs erweitern,
>> und diese Kommunikation muesste *verschluesselt* ablaufen, um das ein-
>> schleusen fremder Schluessel durch einen MitM zu verhindern, und ...
>> Die Etablierung eines komplett neuen Netzwerkprotokolls fuer dann *sicheren*
>> *verschluesselten* Mail-Versand waere vermutlilch einfacher zu etablieren.

> Mailserver kï¿œnnen bisher per SMTP einliefernde MUAs nicht ï¿œber ein
> verschlï¿œsseltes Protokoll auth'en? Sachen gibts...

Bei E-Mail sprechen nicht nur MUAs mit MTAs sondern auch MTAs untereinander.
letztere authentifizieren sich ueblicherweise nicht gegenseitig (zumindest
mocht mit sicheren Methoden). Den Verzicht auf die Kommunikation mit MTAs,
die sich gegenueber anderen MTAs nicht sivher authentifizieren, kann sich
in der Praxis praktisch niemand erlauben ...

> Aber du kannst das sicher besser beurteilen als ich, wieviel Aufwand das

> wï¿œre. Ich denke, der Aufwand liegt eher darin, auf dem Server einen
> manipulationssicheren key store einzurichten.

Selbst wenn es *nur* das waere, waere es zusaetzlicher Aufwand, fuer
den so gut wie kein Mailnutzer bereit waere, zusaetzlich Geld auszugeben,
der Mailserverbetreiber wird also den zusaetzlichen Aufwand nicht bezahlt
bekommen, folglich wird er den Aufwand auch nicht treiben.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:
> Am 06.03.2013 17:28, schrieb Juergen Ilse:
>> Das garantiert dir exakt gar nichts, solange es einfache Moeglichkeiten
>> gibt, den Absender einer Mail zu faken (und die gibt es).
> Wie? Der Absender ist der einzige, der den private key hat.

Im von dir beschriebenen Szenario hat der Empfaenger bei der "Erst-
Kommunikation" den Schluessel nur aus der gerade empfangenen Mail,
und er hat (bis auf die Absenderadresse der Mail, die sich leicht
faken laesst) noch keinerlei Moeglichkeit, die Echtheit des Keys
zu pruefen. Und wenn dir jemand auf diese Weise einen falschen Key
untergejubelt hat, muesstest du konsequenterweise die anschliessend
vom "echten Absender zugestellten Mails" als Faje betrachten, weil
sie mit dem falschen Key signiert sind, und du worst Mails an diesen
Empfaenger mit dem public Key des Fakers verschluesseln ...
was hast du damit an Sicherheit gewonnen?

>> Wenn du mehrere Schluessel zur selben Mailadresse auf dem Server hast,
>> welchem vertraust du dann? Wer hindert einen "Stoerer" (um ihn nicht
>> gleich "Angreifer" zu nennen), einfach zusaetzliche Schluessel zur
>> selben Mailadresse auf den Key-Server hochzuladen?
> Die Absicherung des Servers und des Anwenderzugangs zu dem Server:

Gibt es kei einem Keyserver nicht, und solange du nicht von jedem
Mailserver die "Identitaet" sicher pruefen kannst, koenntest du bei
deiner Idee "Keystore auf dem Mailserver" noch nicht einmal die
Vertrauenswuerdigkeit der von dort erhaltenen Keys pruefen ...
Du drehst dich im Kreis, willst die notwendige Pruefung der Schluessel
immer weiter von einem zum anderen schiewben, in der Hoffnung, dass
das Problem dadurch evz. irhendwann einmal verschwindet, aber es wird
dadurch nicht verschwinden ...

> also genau dieselben Mechanismen, die einen Angreifer jetzt daran hindern,
> eine normale Email in meinem Namen zu verbreiten.

Es hindert ihn aber kein Mechanismus, wenn die Mail ueber einen Server
versendet wird, der dafuer keine Authentifizierung fordert oder der
die Absenderadresse nicht prueft.

[Stefan Kanthak]

"Michael Mendelsohn" <fern...@news.mendelsohn.de> schrieb:

> Am 06.03.2013 18:58, schrieb Juergen Ilse:
>> Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:
>>> Der Vorteil meiner Lï¿œsung ist, dass der Mailserverbetreiber die Echtheit
>>> bestï¿œtigt - das "Web of Trust" hat sozusagen nur eine Kante. Bei
>>> unverschlï¿œsselter Email vertraue ich meinem Mailserverbertreiber bzw.
>>> dem des Empfï¿œngers ohnehin, insofern ist das jetzt kein Rï¿œckschritt.
>>> Bei einem Schlï¿œssel auf einem ï¿œffentlichen Server ist ohne ein
>>> Nachvollziehen des Web of Trust unsicher, wer den da nun platziert hat -
>>> und dieses Nachvollziehen ist Teil des Aufwands, den ich elimieren
>>> mï¿œchte.
>>
>> Du eliminierst ihn nicht, du schiebst ihn auf den Mailserverbetreiber (der
>> aber den aufwand nicht treiben wird, da er ihn nicht bezahlt bekommt) ...
>
> Der Mailserverbetreiber gibt normalerweise einem Kunden die Mï¿œglichkeit,
> sich gegenï¿œber dem Server auszuweisen.

Gegenueber dem "mail submission server", NICHT gegenueber dem MX: dessen
Aufgabe ist es, von Hinz und Kunz an die eigenen Kunden gesendete Mails
entgegenzunehmen, OHNE Authentifizierung (ja, manche ISP lassen ihre MXe
keine Mails von Dialup-Zugaengen annehmen).

JFTR: fuer die Verteilung von oeffentlichen Schluesseln existieren
Server und Protokolle, u.a. X.509, LDAP, ...

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen ￜ823
Abs. 1 sowie ￜ1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.

[Juergen Ilse]

Hallo,

Heiko Schlenker <hsc...@gmx.de> wrote:
> * Juergen Ilse <jue...@usenet-verwaltung.de> schrieb:

>> Heiko Schlenker <hsc...@gmx.de> wrote:
>>> Der Absender braucht doch bloß öffentlich zugängliche Keyserver zu
>>> konsultieren, um an den öffentlichen Schlüssel des Empfängers zu
>>> gelangen. Die Echtheit des öffentlichen Schlüssels lässt sich mit
>>> digitalen Signaturen nachweisen (Stichworte: Web of Trust
>>> <http://de.wikipedia.org/wiki/Web_of_Trust>).

>> Diese Pruefung setzt voraus, dass jemand, dem *DU* vertraust, die
>> Echtheit des Schluessels bestaetigt hat (indem er den Schluessel
>> bei einem persoenlichen Kontakt mit dem Schluesselinhaber geprueft
>> hat, oder mit dem Scvhluesselinhaber auf *sicherem* Wege den
>> Schluessel getauscht hat).
> Im Fall eines WoT wird gefordert, dass ein Schlüssel möglichst
> mehrfach signiert wird, von verschiedenen Personen.

Das langt nicht. Man muss einen Schluessel, den man als vertrauens-
wuerdig entweder selbst geprueft haben, oder der Schluessel muss von
*mindestens* einer Person (evt. mehreren) geprueft worden sein, denen
man eine gruendliche Pruefung zutraut, und von denen man weiss, dass
sie einen Schluessel nur nach *gruendlicher* *sorgfaeltiger Pruefung
signieren. Allein aus der Zazsache, dass ein Schluessel von irgend
welchen, einem selbst moeglicherweise voellig unbekannten, Personen
signiert worden ist, sagt einem ueber die Vertrauenswierdigkeit der
Schluessel gar nichts aus. Die Beurteilung der Vertrauenswierdigkeit
der Schluessel ist trotz mancher moeglicher Automatismen nicht immer
trivial, und mancher Nutzer wird mit dem sinnvollen Betrieb eines
Web of Trust ueberfordert sein.

> Anders formuliert:
> Die Teilnehmer (Plural!) eines WoT übernehmen die Funktion einer
> Zertifizierungsstelle.

... und nicht jeder hat die Kompetenz und das Wissen, duese Aufgabe
verantwortungsvoll zu uebernehmen.

> Je mehr Personen einen Schlüssel beglaubigen,
> desto höher ist das Vertrauen in die Echtheit des Schlüssels.

Das allein (ohne Betrachtung, *wer* denn die Personen sind, die den
Schluessel signiert haben) ist nicht ausreichend (siehe oben), sonst
koennte jeder eine Gruppe von Fake-Identitaeten mit zugehoerigen
Schluesseln erstellen, die sich alle gegenseitig die Schluessel
signieren, um dadurch bei anderen all diese Fake-Identitaeten
anderen gegenueber vertrauenswuerdig zu machen ...

[Michael Mendelsohn]

Am 06.03.2013 22:57, schrieb Stefan Kanthak:
> "Michael Mendelsohn" <fern...@news.mendelsohn.de> schrieb:
>> Am 06.03.2013 18:58, schrieb Juergen Ilse:
>>> Du eliminierst ihn nicht, du schiebst ihn auf den Mailserverbetreiber (der
>>> aber den aufwand nicht treiben wird, da er ihn nicht bezahlt bekommt) ...
>>

>> Der Mailserverbetreiber gibt normalerweise einem Kunden die Möglichkeit,
>> sich gegenüber dem Server auszuweisen.

>
> Gegenueber dem "mail submission server", NICHT gegenueber dem MX: dessen
> Aufgabe ist es, von Hinz und Kunz an die eigenen Kunden gesendete Mails
> entgegenzunehmen, OHNE Authentifizierung (ja, manche ISP lassen ihre MXe
> keine Mails von Dialup-Zugaengen annehmen).

OK, in kleineren Läden ist das derselbe Server, in größeren müssen die
Informationen weitergereicht werden, das ist dann schon mehr Aufwand.

Dass Dialup-Zugänge nicht angenommen werden, war mir bewusst; nun ist
eine Schlüsselabfrage natürlich keine Maileinlieferung, insofern muss
das nicht dringend geblockt werden, aber wenn der SMTP-Dialog gar nicht
erst zustande kommt, nützt das natürlich wenig. :-(

Das wäre dann ein Argument dafür, entweder die Schlüsselausgabe
außerhalb von SMTP zu machen, oder die Abfrage über die "Infrastruktur"
zu leiten, d.h. der MUA fragt "seinen" Einlieferungsserver, und der
fragt den MX: des gewünschten Empfängers (Vorteil: kann gesicherte
Infrastruktur nutzen, falls vorhanden, Nachteil: Mehraufwand, der eigene
Einlieferungsserverbetreiber sitzt optimal für MitM).

> JFTR: fuer die Verteilung von oeffentlichen Schluesseln existieren
> Server und Protokolle, u.a. X.509, LDAP, ...

LDAP erscheint mir etwas viel Aufwand, um vorauszusetzen, dass jeder das
vorhält? Oder könnte man da alternativ zum vollen LDAP-Service einen
"Leichtserver" anbieten, der nur einen bestimmten Subset des Protokolls
implementiert?

X.509 sieht gut aus; der Mailserver hat eh' selbst ein X509-Zertifikat,
wenn er STARTTLS macht. Kann er das benutzen, um die von ihm verteilten
Userzertifikate zu signieren, oder braucht es dazu eine CA? Dann wär's
wieder sehr viel Aufwand.

Viele Grüße
--mendel

--

"Michael" ist kein Name, sondern eine Bevölkerungsgruppe.

http://fiff.de/ Forum InformatikerInnen für Frieden und
gesellschaftliche Verantwortung e.V.

[Michael Mendelsohn]

Am 06.03.2013 22:29, schrieb Juergen Ilse:
> Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:

>> Technisch ist es sicher mï¿œglich, SMTP um eine Anfrage nach dem Schlï¿œssel
>> zu erweitern - Server, die das noch nicht kï¿œnnen, geben dann ja einen
>> stinknormalen Fehler zurï¿œck. Man kï¿œnnte auch spezifizieren, dass die MX
>> auf einem anderen Port diesen Dienst anbietet - dann gï¿œb's aber Probleme
>> mit Firewalls etc.
>
> Dir ist bekannt, dass Firewalls auch manchmal ESMTP-Inspevtion beherrschen
> und "non standard SMTP Kommandos" nicht durchlassen? Oftmals wird noch nicht
> einmal STARTTLS durchgelassen, weil die Firewall dann den restlichen ESMTP
> Dialog nicht mehr mizï¿œesen und auf Standardkonformitaet pruefen koennte ...
> Beispiele duer solche Geraete sind (neben *sehr* *vielen* *anderen*)
> Cisco PIX & ASA ...

Da verwenden die Anwender also einen Mailserver auf ihrer Seite der
Firewall? Gerade bei sowas wï¿œre es besonders sinnvoll,
end-to-end-Verschlï¿œsselung zu haben...

> Probleme mit Firewalls wird es also nicht erst dann geben, wenn man
> fuer deine Erweiterung einen anderen Port verwendet ...

Da wï¿œre es eher einfacher, auf der Firewall einen Port fï¿œr das
Schlï¿œsselprotokoll aufzumachen, als die ESMTP-Inspektion zu updaten.
Klar.

Viele Grￜￜe
--mendel

--

"Michael" ist kein Name, sondern eine Bevï¿œlkerungsgruppe.

http://fiff.de/ Forum InformatikerInnen fï¿œr Frieden und
gesellschaftliche Verantwortung e.V.

[Juergen Ilse]

Hallo,

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:

> LDAP erscheint mir etwas viel Aufwand, um vorauszusetzen, dass jeder das

> vorhï¿œlt? Oder kï¿œnnte man da alternativ zum vollen LDAP-Service einen

> "Leichtserver" anbieten, der nur einen bestimmten Subset des Protokolls
> implementiert?

LDAP ist bereits "lightweight", wie der Name auch bereits sagt ...

> X.509 sieht gut aus; der Mailserver hat eh' selbst ein X509-Zertifikat,
> wenn er STARTTLS macht. Kann er das benutzen, um die von ihm verteilten

> Userzertifikate zu signieren, oder braucht es dazu eine CA? Dann wï¿œr's
> wieder sehr viel Aufwand.

Wenn du ohne eine oder mehrere CAs auskommen willst: wie soll dann der
Mailserver die "Identitaet" des Mailservers "auf der andere Seite" anhand
des Zertifikats pruefen koennen? Auch das ist eine Form der Schluessel-
verwaltung (im Gegensatz zum Web of Trust aber eine zentralisierte), und
eine solche bedeutet eben Aufwand und Kosten, wenn das wirklich halbwegs
sicher funktionieren soll (Kosten und Aufwand, den der Mailserverbetreiber
nicht bezahlt bekommt, weil der Kunde nicht bereit ist, dafuer Geld aus-
zugeben). Das (und die daraus resultierende Bereitschaft der Mailserver-
betreiber, diesen Aufwand zu investieren, wenn sie es nicht bezahlt
bekommen) ist die heutige Realitaet.

[Michael Mendelsohn]

Am 06.03.2013 22:39, schrieb Juergen Ilse:
> Selbst wenn es *nur* das waere, waere es zusaetzlicher Aufwand, fuer
> den so gut wie kein Mailnutzer bereit waere, zusaetzlich Geld auszugeben,
> der Mailserverbetreiber wird also den zusaetzlichen Aufwand nicht bezahlt
> bekommen, folglich wird er den Aufwand auch nicht treiben.

Da beißt sich ja gerade die Katze in den Schwanz: im Moment ist Krypto
für die Anwender zu viel Aufwand gegenüber dem wahrgenommenen Nutzen,
also fragen das nur wenige nach, also bietet es kaum jemand an.

Deswegen fand ich ja Antes naive Idee, einfach mal beim Erstkontakt den
Public key mitzuschicken und den ab dann zu verwenden, so attraktiv: da
kann man mit Krypto anfangen, ohne dass es jemand unterstützen muss
(außer den MUA-Programmierern, bzw. geeigneten Plugins, aber dass die
MUAs Krypto im Prinzip können, dafür reicht die Nachfrage ja schon), für
einen kleinen Gewinn an Sicherheit; das erzeugt dann Nachfrage nach mehr
Sicherheit: bei dem Verfahren mit dem an den Mailserver gebundenen
Schlüsselserver haben wir das, ohne das der Nutzer dazu mehr Aufwand
treiben muss, als das bei seinem Provider einzufordern; und der Weg hin
zur "vollen" Sicherheit mit allem, was hier in der Diskussion gefordert
worden ist, steht offen, so dass die Anwender ihn gehen können, wenn sie
den Nutzen sehen. (Deswegen hatte ich ja Fingerprint-QR-Codes
vorgeschlagen: wenn mein Desktop-Computer den Fingerprint als QR-Code
anzeigen kann, brauche ich nur ein Smartphone-App, um das mit einem
sicheren Referenzcode vergleichen zu können.) Dadurch, dass die Anwender
dann aber schon an Krypto gewohnt sind, ist der Mehraufwand geringer als
er jetzt ist, d.h. das würde sich dann für viele Leute in mehr
Situationen rentieren als heute. Dass hingegen heutige Nutzer von
Email-Krypto Abstriche an ihrer Sicherheit machen, ist ja weder nötig
noch zu erwarten.

Wenn die Computerblättchen an der Tanke ihren Lesern Tipps der Art "so
steigern sie ihre Email-Sicherheit" verkaufen können, dann sind wir auf
dem richtigen Weg.

Mit der "ganz oder gar nicht"-Haltung gibt's eben viele Leute, die "gar
nicht" wählen - und dann bewegt sich wenig.

[Michael Mendelsohn]

Am 06.03.2013 22:58, schrieb Juergen Ilse:
> Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:
>> Am 06.03.2013 17:28, schrieb Juergen Ilse:
>>> Das garantiert dir exakt gar nichts, solange es einfache Moeglichkeiten
>>> gibt, den Absender einer Mail zu faken (und die gibt es).
>> Wie? Der Absender ist der einzige, der den private key hat.
>
> Im von dir beschriebenen Szenario hat der Empfaenger bei der "Erst-
> Kommunikation" den Schluessel nur aus der gerade empfangenen Mail,
> und er hat (bis auf die Absenderadresse der Mail, die sich leicht
> faken laesst) noch keinerlei Moeglichkeit, die Echtheit des Keys
> zu pruefen. Und wenn dir jemand auf diese Weise einen falschen Key
> untergejubelt hat, muesstest du konsequenterweise die anschliessend
> vom "echten Absender zugestellten Mails" als Faje betrachten, weil
> sie mit dem falschen Key signiert sind, und du worst Mails an diesen
> Empfaenger mit dem public Key des Fakers verschluesseln ...
> was hast du damit an Sicherheit gewonnen?

Du kannst aus meiner Sicht den Absendernamen faken, aber nicht den
Absender. Im Detail: Es gibt Absender A und Absender B. Absender A
schickt dir eine verschlüsselte Email, sagt aber, er sei Absender B.
Dann kann Absender B keine Email von Absender A faken, Emails an
Absender B kann dieser nicht lesen, weil er nicht Absender A ist. Der
private/public key identifiziert Sendungen von Absender A (und an ihn!)
absolut (sichere Aufbewahrung des Schlüssels vorausgesetzt), unabhängig
vom Namen, den er benutzt.

Was habe ich an Sicherheit gewonnen? Wenn B sich bei mir beschwert, kann
ich eine Ermittlung starten, welche Emails nun gefälscht und welche echt
sind, und ich kann an den Schlüsseln zuordnen, welche
Absenderidentitäten im Spiel sind. Bei Email ganz ohne Schlüssel kann
ich den Fake nicht "formal", sondern nur an verdächtig erscheinenden
Inhalten bemerken, und ich habe es schwerer, im Nachhinein die Fakes
auszusortieren. Der Gewinn ist nicht groß (schon gar nicht
größtmöglich), aber er ist da.

>>> Wenn du mehrere Schluessel zur selben Mailadresse auf dem Server hast,
>>> welchem vertraust du dann? Wer hindert einen "Stoerer" (um ihn nicht
>>> gleich "Angreifer" zu nennen), einfach zusaetzliche Schluessel zur
>>> selben Mailadresse auf den Key-Server hochzuladen?
>> Die Absicherung des Servers und des Anwenderzugangs zu dem Server:
>
> Gibt es kei einem Keyserver nicht, und solange du nicht von jedem
> Mailserver die "Identitaet" sicher pruefen kannst, koenntest du bei
> deiner Idee "Keystore auf dem Mailserver" noch nicht einmal die
> Vertrauenswuerdigkeit der von dort erhaltenen Keys pruefen ...

Ich gehe halt davon aus, dass jeder, der eine Mailadresse benutzt, für
diese Adresse einen Mailaccount hat, zu dem nur er Zugang hat. Über
diesen Zugang muss dann die Zuordnung des Schlüssels zur Mailadresse
erfolgen. Damit ist der Keystore genauso vertrauenswürdig wie die
Zustellung der Email selbst es bisher schon ist.

(In Ausnahmefällen ist das nicht so; es gab (gibt?) Mailserver mit
öffentlichen Fächern, die man ohne Zugang abfragen konnte. Sowas fällt
dann natürlich aus dem Schema raus.)

> Du drehst dich im Kreis, willst die notwendige Pruefung der Schluessel
> immer weiter von einem zum anderen schiewben, in der Hoffnung, dass
> das Problem dadurch evz. irhendwann einmal verschwindet, aber es wird
> dadurch nicht verschwinden ...

Nein, ich will es nicht hin- und herschieben, ich will den zu einer
Mailadresse assoziierten Key an den Zugang zum entsprechenden
Mailpostfach binden. Logisch?

>> also genau dieselben Mechanismen, die einen Angreifer jetzt daran hindern,
>> eine normale Email in meinem Namen zu verbreiten.
>
> Es hindert ihn aber kein Mechanismus, wenn die Mail ueber einen Server
> versendet wird, der dafuer keine Authentifizierung fordert oder der
> die Absenderadresse nicht prueft.

Ok, das habe ich schlecht formuliert. Es ist derselbe Mechanismus, der
den Angreifer daran hindert, eine Email in meinem Namen vom Server
meines Providers aus zu versenden. Der tut das nämlich, was du forderst.

Das war ja auch die Grundlage zu der Idee: wenn der Server meine
Authentifizierung prüfen kann, dann kann er zu den
Authentifizierungsdaten auch meinen public key aufbewahren und den auf
Anfrage weitergeben. Hat den Zusatzvorteil, dass er dann meinem MUA
anbieten kann, sich über meinen Schlüssel und nicht mehr über Passwort
zu identifizieren -> Sicherheitsgewinn.

[Michael Mendelsohn]

Am 07.03.2013 10:09, schrieb Juergen Ilse:
> Hallo,
>
> Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:
>> LDAP erscheint mir etwas viel Aufwand, um vorauszusetzen, dass jeder das

>> vorhält? Oder könnte man da alternativ zum vollen LDAP-Service einen

>> "Leichtserver" anbieten, der nur einen bestimmten Subset des Protokolls
>> implementiert?
>
> LDAP ist bereits "lightweight", wie der Name auch bereits sagt ...
>
>> X.509 sieht gut aus; der Mailserver hat eh' selbst ein X509-Zertifikat,
>> wenn er STARTTLS macht. Kann er das benutzen, um die von ihm verteilten

>> Userzertifikate zu signieren, oder braucht es dazu eine CA? Dann wär's

>> wieder sehr viel Aufwand.
>
> Wenn du ohne eine oder mehrere CAs auskommen willst: wie soll dann der
> Mailserver die "Identitaet" des Mailservers "auf der andere Seite" anhand
> des Zertifikats pruefen koennen?

Das sich der Mailserverbetreiber bei einer externen CA einmal ein
Zertifikat für seinen Server ausstellen lässt, ist weniger Aufwand, als
wenn er das für jeden Schlüssel jedes seiner Kunden tun müsste.

> Auch das ist eine Form der Schluessel-
> verwaltung (im Gegensatz zum Web of Trust aber eine zentralisierte), und
> eine solche bedeutet eben Aufwand und Kosten, wenn das wirklich halbwegs
> sicher funktionieren soll (Kosten und Aufwand, den der Mailserverbetreiber
> nicht bezahlt bekommt, weil der Kunde nicht bereit ist, dafuer Geld aus-
> zugeben). Das (und die daraus resultierende Bereitschaft der Mailserver-
> betreiber, diesen Aufwand zu investieren, wenn sie es nicht bezahlt
> bekommen) ist die heutige Realitaet.
>
> Tschuess,
> Juergen Ilse (jue...@usenet-verwaltung.de)
>

[Juergen Ilse]

Hallo,

Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:

> Deswegen fand ich ja Antes naive Idee, einfach mal beim Erstkontakt den
> Public key mitzuschicken und den ab dann zu verwenden, so attraktiv: da

> kann man mit Krypto anfangen, ohne dass es jemand unterstï¿œtzen muss

... und man kann es auch gleich sein lassen, weil damit dann keines der
*eigentlichen* Ziele, die man mit Crypto ueblicherweise erreichen will,
erreichen kann (es fehlt immer die notwendige Verifizierung der Schluessel).
Damit man mit Crypto die Ziele erreicht, fuer die man es ueblicherweise
einsetzt, muss zusaetzlicher Aufwand getrieben werden: wahlweise beim
Enduser (der das i.d.R. nicht tun will, weil er den aufwand scheut) oder
beim Provider (der den fuer ihn zusaetzlichen Aufwand nicht bezahlt bekaeme
und deswegen das erst gar nmicht anbietet, weil es ihm keinen Nutzen, dafuer
aber Kosten und aufwand beschert).

> Wenn die Computerblï¿œttchen an der Tanke ihren Lesern Tipps der Art "so
> steigern sie ihre Email-Sicherheit" verkaufen kï¿œnnen, dann sind wir auf
> dem richtigen Weg.

Wenn es den 08/15 Enduser entweder zusaetzlichen Aufwand oder zusaetzliches
Geld kostet, ist es fuer die meisten 08/15 User uninteressant. Leider ist
aber mindestens eins von beiden zwangslaeufig der Fall (sofern man damit
wirklich mehr Sicherheit erreichen und nicht nur "Crypto um der Crypto willen"
betreiben will).

[Lars Gebauer]

* Michael Mendelsohn:

> Am 06.03.2013 20:01, schrieb Lars Gebauer:

>> Fakt ist ganz einfach, daￜ der normale Webseitenbetreiber keine
>> legale Mï¿œglichkeit hat, die dynamischen IPs mit den Providerlogs
>> abzugleichen.
>>
>> Infolgedessen kann er die IPs keinem Anschluￜ und erst recht
>> keiner Person zuordnen.
>>
>> Diese "Datenschï¿œtzer" verbreiten da eindeutig FUD.
>
> "Diese Datenschï¿œtzer" machen eine Unterschied zwischen
> personenbezogenen und personenbeziehbaren Daten.

ROTFL - Seit wann denn /das/?

> Um nicht personenbezogen Daten auf dich beziehen zu kï¿œnnen, reicht

> deinem Supermarkt in Kenntnis deiner Kaufgewohnheiten oft schon dein
> Kassenzettel. Da man nicht absehen kann, wer wann in der Lage ist,

> diese Beziehung herzustellen, mï¿œssen auch personenbeziehbare Daten
> geschï¿œtzt werden - sonst lieï¿œe sich jeder Schutz personenbeozogener
> Daten trivial unterlaufen.

Siehst Du, noch nicht mal Du machst diesen Unterschied.

Praktisch jedes Datum, welches in Zusammenhang mit einem Menschen
anfï¿œllt, ist personenbeziehbar und nach einem gewissen Aufwand auch
personenbezogen.

1.) Wo soll dieser Irrsinn eigentlich hinfï¿œhren und 2.) warum sollte es
mich eigentlich stï¿œren, wenn der Supermarkt meint, meine Kaufgewohheiten
zu kennen.

Ganz im Gegenteil. Ich finde die "Kunden die $X kauften kauften auch
$Y"-Funktion eher nï¿œtzlich.

Nein, dieser ganze Datenschutz-Mumpf schadet - nachhaltig - kleineren
Unternehmen und privilegiert gleichzeitig grￜￜere und groￜe Unternehmen.

Das ist ein Effekt, der in vielen anderen Bereichen wohlbekannt ist. Da
werden aus rein religiï¿œsen Grï¿œnden so hohe Zulassungshï¿œrden aufgebaut,
an denen kleine aber mï¿œglicherweise innovative Unternehmen umgehend
scheitern wï¿œhrenddessen diese von Groï¿œunternehmen problemlos
ï¿œbersprungen werden kï¿œnnen. Erreicht wird das exakte Gegenteil dessen,
was man - angeblich(!) - mï¿œchte. (Ich persï¿œnlich glaube noch nicht mal
an das "angeblich". Ich denke viel eher, daￜ da ganz bewuￜt gelogen und
getï¿œuscht wird.)

[Volker Birk]

Lars Gebauer <lgeb...@arcor.de> wrote:
> 1.) Wo soll dieser Irrsinn eigentlich hinführen und 2.) warum sollte es
> mich eigentlich stören, wenn der Supermarkt meint, meine Kaufgewohheiten
> zu kennen.

Stimmt, Du hast ja nichts zu verbergen.

> Nein, dieser ganze Datenschutz-Mumpf schadet - nachhaltig - kleineren

> Unternehmen und privilegiert gleichzeitig größere und große Unternehmen.

Bull-Shit.

Lars, vergiss es. Nur weil Du nicht verstehst, was andere machen, heisst
das noch lange nicht, dass da nichts ist, was nachvollziehbar wäre.

Es heisst nur, dass Du keinen Bock hast, Dich überhaupt zu kümmern. Auf
unreflektiertes Rumtrollen hier scheinst Du dagegen Lust zu haben. Man
merkt es schon an der Unqualifiziertheit Deiner Kritik: eben
Dumpfbacken-Getrolle.

Viele Grüsse,
VB.
--
“Schicken Sie uns Ihre Söhne für den Krieg, es wird sich für Sie lohnen,
an der Tankstelle!”

(Georg Schramm)

[Lars Gebauer]

* Volker Birk:

> Lars Gebauer <lgeb...@arcor.de> wrote:
>> 1.) Wo soll dieser Irrsinn eigentlich hinführen und 2.) warum
>> sollte es mich eigentlich stören, wenn der Supermarkt meint, meine
>> Kaufgewohheiten zu kennen.
>
> Stimmt, Du hast ja nichts zu verbergen.

Na, dann kläre mich doch mal auf. Was sollte ich denn in dieser Hinsicht
zu verbergen haben?

>> Nein, dieser ganze Datenschutz-Mumpf schadet - nachhaltig -
>> kleineren Unternehmen und privilegiert gleichzeitig größere und
>> große Unternehmen.
>
> Bull-Shit.

So?

> Lars, vergiss es. Nur weil Du nicht verstehst, was andere machen,
> heisst das noch lange nicht, dass da nichts ist, was nachvollziehbar
> wäre.

Du irrst. Ich verstehe sehr wohl, was da getrieben wird. Beginnend
damit, daß "Datenschutzbeauftragter" ein hübsch dotiertes Pöstchen ist,
dessen Existenzberechtigung nun um jeden Preis nachgewiesen werden muß.

[Juergen Ilse]

Hallo,

Lars Gebauer <lgeb...@arcor.de> wrote:
> 1.) Wo soll dieser Irrsinn eigentlich hinführen und 2.) warum sollte es
> mich eigentlich stören, wenn der Supermarkt meint, meine Kaufgewohheiten
> zu kennen.

Weil es sie nichts angeht. Weil sie Daten ueber mich sammeln, die ich evt.
gar nicht an die geben moechte, weil sie Daten kombinieren ("zusammen-
fuehren") die sie vielleicht gar nicht zusammenfuehren *duerfen*.

> Ganz im Gegenteil. Ich finde die "Kunden die $X kauften kauften auch

> $Y"-Funktion eher nützlich.

Ich nicht.

> Nein, dieser ganze Datenschutz-Mumpf schadet - nachhaltig - kleineren

> Unternehmen und privilegiert gleichzeitig größere und große Unternehmen.

IMHO ist eigentlich sogar das Gegenteil der Fall: die Firmen, die nicht
auf grosse "bie Kunden gsammelte Datenbestaende" zurueckgreifen koennen,
weil sie nicht so viele Kunden haben, die firmen mit kleineren Gewinnen,
die sich den Einkauf solcher "zusammengefuehrter Daten" leisten koennen,
diese Firmen muessen damit rechnen, sich ggfs. Nachteile einzufangen, und
das sind nicht die marktbeherrschenden Riesen ...

Tschuess,
Juergen Ilse (jue...@zusenet-verwaltung.de)

[Volker Birk]

Lars Gebauer <lgeb...@arcor.de> wrote:
> * Volker Birk:
>> Lars Gebauer <lgeb...@arcor.de> wrote:
>>> 1.) Wo soll dieser Irrsinn eigentlich hinführen und 2.) warum
>>> sollte es mich eigentlich stören, wenn der Supermarkt meint, meine
>>> Kaufgewohheiten zu kennen.
>> Stimmt, Du hast ja nichts zu verbergen.
> Na, dann kläre mich doch mal auf. Was sollte ich denn in dieser Hinsicht
> zu verbergen haben?

Nichts, nicht das geringste. Im Gegenteil. Sicher wirst Du hier gleich
eine Liste Deiner letzten fünf Sexualpartner mit Anschrift und
Telefonnummern schreiben zusammen mit einer kurzen Bewertung, dazu Deine
Bankverbindung und die PIN für's Onlinebanking. Ausserdem eine kurze
Liste Deiner Geschäftspartner, und mit wem davon Du wieviel Umsatz mit
was genau machst. Eine kurze Darstellung Deiner genauen finanziellen
Situation wäre noch hilfreich, bitte, mit den jeweiligen Zugangsdaten
für Kredite und Kapitalanlagen.

Ach ja, Dein Bewegungsprofil wäre noch nett. Wir wüssten alle gerne,
wann Du Dich wo immer aufgehalten hast die letzten fünf Jahre, und wen
Du dort getroffen hast. Vielleicht noch ein kleiner Bericht, was jeweils
das Gesprächsthema war?

Wie, das geht mich alles einen Scheissdreck an? Das sei Dein
Privatleben? Ja, hast Du denn doch etwas zu verbergen? ;-)

>>> Nein, dieser ganze Datenschutz-Mumpf schadet - nachhaltig -
>>> kleineren Unternehmen und privilegiert gleichzeitig größere und
>>> große Unternehmen.
>> Bull-Shit.
> So?

Nein. Eigentlich ohne Bindestrich: Bullshit.

>> Lars, vergiss es. Nur weil Du nicht verstehst, was andere machen,
>> heisst das noch lange nicht, dass da nichts ist, was nachvollziehbar
>> wäre.
> Du irrst.

Neinein, der Satz war ganz ernst gemeint ;-)

> Ich verstehe sehr wohl, was da getrieben wird. Beginnend damit, daß
> "Datenschutzbeauftragter" ein hübsch dotiertes Pöstchen ist, dessen
> Existenzberechtigung nun um jeden Preis nachgewiesen werden muß.

Du hast also wirklich rein gar keine Ahnung. Nun, nicht dass mich das
jetzt überrascht, natürlich.

[Juergen Ilse]

Hallo,

[ INGRID wegen Korrektur einiger Fipptehler und hinzufuegen eines Woertchens
*nicht*, das mir vorher irgendwie beim tippen abhanden kam ... ]

Lars Gebauer <lgeb...@arcor.de> wrote:
> 1.) Wo soll dieser Irrsinn eigentlich hinfï¿œhren und 2.) warum sollte es
> mich eigentlich stï¿œren, wenn der Supermarkt meint, meine Kaufgewohheiten
> zu kennen.

Weil es sie nichts angeht. Weil sie Daten ueber mich sammeln, die ich evt.
gar nicht an die geben moechte, weil sie Daten kombinieren ("zusammen-
fuehren") die sie vielleicht gar nicht zusammenfuehren *duerfen*.

> Ganz im Gegenteil. Ich finde die "Kunden die $X kauften kauften auch
> $Y"-Funktion eher nï¿œtzlich.

Ich nicht.

> Nein, dieser ganze Datenschutz-Mumpf schadet - nachhaltig - kleineren
> Unternehmen und privilegiert gleichzeitig grￜￜere und groￜe Unternehmen.

IMHO ist eigentlich sogar das Gegenteil der Fall: die Firmen, die nicht

auf grosse "bei Kunden gsammelte Datenbestaende" zurueckgreifen koennen,
weil sie nicht so viele Kunden haben, die Firmen mit kleineren Gewinnen,
die sich den Einkauf solcher "zusammengefuehrter Daten" *nicht* leisten
koennen oder wollen, diese Firmen muessen damit rechnen, sich ggfs. Nach-

[Lars Gebauer]

* Volker Birk:
> Lars Gebauer <lgeb...@arcor.de> wrote:
>> * Volker Birk:
>>> Lars Gebauer <lgeb...@arcor.de> wrote:
>>>> 1.) Wo soll dieser Irrsinn eigentlich hinführen und 2.) warum
>>>> sollte es mich eigentlich stören, wenn der Supermarkt meint,
>>>> meine Kaufgewohheiten zu kennen.
>>> Stimmt, Du hast ja nichts zu verbergen.
>> Na, dann kläre mich doch mal auf. Was sollte ich denn in dieser
>> Hinsicht zu verbergen haben?
>
> Nichts, nicht das geringste.

Siehst Du.

> Im Gegenteil. Sicher wirst Du hier gleich eine Liste Deiner letzten
> fünf Sexualpartner mit Anschrift und Telefonnummern schreiben
> zusammen mit einer kurzen Bewertung, dazu Deine Bankverbindung und
> die PIN für's Onlinebanking. Ausserdem eine kurze Liste Deiner
> Geschäftspartner, und mit wem davon Du wieviel Umsatz mit was genau
> machst. Eine kurze Darstellung Deiner genauen finanziellen Situation
> wäre noch hilfreich, bitte, mit den jeweiligen Zugangsdaten für
> Kredite und Kapitalanlagen.
>
> Ach ja, Dein Bewegungsprofil wäre noch nett. Wir wüssten alle gerne,
> wann Du Dich wo immer aufgehalten hast die letzten fünf Jahre, und
> wen Du dort getroffen hast. Vielleicht noch ein kleiner Bericht, was
> jeweils das Gesprächsthema war?

Volker, Du bist nur begrenzt lustig. Sehr begrenzt. Wirklich.

Es ging ganz konkret um meine Kaufgewohnheiten im Supermarkt. Ganz
offensichtlich fällt Dir /da zu/ nichts ein. Vielleicht schaffst Du es
auch nicht, da ein bischen zu differenzieren. Weswegen Du meinst, hier
abschweifen zu müssen.

> Wie, das geht mich alles einen Scheissdreck an? Das sei Dein
> Privatleben? Ja, hast Du denn doch etwas zu verbergen? ;-)

In der Tat, Volker. *Selbstverständlich* hüte ich eifersüchtig meine
kleinen (und großen) dreckigen Geheimnisse. Nur, das geschieht
vollkommen unabhängig von irgendeinem Datenschutz-Kokolores. Ich wäre
diesbezüglich nie so blöde, mich ausgerechnet darauf zu verlassen.

Abgesehen davon: Etliches von dem, was Du oben (abschweifenderweise)
aufgezählt hast, das ist quasi-öffentlich. Nur wirst Du davon recht
wenig im Netz finden. Du müßtest schon herkommen, die richtigen Personen
befragen usw. Also selbst recherchieren.

Umgekehrt könnte ich via klassische Recherche auch eine Menge über Dich
in Erfahrung bringen. Wenn ich wollte. (Aber dafür ist mir meine Zeit zu
schade.)

Und Dein Datenschutz hilft Dir dabei kein bischen.

[Stefan Kanthak]

"Michael Mendelsohn" <fern...@news.mendelsohn.de> schrieb:

> Am 06.03.2013 22:39, schrieb Juergen Ilse:
>> Selbst wenn es *nur* das waere, waere es zusaetzlicher Aufwand, fuer
>> den so gut wie kein Mailnutzer bereit waere, zusaetzlich Geld auszugeben,
>> der Mailserverbetreiber wird also den zusaetzlichen Aufwand nicht bezahlt
>> bekommen, folglich wird er den Aufwand auch nicht treiben.
>
> Da beißt sich ja gerade die Katze in den Schwanz: im Moment ist Krypto
> für die Anwender zu viel Aufwand gegenüber dem wahrgenommenen Nutzen,
> also fragen das nur wenige nach, also bietet es kaum jemand an.
>
> Deswegen fand ich ja Antes naive Idee, einfach mal beim Erstkontakt den
> Public key mitzuschicken und den ab dann zu verwenden, so attraktiv:

Genau das machen die ueblichen MUAs doch, wenn Du eine Mail signierst:
sie senden den oeffentlichen Schluessel mit.
Nur DARFST Du den nicht ohne Pruefung verwenden, wenn Du Kryptografie
richtig nutzen willst: JEDER kann eine Mail mit Absender
<fern...@news.mendelsohn.de> erzeugen und einen oeffentlichen Schluessel
fuer diese Mail-Adresse anhaengen!

[...]

> Dass hingegen heutige Nutzer von Email-Krypto Abstriche an ihrer
> Sicherheit machen, ist ja weder nötig noch zu erwarten.

OHNE Pruefung (der Authentizitaet) der Schluessel gaukelt Email-Krypto
nur SCHEINBARE Sicherheit vor.

> Wenn die Computerblättchen an der Tanke ihren Lesern Tipps der Art "so
> steigern sie ihre Email-Sicherheit" verkaufen können, dann sind wir auf
> dem richtigen Weg.
>
> Mit der "ganz oder gar nicht"-Haltung gibt's eben viele Leute, die "gar
> nicht" wählen - und dann bewegt sich wenig.

OHNE Kenntnis der Grundlagen, dass und wie die Authentizitaet eines
oeffentlichen Schluessels zu pruefen ist, geht's aber nicht!

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.

[Lars Gebauer]

* Juergen Ilse:

> Lars Gebauer <lgeb...@arcor.de> wrote:
>> 1.) Wo soll dieser Irrsinn eigentlich hinfï¿œhren und 2.) warum sollte es
>> mich eigentlich stï¿œren, wenn der Supermarkt meint, meine Kaufgewohheiten
>> zu kennen.
>
> Weil es sie nichts angeht.

Es geht also ums Prinzip. Willkommen in der Datenschutz-Kirche.

> Weil sie Daten ueber mich sammeln, die ich evt.
> gar nicht an die geben moechte, weil sie Daten kombinieren ("zusammen-
> fuehren") die sie vielleicht gar nicht zusammenfuehren *duerfen*.

Diese Heilige Einfalt scheitert schon am geltenden Recht in D. (Von
anderen Lï¿œndern will ich gar nicht anfangen.)

>> Nein, dieser ganze Datenschutz-Mumpf schadet - nachhaltig - kleineren
>> Unternehmen und privilegiert gleichzeitig grￜￜere und groￜe Unternehmen.
>
> IMHO ist eigentlich sogar das Gegenteil der Fall: die Firmen, die nicht
> auf grosse "bei Kunden gsammelte Datenbestaende" zurueckgreifen koennen,
> weil sie nicht so viele Kunden haben, die Firmen mit kleineren Gewinnen,
> die sich den Einkauf solcher "zusammengefuehrter Daten" *nicht* leisten
> koennen oder wollen, diese Firmen muessen damit rechnen, sich ggfs. Nach-
> teile einzufangen, und das sind nicht die marktbeherrschenden Riesen ...

Das hast Du jetzt zwar entsetzlich umstï¿œndlich ausgedrï¿œckt aber ja, nach
mehrmaligem Durchlesen: Du hast exakt das wiederholt, was ich
geschrieben hatte. Wir sind uns also in diesem Punkt einig.

[Volker Birk]

Lars Gebauer <lgeb...@arcor.de> wrote:
> * Volker Birk:

>> Im Gegenteil. Sicher wirst Du hier gleich eine Liste Deiner letzten
>> fünf Sexualpartner mit Anschrift und Telefonnummern schreiben
>> zusammen mit einer kurzen Bewertung, dazu Deine Bankverbindung und
>> die PIN für's Onlinebanking. Ausserdem eine kurze Liste Deiner
>> Geschäftspartner, und mit wem davon Du wieviel Umsatz mit was genau
>> machst. Eine kurze Darstellung Deiner genauen finanziellen Situation
>> wäre noch hilfreich, bitte, mit den jeweiligen Zugangsdaten für
>> Kredite und Kapitalanlagen.
>> Ach ja, Dein Bewegungsprofil wäre noch nett. Wir wüssten alle gerne,
>> wann Du Dich wo immer aufgehalten hast die letzten fünf Jahre, und
>> wen Du dort getroffen hast. Vielleicht noch ein kleiner Bericht, was
>> jeweils das Gesprächsthema war?
> Volker, Du bist nur begrenzt lustig. Sehr begrenzt. Wirklich.

Ich hab Dich mal mit der Nase draufgestossen. Wenn Du jetzt noch einen
Schritt zurück gehst, wirst Du sehen, um was es geht.

> Es ging ganz konkret um meine Kaufgewohnheiten im Supermarkt. Ganz
> offensichtlich fällt Dir /da zu/ nichts ein.

Ganz im Gegenteil. Aber wenn ich Dich derart undifferenziert über “die
Datenschützer” lamentieren höre, so ist mal eine Rosskur angesagt. Falls
wir dadurch den Konsens bekommen, dass Privatheit (wie es ja richtig
übersetzt aus dem englischen “Privacy” heissen muss) eben nicht völlig
überflüssig ist, sondern man muss diskutieren, welche Menschen vor wem
geschützt werden müssen, der Daten über sie sammelt, dann haben wir
einen Diskussionsanfang.

Dann können wir auch differenzieren und darüber sprechen, was denn im
Falle eines Einkaufs im Supermarkt in Ordnung geht, und wo der Spass
auch da aufhört.

Vorher ist jede Diskussion sinnlos.

Nun meine Frage an Dich: sind wir jetzt soweit? Können wir mal das
Global-Gebashe weglassen, und differenziert diskutieren? Gerne stecke
ich die rhetorische Keule dann wieder ein und greife stattdessen zum
Florett ;-)

Falls Du weiter den Morgenstern bevorzugst: bitte.

[Stefan Kanthak]

"Michael Mendelsohn" <fern...@news.mendelsohn.de> schrieb:

> Am 06.03.2013 22:58, schrieb Juergen Ilse:
>> Michael Mendelsohn <fern...@news.mendelsohn.de> wrote:
>>> Am 06.03.2013 17:28, schrieb Juergen Ilse:
>>>> Das garantiert dir exakt gar nichts, solange es einfache Moeglichkeiten
>>>> gibt, den Absender einer Mail zu faken (und die gibt es).
>>> Wie? Der Absender ist der einzige, der den private key hat.
>>
>> Im von dir beschriebenen Szenario hat der Empfaenger bei der "Erst-
>> Kommunikation" den Schluessel nur aus der gerade empfangenen Mail,
>> und er hat (bis auf die Absenderadresse der Mail, die sich leicht
>> faken laesst) noch keinerlei Moeglichkeit, die Echtheit des Keys
>> zu pruefen. Und wenn dir jemand auf diese Weise einen falschen Key
>> untergejubelt hat, muesstest du konsequenterweise die anschliessend
>> vom "echten Absender zugestellten Mails" als Faje betrachten, weil
>> sie mit dem falschen Key signiert sind, und du worst Mails an diesen
>> Empfaenger mit dem public Key des Fakers verschluesseln ...
>> was hast du damit an Sicherheit gewonnen?
>
> Du kannst aus meiner Sicht den Absendernamen faken, aber nicht den
> Absender. Im Detail: Es gibt Absender A und Absender B. Absender A

> schickt dir eine verschl�ｿｽsselte Email, sagt aber, er sei Absender B.

> Dann kann Absender B keine Email von Absender A faken, Emails an
> Absender B kann dieser nicht lesen, weil er nicht Absender A ist. Der
> private/public key identifiziert Sendungen von Absender A (und an ihn!)

> absolut (sichere Aufbewahrung des Schl�ｿｽssels vorausgesetzt), unabh�ｿｽngig

> vom Namen, den er benutzt.

JEDER kann sich einen privaten und oeffentlichen Schluessel fuer JEDE
beliebige Mail-Adresse erstellen. Selbst-signierte X.509-Zertifikate
existieren.

[...]

> Ich gehe halt davon aus, dass jeder, der eine Mailadresse benutzt, f�ｿｽr
> diese Adresse einen Mailaccount hat, zu dem nur er Zugang hat. �ｿｽber
> diesen Zugang muss dann die Zuordnung des Schl�ｿｽssels zur Mailadresse
> erfolgen. Damit ist der Keystore genauso vertrauensw�ｿｽrdig wie die

> Zustellung der Email selbst es bisher schon ist.

AUTSCH! Die Zustellung von Email ist GANZ UND GAR NICHT vertrauenswuerdig!

> (In Ausnahmef�ｿｽllen ist das nicht so; es gab (gibt?) Mailserver mit
> �ｿｽffentlichen F�ｿｽchern, die man ohne Zugang abfragen konnte. Sowas f�ｿｽllt
> dann nat�ｿｽrlich aus dem Schema raus.)

>
>
>> Du drehst dich im Kreis, willst die notwendige Pruefung der Schluessel
>> immer weiter von einem zum anderen schiewben, in der Hoffnung, dass
>> das Problem dadurch evz. irhendwann einmal verschwindet, aber es wird
>> dadurch nicht verschwinden ...
>
> Nein, ich will es nicht hin- und herschieben, ich will den zu einer
> Mailadresse assoziierten Key an den Zugang zum entsprechenden
> Mailpostfach binden. Logisch?

Nein, inhaerent UNSICHER!
Mailboxen werden immer wieder mit minimalem Aufwand geknackt.

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen �ｿｽ823
Abs. 1 sowie �ｿｽ1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.

[Lars Gebauer]

* Volker Birk:
> Lars Gebauer <lgeb...@arcor.de> wrote:

>> Es ging ganz konkret um meine Kaufgewohnheiten im Supermarkt. Ganz
>> offensichtlich fällt Dir /da zu/ nichts ein.
>
> Ganz im Gegenteil. Aber wenn ich Dich derart undifferenziert über “die
> Datenschützer” lamentieren höre, so ist mal eine Rosskur angesagt. Falls
> wir dadurch den Konsens bekommen, dass Privatheit (wie es ja richtig
> übersetzt aus dem englischen “Privacy” heissen muss) eben nicht völlig
> überflüssig ist, sondern man muss diskutieren, welche Menschen vor wem
> geschützt werden müssen, der Daten über sie sammelt, dann haben wir
> einen Diskussionsanfang.

... und auch schon ein Ende.

Ich bin *nicht* der Meinung, daß sich Menschen zum "Beschützer" anderer
Menschen aufschwingen sollten. Ganz im Gegenteil: Ich mißtraue diesen
selbsternannten Schützern zutiefst.

[Volker Birk]

Lars Gebauer <lgeb...@arcor.de> wrote:
> Ich bin *nicht* der Meinung, daß sich Menschen zum "Beschützer" anderer
> Menschen aufschwingen sollten. Ganz im Gegenteil: Ich mißtraue diesen
> selbsternannten Schützern zutiefst.

Du bist also der Ansicht, man muss Strafverfolgung sofort einstellen,
alle Polizisten und Staatsanwälte entlassen und die Gerichte auflösen?
Auch die zivilen natürlich, weil ja kein Urteil mehr durchsetzungsfähig
ist, schliesslich müssen auch die Gerichtsvollzieher weg?

Und Du bist der Ansicht, alle Krankenhäuser, Ärzte und Rettungsdienste
gehören ebenfalls weg?