Re: E-Mail digital unterschreiben als Schutz vor Phishing?

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:
>On Mon, 25 Oct 2021 21:12:23 +0200, Helmut Waitzmann wrote:
>> Michael Pachta <mip...@gmx.de>:
>>
>>> E-Mail-Verschlüsselung (und Signierung) wird sich erst dann auf
>>> breiter Front durchsetzen, wenn dies ohne Zutun des Anwenders
>>> läuft, also völlig transparent.
>>
>> Ohne Zutun des Anwenders?  Woran hängt man dann die Zuordnung
>> eines öffentlichen Schlüssels (Zertifikats) zu einer Person, wenn
>> man keine Fingerprintprüfung machen will?

[…]

>Ich stimme Michael zu.
>
>
>Es müsste einen Dienst (vermutlich über Webinterface) geben, was
>dem Besitzer transparent alles einrichtet. Dieses müsste schlau
>genug sein zu erkennen, ob der Gegenüber ebenfalls dieses
>Webinterface (oder eines, was einen identischen Service anbietet)
>nutzt, um dann E-Mails (wieder transparent, also ohne Zutun des
>Benutzers) ver- und entschlüsselt.

Könntest Du erläutern, wie so ein System den Phisher, der als
Gegenüber ebenfalls diesen Dienst nutzt, davon abhält, seine
betrügerische Nachricht dem Benutzer, der nichts zu seiner
Sicherheit zu tun bereit ist, unterzujubeln?

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:
>On Mon, 25 Oct 2021 23:56:45 +0200, Helmut Waitzmann wrote:
>> Andreas Kohlbach <a...@spamfence.net>:

>>> Es müsste einen Dienst (vermutlich über Webinterface) geben, was
>>> dem Besitzer transparent alles einrichtet. Dieses müsste schlau
>>> genug sein zu erkennen, ob der Gegenüber ebenfalls dieses
>>> Webinterface (oder eines, was einen identischen Service
>>> anbietet) nutzt, um dann E-Mails (wieder transparent, also ohne
>>> Zutun des Benutzers) ver- und entschlüsselt.
>>
>> Könntest Du erläutern, wie so ein System den Phisher, der als
>> Gegenüber ebenfalls diesen Dienst nutzt, davon abhält, seine
>> betrügerische Nachricht dem Benutzer, der nichts zu seiner
>> Sicherheit zu tun bereit ist, unterzujubeln?
>

>Phishing geht über Webseiten. Natürlich könnte er auch eine
>signierte und/oder verschlüsselte Nachricht senden. Wie jeder
>andere auch.

Die Praxis zeigt, dass Phishing‐Opfer nicht einmal einen
Blick auf die Absender‐E‐Mail‐Adresse oder den angepriesenen URL
werfen.  Sonst würde die angeführte angeblich von der Postbank
stammende Phishing‐Nachricht nicht funktionieren.

>Nur sich per Mail nicht als jemand anderes dabei ausgeben.
>

Das sehe ich genau so.


Wie nebenan in dem Beispiel unter dem Betreff
«E-Mail-Verschluesselung und -Signierung ohne Zutun des Anwenders?»
beschrieben, halte ich es heutzutage für möglich, dass es passieren
kann, dass man gezwungen wird, seine E‐Mail‐Adresse zu wechseln. 
Und das muss nicht die Schuld des Anwenders sein:

Ich war beispielsweise früher mit der E‐Mail‐Adresse
<Helmut.W...@web.de> unterwegs (und habe die Adresse zwar immer
noch), habe sie aber praktisch aufgegeben, weil sich Web.DE
erdreistet hat, mir eine Nachricht nicht zuzustellen, sondern sie
einfach verschwinden zu lassen – sie war auch nicht im
Spam‐Ordner –, ohne den Absender davon in Kenntnis zu setzen, obwohl
es in der Leistungsbeschreibung zugesichert hatte, keine Nachricht
unter den Tisch fallen zu lassen.

Nachdem ich Web.DE per E‐Mail um nachträgliche Zustellung der
Nachricht gebeten hatte, kam als Antwort sinngemäß nur, dass es im
Free‐Mail‐Produkt keine ausführliche Hilfe anbietet, blabla…  Ich
könne aber die Hilfetexte – URLs waren angegeben –, die allesamt das
dreiste Löschen nicht zum Thema hatten, lesen oder alternativ eine
0900‐Telefonnummer anrufen.

Viermal habe ich ihm geschrieben und es gebeten, mir die gelöschte
Nachricht nachträglich zuzustellen; viermal kam dieselbe
Blabla‐Antwort.  Beim letzten Mal habe ich ihm außerdem den
Abschnitt aus der im WWW vorgehaltenen Leistungsbeschreibung
zitiert, aus dem hervorgeht, dass Web.DE nie Nachrichten löscht.

Daraufhin hat Web.DE heimlich die im WWW vorgehaltene
Leistungsbeschreibung geändert, ohne mich davon zu benachrichtigen. 
Eine Bitte um Entschuldigung habe ich nicht von Web.DE erhalten.

=> Eine (Web.DE‐)E‐Mail‐Adresse taugt nicht als lebenslängliches
Kennzeichen.  => Wenn man den E‐Mail‐Provider die Kryptografie
transparent machen lässt, kann es sein, dass man auf einmal ohne
sein Schlüsselpaar dasteht.


>Also wenn ich das beispielsweise machen würde, könnte sich niemand
>anders als mich ausgeben.

Ich würde es so formulieren:  Gegenüber denjenigen, die deinen
Schlüssel kennen, könnte sich niemand anderes als dich ausgeben.

Die Einschränkung ist wichtig:  E‐Mail‐Nachrichten von dir können
von Nachrichten von allen anderen Andreas Kohlbachs – seien diese
anderen Andreas Kohlbachs nun echt oder nur Pseudonyme – nur an der
mit deinem Signierschlüssel erstellten Signatur sicher unterschieden
werden.  Dazu ist es notwendig, dass derjenige, der so eine
Unterscheidung vornehmen will, deinen öffentlichen Schlüssel kennt. 
Das kann er aber nur, wenn du ihm deinen Schlüssel (oder dessen
Fingerprint) unfälschbar übermittelst und er die Fingerprintprüfung
sowie die Zertifizierung deines Schlüssels selber macht.

=> Ohne das Zutun von Absender und Empfänger geht es nicht.

[Christian Garbs]

Mahlzeit!

Helmut Waitzmann <nn.th...@xoxy.net> wrote:

> Ich war beispielsweise früher mit der E‐Mail‐Adresse
> <Helmut.W...@web.de> unterwegs (und habe die Adresse zwar immer
> noch), habe sie aber praktisch aufgegeben, weil sich Web.DE
> erdreistet hat, mir eine Nachricht nicht zuzustellen, sondern sie
> einfach verschwinden zu lassen – sie war auch nicht im
> Spam‐Ordner –, ohne den Absender davon in Kenntnis zu setzen, obwohl
> es in der Leistungsbeschreibung zugesichert hatte, keine Nachricht
> unter den Tisch fallen zu lassen.

Wenn eine E-Mail angenommen (also nicht an den Absender mit
Fehlermeldung zurückgeschickt), Dir aber nicht zugestellt wird
(solange Du nicht irgendwo zugestimmt hast, dass ganz doll nach Spam
aussehende Mails direkt und unwiderbringlich gelöscht werden), ist man
da noch im Bereich der Leistungsbeschreibung oder schon bei §206 StGB
(2) 2.?

Ich war irgendwann mal bei einem Freemailer, der der Meinung war,
solange meine Empfängeradresse weder im To: noch im Cc: auftaucht,
kann er die Mail unkommentiert wegschmeißen. SMTP-Envelopes oder Bcc:
existierten für den wohl nicht. Letztendlich bin ich da weg. Leider
wusste ich das mit dem §206 StGB da noch nicht, sonst hätte ich da mal
nachgebohrt. Er mir sein Vorgehen ja sogar schriftlich dargelegt, da
wäre bestimmt was gegangen ;-)

Gruß
Christian

PS: Sind wir noch bei .security oder müssen wir nach .mail rüber?
--
....Christian.Garbs....................................https://www.cgarbs.de
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

[Chr. Maercker]

Andreas Kohlbach wrote:
> "Hausgemachte" Lösungen, wie PGP oder S/MIME werden daran scheitern, dass
> der Nutzer etwas tun muss.

... und einige beliebte Mailer es nicht bzw. unzureichend unterstützen.
Mein langjähriger Favorit zählt leider dazu.

--


CU Chr. Maercker.

[Christian Garbs]

Mahlzeit!

Andreas Kohlbach <a...@spamfence.net> wrote:

> Hatte GMX da nicht mal eine Kampagne mit "DE-Mail"?

Ich hatte auch schon gesucht, wie das heißt.

DE-Mail ist ja dieses Behördenzeugs, was nichts mit Email zu tun hat
und dich zwingt, um Urlaub in windigen Internetcafes jeden Tag dein
hochgeheimes Passwort einzugeben, weil die Fristen rechtlich ab
Zustellung, nicht ab Kenntnisnahme laufen (oder so ähnlich).

Was Du meinst, ist glaube ich die wahnsinnige progressive Idee einer
deutschlandweiten Allianz von Mailprovidern, publikumswirksam TLS
zwischen ihren Mailservern einzuschalten.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Ist die Katze gesund,
freut sich der Hund.

[Marco Moock]

Am Wed, 27 Oct 2021 07:55:23 -0000 (UTC)
schrieb Christian Garbs <mi...@cgarbs.de>:

> Was Du meinst, ist glaube ich die wahnsinnige progressive Idee einer
> deutschlandweiten Allianz von Mailprovidern, publikumswirksam TLS
> zwischen ihren Mailservern einzuschalten

Es findet zwar eine Transportverschlüsselung statt - dabei bleibt es
aber. Eine Ende-zu-Ende-Verschlüsselung gibt es nicht und ist aus
"Sicherheitsgründen" (andere wollen gerne mitlesen) auch so nicht
vorgesehen.
Zudem hat der Dienst pro Mail Geld gekostet und war nicht mit fremden
SMTP-Servern kompatibel. Ergo wird man gezwungen, einer der Anbieter zu
nutzen und damit sit der Vorteil von E-Mail komplett weg.

[Chr. Maercker]

Andreas Kohlbach wrote:

> On Wed, 27 Oct 2021 09:54:56 +0200, Chr. Maercker wrote:
>> ... und einige beliebte Mailer es nicht bzw. unzureichend unterstützen.
>> Mein langjähriger Favorit zählt leider dazu.

> Der ist?

siehe "X-Mailer". ;-)

> Sonst schaue Dir Emacs Gnus oder mutt an.

Es wird eher Seamonkey oder Thunderbird mit Enigmail, nutze ich
gelegentlich schon. Muss nur irknwann die Ordner zusammenführen.

--


CU Chr. Maercker.

[Christian Garbs]

Mahlzeit!

Chr. Maercker <Zwei...@gmx-topmail.de> wrote:
> Andreas Kohlbach wrote:
>> On Wed, 27 Oct 2021 09:54:56 +0200, Chr. Maercker wrote:

>>> ... und einige beliebte Mailer es nicht bzw. unzureichend unterstützen.
>>> Mein langjähriger Favorit zählt leider dazu.
>
>> Der ist?
>
> siehe "X-Mailer". ;-)

Der steht aber nicht in den News-Headern ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

If u c4n r34d this u r34lly n33d t0 g37 l41d

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Tue, 26 Oct 2021 22:43:22 +0200, Helmut Waitzmann wrote:
>> Andreas Kohlbach <a...@spamfence.net>:

>>> Also wenn ich das beispielsweise machen würde, könnte sich
>>> niemand anders als mich ausgeben.
>>
>> Ich würde es so formulieren:  Gegenüber denjenigen, die deinen
>> Schlüssel kennen, könnte sich niemand anderes als dich ausgeben.
>>
>> Die Einschränkung ist wichtig:  E‐Mail‐Nachrichten von dir können
>> von Nachrichten von allen anderen Andreas Kohlbachs – seien diese
>> anderen Andreas Kohlbachs nun echt oder nur Pseudonyme – nur an
>> der mit deinem Signierschlüssel erstellten Signatur sicher
>> unterschieden werden.  Dazu ist es notwendig, dass derjenige, der
>> so eine Unterscheidung vornehmen will, deinen öffentlichen
>> Schlüssel kennt.  Das kann er aber nur, wenn du ihm deinen
>> Schlüssel (oder dessen Fingerprint) unfälschbar übermittelst und
>> er die Fingerprintprüfung sowie die Zertifizierung deines
>> Schlüssels selber macht.
>

>Meinen Namen gibt es mehr als ein Mal.
>

[…]

>Wer aber meine PGP-Schlüssel holt und eine Mail damit
>sendet, kann nur ich sie entschlüsseln; niemand

[…]

sonst.

Das ist der entscheidende Punkt: «Wer aber meine PGP-Schlüssel
holt…».  Da ist es dann vorbei mit «transparent ohne Zutun des
Anwenders»:

Wenn du deine Schlüssel transparent ohne dein Zutun beispielsweise
vom E‐Mail‐Provider – im folgenden Schlüssel‐Verwalter genannt –
verwalten lässt, anstatt sie selbst zu verwalten, kannst du deinen
öffentlichen Schlüssel (oder den Fingerprint desselben) demjenigen,
der «deinen PGP‐Schlüssel holt», nicht unverfälschbar übermitteln,
weil du sie selber nicht hast.  Sollte dann dein Schlüssel‐Verwalter
dein Schlüssel‐Konto schließen, stehst du ohne deine Schlüssel da. 
(Darüber hinaus musst du deinem Schlüssel‐Verwalter vertrauen, dass
er deinen privaten Schlüssel nicht missbraucht.)

>> => Ohne das Zutun von Absender und Empfänger geht es nicht.
>>
>

>IMO doch. Das ganze Einrichten meines Schlüssels sollte sich
>automatisieren lassen, *wenn* man auf das Einrichten des Mantra
>verzichtet.

Ja.  Das Erzeugen eines Schlüsselpaars lässt sich so automatisieren,
das ist richtig.

Damit ist es aber nicht getan, wie bereits in dem von dir nicht
mitzitierten Teil meines Beitrags beschrieben.  Solange du auf den
Teil nicht eingehst, ist ein «IMO doch» nicht mehr als eine
unbewiesene Behauptung.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Thu, 28 Oct 2021 22:05:37 +0200, Helmut Waitzmann wrote:
>> Andreas Kohlbach <a...@spamfence.net>:
>>

>>> Wer aber meine PGP-Schlüssel holt und eine Mail damit sendet,
>>> kann nur ich sie entschlüsseln; niemand
>>
>> […]
>>
>> sonst.
>>
>> Das ist der entscheidende Punkt: «Wer aber meine PGP-Schlüssel
>> holt…».  Da ist es dann vorbei mit «transparent ohne Zutun des
>> Anwenders»:
>

>Das war das Beispiel, wie es heute ohne "automatisierte"
>Verschlüsselung ist.

Könntest du bitte ausführen, wie automatisierte Verschlüsselung und
Unterschrift funktionieren könnte?  Besonders interessiert bin ich
an zwei Fragen:

Wie bekommt der Automat, der für mich arbeitet, wenn ich
eine Nachricht für dich verschlüsseln will, dann beispielsweise
heraus, welcher öffentliche Schlüssel der deine ist, damit er
meine Nachricht für dich und nicht jemand anderen verschlüsselt?

Wie bekommt der Automat, der für mich arbeitet, wenn ich bei einer
angeblich von dir kommenden Nachricht nachweisen will, dass sie
tatsächlich von dir stammt, heraus, welcher öffentliche Schlüssel
der deine ist, damit er zum richtigen Prüfungsergebnis kommt?

>Dein guter Punkt war (und das hätte ich vorher anführen müssen),
>dass man dem Schlüssel-Verwalter unbedingtes Vertrauen schenken
>muss.

Das kommt dazu – und ich habe angenommen, dass er das Vertrauen
bereits hat.  Das reicht aber nicht.  Das größte Problem ist, den
Schlüssel‐Verwaltern der Kommunikationspartner den eigenen
öffentlichen Schlüssel unverfälscht bekannt zu machen.  Wie das
automatisiert gelingen kann, hast du bisher nicht beschrieben.

>Das Eigene machen (ohne einen öffentlichen Schlüssel-Verwalter) ist
>zum Scheitern erklärt. Was heute daran zu erkennen ist, dass kaum
>ein Bruchteil der Mails verschlüsselt wird, weil es den Benutzern
>zu aufwändig ist, es einzurichten.

Den Benutzern ist es nicht zu aufwändig, das einzurichten.  Die
Einrichtung (also Erzeugung) eines eigenen Schlüsselpaares kann man
in der Tat automatisieren:  Ein Knopfdruck «Neues Schlüsselpaar
erstellen» beispielsweise im Mailerprogramm reicht, um das
anzustoßen – und selbst das kann das Mailerprogramm automatisch
anstoßen, wenn es noch kein Schlüsselpaar hat.  Und wenn man darauf
verzichtet, den eigenen privaten Schlüssel durch ein eigenes
Passwort zu sichern (etwa, weil das ganze Gerät bereits durch ein
Passwort gesichert ist), muss das Mailerprogramm nicht einmal nach
einem Passwort fragen sondern kann die Einrichtung ohne weitere
Belästigung des Anwenders vollenden.

Den Benutzern ist es jedoch zu aufwändig, zu verstehen, worum es bei
Public‐Key‐Kryptografie geht.  Und weil sie es nicht verstehen,
scheitern sie dann, wenn es darum geht, potentiellen
Kommunikationspartnern den eigenen öffentlichen Schlüssel
unverfälscht mitzuteilen und umgekehrt von ihnen ihren öffentlichen
Schlüssel unverfälscht zu erhalten, obwohl das nur wenig aufwendiger
ist, als jemandem die eigene Telefonnummer unverfälscht mitzuteilen
oder von jemandem dessen Telefonnummer unverfälscht zu erhalten (40
Sedezimalziffern für den Fingerprint, den man auf Knopfdruck vom
Mailerprogramm angezeigt bekommt, statt eine vielleicht 14stellige
Telefonnummer).

Der Witz liegt dabei auf dem Begriff «unverfälscht»:  Bei
Telefonnummern wird er im Alltag nicht beachtet, weil man –
jedenfalls bisher, von Ausnahmen abgesehen – beim Anruf ja im
Nachhinein an der Stimme des Angerufenen merkt, ob man den richtigen
Gesprächspartner am Apparat hat.

Eine Ausnahme ist der Enkeltrick
(<https://de.wikipedia.org/wiki/Enkeltrick#top>), der genau deshalb
funktioniert, weil der Angerufene an der Stimme den Betrug nicht
erkennt.

Ich möchte nicht ausschließen, dass es in Zukunft möglich sein wird,
in Echtzeit einer Stimme eines Betrügers die Stimme eines Enkels des
Betrugsopfers überzustülpen.  Dann funktioniert der Schluss
«Selbstverständlich ist das mein Enkel, der mich da anruft.  Ich
erkenne ihn ja an der Stimme» nicht mehr, auch wenn man noch so gut
hört.

Bei elektronischer Datenverarbeitung gibt es die nachträgliche
Stimmenkontrolle nicht, und deswegen muss auf andere Weise
sichergestellt werden, dass die Schlüssel unverfälscht übertragen
werden.

Im Verstehen, warum die Anforderung «unverfälschte Übertragung» so
entscheidend ist, liegt das Problem, nicht an der angeblich
umständlichen Einrichtung der Public‐Key‐Kryptografie.

Traditionell gibt es zwei Antworten auf diese Anforderung:


1: Triff die Kommunikationspartner persönlich und bring ihnen den
eigenen öffentlichen Schlüssel (oder seinen Fingerprint) und lass
dir von ihnen den ihren geben.  Das geht naturgemäß nicht
automatisch.

2: Bedien dich vertrauenswürdiger Kontaktleute, die das für dich
tun.  (Das ist das Web of Trust.)  Das geht auch nicht vollständig
automatisch:  Zumindest eine allererste vertrauenswürdige
Kontaktperson musst du einmal (auf die erste Art) getroffen haben,
um einen Anschluss ans Web of Trust zu haben; und kein
Schlüsselverwalter kann wissen, wen du für vertrauenswürdig hältst. 
Das musst du deinem Schlüsselverwalter also selber mitteilen.  Das
geht auch nicht automatisch.

«Aber bei WhatsApp geht doch alles automatisch?» – «Nein, das tut es
auch dort nicht!».

Laut Seite 10 des Papiers
<https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf>
gibt es dort QR‐Codes zur Schlüsselprüfung, die man mit dem
potentiellen Kommunikationspartner im direkten persönlichen Kontakt
abgleicht.  Sie entsprechen in ihrer Funktion den Fingerprints von
OpenPGP.

[Chr. Maercker]

Andreas Kohlbach wrote:
>> siehe "X-Mailer". ;-)

> Gibt es nicht. Der User-Agent hier sagt Firefox. Müsste da nicht
> Seamonkey oder Thunderbird stehen?

Du bekommst gelegentlich eMails von mir. Schau dort mal nach. ;-)

--


CU Chr. Maercker.

[Chr. Maercker]

Christian Garbs wrote:
> Mahlzeit!
>
> Chr. Maercker <Zwei...@gmx-topmail.de> wrote:
>> Andreas Kohlbach wrote:
>>> On Wed, 27 Oct 2021 09:54:56 +0200, Chr. Maercker wrote:
>
>>>> ... und einige beliebte Mailer es nicht bzw. unzureichend unterstützen.
>>>> Mein langjähriger Favorit zählt leider dazu.
>>
>>> Der ist?
>>
>> siehe "X-Mailer". ;-)
>
> Der steht aber nicht in den News-Headern ;-)

Der Agent-String schon, auch wenn er sich dort User-Agent nennt. Andreas
Kohlbach muss aber ganz woanders suchen und ich glaubte, ihm das nicht
ausführlich erklären zu müssen. ;-)
--


CU Chr. Maercker.

[Stefan Claas]

On Saturday, October 30, 2021 at 8:17:44 PM UTC+2, Helmut Waitzmann wrote:

> Könntest du bitte ausführen, wie automatisierte Verschlüsselung und
> Unterschrift funktionieren könnte? Besonders interessiert bin ich
> an zwei Fragen:
>
> Wie bekommt der Automat, der für mich arbeitet, wenn ich
> eine Nachricht für dich verschlüsseln will, dann beispielsweise
> heraus, welcher öffentliche Schlüssel der deine ist, damit er
> meine Nachricht für dich und nicht jemand anderen verschlüsselt?
>
> Wie bekommt der Automat, der für mich arbeitet, wenn ich bei einer
> angeblich von dir kommenden Nachricht nachweisen will, dass sie
> tatsächlich von dir stammt, heraus, welcher öffentliche Schlüssel
> der deine ist, damit er zum richtigen Prüfungsergebnis kommt?

Das automatische verschlüsseln ging damals mit Autocrypt für Thunderbird.
Ob Autocrypt noch gepflegt wird ist mir jedoch nicht bekannt.

<https://addons.thunderbird.net/en-US/thunderbird/addon/autocrypt/reviews/>

Grüße
Stefan

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

> On Sat, 30 Oct 2021 20:15:53 +0200, Helmut Waitzmann wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net>:
>>> On Thu, 28 Oct 2021 22:05:37 +0200, Helmut Waitzmann wrote:
>>>
>>>> Andreas Kohlbach <a...@spamfence.net>:
>>>>
>>>>> Wer aber meine PGP-Schlüssel holt und eine Mail damit sendet,
>>>>> kann nur ich sie entschlüsseln; niemand
>>>>
>>>> […]
>>>>
>>>> sonst.
>>>>
>>>> Das ist der entscheidende Punkt: «Wer aber meine PGP-Schlüssel
>>>> holt…».  Da ist es dann vorbei mit «transparent ohne Zutun des
>>>> Anwenders»:
>>>
>>> Das war das Beispiel, wie es heute ohne "automatisierte"
>>> Verschlüsselung ist.
>>
>> Könntest du bitte ausführen, wie automatisierte Verschlüsselung
>> und Unterschrift funktionieren könnte?  Besonders interessiert
>> bin ich an zwei Fragen:
>>
>> Wie bekommt der Automat, der für mich arbeitet, wenn ich eine
>> Nachricht für dich verschlüsseln will, dann beispielsweise heraus,
>> welcher öffentliche Schlüssel der deine ist, damit er meine
>> Nachricht für dich und nicht jemand anderen verschlüsselt?
>>
>> Wie bekommt der Automat, der für mich arbeitet, wenn ich bei
>> einer angeblich von dir kommenden Nachricht nachweisen will, dass
>> sie tatsächlich von dir stammt, heraus, welcher öffentliche
>> Schlüssel der deine ist, damit er zum richtigen Prüfungsergebnis
>> kommt?
>

>Abstrakt: der "Automat" legt beim Einrichten automatisch und ohne
>mein Zutun ein Schlüsselpaar für mich an.

Wenn der Automat bei deinem E‐Mail‐Provider läuft, kann er alle
Nachrichten, die du über ihn mittels Message‐Submission mit TLS
gesichert verschickst, digital mit dem Schlüssel, den er für dich
erzeugt hat, unterschreiben, denn er weiß aufgrund deines
Einloggens, dass du es bist, der die Nachricht einliefert.

Mein Automat wird sicher nicht, wenn du deine E‐Mail‐Adresse bei
deinem E‐Mail‐Provider einrichtest, ein Schlüsselpaar für dich bei
sich einrichten.

Wenn ich nun bei einer Nachricht, die angeblich von dir stammt, die
Unterschrift prüfen will oder dir eine Nachricht verschlüsselt
schicken will, muss ich (oder mein Automat) deinen öffentlichen
Schlüssel kennen.

> Beim Senden (oder Empfangen) einer Mail kennt der "Automat" meinen
> Schlüssel oder den des Senders; wird ihn prüfen und sagen, ob er
> koscher ist.

Wenn du eine Nachricht empfängst, die angeblich von mir
unterschrieben ist, kann der Automat deines E‐Mail‐Providers nicht
prüfen, ob der Schlüssel, mit dem die Nachricht unterschrieben ist,
wirklich mein Schlüssel ist, oder, ob der Schlüssel jemand anderem
gehört, der dir eine Nachricht geschickt hat, die den (gefälschten)
Absender <nn.th...@xoxy.net> trägt.  Damit er das prüfen könnte,
müsste er meinen Schlüssel kennen.  Das ist aber nicht der Fall:

Im Gegensatz zu dir habe ich bei deinem E‐Mail‐Provider kein
E‐Mail‐Konto, in das ich mich mit TLS gesichert beim
Nachrichtenversand (Message‐Submission) oder beim Nachrichtenempfang
(IMAP) mit Benutzername und Passwort einloggen und mich dadurch
deinem Mail‐Provider gegenüber ausweisen könnte.  Auch hat dein
E‐Mail‐Provider für mich kein Schlüsselpaar erzeugt.

>Stell Dir die Einrichtung von PGP vor, nur automatisiert, ohne
>Zutun der User (keine Mantra).

Ja:  PGP ohne Mantra ist immer noch auf fälschungssichere Schlüssel‐
oder Fingerprint‐Übermittlung angewiesen.  Wie also kommt dein
Schlüssel oder der Fingerprint deines Schlüssels fälschungssicher zu
mir und umgekehrt meiner zu dir?

>> Das größte Problem ist, den Schlüssel‐Verwaltern der
>> Kommunikationspartner den eigenen öffentlichen Schlüssel
>> unverfälscht bekannt zu machen.  Wie das automatisiert gelingen
>> kann, hast du bisher nicht beschrieben.
>

>Muss er nicht. Wenn jemand eine Mail über einen entsprechend
>ausgestatteten Anbieter sendet, prüft der "Automat", ob der
>Empfänger in der Datenbank ebenfalls eingetragen ist. Nur dann
>würde die Mail verschlüsselt. Der Absender kann ggf. einen Hinweis
>erhalten, ob, oder ob nicht, die Mail verschlüsselt wurde.

Für fälschungssichere E‐Mail‐Übertragung reicht es nicht,
Nachrichten zu verschlüsseln.  Sie müssen auch unterschrieben sein. 
Das wird gerne übersehen, wenn man einem Trugschluss aufsitzt, wie
folgt:

Wenn Alice Bob's öffentlichen Schlüssel kennt und ihm eine
verschlüsselte Nachricht schickt, kann Mallory sie nicht lesen. 
Richtig?  Stimmt.

Und deshalb kann sie sie auch nicht verändern.  Richtig?  Stimmt
nicht:  Mallory kann die Nachricht zwar nicht lesen, aber sie kann
die Nachricht vollständig verändern, ohne sie zu lesen:  Sie kann
eine Nachricht komplett neu erfinden, als Absender Alice eintragen,
die Nachricht verschlüsseln und Bob schicken.  Nur an der
Unterschrift, die nicht Alice's sondern Mallory's ist, kann Bob den
Betrug erkennen.  Dazu muss er allerdings Alice's Schlüssel kennen,
damit er nicht Mallory's für Alice's hält.

Weder der Automat meines E‐Mail‐Providers noch ich selbst können
überprüfen, ob die Unterschrift, die eine angeblich von dir
stammende Nachricht trägt, deine Unterschrift ist, wenn wir deinen
öffentlichen Schlüssel nicht kennen.

Wenn der Automat meines Anbieters nach deinem Schlüssel oder deiner
E‐Mail‐Adresse in seiner Datenbank sucht, wird er nichts finden: 
Dein Schlüssel ist nicht in seiner Datenbank.  Und mir geht es genau
so:  Auch in meiner GnuPG‐Datenbank ist dein Schlüssel nicht drin,
ehe ich ihn (oder seinen Fingerprint) von dir fälschungssicher
erhalten habe.

Wenn man dem Problem mit einer Datenbank beikommen will, müsste das
eine Datenbank sein, die von allen E‐Mail‐Providern gemeinsam
bestückt und benutzt wird.  Dazu müssten alle beteiligten
E‐Mail‐Provider einander vertrauen, dass keiner falsche Schlüssel
einträgt – und das weltweit.  Dass das nie passieren wird, dürfte
klar sein.  Ich sage nur: Deutschland vor 80 Jahren, heute China…

>>> Das Eigene machen (ohne einen öffentlichen Schlüssel-Verwalter)
>>> ist zum Scheitern erklärt. Was heute daran zu erkennen ist, dass
>>> kaum ein Bruchteil der Mails verschlüsselt wird, weil es den
>>> Benutzern zu aufwändig ist, es einzurichten.

Es würde auch mit Schlüsselverwalter und automatischem Einrichten
ohne Zutun der Anwender nicht besser werden, denn mit Einrichten ist
es nicht getan:  Immer dann, wenn sie einen neuen
Kommunikationspartner haben, müssen sie sich um fälschungssicheren
Schlüssel‐ oder Fingerprint‐Austausch kümmern.  Weil viele Anwender
Public‐Key‐Kryptografie nicht verstehen, verstehen sie auch die
Notwendigkeit fälschungssicheren Schlüssel‐ oder
Fingerprint‐Austauschs nicht.

Als einzigen Weg, da voran zu kommen, sehe ich nur, den Leuten
Public‐Key‐Kryptografie beizubringen – und dazu gehört auch, dass
der Hinweis, nach dem Fingerprintaustausch müsse und könne man die
E‐Mail‐Adresse im User‐Id des Schlüssels des Kommunikationspartners
durch eine Test‐Nachricht überprüfen, endlich dorthin verbannt wird,
wo er hingehört: ins Reich der Märchen._ (Es gibt Ausnahmen:  Der
E‐Mail‐Provider weiß, welche E‐Mail‐Adresse jeder seiner
E‐Mail‐Account‐Inhaber bei ihm hat.  Zwei E‐Mail‐Account‐Inhaber
beim selben E‐Mail‐Provider können, wenn sie dem E‐Mail‐Provider
vertrauen, die E‐Mail‐Adresse des jeweils anderen überprüfen.)

>> Den Benutzern ist es nicht zu aufwändig, das einzurichten.  Die
>> Einrichtung (also Erzeugung) eines eigenen Schlüsselpaares kann
>> man in der Tat automatisieren:  Ein Knopfdruck «Neues
>> Schlüsselpaar erstellen» beispielsweise im Mailerprogramm reicht,
>> um das anzustoßen – und selbst das kann das Mailerprogramm
>> automatisch anstoßen, wenn es noch kein Schlüsselpaar hat.  Und
>> wenn man darauf verzichtet, den eigenen privaten Schlüssel durch
>> ein eigenes Passwort zu sichern (etwa, weil das ganze Gerät
>> bereits durch ein Passwort gesichert ist), muss das
>> Mailerprogramm nicht einmal nach einem Passwort fragen sondern
>> kann die Einrichtung ohne weitere Belästigung des Anwenders
>> vollenden.
>

>Ja, nein.
>

Ja, nicht nein:  Das geht vollständig ohne Zutun des Anwenders.


>Heutige Anwender wissen vielleicht nicht mal, was Mail ist. Sie
>tappen auf das Brief-Symbol auf ihrem Smartphone (oder die App
>öffnet sich, wenn ein "Email Ereignis" passiert).

Tja, so ist das mit der Totalintegration:  Kaum ist ein Dienst
perfekt eingebunden, erkennt man ihn nicht mehr als eigenständigen
Dienst.

>Auch versteht der heutige Facebook-Nutzer nicht, warum in aller
>Welt er seine Privatsphäre schützen sollte.

Wenn er auf die, die ihn davor warnen, seine Privatsphäre verkommen
zu lassen, nicht hört, wird er es erst einsehen, wenn er damit
gewaltig auf die Schnauze gefallen ist.  Ach nein:  Das versteht er
ja wegen der Totalintegration der Dienste nicht mehr.

>Neulich in einem Gastronimiebereiches eines Einkaufszentrums. Eine
>Frau kam an meinen Tisch und fragte, wie sie das WIFI nutzen könne.
>Es gibt ein "Captive Portal", dass man nur einen Link
>klicken/tappen muss, um ins Internet zu kommen. Ich sagte, sie
>müsse den Web Browser starten. Sie verstand nicht. Ich deutete auf
>das entsprechende Icon auf ihrem Smartphone. Sie "Oh, Google!"...

Kein Wunder!  Ich habe hier gerade ein Android‐Smartphone vor der
Nase.  Da sehe ich an Apps – die mit einem Sternchen markierten
haben ein Logo im Googleschen 4‐Farbfelder‐Stil – Chrome(*),
Dateien, Drive(*), Einstellungen, Favoriten, Fotos(*), GMail,
Google(*), Gruppen, Kalender, Kamera, Kontakte (2 unterschiedliche),
Kurzanleitung, Maps(*), Messages, Musik, Navigation, Notizen, Play
Store(*), Rechner, SIM‐Toolkit, Software‐Update, Soundrecorder,
Telefon, Uhr, Videos.  Da sieht man nicht, wo Dienstegrenzen liegen,
nicht einmal, welche Apps externe Dienste nutzen und welche nur
lokal im Smartphone agieren.  Ein erklärender Text steht nicht
dabei.  Gescheite Handbücher gibt es auch nicht.

>Heutige Web-Surfer haben in der Regel keine Ahnung, was da wirklich
>abläuft.

Chrome ist ein Web‐Browser.  Was aber sind die Apps Drive, Fotos,
Google, Gruppen, Kontakte, Maps, Musik, Navigation, Play Store,
Videos?  Haben die mit WWW etwas zu tun oder agieren sie nur lokal? 
Da blicke ich auch nicht vollständig durch.  Inzwischen weiß ich
immerhin, dass die Favoriten und die einen der beiden Kontakte nur
Nebennamen zum Mobiltelefon (True Phone) sind.

Die Apps kommen alle gleich daher, obwohl sie sehr unterschiedlich
sind.  So rächt sich die Totalintegration.

>Eine große Verbreitung von verschlüsselten Nachrichten (Email) wird
>nie passieren.

Ich fürchte, da hast du recht, jedenfalls, solange es nicht um Leben
und Tod geht.

Ich wehre mich aber dagegen, dass man den Entwicklern der
Mailer‐Programme vorwirft:  «Warum integrieren die nerdigen
Entwickler die E‐Mail‐Verschlüsselung und ‐Unterschrift nicht so in
das Mailer‐Programm, dass es ohne Zutun des Anwenders geht?  Wenn
die ihre Hausaufgaben machen würden, wäre das alles kein Problem!»

[Helmut Waitzmann]

Stefan Claas <spam.tra...@gmail.com>:

>On Saturday, October 30, 2021 at 8:17:44 PM UTC+2, Helmut Waitzmann wrote:
>
>> Könntest du bitte ausführen, wie automatisierte Verschlüsselung
>> und Unterschrift funktionieren könnte? Besonders interessiert bin
>> ich an zwei Fragen:
>>
>> Wie bekommt der Automat, der für mich arbeitet, wenn ich eine
>> Nachricht für dich verschlüsseln will, dann beispielsweise
>> heraus, welcher öffentliche Schlüssel der deine ist, damit er
>> meine Nachricht für dich und nicht jemand anderen verschlüsselt?
>>
>> Wie bekommt der Automat, der für mich arbeitet, wenn ich bei
>> einer angeblich von dir kommenden Nachricht nachweisen will, dass
>> sie tatsächlich von dir stammt, heraus, welcher öffentliche
>> Schlüssel der deine ist, damit er zum richtigen Prüfungsergebnis
>> kommt?
>
>Das automatische verschlüsseln ging damals mit Autocrypt für
>Thunderbird.

<https://de.wikipedia.org/wiki/Autocrypt#top>:

«Autocrypt ist eine standardisierte Richtlinie für E-Mail-Programme,
die eine nutzerfreundliche Verschlüsselung von E-Mails und
automatisierten aber ungesicherten Austausch kryptografischer
Schlüssel ermöglicht.»

Autocrypt macht genau das, was automatisiert werden kann: das
automatische Einrichten eines eigenen Schlüsselpaars und das
ungesicherte Verteilen öffentlicher Schlüssel.  Die zwei oben
gestellten Fragen beantwortet es nicht.

[Paul Muster]

On 07.11.21 23:50, Helmut Waitzmann wrote:

> Wenn man dem Problem mit einer Datenbank beikommen will, müsste das eine
> Datenbank sein, die von allen E‐Mail‐Providern gemeinsam bestückt und
> benutzt wird.

Nein, es ist nicht notwendig, dass das _eine_ Datenbank ist. Der
Mailclient des Absenders könnte durchaus, weil an <localpart>@gmx.de
gesendet werden soll, die Datenbank bei GMX abfragen. Und Schlüssel für
E-Mail-Adressen @gmail.com ebendort. Klar, es müsste ein
standardisiertes Interface dafür her, aber da muss man wahrscheinlich
nur mal durch die IETF-RfCs schauen, Vorschläge dafür gibt es bestimmt
längst.


mfG Paul

[Stefan Claas]

Wenn wir beide Autocrypt nutzen würden und ich Dir eine Einleitungs
email, alá "Hallo Helmut" unverschlüsselt sende, dann hat meine email
im Header mein pub key und Du kannst mir dann *automatisch*, ohne key
Management usw., verschlüsselt antworten. Sobald ich deine verschlüsselte
Antwort erhalten habe, antworte ich Dir dann auch automatisch und verschlüsselt,
da ich ja ebenfalls dein pub key im Header habe.

Probiere das doch einfach mal mit Freunden aus.

MITM ist da auch nicht einfach. Ich hatte das damals mal probiert, bin jedoch
dabei nicht erfolgreich gewesen (weil vermutlich zu blöd).

Grüße
Stefan

[Helmut Waitzmann]

Stefan Claas <spam.tra...@gmail.com>:

>Wenn wir beide Autocrypt nutzen würden und ich Dir eine Einleitungs
>email, alá "Hallo Helmut" unverschlüsselt sende, dann hat meine
>email im Header mein pub key

Nein.  Dann hat die Nachricht, die ich erhalte, einen öffentlichen
Schlüssel im Vorspann[1].  Ich habe aber keine Garantie, dass das
dein Schlüssel ist.  Weil E‐Mail‐Transport im Allgemeinen nicht
fälschungssicher ist, könnte der Schlüssel von einem Man in the
Middle ausgetauscht worden sein.  Ich könnte es nicht erkennen.

>und Du kannst mir dann *automatisch*, ohne key Management usw.,
>verschlüsselt antworten.

Nein.  Ich könnte dir dann automatisch, ohne Schlüsselverwaltung
usw., eine Nachricht schicken, von der ich glaube, dass sie für dich
verschlüsselt ist, obwohl sie für den Man in the Middle
verschlüsselt ist.

Der könnte sie abfangen, (logischer Weise) entschlüsseln,
verfälschen, wie es ihm passt, und für dich verschlüsseln.  Du
erhältst in der verfälschten Nachricht dann natürlich seinen statt
meinen öffentlichen Schlüssel im Vorspann.

>Sobald ich deine verschlüsselte Antwort erhalten habe, antworte ich
>Dir dann auch automatisch und verschlüsselt, da ich ja ebenfalls
>dein pub key im Header habe.

Nein.  Sobald du seine verschlüsselte Antwort erhalten hast, hältst
du seinen Schlüssel für meinen[1].  Wenn du mir dann automatisch und
verschlüsselt antwortest, verschlüsselst du in Wirklichkeit für den
Man in the Middle.

Der fängt deine Nachricht ab, entschlüsselt sie, verfälscht sie, wie
es ihm passt, verschlüsselt sie für mich und schickt sie weiter an
mich.

=> Weder du noch ich merken etwas vom Betrug:  Wir sind beide der
Meinung, miteinander gesichert zu kommunizieren; in Wirklichkeit
sitzen wir dem Man in the Middle auf, der unsere Kommunikation
vollständig mitlesen und manipulieren kann.

[1] Dem ist nur beizukommen, indem wir beide einander unsere
öffentlichen Schlüssel (oder deren Fingerprints) auf unverfälschbare
Weise zukommen lassen.  Diese unverfälschbare Weise kann der von
Autocrypt genutzte Nachrichtenvorspann des fälschbaren Mediums
E‐Mail gerade nicht sein.  Wir könnten einander beispielsweise
treffen oder einen vertrauenswürdigen Boten benutzen, der uns beide
trifft.  (Dieser Bote wäre dann eine Personifizierung des Webs of
Trust.)

>MITM ist da auch nicht einfach. Ich hatte das damals mal probiert,
>bin jedoch dabei nicht erfolgreich gewesen (weil vermutlich zu
>blöd).

Zu blöd warst du vermutlich nicht; du hattest nur das technische
Handwerkszeug nicht dazu zur Verfügung:  Man braucht als MITM dazu
die Möglichkeit, Nachrichten zu manipulieren, genauer: abzufangen,
also mitzulesen und am Weiterreisen zu hindern, und statt dessen
eine andere Nachricht auf die Reise zu schicken.  Das kann man
beispielsweise, wenn man der Systemadministrator des
E‐Mail‐Providers ist.

[Helmut Waitzmann]

Paul Muster <exp-3...@news.muster.net>:

>On 07.11.21 23:50, Helmut Waitzmann wrote:
>
>> Wenn man dem Problem mit einer Datenbank beikommen will, müsste
>> das eine Datenbank sein, die von allen E‐Mail‐Providern gemeinsam
>> bestückt und benutzt wird.
>
>Nein, es ist nicht notwendig, dass das _eine_ Datenbank ist. Der
>Mailclient des Absenders könnte durchaus, weil an <localpart>@gmx.de
>gesendet werden soll, die Datenbank bei GMX abfragen. Und Schlüssel
>für E-Mail-Adressen @gmail.com ebendort.

Ja, richtig.  Es genügt auch, wenn der E‐Mail‐Provider von
<Al...@ihr-provider.example> eine eigene Datenbank pflegt und
Alice's Mailclient die Datenbank des Providers von
<B...@sein-provider.example> abfragt, wenn Alice eine Nachricht an
Bob verschlüsseln will.  Allerdings schafft das das Problem der
mangelnden Gewissheit über die öffentlichen Schlüssel auch nicht aus
der Welt:

Wie war das mit Yahoo und dem chinesischen Staat (siehe
<https://de.wikipedia.org/wiki/Altaba#Kritik>)?  Ich würde keiner
Schlüssel‐Datenbank bei irgend einem E‐Mail‐Provider trauen.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Sun, 07 Nov 2021 23:50:23 +0100, Helmut Waitzmann wrote:
>> Andreas Kohlbach <a...@spamfence.net>:
>>> On Sat, 30 Oct 2021 20:15:53 +0200, Helmut Waitzmann wrote:

>Es sieht doch heute so aus: Wenn ich Dir nun eine nicht signierte
>Mail sende, kannst Du nicht sicher sein, dass die wirklich von mir
>ist. Hast Du aber meinen Schlüssel in Deiner Datenbank hast (mal
>außen vorgelassen, wie mein Schlüssel vertrauenswürdig zu Dir
>kommt), kannst Du zumindest annehmen, dass die Mail wirklich von
>mir stammt.

Gut, dass wir darin übereinstimmen.


>Ich habe beispielsweise Deinen Schlüssel, wenn ihm auch nicht voll
>vertraut wird:
>
>| uid [ unknown] Helmut Waitzmann (Anti-Spam-Ticket.b.qc3c) <oe.th...@xoxy.net>

Wie hast du überprüft, dass es wirklich mein Schlüssel ist?  Hilft
dir dabei das Web of Trust, oder hast du (oder der Automat beim
Provider, der für dich arbeitet) ein User‐Id zertifiziert?

>>>>> Das Eigene machen (ohne einen öffentlichen
>>>>> Schlüssel-Verwalter) ist zum Scheitern erklärt. Was heute
>>>>> daran zu erkennen ist, dass kaum ein Bruchteil der Mails
>>>>> verschlüsselt wird, weil es den Benutzern zu aufwändig ist, es
>>>>> einzurichten.
>>
>> Es würde auch mit Schlüsselverwalter und automatischem Einrichten
>> ohne Zutun der Anwender nicht besser werden, denn mit Einrichten
>> ist es nicht getan:  Immer dann, wenn sie einen neuen
>> Kommunikationspartner haben, müssen sie sich um
>> fälschungssicheren Schlüssel‐ oder Fingerprint‐Austausch
>> kümmern.  Weil viele Anwender Public‐Key‐Kryptografie nicht
>> verstehen, verstehen sie auch die Notwendigkeit
>> fälschungssicheren Schlüssel‐ oder Fingerprint‐Austauschs nicht.
>>
>> Als einzigen Weg, da voran zu kommen, sehe ich nur, den Leuten
>> Public‐Key‐Kryptografie beizubringen – und dazu gehört auch, dass
>> der Hinweis, nach dem Fingerprintaustausch müsse und könne man
>> die E‐Mail‐Adresse im User‐Id des Schlüssels des
>> Kommunikationspartners durch eine Test‐Nachricht überprüfen,
>> endlich dorthin verbannt wird, wo er hingehört: ins Reich der
>> Märchen._ (Es gibt Ausnahmen:  Der E‐Mail‐Provider weiß, welche
>> E‐Mail‐Adresse jeder seiner E‐Mail‐Account‐Inhaber bei ihm hat. 
>> Zwei E‐Mail‐Account‐Inhaber beim selben E‐Mail‐Provider können,
>> wenn sie dem E‐Mail‐Provider vertrauen, die E‐Mail‐Adresse des
>> jeweils anderen überprüfen.)
>

>Das überfordert Benutzer seit Jahrzehnten. Es wird IMO nie dazu
>kommen. Und wie erwähnt kommt bei der "automatischen Methode" eben
>hinzu, dass Leute von Außerhalb des ISP außen vorbleiben.

Damit ist die automatische Methode etwa so sinnvoll wie mehrere
Telefonnetze, die nicht miteinander verbunden sind:  Es funktioniert
nicht.

>Insgesamt gesehen bin ich der Meinung, dass sich aufgrund der
>Unwissenheit und Überfordertsein sich Verschlüsselungen nie
>durchsetzen werden. Somit ist diese Diskussion müßig.

Offensichtlich ist sie es nicht.  Immerhin hast du nun verstanden,
warum es «automatisch und ohne Zutun des Anwenders»
provider‐übergreifend prinzipiell nicht funktionieren kann, solange
man nicht allen daran beteiligten E‐Mail‐Providern vertrauen kann. 
Außerdem hätte es sonst den Beitrag


Subject: Re: [Lösung Subjectwechsel]
From: Michael Pachta <mip...@gmx.de>
Newsgroups: de.comm.software.mozilla.mailnews
Date: Sat, 23 Oct 2021 09:17:15 +0200
Message-ID: <ithr7p...@mid.individual.net>

mit der Aussage (Zitat)

E-Mail-Verschlüsselung (und Signierung) wird sich erst
dann auf breiter Front durchsetzen, wenn dies ohne Zutun
des Anwenders läuft, also völlig transparent.

so nicht gegeben:  «wird sich erst […] durchsetzen, wenn…» lässt die
Hoffnung anklingen, dass die Bedingung prinzipiell erfüllt werden
kann und erfüllt werden wird, wenn sich jemand auf den Hosenboden
setzt und ans Werk geht.  Anderenfalls würde da «würde sich erst […]
durchsetzen, wenn dies ohne Zutun des Anwenders liefe…» stehen.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:
>On Tue, 09 Nov 2021 10:42:18 +0100, Helmut Waitzmann wrote:
[E‐Mail‐Verschlüsselung und ‐Digitalunterschrift mit einem
automatisierten System ohne Zutun des Anwenders bereitzustellen,
krankt an der Verletzlichkeit gegenüber einem
Man‐in‐the‐Middle‐Angriff und ist deshalb keine gute Idee.]

>Aber ein automatisiertes System ist IMO der einzige Weg,
>technophobe User zum Verschlüsseln zu bringen.

Solche Anwender sind weniger technophob sondern eher mathematische
Analphabeten.

>Das die Sicherheit nicht optimal ist
>

Du hast aber schon verstanden, dass bei einem
Man‐in‐the‐Middle‐Angriff die Sicherheit nicht nur nicht optimal
ist, sondern schlichtweg vollständig zerstört ist?

>muss vom User akzeptiert werden.
>

Das sage bitte denen ins Gesicht, die Opfer eines
Man‐in‐the‐Middle‐Angriffs geworden sind, weil sie auf den
Werbeslogan «Geht ganz automatisch ohne Zutun des Anwenders!  Kein
Web of Trust und kein Austausch von Fingerprints nötig!»
hereingefallen sind.

Hast du jetzt wenigstens verstanden, dass zum Aufbau einer abhör‐
und fälschungssicheren Kommunikation per E‐Mail zwischen zwei
Partnern (mit je einem Nachrichtenkanal in jeder Richtung) von vorne
herein beide Kanäle abhör‐ oder beide Kanäle fälschungssicher sein
müssen oder in einer Richtung ein abhör‐ und fälschungssicherer
Kanal vorhanden sein muss?  Wenn zwischen den beiden
Kommunikationspartnern (wenigstens) eine dieser Möglichkeiten
vorhanden ist, dann können beide Partner daraus mittels
Public‐Key‐Kryptografie in beide Richtungen je einen abhör‐ und
fälschungssicheren Nachrichtenkanal erstellen.  Billiger kriegt man
es nicht hin.

Das bekannteste Beispiel ist der Austausch der Fingerprints auf
einer Kryptoparty:  Wenn sich die Kommunikationspartner
gegenüberstehen und einander je einen Zettel mit dem eigenen
Fingerprint in die Hand drücken, ist das in beide Richtungen je ein
fälschungssicherer Nachrichtenkanal.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Thu, 11 Nov 2021 22:48:11 +0100, Helmut Waitzmann wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net>:
>>>On Sun, 07 Nov 2021 23:50:23 +0100, Helmut Waitzmann wrote:
>

>[...]

>
>>> Ich habe beispielsweise Deinen Schlüssel, wenn ihm auch nicht
>>> voll vertraut wird:
>>>
>>>| uid [ unknown] Helmut Waitzmann (Anti-Spam-Ticket.b.qc3c) <oe.th...@xoxy.net>
>>
>> Wie hast du überprüft, dass es wirklich mein Schlüssel ist? 
>> Hilft dir dabei das Web of Trust, oder hast du (oder der Automat
>> beim Provider, der für dich arbeitet) ein User‐Id zertifiziert?
>

>Mir ist in diesem Fall Vertrauen nicht wichtig.
>

Ich habe dich nicht nach Vertrauen sondern nach Überprüfung
gefragt.  Kannst oder willst du mich nicht verstehen oder nimmst du
es mit deinen Formulierungen nicht genau?  (So langsam vergeht mir
echt die Lust, alles wieder und wieder geradezurücken.)

Hier geht es nicht darum, ob du mir oder meinem Schlüssel
vertraust.  Hier geht es darum, dass oder woher du weißt, dass der
Schlüssel, den du als den meinen ansiehst, auch wirklich meiner ist:

>Wenn ich von einem User eine Email-Adresse im Usenet sehe, die auch
>in einer PGP-Datenbank enthalten ist, reicht mir das.

Ich gehe mal davon aus, dass die PGP‐Datenbank die Datenbank eines
öffentlichen Schlüsselservers war.  Ich habe meinen Schlüssel
jedenfalls nirgends sonst wohin als auf öffentliche Schlüsselserver
gelegt.

Du weißt aber schon, dass jeder einen Schlüssel, der meine
E‐Mail‐Adresse als User‐Id trägt, auf einen Schlüsselserver
hochladen kann?

Tipp:  Es gibt (oder: gab, falls die einschlägischen Schlüsselserver
inzwischen nicht mehr laufen) außer dem von dir gefundenen noch
mindestens einen weiteren Schlüssel auf Schlüsselservern, der in
einem User‐Id den Namen «Helmut Waitzmann» stehen hat.

>Der Grund ist, dass wenn wir privat mailen sollten, auch bei einer
>Verschlüsselungen wohl keine sensitiven Daten ausgetauscht werden.

Der Grund?  Wohl eher die Folgerung.


>Wenn Du aber eine Behörde oder Bank währst, würde ich Deinem Key
>ohne weitere Überprüfung allerdings nicht vertrauen.

Bitte sei in der Formulierung genau.  Du meinst:  Du würdest darauf,
dass ein Schlüssel, der als User‐Id meinen Namen trägt, wirklich mir
gehört, ohne weitere Überprüfung nicht vertrauen.

Solche Ungenauigkeiten tragen auch dazu bei, dass Leute, die mit
OpenPGP anfangen wollen, wenn sie ihren Verstand einsetzen, nur
Bahnhof verstehen und glauben, ihnen fehle das Verständnis.  In
Wirklichkeit stolpern sie (zu Recht) über einen Fehler im Text und
geben auf.

>[...]

>
>>> Insgesamt gesehen bin ich der Meinung, dass sich aufgrund der
>>> Unwissenheit und Überfordertsein sich Verschlüsselungen nie
>>> durchsetzen werden. Somit ist diese Diskussion müßig.
>>
>> Offensichtlich ist sie es nicht.  Immerhin hast du nun
>> verstanden, warum es «automatisch und ohne Zutun des Anwenders»
>> provider‐übergreifend prinzipiell nicht funktionieren kann,
>> solange man nicht allen daran beteiligten E‐Mail‐Providern
>> vertrauen kann.  Außerdem hätte es sonst den Beitrag
>>
>>
>> Subject: Re: [Lösung Subjectwechsel]
>> From: Michael Pachta <mip...@gmx.de>
>> Newsgroups: de.comm.software.mozilla.mailnews
>> Date: Sat, 23 Oct 2021 09:17:15 +0200
>> Message-ID: <ithr7p...@mid.individual.net>
>>
>> mit der Aussage (Zitat)
>>
>>
>> E-Mail-Verschlüsselung (und Signierung) wird sich erst
>> dann auf breiter Front durchsetzen, wenn dies ohne Zutun
>> des Anwenders läuft, also völlig transparent.
>>
>> so nicht gegeben:  «wird sich erst […] durchsetzen, wenn…» lässt
>> die Hoffnung anklingen, dass die Bedingung prinzipiell erfüllt
>> werden kann und erfüllt werden wird, wenn sich jemand auf den
>> Hosenboden setzt und ans Werk geht.  Anderenfalls würde da «würde
>> sich erst […] durchsetzen, wenn dies ohne Zutun des Anwenders
>> liefe…» stehen.
>

>Das grundlegende Problem wird sein, dass der Benutzer bei einer
>"automatisierten" Methode dem Anbieter voll und ganz vertrauen
>muss.

Nicht nur «dem Anbieter» sondern «den Anbietern», nämlich seinem
eigenen und denen der Nachrichtenempfänger.  Wenn auch nur einer von
ihnen ein Maulwurf ist, ist es vorbei mit der Vertraulichkeit der
verschlüsselten Nachricht.

>Will er das nicht, muss er sich auf seinen Hosenboden setzen, und
>selbst ans Werk gehen.
>
>So mache ich das. DE-Mail und ähnliche (automatisierte) Anbieter
>nutze ich daher nicht.

Ich auch nicht.

>
>Trotzdem erscheint mir eine automatisierte Methode besser, als gar
>keine Verschlüsselung/Signierung zu nutzen. Ohne, kann jeder Man In
>The Middle alle Mails mitlesen.

Sei bei diesem nicht ganz einfachen Thema bitte genau in der
Verwendung der Begriffe:  Ein Man In The Middle ist ein Angreifer,
der es schafft, in den Aufbau einer verschlüsselten Kommunikation so
(wie in dieser Diskussion beschrieben) einzubrechen, dass beide
Kommunikationspartner in ihrem Wissen, welchen Schlüssel ihr
Kommunikationspartner benutzt, so getäuscht werden, dass sie
anschließend (je) einen Schlüssel des Angreifers für den ihres
jeweiligen Kommunikationspartners halten und ihre Nachrichten
fröhlich für den Angreifer statt den Kommunikationspartner
verschlüsseln:

Wenn Mallory es schafft, Man In The Middle in der Kommunikation von
Alice und Bob zu werden, hält Alice einen von Mallory erzeugten
Schlüssel für Bob's, und Bob hält einen von Mallory erzeugten
Schlüssel für Alice's.  (Mallory kann für Alice und Bob denselben
Täuschungsschlüssel verwenden; sie kann aber auch für Alice einen
anderen als für Bob verwenden.)

Die Folge ist, dass Alice glaubt, ihre Nachrichten für Bob zu
verschlüsseln.  Aber sie verschlüsselt sie in Wahrheit für Mallory,
ohne es zu merken.  Dasselbe gilt umgekehrt auch für Bob.

Im Begriff «Man In The Middle» ist das Bild enthalten, dass der Man
In The Middle dem Blickkontakt zwischen beiden
Kommunikationspartnern im Weg steht:  Die Folge ist, dass beide
Kommunikationspartner einander nicht sehen können und, weil sie
einander zuvor nie gesehen haben, den Man In The Middle jeweils für
den anderen Kommmunikationspartner halten.

Nochmal zitiert:


>Trotzdem erscheint mir eine automatisierte Methode besser, als gar
>keine Verschlüsselung/Signierung zu nutzen. Ohne, kann jeder Man In
>The Middle alle Mails mitlesen.

Der letzte Satz darf (und sollte) also so heißen:  Ohne
Verschlüsselung/Signierung kann jeder, der an der Leitung lauschen
kann, alle Mails mitlesen.  Man In The Middle muss er dafür nicht
sein.

Eine automatisierte Methode schützt nur vor passiven Lauschern. 
Täuschende Mittelsmänner hält sie nicht ab.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Thu, 11 Nov 2021 22:49:25 +0100, Helmut Waitzmann wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net>:
>>>On Tue, 09 Nov 2021 10:42:18 +0100, Helmut Waitzmann wrote:
>>>
>> [E‐Mail‐Verschlüsselung und ‐Digitalunterschrift mit einem
>> automatisierten System ohne Zutun des Anwenders bereitzustellen,
>> krankt an der Verletzlichkeit gegenüber einem
>> Man‐in‐the‐Middle‐Angriff und ist deshalb keine gute Idee.]
>>
>>> Aber ein automatisiertes System ist IMO der einzige Weg,
>>> technophobe User zum Verschlüsseln zu bringen.
>>
>> Solche Anwender sind weniger technophob sondern eher
>> mathematische Analphabeten.
>

>Okay. Beide Begriffe fallen in diesem Bezug aber IMO in dieselbe
>Kategorie.

Finde ich nicht.  Digital natives würde ich nicht als technophob
bezeichnen.  Trotzdem werden viele von ihnen E‐Mails nicht
eigenhändig mit Public‐Key‐Kryptografie verschlüsseln und
unterschreiben wollen.

Public‐Key‐Kryptografie stützt sich auf wenige Voraussetzungen, die
man verstanden haben sollte, wenn man sie nutzen möchte:

(1)

Es geht immer um Schlüsselpaare.  Ein jeder Schlüssel in so einem
Paar erlaubt es, eine gewisse mathematische Abbildung – die
Verschlüsselung oder Entschlüsselung – vorzunehmen.  Bildlich
ausgedrückt:  Man dreht die zu verschlüsselnden Daten zusammen mit
dem Schlüssel als Gewürz durch einen Fleischwolf.  Heraus kommen die
Daten in gewürzter (= verschlüsselter) Form.  Im Gegensatz zur Küche
ist das Gewürz so stark, dass aus den gewürzten Daten das Original
nicht mehr zu erkennen ist.

Dabei passen die beiden Schlüssel eines Paares so zusammen, dass die
mit ihnen berechenbaren Abbildungen die Umkehrungen von einander
sind:  Was man mit dem einen Schlüssel verschlüsselt, kann man mit
dem anderen wieder entschlüsseln.  Und das funktioniert sogar in
beide Richtungen:  Seien Schlüssel 1 und Schlüssel 2 die beiden
Schlüssel eines Schlüsselpaares.  Dann kann man einen Text mit dem
Schlüssel 1 verschlüsseln und danach mit dem Schlüssel 2 wieder
entschlüsseln.  Und man kann einen Text mit dem Schlüssel 2
verschlüsseln und danach mit dem Schlüssel 1 wieder entschlüsseln. 
(Dabei kommt, wenn man einen Text mit dem Schlüssel 1 verschlüsselt,
etwas anderes dabei heraus, als dann, wenn man ihn mit dem Schlüssel
2 verschlüsselt.)

Bildlich ausgedrückt:  Die beiden Gewürze des Gewürzpaares passen
folgendermaßen zusammen:  Wenn ich Daten mit dem einen Gewürz durch
den Fleischwolf drehe und das, was dabei herauskommt, zusammen mit
dem anderen Gewürz nochmal durch den Fleischwolf drehe, dann erhalte
ich (auf wundersame Weise) wieder das ungewürzte Original.  Das
funktioniert auch, wenn ich jeweils beide Gewürze vertausche, also
zuerst mit dem anderen und dann mit dem einen Gewürz würze.  (Dabei
kommt, wenn ich die Daten mit dem einen Gewürz durch den Fleischwolf
drehe, etwas anderes heraus, als dann, wenn ich die Daten mit dem
anderen Gewürz durch den Fleischwolf drehe.)

(2)

Obwohl der Schlüssel 2 genau zum Schlüssel 1 passt (und umgekehrt),
kann man den einen Schlüssel nicht aus dem anderen berechnen. 
Dieses Nichtberechnenkönnen ist sehr wichtig, weil man in der
Anwendung des Verschlüsselungsverfahrens (s. u.) den einen von
beiden Schlüsseln bei sich geheim halten und den anderen
veröffentlichen will.

Dass man Verschlüsselungsverfahren so entwickeln kann, dass man den
einen Schlüssel eines Paares nicht aus dem anderen berechnen kann,
obwohl jeweils der eine die Umkehrrechnung des anderen ermöglicht,
ist durchaus erstaunlich.

Ein Gegenbeispiel soll das verdeutlichen:  Beispielsweise passt beim
Caesar‐Verschlüsselungsverfahren
(<https://de.wikipedia.org/wiki/Caesar-Verschl%C3%BCsselung#top>)
zum Verschlüsselungsschlüssel «jeder Buchstabe im Alphabet wird
durch seinen Nachfolger ersetzt (das A durch das B, das B durch das
C… das Y durch das Z und das Z durch das A)» der
Entschlüsselungsschlüssel «jeder Buchstabe im Alphabet wird durch
seinen Vorgänger ersetzt (das A durch das Z, das B durch das A… das
Z durch das Y)».  Hier ist es ein leichtes, aus dem
Verschlüsselungsschlüssel den passenden Entschlüsselungsschlüssel zu
berechnen:  Man braucht nur die Verschieberichtung des Alphabets
umzukehren.  Es ist also unmöglich, beim
Caesar‐Verschlüsselungsverfahren einen von beiden Schlüsseln geheim
zu halten, wenn man den anderen veröffentlicht.

(3)

Es ist praktisch unmöglich, einen mit dem Schlüssel 1
verschlüsselten Text zu entschlüsseln, wenn man den Schlüssel 2
nicht hat.  Dasselbe gilt, wenn man einen Text mit Schlüssel 2
verschlüsselt und versucht, ihn ohne Schlüssel 1 zu entschlüsseln.

Bildlich ausgedrückt:  Es ist praktisch unmöglich, Daten, die man
mit dem einen Gewürz durch den Fleischwolf gedreht hat, wieder zu
entwürzen, ohne das andere Gewürz aus dem Gewürzpaar zur Verfügung
zu haben.


Weil man den einen Schlüssel eines Schlüsselpaares nicht aus dem
anderen berechnen kann, braucht man ein Verfahren, mit dem man beide
Schlüssel gleichzeitig zusammen «erfindet».  Und solche Verfahren
gibt es.

(4)

Wenn man nun einen Schlüssel des Paares geheim halten und den
anderen veröffentlichen will, folgt daraus, dass derjenige, bei dem
der geheime Schlüssel bleiben soll, so ein Verfahren am besten
selber anwendet.  Wenn er das Schlüsselpaar statt dessen von jemand
anderem erzeugen lässt, ist bei der späteren Verwendung des
Schlüsselpaares die Vertraulichkeit nur dann gewahrt, wenn dieser
jemand andere den geheimen Schlüssel weder selber missbraucht noch
ihn anderen in die Hände fallen lässt.

Verschlüsselungsverfahren und Schlüsselpaare so zu entwickeln, dass
sie die aufgezählten Eigenschaften haben, ist Mathematik und
Kryptologie.

Der Anwender braucht für das Verständnis der Public‐Key‐Kryptografie
aber kein Kryptologe zu sein, wenn er sich nicht weiter hineinknien
möchte – für ihn genügt es, die geforderten Eigenschaften zu
verstehen.  Das meine ich mit dem Begriff «kein mathematischer
Analphabet zu sein».

Jetzt kann man sich typische Anwendungsfälle ansehen, die
funktionieren, weil die Verschlüsselungsverfahren und die
Schlüsselpaare die geforderten Eigenschaften haben:

Alice beschafft sich (beispielsweise automatisch mit Hilfe ihres
Mailer‐Programms) ein Schlüsselpaar mit den Schlüsseln A1 und A2,
die die oben angeführten Eigenschaften haben.  Den Schlüssel A1 hält
sie geheim; Kopien des Schlüssels A2 gibt sie allen ihren
Kommunikationspartnern (oder einfach der ganzen Welt).

Ebenso beschafft sich Bob ein Schlüsselpaar mit den Schlüsseln B1
und B2 und verfährt entsprechend.

Wenn Alice eine Kopie des Schlüssels B2 hat, kann sie damit eine
Nachricht verschlüsseln und Bob per E‐Mail schicken oder im Usenet
posten oder in einer Tageszeitung abdrucken lassen oder auf
Plakatwänden veröffentlichen.  Wenn Bob seinen Schlüssel B1 geheim
hält, ist er der einzige, der die Nachricht entschlüsseln kann: 
Wegen der Eigenschaft (3) kann niemand den Text ohne den Schlüssel
B1 entschlüsseln.  Wegen der Eigenschaft (2) kann sich niemand den
Schlüssel B1 selber aus dem Schlüssel B2 herstellen.

Beobachtungen:  Damit Alice eine Nachricht verfassen kann, die nur
Bob entschlüsseln kann, braucht es ein Schlüsselpaar, dessen
geheimer Schlüssel bei Bob ist und dessen öffentlicher Schlüssel bei
Alice ist:

Wenn der geheime Schlüssel (außer bei Bob noch) bei jemand anderem
ist, kann dieser jemand andere mitlesen.

(5)

Wenn der öffentliche Schlüssel nicht bei Alice ist, sondern Alice
einen anderen öffentlichen Schlüssel für Bob's hält, verschlüsselt
Alice die Nachricht nicht für Bob sondern für den, dem der andere
öffentliche Schlüssel gehört.  (Das ist beim
Man‐in‐the‐Middle‐Angriff der Fall.)  Und der kann dann die
Nachricht, wenn er sie abhört, entschlüsseln.

=> Voraussetzungen, damit die Nachricht vertraulich bleibt:  Niemand
außer Bob darf den Schlüssel B1 haben.  Alice muss den Schlüssel B2
haben und ihn für die Verschlüsselung von Nachrichten an Bob
benutzen.

>>> Das die Sicherheit nicht optimal ist
>>>
>>
>> Du hast aber schon verstanden, dass bei einem
>> Man‐in‐the‐Middle‐Angriff die Sicherheit nicht nur nicht optimal
>> ist, sondern schlichtweg vollständig zerstört ist?
>

>Ich kann auch im Beispiel einer automatisierten Methode keinen
>Man-in-the-Middle-Angriff erkennen.

Was ist dir bei


Subject: E-Mail-Verschluesselung und -Signierung ohne Zutun des
Anwenders? (was: [Lösung Subjectwechsel]) From: Helmut Waitzmann
<nn.th...@xoxy.net> Newsgroups:
de.comm.software.mozilla.mailnews, de.comp.security.misc
Followup-To: de.comp.security.misc Date: Mon, 25 Oct 2021
21:59:41 +0200 Message-ID:
<83tuh4c1...@helmutwaitzmann.news.arcor.de>

nicht verständlich?


Dass eine automatisierte Methode die Mitwirkung der E‐Mail‐Provider
des Nachrichten‐Senders und des Nachrichten‐Empfängers erfordert,
wurde ja inzwischen in der Diskussion festgehalten.  Des weiteren
kam dabei heraus, dass der Systemadministrator jedes beteiligten
E‐Mail‐Providers die Möglichkeit hat, Nachrichten abzufangen und
unter den Tisch fallen zu lassen oder zu verändern und verändert
weiterzuschicken oder sich neue selber auszudenken und im Namen
jedes beliebigen seiner Kunden weiterzuschicken.  Wenn er diese
Möglichkeiten nutzt, um gleich zu Anfang, wenn eine automatisierte
Methode eine (scheinbar) sichere Kommunikation aufbaut,
dazwischenzufunken, kann er zum Man in the Middle werden und die
Kommunikation vollständig unter seine Kontrolle bringen, ohne dass
die Kommunikationspartner etwas davon merken.

>Der Unterschied zwischen "selbst PGP machen" und einer
>automatisierten Methode liegt IMO darin, seine Keys vom Anbieter
>(statt selbst lokal) erzeugt zu haben.

Das berührt den Punkt (4) von oben.  Das ist aber nicht der ganze
Unterschied.  Ein weiterer ist, dass man die Zertifizierung der
Schlüssel der Kommunikationspartner nicht mehr selber vornimmt
sondern das den Anbietern der Kommunikationspartner überlässt.  Das
berührt den Punkt (5) von oben.

>Man muss dazu diesem Anbieter
>

nicht nur diesem Anbieter sondern auch den Anbietern der
Kommunikationspartner

>(statt nur sich selbst) voll und ganz vertrauen.
>
>
>Ohne kann man immer Man-in-the-Middle-Angriffen ausgesetzt sein.
>

Egal, ob man dem eigenen E‐Mail‐Anbieter und den E‐Mail‐Anbietern
der Kommunikationspartner vertraut oder nicht:  Wenn die
E‐Mail‐Anbieter die Schlüsselpaare für die Anwender erzeugen, können
sie die Punkte (4) und (5) von oben verletzen und einen
Man‐in‐the‐Middle‐Angriff fahren.

Wem das als Anwender nicht passt, der muss seine Schlüssel selber
erzeugen und die seiner Kommunikationspartner selber zertifizieren. 
Erst dann haben Man‐in‐the‐Middle‐Angriffe keine Chance.

Seine eigenen Schlüssel selber zu erzeugen, ist einfach:  Wie
beschrieben, können das Mailer‐Programme sogar ohne Zutun des
Anwenders automatisch tun.

Schwieriger ist das Zertifizieren des Schlüssels des
Kommunikationspartners, also die Zuordnung eines Schlüssels zu einem
Kommunikationspartner, weil der Schlüssel dabei unverfälscht vom
Kommunikationspartner zum Anwender kommen muss.  Die klassische
Methode ist, den Kommunikationspartner zu treffen und sich den
Schlüssel (oder dessen Fingerprint) geben zu lassen oder – sofern
bereits vorhanden – das Web of Trust zu nutzen.

>Das Vertrauen in einen externen Anbieter scheint mir das kleinere
>Übel zu sein.

Ich sage nur «Yahoo».

>>> muss vom User akzeptiert werden.
>>>
>>
>> Das sage bitte denen ins Gesicht, die Opfer eines
>> Man‐in‐the‐Middle‐Angriffs geworden sind, weil sie auf den
>> Werbeslogan «Geht ganz automatisch ohne Zutun des Anwenders! 
>> Kein Web of Trust und kein Austausch von Fingerprints nötig!»
>> hereingefallen sind.
>>
>> Hast du jetzt wenigstens verstanden, dass zum Aufbau einer abhör‐
>> und fälschungssicheren Kommunikation per E‐Mail zwischen zwei
>> Partnern (mit je einem Nachrichtenkanal in jeder Richtung) von
>> vorne herein beide Kanäle abhör‐ oder beide Kanäle
>> fälschungssicher sein müssen oder in einer Richtung ein abhör‐
>> und fälschungssicherer Kanal vorhanden sein muss?  Wenn zwischen
>> den beiden Kommunikationspartnern (wenigstens) eine dieser
>> Möglichkeiten vorhanden ist, dann können beide Partner daraus
>> mittels Public‐Key‐Kryptografie in beide Richtungen je einen
>> abhör‐ und fälschungssicheren Nachrichtenkanal erstellen. 
>> Billiger kriegt man es nicht hin.
>

>Eine automatisierte Methode (alles von einem Anbieter einrichten zu
>lassen) bietet diese Funktion.

Nein:  Wenn sich die von OpenPGP gesicherten Nachrichtenkanäle nur
auf den Weg vom E‐Mail‐Anbieter der Anwenderin bis zum
E‐Mail‐Anbieter des Kommunikationspartners erstrecken statt von der
Anwenderin zum Kommunikationspartner, können sich die
Administratoren der E‐Mail‐Anbieter zum Man in the Middle machen.

>Wie erwähnt, muss man dem Anbieter aber dabei unbedingt vertrauen.
>

Man muss allen beteiligten Anbietern, nicht nur dem eigenen,
vertrauen.

>Also angenommen Du und ich würden einen entsprechenden
>(automatisierten) Dienst beim Versenden und Empfangen von E-Mails
>über ein Web-Interface nutzen, können diese nicht abgehört werden.

Egal, ob Web‐Interface oder sonst wie:  Die beteiligten
E‐Mail‐Provider können Man‐in‐the‐Middle‐Angriffe fahren.

>IMO ist eine automatisierte Methode (in der der Nutzer dem Anbieter
>kein volles Vertrauen schenkt) besser, als seine Kommunikation gar
>nicht zu verschlüsseln.

Ein Anwender, der sich auf eine automatisierte Methode seines
Anbieters verlässt, schenkt den beteiligten Anbietern damit
automatisch volles Vertrauen, denn er kann ihnen nicht auf die
Finger schauen.  Also gibt es keine automatisierte Methode des
Anbieters, in der der Anwender dem Anbieter kein volles Vertrauen
schenkt.

Ob das besser ist, als überhaupt nicht zu verschlüsseln, mag auf den
Einzelfall ankommen.  Auf jeden Fall ist es gefährlich, für die
Benutzung einer provider‐gestützten automatisierten Methode zu
werben oder nach einer solchen zu rufen, ohne den Adressaten der
Werbung zu erklären, wo dabei die Gefahr des Totalverlusts der
Vertraulichkeit und der Fälschungssicherheit lauert.

Und wenn man den Adressaten der Werbung die Gefahr so gut erklärt
hat, dass sie sie verstanden haben – dazu müssen sie insbesondere
die Punkte (1) bis (5) von oben verstanden haben –, dann braucht man
die provider‐gestützte automatisierte Methode nicht mehr, weil die
Adressaten dann in der Lage sind, in Beachtung der Punkte (1) bis
(5), unterstützt von ihrem Mailer‐Programm, die Schlüssel für die
Public‐Key‐Kryptografie selber zu verwalten.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Tue, 16 Nov 2021 23:07:09 +0100, Helmut Waitzmann wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net>:

>> Hier geht es nicht darum, ob du mir oder meinem Schlüssel
>> vertraust.  Hier geht es darum, dass oder woher du weißt, dass
>> der Schlüssel, den du als den meinen ansiehst, auch wirklich
>> meiner ist:
>

>Wissen, ob es meiner ist, ist doch mit Vertrauen gleichzusetzen,
>oder?

Wenn du hier unbedingt von Vertrauen sprechen willst, ist es das
Vertrauen, das du in dich hast:  Du vertraust dir, dass du
sorgfältig genug geprüft hast, ob der Schlüssel, von dem du
annimmst, dass er meiner ist, auch wirklich mein Schlüssel ist.

Sollte sich irgendwann herausstellen, dass der Schlüssel nicht
meiner ist, habe nicht ich oder der Schlüssel dein Vertrauen
enttäuscht sondern du selbst.

>>> Wenn ich von einem User eine Email-Adresse im Usenet sehe, die
>>> auch in einer PGP-Datenbank enthalten ist, reicht mir das.
>>
>> Ich gehe mal davon aus, dass die PGP‐Datenbank die Datenbank
>> eines öffentlichen Schlüsselservers war.  Ich habe meinen
>> Schlüssel jedenfalls nirgends sonst wohin als auf öffentliche
>> Schlüsselserver gelegt.
>

>Ja, öffentlicher Schlüsselserver.

>
>
>> Du weißt aber schon, dass jeder einen Schlüssel, der meine
>> E‐Mail‐Adresse als User‐Id trägt, auf einen Schlüsselserver
>> hochladen kann?
>

>Ja. Erscheint mir aber so unwahrscheinlich, dass ich den trotzdem
>"vertraue". Außer Du wärst eine "High-Profile" Person. Dann würde
>ich den Schlüssel lieber persönlich erhalten.

Ich fürchte, ich muss doch noch irgendwo einen Schlüssel mit einem
User‐Id für Andreas Kohlbach hochladen, auch wenn du nicht
«high‐profile» sein solltest.

>Was auch hilft ist den Fingerprint des eigenen Schlüssels auf der
>eigenen Webseite zu veröffentlichen - wenn man darauf vertraut,
>dass die Webseite auch der entsprechenden Person gehört.

… und, dass sie nicht gekapert ist, und, dass die Zertifikate‐Kette
der HTTPS‐Verbindung nicht kompromittiert ist.

>>>[...]

>>>
>>> Das grundlegende Problem wird sein, dass der Benutzer bei einer
>>> "automatisierten" Methode dem Anbieter voll und ganz vertrauen
>>> muss.
>>
>> Nicht nur «dem Anbieter» sondern «den Anbietern», nämlich seinem
>> eigenen und denen der Nachrichtenempfänger.  Wenn auch nur einer
>> von ihnen ein Maulwurf ist, ist es vorbei mit der Vertraulichkeit
>> der verschlüsselten Nachricht.
>

>Ich ging der Einfachheit halber erst von einer Methode aus, die
>durchaus mehrere Anbieter anbieten können. Wie "DE-MAIL". Man muss
>nur DE-MAIL selbst vertrauen.

Da hast du De‐Mail nicht richtig verstanden:  Man muss dabei vor
allem den beteiligten Anbietern vertrauen, denn De‐Mail macht
m. W. nur Transportverschlüsselung.  Deshalb kann jeder am Transport
beteiligte De‐Mail‐Anbieter die Nachricht lesen und verändern.

>>> Trotzdem erscheint mir eine automatisierte Methode besser, als
>>> gar keine Verschlüsselung/Signierung zu nutzen. Ohne, kann jeder
>>> Man In The Middle alle Mails mitlesen.
>>
>> Sei bei diesem nicht ganz einfachen Thema bitte genau in der
>> Verwendung der Begriffe:  Ein Man In The Middle ist ein
>> Angreifer, der es schafft, in den Aufbau einer verschlüsselten
>> Kommunikation so (wie in dieser Diskussion beschrieben)
>> einzubrechen, dass beide Kommunikationspartner in ihrem Wissen,
>> welchen Schlüssel ihr Kommunikationspartner benutzt, so getäuscht
>> werden, dass sie anschließend (je) einen Schlüssel des Angreifers
>> für den ihres jeweiligen Kommunikationspartners halten und ihre
>> Nachrichten fröhlich für den Angreifer statt den
>> Kommunikationspartner verschlüsseln:
>

>Dazu müsste die entsprechende Methode gehackt sein. Oder (was sehr
>viel wahrscheinlicher ist) der Rechner einer oder beider Parteien
>kompromittiert sein.

Nein.  Gehackt oder kompromittiert muss dazu nichts sein.  Es
genügt, wenn ein Systemadministrator eines der am Transport der
(De‐Mail‐) Nachricht beteiligten Anbieter seine technischen
Möglichkeiten nutzt, um Man‐in‐the‐Middle zu spielen.

[Helmut Waitzmann]

Helmut Waitzmann <nn.th...@xoxy.net>:

>Was ist dir bei
>
>
> Subject: E-Mail-Verschluesselung und -Signierung ohne Zutun des
> Anwenders? (was: [Lösung Subjectwechsel]) From: Helmut Waitzmann
> <nn.th...@xoxy.net> Newsgroups:
> de.comm.software.mozilla.mailnews, de.comp.security.misc
> Followup-To: de.comp.security.misc Date: Mon, 25 Oct 2021
> 21:59:41 +0200 Message-ID:
> <83tuh4c1...@helmutwaitzmann.news.arcor.de>
>

Autsch.  Das hätte so aussehen sollen:

[Friedhelm Waitzmann]

Helmut Waitzmann:

>Das sage bitte denen ins Gesicht, die Opfer eines
>Man‐in‐the‐Middle‐Angriffs geworden sind, weil sie auf den
>Werbeslogan «Geht ganz automatisch ohne Zutun des Anwenders! 
>Kein Web of Trust und kein Austausch von Fingerprints nötig!»
>hereingefallen sind.

Diesen verlogenen Werbeslogan findet man z. B. bei Mailvelope
(<https://keys.mailvelope.com/>). Zitat:

>No Web of Trust
>
>No more key signing parties or publishing your social network
>online. You can even delete your public key at anytime.

Zitatende. Und unter »Learn more
(<https://github.com/mailvelope/keyserver/blob/master/README.md#why-not-use-web-of-trust>)
im Abschnitt »Usability« (Zitat):

>The main issue with the Web of Trust though is that it does not
>scale in terms of usability. The goal of this key server is to
>enable a better user experience for OpenPGP user agents by
>providing a more reliable source of public keys. Similar to
>messengers like Signal, users verify their email address by
>clicking on a link of a PGP encrypted message. This prevents
>user A from uploading a public key for user B. With this
>property in place, automatic key lookup is more reliable than
>with standard SKS servers.

Zitatende. Soso. Wenn durch dieses Verfahren – Link in einer
pgp‐verschlüsselten, d. h., für den Angreifer A verschlüsselten,
Nachricht – verhindert werden können soll, dass der Angreifer A
einen falschen öffentlichen Schlüssel für Benutzer B hochlädt,
muss der E‐Mail‐Dienst abhörsicher sein, damit der Angreifer A
diesen Link trotzdem nicht bekommt, obwohl er für ihn
verschlüsselt ist. In diesem Fall braucht man dann überhaupt
keine E‐Mail‐Verschlüsselung mehr, und Mailvelope ist damit
überflüssig.



Friedhelm

[Arno Welzel]

Andreas Kohlbach:

[...]

> Eine automatisierte Methode (alles von einem Anbieter einrichten zu

> lassen) bietet diese Funktion. Wie erwähnt, muss man dem Anbieter aber
> dabei unbedingt vertrauen. Allerdings wird diese aber nur bei der
> Kommunikation über sein Web-Interface funktionieren.

Genau deshalb ist dieser Anbieter ja "Man-in-the-middle".

> Also angenommen Du und ich würden einen entsprechenden (automatisierten)
> Dienst beim Versenden und Empfangen von E-Mails über ein Web-Interface
> nutzen, können diese nicht abgehört werden.

Doch - vom Betreiber des Web-Interface.



--
Arno Welzel
https://arnowelzel.de

[Arno Welzel]

Friedhelm Waitzmann:

[...]

> Zitatende. Und unter »Learn more
> (<https://github.com/mailvelope/keyserver/blob/master/README.md#why-not-use-web-of-trust>)
> im Abschnitt »Usability« (Zitat):
>
>> The main issue with the Web of Trust though is that it does not
>> scale in terms of usability. The goal of this key server is to
>> enable a better user experience for OpenPGP user agents by
>> providing a more reliable source of public keys. Similar to
>> messengers like Signal, users verify their email address by
>> clicking on a link of a PGP encrypted message. This prevents
>> user A from uploading a public key for user B. With this
>> property in place, automatic key lookup is more reliable than
>> with standard SKS servers.
>
> Zitatende. Soso. Wenn durch dieses Verfahren – Link in einer
> pgp‐verschlüsselten, d. h., für den Angreifer A verschlüsselten,
> Nachricht – verhindert werden können soll, dass der Angreifer A
> einen falschen öffentlichen Schlüssel für Benutzer B hochlädt,
> muss der E‐Mail‐Dienst abhörsicher sein, damit der Angreifer A
> diesen Link trotzdem nicht bekommt, obwohl er für ihn
> verschlüsselt ist. In diesem Fall braucht man dann überhaupt
> keine E‐Mail‐Verschlüsselung mehr, und Mailvelope ist damit
> überflüssig.

Demonstriere bitte, wie Du eine E-Mail an mich von einem von mir
vorgegebenen Server abfängst - also konkret an use...@arnowelzel.de.
Wenn Du das zuverlässig vorführen kannst, dann reden wir weiter.

Neben der theoretischen Möglichkeit muss man auch immer die praktische
Durchführbarkeit berücksichtigen.

[Stefan Claas]

On Monday, November 22, 2021 at 6:04:50 PM UTC+1, Arno Welzel wrote:
> Friedhelm Waitzmann:

> > Zitatende. Soso. Wenn durch dieses Verfahren – Link in einer
> > pgp‐verschlüsselten, d. h., für den Angreifer A verschlüsselten,
> > Nachricht – verhindert werden können soll, dass der Angreifer A
> > einen falschen öffentlichen Schlüssel für Benutzer B hochlädt,
> > muss der E‐Mail‐Dienst abhörsicher sein, damit der Angreifer A
> > diesen Link trotzdem nicht bekommt, obwohl er für ihn
> > verschlüsselt ist. In diesem Fall braucht man dann überhaupt
> > keine E‐Mail‐Verschlüsselung mehr, und Mailvelope ist damit
> > überflüssig.
> Demonstriere bitte, wie Du eine E-Mail an mich von einem von mir
> vorgegebenen Server abfängst - also konkret an use...@arnowelzel.de.
> Wenn Du das zuverlässig vorführen kannst, dann reden wir weiter.
>
> Neben der theoretischen Möglichkeit muss man auch immer die praktische
> Durchführbarkeit berücksichtigen.

Warum sollte er das hier für dich demonstrieren? Glaube mir, MITM trotz
zusätzlicher TLS Verschlüsselung deines eigenen email Servers, funktioniert.

Grüße
Stefan

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Sat, 20 Nov 2021 23:52:22 +0100, Helmut Waitzmann wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net>:
>>> On Tue, 16 Nov 2021 23:07:09 +0100, Helmut Waitzmann wrote:
>>>>
>>>> Du weißt aber schon, dass jeder einen Schlüssel, der meine
>>>> E‐Mail‐Adresse als User‐Id trägt, auf einen Schlüsselserver
>>>> hochladen kann?
>>>
>>> Ja. Erscheint mir aber so unwahrscheinlich, dass ich den
>>> trotzdem "vertraue". Außer Du wärst eine "High-Profile" Person.
>>> Dann würde ich den Schlüssel lieber persönlich erhalten.
>>
>> Ich fürchte, ich muss doch noch irgendwo einen Schlüssel mit
>> einem User‐Id für Andreas Kohlbach hochladen, auch wenn du nicht
>> «high‐profile» sein solltest.
>

>Wo ist das ein Problem? Mein Name ist zwar nicht häufig
>anzutreffen, trotzdem gibt es noch andere mit diesem Namen.

Wenn jemand ebenfalls einen Schlüssel mit einem User‐Id, das den
Namen Andreas Kohlbach und deine E‐Mail‐Adresse enthält,
veröffentlicht, hat jeder, der sich deinen Schlüssel vom
Schlüssel‐Server holen will, Auswahl.  Solange er von dir nicht den
Fingerprint unverfälscht erhalten hat, weiß er nicht, welchen der
Schlüssel er als den deinen ansehen soll.

>Ich könnte sagen, "Ich muss mal einen Schlüssel mit der User-Id
>"Thomas Meyer" hochladen.
>
>Gerade mal einen Keyserver abgesucht:
>
>
>| Keys 1-14 of 100 for "Thomas Meyer"
>
>Wie will ich da einem bestimmten Thomas Meyer durch einen Upload
>Schaden zufügen können? Dazu müsste ich einen Schlüssel *mit*
>seiner Email-Adresse erstellen (kann ich) und hochladen (kann ich
>nicht).

Ich habe schon länger nicht mehr versucht, auf einen
Schlüssel‐Server einen Schlüssel hochzuladen; aber, als ich das das
letzte Mal getan habe, konnte ich einen Schlüssel mit einem
beliebigen User‐Id hochladen:  Ich musste mich dazu nicht am
Schlüssel‐Server einloggen und auch nicht beweisen, dass die im
User‐Id enthaltene E‐Mail‐Adresse mir gehört (so ein Beweis ist im
Allgemeinen auch nicht möglich).

=> Ich hätte ohne weiteres als User‐Id deine E‐Mail‐Adresse wählen
können.

>[...]

>
>>>> Nicht nur «dem Anbieter» sondern «den Anbietern», nämlich
>>>> seinem eigenen und denen der Nachrichtenempfänger.  Wenn auch
>>>> nur einer von ihnen ein Maulwurf ist, ist es vorbei mit der
>>>> Vertraulichkeit der verschlüsselten Nachricht.
>>>
>>> Ich ging der Einfachheit halber erst von einer Methode aus, die
>>> durchaus mehrere Anbieter anbieten können. Wie "DE-MAIL". Man
>>> muss nur DE-MAIL selbst vertrauen.
>>

[De‐Mail macht keine Ende‐zu‐Ende‐Verschlüsselung.]

>> Deshalb kann jeder am Transport beteiligte De‐Mail‐Anbieter die
>> Nachricht lesen und verändern.
>

>Der/die Anbieter kann/können immer. Hier kommt das mehrfach
>erwähnte unbedingte Vertrauen ins Spiel.

Vielleicht kriegen wir doch noch die Kurve:  Wenn Alice und Bob
einander die öffentlichen Schlüssel unverfälscht zukommen lassen
haben, haben Man‐in‐the‐Middle‐Angriffe keine Chance mehr.  Dann
können selbst die (De‐Mail‐) Anbieter keinen Angriff mehr fahren: 
Die Kommunikation von Alice mit Bob bleibt unverfälscht und
vertraulich.

Alice und Bob können also beliebige E‐Mail‐Anbieter nutzen – sie
können sogar ganz ohne E‐Mail arbeiten und ihre verschlüsselten
unterschriebenen Nachrichten beispielsweise im Usenet
veröffentlichen oder in einer Tageszeitung abdrucken lassen oder auf
Litfaßsäulen plakatieren.

=> De‐Mail ist, was die Sicherung der Unverfälschtheit und
Vertraulichkeit von Nachrichten zwischen Alice und Bob angeht, weder
hinreichend noch notwendig, kurz: vollkommen überflüssig.

[Friedhelm Waitzmann]

Arno Welzel:

>Demonstriere bitte, wie Du eine E-Mail an mich von einem von mir
>vorgegebenen Server abfängst - also konkret an use...@arnowelzel.de.
>Wenn Du das zuverlässig vorführen kannst, dann reden wir weiter.

Das braucht ja nicht an Deinem Mailserver zu geschehen. Dass
beispielsweise Yahoo sich hat von China kompromittieren lassen,
wurde ja schon erwähnt.



Friedhelm

[Arno Welzel]

Andreas Kohlbach:

> On Mon, 22 Nov 2021 17:53:56 +0100, Arno Welzel wrote:
>>
>> Andreas Kohlbach:
>>
>> [...]
>>> Eine automatisierte Methode (alles von einem Anbieter einrichten zu
>>> lassen) bietet diese Funktion. Wie erwähnt, muss man dem Anbieter aber
>>> dabei unbedingt vertrauen. Allerdings wird diese aber nur bei der
>>> Kommunikation über sein Web-Interface funktionieren.
>>
>> Genau deshalb ist dieser Anbieter ja "Man-in-the-middle".
>

> Wenn man dem Anbieter vertraut, akzeptiert man den "Man-in-the-middle".

Was an der technischen Konstellation dennoch nichts ändert. Wenn man
generell irgendwem vertraut, braucht man diesen Anbieter nicht, sondern
kann dem Kommunikationspartner den eigenen Schlüssel auch direkt geben,
z.B. als Datei auf der eigenen Website, die per HTTPS erreichbar ist.

[Arno Welzel]

Stefan Claas:

Wenn es funktioniert, kann man es ja sicher leicht demonstrieren.

[Arno Welzel]

Friedhelm Waitzmann:

Das hat dann aber nichts mehr mit "abören" im Sinne eins
Man-in-the-middle zu tun, sondern ist ein gehackter E-Mail-Account. Da
muss niemand mehr unterwegs etwas abgreifen, sondern holt sich die Daten
einfach auf dem Mailservers des Empfängers.

Auch der PC des Empfängers kann gehackt werden - Malware und Trojaner
existieren ja ebenfalls.

[Arno Welzel]

Volker Delf:

> Friedhelm Waitzmann schrieb:

>>
>> Zitatende. Soso. Wenn durch dieses Verfahren – Link in einer

>> pgp?verschlüsselten, d.?h., für den Angreifer A verschlüsselten,

>> Nachricht – verhindert werden können soll, dass der Angreifer A
>> einen falschen öffentlichen Schlüssel für Benutzer B hochlädt,

>> muss der E?Mail?Dienst abhörsicher sein, damit der Angreifer A

>> diesen Link trotzdem nicht bekommt, obwohl er für ihn
>> verschlüsselt ist. In diesem Fall braucht man dann überhaupt

>> keine E?Mail?Verschlüsselung mehr, und Mailvelope ist damit
>> überflüssig.
>>
> Wozu die Aufregung: Wenn De-Mail stirbt, so bei der Telekom, dann stirbt
> auch Mailvelope.

Verschlüsselung von E-Mail mag im Einzelfall zwischen einer handvoll
Leuten funktionieren, die sich das explizit so ausgesucht haben und die
Abläufe beherrschen. Aber in der breiten Masse hat das faktisch nie
funktioniert und wird auch nicht funktionieren, egal wie sehr man es
versucht. E-Mail war nie dafür gedacht und das nachträglich
dranzufrickeln, ändert daran nichts.

Siehe dazu auch:

<https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html>

<https://florian-berger.de/de/texte/bitte-hoert-auf-fuer-pgp-zu-werben/>

[Stefan Claas]

Sicherlich könnte man das, jedoch müssten dann vermutlich Personen in dieser
Position, für eine öffentliche Demonstration, sich mit dir in Verbindung setzen
und schriftlich absichern, damit das offiziell wär. Fraglich ist nur ob sie ihre
Trümpfe gerne aus der Hand geben.

Grüße
Stefan

[Arno Welzel]

Stefan Claas:

> On Tuesday, November 23, 2021 at 11:25:19 AM UTC+1, Arno Welzel wrote:

[...]

>> Wenn es funktioniert, kann man es ja sicher leicht demonstrieren.
>
> Sicherlich könnte man das, jedoch müssten dann vermutlich Personen in dieser
> Position, für eine öffentliche Demonstration, sich mit dir in Verbindung setzen
> und schriftlich absichern, damit das offiziell wär. Fraglich ist nur ob sie ihre
> Trümpfe gerne aus der Hand geben.

Ich würde das selbstverständlich auch jederzeit rechtsverbindlich
bestätigen, dass ich das Abfangen einer E-Mail von mir keine
juristischen Folgen hätte. Und "Trümpfe aus der Hand" geben verlange ich
gar nicht - es würde schon genügen, wenn jemand zeigen kann, wie er sich
vom Inhalt einer E-Mail, die ich von einer GMail-Adresse an eine
GMX-Adresse schicke (oder umgekehrt), Kenntnis verschaffen kann, indem
er einen darin enthalten Text 1:1 wiedergibt.

[Stefan Claas]

Und was hättest Du davon? Selbst wenn die Technik gut wär, Du bist abhängig
von Dritten (Menschen deren Verhalten Du nicht kennst) und im Fall, dass Dein Kommunikationspartner nicht die Fitness wie Du besitzt, dass er dann auch ein
Einfallstor sein kann.

Grüße
Stefan

[Andreas Kohlbach]

On Tue, 23 Nov 2021 11:24:46 +0100, Arno Welzel wrote:
>
> Andreas Kohlbach:
>
>> On Mon, 22 Nov 2021 17:53:56 +0100, Arno Welzel wrote:
>>>
>>> Andreas Kohlbach:
>>>
>>> [...]
>>>> Eine automatisierte Methode (alles von einem Anbieter einrichten zu
>>>> lassen) bietet diese Funktion. Wie erwähnt, muss man dem Anbieter aber
>>>> dabei unbedingt vertrauen. Allerdings wird diese aber nur bei der
>>>> Kommunikation über sein Web-Interface funktionieren.
>>>
>>> Genau deshalb ist dieser Anbieter ja "Man-in-the-middle".
>>
>> Wenn man dem Anbieter vertraut, akzeptiert man den "Man-in-the-middle".
>
> Was an der technischen Konstellation dennoch nichts ändert. Wenn man
> generell irgendwem vertraut, braucht man diesen Anbieter nicht, sondern
> kann dem Kommunikationspartner den eigenen Schlüssel auch direkt geben,
> z.B. als Datei auf der eigenen Website, die per HTTPS erreichbar ist.

Das ist für die meisten zu kompliziert. So lassen sie es.

Eine automatisierte Methode könnte dagegen zumindest einige dieser dazu
bewegen, doch zu verschlüsseln, da sie sich selbst um Schlüsselübergaben
und anderes nicht kümmern müssen.

Erinnert mich an die 1990er, als das Internet für die meisten neu war. In
Windows (95) z.B. könnte man in die Einstellungen gehen, ggf. TCP/IP
hinzufügen, ID und Passwort eintragen. Genau oben genannte Klientel
scheiterte daran. Wie "gut", dass es AOL (und andere Anbieter) habe, die
Haushalte mit kostenlosen Bierdeckeln überschwemmten. Einlegen, ein paar
Klicks, und schon war man drin. Das wusste sogar Boris Becker.

Ohne diese ebenfalls automatisierte Lösungen wären viele User außen vor
geblieben. Scheint mir analog zu den Verschüsselungsproblem zu sein.
--
Andreas

[Andreas Kohlbach]

On Tue, 23 Nov 2021 11:29:59 +0100, Arno Welzel wrote:
>
> Volker Delf:

>
>> Wozu die Aufregung: Wenn De-Mail stirbt, so bei der Telekom, dann stirbt
>> auch Mailvelope.
>
> Verschlüsselung von E-Mail mag im Einzelfall zwischen einer handvoll
> Leuten funktionieren, die sich das explizit so ausgesucht haben und die
> Abläufe beherrschen. Aber in der breiten Masse hat das faktisch nie
> funktioniert und wird auch nicht funktionieren, egal wie sehr man es
> versucht.

Sehe ich auch so. Selbst eine von mir erwähnte automatische Methode wird
kaum mehr Leute zum Verschlüsseln bewegen (abgesehen davon, dass man
selbst keine Kontrolle hat, sondern den Anbietern voll vertrauen muss).

> E-Mail war nie dafür gedacht und das nachträglich dranzufrickeln,
> ändert daran nichts.

Aber PGP und anderes funktionieren, auch wenn es dazugefrickelt
ist. Verschlüsseltes wird über einen Klartext-Kanal verschickt. Ein
Man-In-The-Middle sieht trotzdem nur Verschlüsseltes.
--
Andreas

[Stefan Claas]

Dann frage dich mal warum damals MITM bei PGP erwähnt wurde,
denn PGP wurde ja nicht wegen MITM entwickelt.

Oder anders herumgefragt, weißt du wo Eve oder Mallory abgreift
und wie? Ich würde den Begriff heutzutage eher umbenennen in
Mann (irgendwo) im Kanal (inklusive Endpunkt) und nicht in der Mitte.

Grüße
Stefan

[Arno Welzel]

Andreas Kohlbach:

> On Mon, 22 Nov 2021 22:57:45 +0100, Helmut Waitzmann wrote:
[...]

>> Ich habe schon länger nicht mehr versucht, auf einen Schlüssel‐Server
>> einen Schlüssel hochzuladen; aber, als ich das das letzte Mal getan
>> habe, konnte ich einen Schlüssel mit einem beliebigen User‐Id
>> hochladen:  Ich musste mich dazu nicht am Schlüssel‐Server einloggen
>> und auch nicht beweisen, dass die im User‐Id enthaltene E‐Mail‐Adresse
>> mir gehört (so ein Beweis ist im Allgemeinen auch nicht möglich).
>>
>> => Ich hätte ohne weiteres als User‐Id deine E‐Mail‐Adresse wählen
>> können.
>

> Was genau ist in diesem Zusammenhang eine User-ID?

Gemeint war wohl die E-Mail-Adresse, die zur Identifikation des
Schlüssels dient. Bei den alten PGP-Key-Servern ging das - jeder konnte
einfach einen neuen Public Key für eine existierende E-Mail-Adresse
erzeugen und hochladen. Der Absender musst dann selber entscheiden,
welchem der verfügbaren Keys er vertraut.

[Arno Welzel]

Andreas Kohlbach:

> On Tue, 23 Nov 2021 11:24:46 +0100, Arno Welzel wrote:
>>
>> Andreas Kohlbach:
>>
>>> On Mon, 22 Nov 2021 17:53:56 +0100, Arno Welzel wrote:
>>>>
>>>> Andreas Kohlbach:
>>>>
>>>> [...]
>>>>> Eine automatisierte Methode (alles von einem Anbieter einrichten zu
>>>>> lassen) bietet diese Funktion. Wie erwähnt, muss man dem Anbieter aber
>>>>> dabei unbedingt vertrauen. Allerdings wird diese aber nur bei der
>>>>> Kommunikation über sein Web-Interface funktionieren.
>>>>
>>>> Genau deshalb ist dieser Anbieter ja "Man-in-the-middle".
>>>
>>> Wenn man dem Anbieter vertraut, akzeptiert man den "Man-in-the-middle".
>>
>> Was an der technischen Konstellation dennoch nichts ändert. Wenn man
>> generell irgendwem vertraut, braucht man diesen Anbieter nicht, sondern
>> kann dem Kommunikationspartner den eigenen Schlüssel auch direkt geben,
>> z.B. als Datei auf der eigenen Website, die per HTTPS erreichbar ist.
>
> Das ist für die meisten zu kompliziert. So lassen sie es.

E-Mail mit eigenem Client ist schon ohne Verschlüsselung komplex genug -
man muss wissen, welche Server man für Posteingang und Versand benutzen
muss, ob man IMAP oder POP3 verwenden will, ob die Server STARTTLS oder
TLS arbeiten, wie das Passwort übermittelt werden soll usw..

Das führt dazu, dass viele Leute nur die Web-Oberfläche ihres
Mailanbieters nutzen - und Verfahren wie PGP sind da ohnehin komplett
sinnfrei.

> Eine automatisierte Methode könnte dagegen zumindest einige dieser dazu
> bewegen, doch zu verschlüsseln, da sie sich selbst um Schlüsselübergaben
> und anderes nicht kümmern müssen.

Ja - einige der Wenigen von den Wenigen, die überhaupt ein eigenes
E-Mail-Programm nutzen. Und für Firmenkunden ist das auch eher
uninteressant, weil sich da auch eine Administration um die
E-Mail-Konfiguration kümmert.

> Erinnert mich an die 1990er, als das Internet für die meisten neu war. In
> Windows (95) z.B. könnte man in die Einstellungen gehen, ggf. TCP/IP
> hinzufügen, ID und Passwort eintragen. Genau oben genannte Klientel

Mit einem Router war das nicht erforderlich - genauso wenig, wie heute.
Nur hatte damals halt nicht jeder einen Router, weil das in den frühen
Jahren des Internet via ISDN oder Modem nicht üblich war. Und für ISDN
oder Modems genügte auch nicht nur ID und Passwort, sondern man musste
auch die ISDN-Hardware oder Modem einrichten - das war auch für AOL oder
T-Online notwendig.

> scheiterte daran. Wie "gut", dass es AOL (und andere Anbieter) habe, die
> Haushalte mit kostenlosen Bierdeckeln überschwemmten. Einlegen, ein paar
> Klicks, und schon war man drin. Das wusste sogar Boris Becker.

Das hast Du definitiv falsch in Erinnerung. Auch die AOL-Software
benötigte wenigstens ein Modem oder eine ISDN-Verbindung, die man
*vorher* schon funktionsfähig einrichten musste.

> Ohne diese ebenfalls automatisierte Lösungen wären viele User außen vor
> geblieben. Scheint mir analog zu den Verschüsselungsproblem zu sein.

Nein. PGP gibt es 30(!) Jahren. Das RFC zu S/MIME auch seit 22(!)
Jahren. Neu ist daran also gar nichts. Dass es nicht funktioniert, liegt
an dem generellen Problem, dass E-Mail ursrpünglich nicht mit
Verschlüsselung entwickelt wurde und diese Verfahren nachträglich
drangebastelt wurden - mit all den Problemen, die man damit hat.

[Arno Welzel]

Stefan Claas:

> On Tuesday, November 23, 2021 at 3:46:13 PM UTC+1, Arno Welzel
> wrote:
>> Stefan Claas:
>>> On Tuesday, November 23, 2021 at 11:25:19 AM UTC+1, Arno Welzel
>>> wrote:
>> [...]
>>>> Wenn es funktioniert, kann man es ja sicher leicht
>>>> demonstrieren.
>>>
>>> Sicherlich könnte man das, jedoch müssten dann vermutlich
>>> Personen in dieser Position, für eine öffentliche Demonstration,
>>> sich mit dir in Verbindung setzen und schriftlich absichern,
>>> damit das offiziell wär. Fraglich ist nur ob sie ihre Trümpfe
>>> gerne aus der Hand geben.
>> Ich würde das selbstverständlich auch jederzeit rechtsverbindlich
>> bestätigen, dass ich das Abfangen einer E-Mail von mir keine
>> juristischen Folgen hätte. Und "Trümpfe aus der Hand" geben
>> verlange ich gar nicht - es würde schon genügen, wenn jemand zeigen
>> kann, wie er sich vom Inhalt einer E-Mail, die ich von einer
>> GMail-Adresse an eine GMX-Adresse schicke (oder umgekehrt),
>> Kenntnis verschaffen kann, indem er einen darin enthalten Text 1:1
>> wiedergibt.
>
> Und was hättest Du davon? Selbst wenn die Technik gut wär, Du bist

Einen sehr gutes Beispiel dafür, warum es keine gute Idee ist,
vertrauliche Informationen unverschlüsselt per E-Mail zu versenden.

Bislang ist das nur "best practice" ohne dass es dafür konkrete
Beispiele gibt. Und dabei rede ich nicht von Hacks, bei denen Server
kompromittiert wurden sondern ich meine schon explizit Anbieter, wo
aktuell kein Hack bekannt ist und jemand dennoch demonstrieren kann,
dass es technisch möglich ist, den Mailverkehr dazwischen abzufangen.

> abhängig von Dritten (Menschen deren Verhalten Du nicht kennst) und
> im Fall, dass Dein Kommunikationspartner nicht die Fitness wie Du
> besitzt, dass er dann auch ein Einfallstor sein kann.

Ich würde beide E-Mail-Adressen selber stellen. Einen Account sowohl bei
GMail wie auch GMX zu betreiben, ist ja kein Problem.

[Arno Welzel]

Andreas Kohlbach:

> On Tue, 23 Nov 2021 11:29:59 +0100, Arno Welzel wrote:[...]

>> E-Mail war nie dafür gedacht und das nachträglich dranzufrickeln,
>> ändert daran nichts.
>
> Aber PGP und anderes funktionieren, auch wenn es dazugefrickelt
> ist. Verschlüsseltes wird über einen Klartext-Kanal verschickt. Ein
> Man-In-The-Middle sieht trotzdem nur Verschlüsseltes.

Die Metadaten sind dennoch sichtbar - also wer schickt wem etwas und
wann. Auch diese Information ist u.U. wertvoll, selbst wenn der Inhalt
der Nachricht nicht lesbar ist.

[Stefan Claas]

Genau.

> Bislang ist das nur "best practice" ohne dass es dafür konkrete
> Beispiele gibt. Und dabei rede ich nicht von Hacks, bei denen Server
> kompromittiert wurden sondern ich meine schon explizit Anbieter, wo
> aktuell kein Hack bekannt ist und jemand dennoch demonstrieren kann,
> dass es technisch möglich ist, den Mailverkehr dazwischen abzufangen.
> > abhängig von Dritten (Menschen deren Verhalten Du nicht kennst) und
> > im Fall, dass Dein Kommunikationspartner nicht die Fitness wie Du
> > besitzt, dass er dann auch ein Einfallstor sein kann.
> Ich würde beide E-Mail-Adressen selber stellen. Einen Account sowohl bei
> GMail wie auch GMX zu betreiben, ist ja kein Problem.

Nun, Du weißt doch selber das Du als Systemverwalter die volle Kontrolle
über dein System hast. Das gleiche gilt doch auch für Anbieter Systeme.
Die Frage ist doch nicht ob das geht, sondern wer und warum dort so etwas
machen könnte. Die zweite Frage wäre dann ggf. warum in den letzten
Jahren, neben den großen bekannten email Anbietern, sog. privacy email
Anbieter wie Pilze aus dem Boden geschossen sind und warum z.B. bei
solchen die in .de sind zwecks TKÜ gerichtlich 'nachgerüstet' werden musste.

Was privacy email provider betrifft, da gibt es sogar welche die regelmäßig
warrant canaries posten.

Grüße
Stefan

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Sat, 20 Nov 2021 23:36:55 +0100, Helmut Waitzmann wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net>:
>>> On Thu, 11 Nov 2021 22:49:25 +0100, Helmut Waitzmann wrote:
>>>>
>>>> Andreas Kohlbach <a...@spamfence.net>:
>

>[...]

>

>> Was ist dir bei
>>
>>
>> Subject: E-Mail-Verschluesselung und -Signierung ohne Zutun des
>> Anwenders? (was: [Lösung Subjectwechsel]) From: Helmut Waitzmann
>> <nn.th...@xoxy.net> Newsgroups:
>> de.comm.software.mozilla.mailnews, de.comp.security.misc
>> Followup-To: de.comp.security.misc Date: Mon, 25 Oct 2021
>> 21:59:41 +0200 Message-ID:
>> <83tuh4c1...@helmutwaitzmann.news.arcor.de>
>>
>> nicht verständlich?
>>

>So ziemlich alles.
>

Da böte sich ein Followup von dir auf jene Nachricht an.


>Du schreibst mitunter so viel (und vermutlich Richtiges), dass es
>zumindest mit schwer fällt, eine Essenz herauszuziehen. Meist gebe
>ich nach zwei- oder dreimaligem Lesen auf. Auch das, was Du
>Eingangs schriebst, ist diesem Problem zum Opfer gefallen (daher
>antworte ich darauf nicht und habe es entfernt).

Das ist für die Kommunikation natürlich eine Katastrophe.  Ich
versuche zwar, mich unmissverständlich auszudrücken (deshalb werden
meine Texte oft sehr lang und holpern gelegentlich auch), weiß aber
nicht, ob mir das wirklich gelingt.  Umgekehrt sehe ich im Usenet
oft Beiträge, die zwar kurz und elegant sind, aber bei genauem Lesen
jede Menge Fragezeichen stehen lassen.  Sie führen dann in der Folge
gerne zu Diskussionen, bei denen es 10 und mehr Followups braucht,
bis die anfangs gemachte Aussage zweifelsfrei ans Licht gekommen
ist, wobei als Kollateralschaden auch noch mindestens 2 Diskutanten
Beleidigungen an den Kopf geworfen werden.

>Um das noch Mal zusammenzufassen: Es ist wie die manuelle Nutzung
>von PGP durch eine Person. Nur dass die komplette Konfiguration
>(Schlüsselerstellung, Mantra fällt weg,...) dem Anbieter allein
>überlassen wird - der Benutzer muss sich (außer der einmaligen
>Bestätigung, dass er diesen Dienst nutzen möchte) *nichts* kümmern.

Du zählst in der Klammer ausdrücklich die Schlüsselerstellung und
das Mantra auf.  Das sind allerdings genau die Teile, die das
Mailer‐Programm des Anwenders in der Tat ohne Beteiligung eines
Anbieters selber ohne Zutun des Anwenders durchführen kann.  Dafür
muss man also auf Man‐in‐the‐Middle‐Robustheit nicht verzichten.

Spannend wird es bei den Teilen, die du nur durch «...» angedeutet
hast.  Solang du die «...» nicht genauer ausführst, tritt die
Diskussion auf der Stelle.

>> Des weiteren kam dabei heraus, dass der Systemadministrator jedes
>> beteiligten E‐Mail‐Providers die Möglichkeit hat, Nachrichten
>> abzufangen und unter den Tisch fallen zu lassen oder zu verändern
>> und verändert weiterzuschicken oder sich neue selber auszudenken
>> und im Namen jedes beliebigen seiner Kunden weiterzuschicken.
>

>Ignorieren wird das. Denn das kann er auch ohne Verschlüsselung.
>

Sicher kann er das ohne und mit Verschlüsselung, aber mit
Verschlüsselung fällt es Alice und Bob auf.  Genauer:  Nachrichten
unter den Tisch fallen lassen (also, zu verhindern, dass sie den
Empfänger erreichen), kann er in der Tat immer.  Das einzige, was
der Absender dagegen tun kann, ist, den Empfänger auf möglichst
vielen Wegen zu erreichen zu suchen.  Bei Harry Potter hat einfach
die Unmenge an Briefen mit demselben Inhalt, die Harry erhielt, dazu
geführt, dass sie von den Dursleys nicht mehr abgefangen werden
konnten.

In der EDV Nachrichtenkanäle so zu fluten, dass nicht mehr alle
Nachrichten abgefangen werden können, ist in der Tat schwieriger.

Alle anderen Fälle (Nachrichten zu ändern oder neue zu erfinden)
kann der Systemadministrator natürlich weiterhin tun.  Sie bleiben
aber, wenn die Originalnachricht vom Absender kryptografisch
unterschrieben wurde und der Empfänger die Unterschrift des
Absenders kennt, nicht unbemerkt, weil nach der Manipulation
entweder die Unterschrift nicht mehr zur Nachricht passt oder die
Unterschrift nicht mehr die des originalen Absenders ist.  Das
Mailerprogramm des Empfängers kann das feststellen und den Empfänger
warnen.  Der kann solche gefälschten Nachrichten dann einfach
wegwerfen, ohne ihnen Glauben zu schenken.

[Es geht um einen Angreifer:]

>> Wenn er diese Möglichkeiten nutzt, um gleich zu Anfang, wenn eine
>> automatisierte Methode eine (scheinbar) sichere Kommunikation
>> aufbaut, dazwischenzufunken, kann er zum Man in the Middle werden
>> und die Kommunikation vollständig unter seine Kontrolle bringen,
>> ohne dass die Kommunikationspartner etwas davon merken.
>

>Um dieses Argument abzufangen, hatte ich bereits mehrfach
>geschrieben, dass der Kunde dem Anbieter unbedingtes Vertrauen
>schenken muss. Sollte das von Seiten des Nutzers nicht bestehen,
>wird *meine* ganze Argumentation fruchtlos.

Der Witz ist folgender:  Der Ausgangspunkt der Diskussion forderte,
OpenPGP ohne Zutun des Anwenders nutzbar zu machen, und ging davon
aus, dass so etwas möglich wäre, wenn die nerdigen Entwickler von
Mailer‐Programmen nicht nur an sich selber dächten, sondern mehr auf
die Anwender Rücksicht nähmen und OpenPGP vernünftig einbauen
würden.

Ich habe die Diskussion losgetreten, weil ich meine, den Beweis zu
haben, dass das nicht möglich ist:  Wer OpenPGP ohne Zutun des
Anwenders nutzbar macht, setzt den Anwender dem Risiko des
Man‐in‐the‐Middle‐Angriffs aus.  Daran sind genau die Teile schuld,
die du oben mit «...» nur angedeutet hast, weil sie das Zutun des
Anwenders erfordern.

Phil Zimmermann machte mit seinem PGP‐Programm Kommunikation per
E‐Mail immun gegen Man‐in‐the‐Middle‐Angriffe.  Dazu ist allerdings
das wissende Zutun des Anwenders erforderlich.

Darum geht es mir:


Wer nach OpenPGP‐Nutzung ohne Zutun des Anwenders ruft, muss so
ehrlich sein, dazu zu sagen, dass dann eine wirklich sichere
Verwendung von OpenPGP von vorne herein ausgeschlossen ist.

Damit Anwender in die Lage versetzt werden, OpenPGP mit wissendem
Zutun (und deshalb wirklich sicher) zu verwenden, müssen sie die
Grundzüge (Eigenschaften und Zweck der Public‐Key‐Kryptografie)
verstanden haben.  Das habe ich versucht, mit den Punkten (1) bis
(5) zu vermitteln.

>
>[...]

>
>>> Man muss dazu diesem Anbieter
>>>
>>
>> nicht nur diesem Anbieter sondern auch den Anbietern der
>> Kommunikationspartner
>

>Mein Fehler. Ich hätte in der Plural schreiben müssen.
>

Aber lass dir auch die Folgen des Plurals auf der Zunge zergehen: 
Wer beispielsweise an eine E‐Mail‐Adresse bei Yahoo schrieb, durfte
davon ausgehen, dass seine Nachricht nicht vertraulich blieb, wenn
sie nicht Ende‐zu‐Ende vom Absender bis zum Empfänger gesichert
war.  Da nützte es dem Absender nichts, dass er seinem eigenen
Provider vertraute, wenn er Yahoo nicht vertraut.

>*Wenn* ich (und der Gegenüber) beiden Anbietern vertraue, gibt es
>keinen Man-in-the-Middle. Mir ist klar, dass sie könnten. Aber wenn
>der Nutzer das für möglich hält, hat er kein Vertrauen, und die
>Sache ist hinfällig.

Ja, OpenPGP ohne Zutun des Anwenders ist dann hinfällig.  Anders
sieht es mit wissendem Zutun des Anwenders aus: 
Man‐in‐the‐Middle‐Angriffe werden dann vereitelt.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Mon, 22 Nov 2021 22:57:45 +0100, Helmut Waitzmann wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net>:
>>> On Sat, 20 Nov 2021 23:52:22 +0100, Helmut Waitzmann wrote:
>>>>
>>>> Andreas Kohlbach <a...@spamfence.net>:
>>>>>

>>>>> Ja. Erscheint mir aber so unwahrscheinlich, dass ich den
>>>>> trotzdem "vertraue". Außer Du wärst eine "High-Profile"
>>>>> Person. Dann würde ich den Schlüssel lieber persönlich
>>>>> erhalten.
>>>>
>>>> Ich fürchte, ich muss doch noch irgendwo einen Schlüssel mit
>>>> einem User‐Id für Andreas Kohlbach hochladen, auch wenn du
>>>> nicht «high‐profile» sein solltest.
>>>
>>> Wo ist das ein Problem? Mein Name ist zwar nicht häufig
>>> anzutreffen, trotzdem gibt es noch andere mit diesem Namen.
>>
>> Wenn jemand ebenfalls einen Schlüssel mit einem User‐Id, das den
>> Namen Andreas Kohlbach und deine E‐Mail‐Adresse enthält,
>> veröffentlicht, hat jeder, der sich deinen Schlüssel vom
>> Schlüssel‐Server holen will, Auswahl.  Solange er von dir nicht
>> den Fingerprint unverfälscht erhalten hat, weiß er nicht, welchen
>> der Schlüssel er als den deinen ansehen soll.
>

>Ggf. ging ich von falschen Tatsachen aus. War der Annahme, dass
>jede Email-Adresse nur ein Mal existieren kann. Niemand also einen
>Schlüssel mit der hier im Artikel verwendeten Email-Adresse
>hochladen kann, da sie schon existiert.

Solche Beschränkungen erzwingen traditionelle Schlüssel‐Server
nicht.  Einer der Gründe dafür ist, dass sie dann ein vernetztes
Datenbanksystem bilden müssten, denn jeder Hochladeversuch an einem
von ihnen würde dann erfordern, dass der Schlüssel‐Server, auf den
etwas hochgeladen werden soll, bei allen anderen Schlüssel‐Servern
nachfragen müsste, ob sie vielleicht bereits einen Schlüssel mit
derselben E‐Mail‐Adresse haben.  Und erst dann, wenn er von allen
Schlüssel‐Servern ein Nein erhalten hat, würde er den Schlüssel
akzeptieren.

Und selbst, wenn alle Schlüssel‐Server so eine Beschränkung
durchführen würden, wäre das nicht sinnvoll:  Überlege dir, was
geschieht, wenn du deinen Schlüssel hochladen willst, der
Schlüssel‐Server aber bereits einen Schlüssel mit deiner
E‐Mail‐Adresse hat, weil ich dir zuvorgekommen bin und bereits einen
meiner Schlüssel mit deiner E‐Mail‐Adresse hochgeladen habe.

>
>>> Ich könnte sagen, "Ich muss mal einen Schlüssel mit der User-Id
>>> "Thomas Meyer" hochladen.
>>>
>>> Gerade mal einen Keyserver abgesucht:
>>>
>>>
>>>| Keys 1-14 of 100 for "Thomas Meyer"
>>>
>>> Wie will ich da einem bestimmten Thomas Meyer durch einen Upload
>>> Schaden zufügen können? Dazu müsste ich einen Schlüssel *mit*
>>> seiner Email-Adresse erstellen (kann ich) und hochladen (kann
>>> ich nicht).
>>
>> Ich habe schon länger nicht mehr versucht, auf einen
>> Schlüssel‐Server einen Schlüssel hochzuladen; aber, als ich das
>> das letzte Mal getan habe, konnte ich einen Schlüssel mit einem
>> beliebigen User‐Id hochladen:  Ich musste mich dazu nicht am
>> Schlüssel‐Server einloggen und auch nicht beweisen, dass die im
>> User‐Id enthaltene E‐Mail‐Adresse mir gehört (so ein Beweis ist
>> im Allgemeinen auch nicht möglich).
>>
>> => Ich hätte ohne weiteres als User‐Id deine E‐Mail‐Adresse
>> wählen können.
>

>Was genau ist in diesem Zusammenhang eine User-ID?
>

Beispielsweise die folgende Zeile, die du in der Nachricht mit
Message‐Id <87v913w...@usenet.ankman.de> gezeigt hattest:

| uid [ unknown] Helmut Waitzmann (Anti-Spam-Ticket.b.qc3c) <oe.th...@xoxy.net>

Meine Vermutung ist, dass du da einen Auszug der Ausgabe des
Kommandos

gpg --list-keys -- \
'Helmut Waitzmann (Anti-Spam-Ticket.b.qc3c) <oe.th...@xoxy.net>'

gezeigt hast.  Er zeigt das User‐Id «Helmut Waitzmann
(Anti-Spam-Ticket.b.qc3c) <oe.th...@xoxy.net>».  (Deswegen steht
am Anfang der Zeile auch die Abkürzung «uid».)

Oder wolltest du eher auf eine technische Antwort hinaus?  Das
User‐Id ist ein Datensatz, den der Schlüsselinhaber an seinen
öffentlichen Schlüssel anheftet.  Das Anheften geschieht dadurch,
dass er ihn mit seinem geheimen Schlüssel signiert.  Der Datensatz
ist dafür gedacht, dass andere, die seinen öffentlichen Schlüssel
nutzen wollen (etwa, um eine Unterschrift zu prüfen), sich nicht den
Fingerprint dieses Schlüssels merken müssen, sondern etwas leichter
zu Merkendes haben.

Gleichzeitig stellt das User‐Id auch eine Behauptung auf, die der
Schlüsselinhaber macht.  In dem von dir gezeigten User‐Id sieht die
etwa so aus:

«Ich, der Besitzer des zu diesem öffentlichen Schlüssel gehörenden
geheimen Schlüssels, behaupte folgendes: Ich heiße ‹Helmut
Waitzmann›.  Der Kommentar ‹(Anti-Spam-Ticket.b.qc3c)› ist wahr. 
Ich habe Zugriff auf das Postfach ‹oe.th...@xoxy.net›.»

Prinzipiell braucht ein Schlüssel ja keine User‐Ids:  Die
Kryptografie funktioniert auch ohne sie.  User‐Ids sind aber eine
bequeme Möglichkeit, einem Schlüssel einen Namen, der besser lesbar
als ein Fingerprint ist, zu geben.

Wenn der Name eine E‐Mail‐Adresse enthält, ordnen Mailer‐Programme
den Schlüssel gerne der entsprechenden E‐Mail‐Adresse zu.

Beispielsweise könnte dein Mailer‐Programm dir vorschlagen,
Nachrichten an <oe.th...@xoxy.net> mit dem damit benannten
Schlüssel zu verschlüsseln.

>> [De‐Mail macht keine Ende‐zu‐Ende‐Verschlüsselung.]
>>
>

>Das macht nichts, solange der Content selbst verschlüsselt ist.
>

Du meinst, unabhängig von De‐Mail verschlüsselt?  Dann macht es in
der Tat nichts.  Dann ist aber De‐Mail ziemlich überflüssig.

>[...]

>
>> => De‐Mail ist, was die Sicherung der Unverfälschtheit und
>> Vertraulichkeit von Nachrichten zwischen Alice und Bob angeht,
>> weder hinreichend noch notwendig, kurz: vollkommen überflüssig.
>

>Ich hatte die Vertraulichkeit nun schon mehrfach als *nicht*
>gegeben genannt.

Ich glaube, da missverstehen wir uns:  Der Begriff «Vertraulichkeit»
ist zwar mit dem Begriff «Vertrauen» verwandt, meint aber nur: nicht
für Unbefugte.  Wenn Alice Bob eine vertrauliche Nachricht schickt,
heißt das nur, dass er es so anstellt, dass nur Alice die Nachricht
lesen kann.  Die technische Lösung dafür, um die es hier geht, ist
die Verschlüsselung, kurz:  Damit die Nachricht vertraulich bleibt,
verschlüsselt Alice die Nachricht mit Bob's öffentlichem Schlüssel.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>Sehe ich auch so. Selbst eine von mir erwähnte automatische Methode
>wird kaum mehr Leute zum Verschlüsseln bewegen (abgesehen davon,
>dass man selbst keine Kontrolle hat, sondern den Anbietern voll
>vertrauen muss).

Und nicht einmal das volle Vertrauen genügt:  Angenommen, du hättest
so einen Anbieter (und würdest ihm voll vertrauen), so könnte auch
dein Anbieter nicht herausbekommen, welcher Schlüssel der richtige
für <oe.th...@xoxy.net> ist, ehe er nicht von mir den Fingerprint
meines Schlüssels unverfälscht genannt bekommt oder er sich des
Web's of Trust bedienen kann.

>Aber PGP und anderes funktionieren, auch wenn es dazugefrickelt
>ist. Verschlüsseltes wird über einen Klartext-Kanal verschickt. Ein
>Man-In-The-Middle sieht trotzdem nur Verschlüsseltes.

Dann ist er kein Man‐in‐the‐Middle sondern nur ein Lauscher.

[Enrik Berkhan]

Andreas Kohlbach <a...@spamfence.net> wrote:

> On Wed, 24 Nov 2021 23:53:26 +0100, Helmut Waitzmann wrote:
>> Dann ist er kein Man‐in‐the‐Middle sondern nur ein Lauscher.
>

> Worin liegt der Unterschied?

Ein Lauscher ist z.B. bereits der Briefträger, der deine Postkarten
liest und auch sehen kann, von wem du Briefe bekommst.

Ein Man-in-the-Middle legt ein Postfach auf deinen Namen an, in das
deine Postkarten und Briefe umgeleitet werden. Nachdem er die Briefe in
aller Ruhe dort abgeholt, geöffnet, gelesen, ggf. manipuliert und neu
kuvertiert hat, wirft er sie dann bei dir zu Hause ein, als hätte das
der Briefträger getan.

[Stefan Kanthak]

"Andreas Kohlbach" <a...@spamfence.net> schrieb:

> On Mon, 22 Nov 2021 22:57:45 +0100, Helmut Waitzmann wrote:

>> Wenn jemand ebenfalls einen Schlüssel mit einem User-Id, das den Namen
>> Andreas Kohlbach und deine E-Mail-Adresse enthält, veröffentlicht, hat
>> jeder, der sich deinen Schlüssel vom Schlüssel-Server holen will,

>> Auswahl. Solange er von dir nicht den Fingerprint unverfälscht
>> erhalten hat, weiß er nicht, welchen der Schlüssel er als den deinen
>> ansehen soll.
>

> Ggf. ging ich von falschen Tatsachen aus.

Amen!

> War der Annahme, dass jede Email-Adresse nur ein Mal existieren kann.

Welche ZENTRALE Instanz sollte das pruefen und garantieren?

> Niemand also einen Schlüssel mit der hier im Artikel verwendeten Email-
> Adresse hochladen kann, da sie schon existiert.

Genau das ist in einem dezentralisierten "web of trust" NICHT gegeben!

[...]

> Wem es aber um das reine Verschlüsseln geht - auch wenn er nicht sicher
> sein kann, ob der Anbieter vielleicht MITM spielt - kann so zumindest den
> Inhalt einer Mail auf dem sonst ungesicherten Transportweg verschlüsseln.

Du bist ahnungslos und verbreitest Kwatsch: gesicherte Transportwege sind
seit VIELEN Jahren gaengige Praxis!
Die ueblichen von Nutzern verwendeten Clients kommunizieren SSL/TLS-gesichert
mit ihren POP3/IMAP4/SMTP-Servern -- wobei die Transportsicherung primaer die
zur Benutzeridentifikation notwendigerweise uebertragenen Daten schuetzt.
Und seit Edward Snowden wird auch die (ueblicherweise DIREKTE) Uebertragung
zwischen den "smart hosts" alias "mail submission"-Servern des Sender-Anbieters
sowie den meisten MXen der Empfaenger-Anbieter SSL/TLS-gesichert -- allerdings
ohne gegenseitige Authentifikation der beteiligten Hosts ueber ihre X.509-
Zertifikate.
Somit koennten nur die Betreiber der SMTP/IMAP4/POP3-Server MiTM spielen bzw.
Mitlesen.

Stefan
--
<https://www.duden.de/rechtschreibung/Kanthaken>

[Helmut Waitzmann]

Helmut Waitzmann <nn.th...@xoxy.net>:
>Andreas Kohlbach <a...@spamfence.net>:

>> Ich hatte die Vertraulichkeit nun schon mehrfach als *nicht*
>> gegeben genannt.
>
>Ich glaube, da missverstehen wir uns:  Der Begriff «Vertraulichkeit»
>ist zwar mit dem Begriff «Vertrauen» verwandt, meint aber nur: nicht
>für Unbefugte.  Wenn Alice Bob eine vertrauliche Nachricht schickt,
>heißt das nur, dass er es so anstellt, dass nur Alice die Nachricht
>lesen kann.

Der letzte Satz ist natürlich Unsinn.  Richtig muss es so heißen:

Wenn Alice Bob eine vertrauliche Nachricht schickt, heißt das nur,

dass sie es so anstellt, dass nur Bob die Nachricht lesen kann.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>Danke.

Schau noch mal im Beispiel aus der Nachricht (mit Message‐Id
<83tuh4c1...@helmutwaitzmann.news.arcor.de>), mit der ich die
Diskussion begonnen habe, nach, was Mallory dort tut:  Sie schwatzt
Alice und Bob je eine neue E‐Mail‐Adresse angeblich von Bob
bzw. Alice, in Wahrheit aber von ihr selbst, auf.  So bewirkt sie,
dass entsprechend zu Enriks Vergleich alle Post von Alice an Bob und
von Bob an Alice zu ihr umgeleitet wird.

[Arno Welzel]

Andreas Kohlbach:

> On Wed, 24 Nov 2021 09:27:38 +0100, Arno Welzel wrote:
[...]

>> Das hast Du definitiv falsch in Erinnerung. Auch die AOL-Software
>> benötigte wenigstens ein Modem oder eine ISDN-Verbindung, die man
>> *vorher* schon funktionsfähig einrichten musste.
>

> Das wage ich zu bezweifeln; die Software sollte auch das - wie oben
> erwähnt - für den User einrichten. Denn die Massen der Leute, die ins
> Internet wollten, sind Dummuser. Ohne vollständig automatischer
[...]

Ja - und diversen dieser "Dummuser" habe ich damals auch dabei geholfen,
T-Online oder AOL einzurichten, eben *weil* sich Modem oder ISDN-Adapter
nicht ohne manuelle Eingriffe funktionsfähig waren, trotz der
"vollautomatischen" Einrichtung, die halt auch nur mit der Hardware
funktioniert hat, mit der die Anbieter sie getestet haben.

[...]
> Habe ein Video einer AOL-Software Installation für Windows 98 auf
> Französisch (auf die Schnelle nichts anderes gefunden) auf
> <https://www.youtube.com/watch?v=s7vURFhNhuw> geschaut. Ich nehme an,
> dass nichts vorher eingerichtet wird. Die Installation schreibt (man muss

Das msn-Logo auf dem Desktop sowie das Icon für die Netzwerkumgebung
("Voisinage résau" - "Netzwerkumgebung") deuten darauf hin, dass sehr
wohl vorher schon etwas installiert wurde.

> genau hinsehen) auch nach C:\system, wird also Windows modifizieren. Am
> Ende sehe ich noch, dass die AOL Software auch TCP/IP in Windows
> konfiguriert.

Ja. Ändert dennoch nichts daran, dass mindestens ein Modem oder
ISDN-Adapter funktionsfähig vorhanen sein müssen.

[Arno Welzel]

Arno Welzel:

Ergänzung: ein Modem wurde da auch gar nicht benutzt.

Ab 3:45 (<https://youtu.be/s7vURFhNhuw?t=225>) sieht man, wie TCP/IP
*statt* eines Modems verwendet wird. Das Gerät hatte also schon eine
funktionsfähige Netzwerkverbindung *inklusive* Internetzugang über einen
Router. AOL wurde hier nur als zusätzlicher Dienst eingerichtet, auf den
dann über den vorhandeenn Internetzugang zugegriffen wurde - ja, das gab
es eine Weile auch noch - auch bei CompuServer - bis AOL dann irgendwann
die eigenen Dienste eingestellt hat.

[Arno Welzel]

Stefan Claas:

> On Wednesday, November 24, 2021 at 9:31:35 AM UTC+1, Arno Welzel wrote:

[...]

>> Ich würde beide E-Mail-Adressen selber stellen. Einen Account sowohl bei
>> GMail wie auch GMX zu betreiben, ist ja kein Problem.
>
> Nun, Du weißt doch selber das Du als Systemverwalter die volle Kontrolle
> über dein System hast. Das gleiche gilt doch auch für Anbieter Systeme.
> Die Frage ist doch nicht ob das geht, sondern wer und warum dort so etwas
> machen könnte. Die zweite Frage wäre dann ggf. warum in den letzten
> Jahren, neben den großen bekannten email Anbietern, sog. privacy email
> Anbieter wie Pilze aus dem Boden geschossen sind und warum z.B. bei
> solchen die in .de sind zwecks TKÜ gerichtlich 'nachgerüstet' werden musste.
>
> Was privacy email provider betrifft, da gibt es sogar welche die regelmäßig
> warrant canaries posten.

Sag' doch gleich, worum es geht - nicht Abhören von E-Mail durch
irgendwen, sondern staatliche Überwachung. Und wieso soll es dann so
viel besser sein, wenn die staatlichen Überwacher nur Metadaten haben
und sehen, wer mit wem wann kommunuziert hat?

[Stefan Claas]

Ich mache es kurz und lasse es dann.

Bei einem privacy email provider sind deine emails verschlüsselt mit
deinem Schlüssel der bei Kontoerstellung erstellt wurde und durch
deine Passphrase geschützt ist. So kann dann kein neugieriger oder
gelangweilter, bestochener oder als Maulwurf arbeitender Mitarbeiter
deine Post lesen oder eben die lieben Überwacher.

Grüße
Stefan

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>Die Schlüsselerstellung und die des Mantras sollten bei
>automatisierten Methoden transparent sein, um den Benutzer diese
>Hürde nicht aufzubeugen.

Wenn der Anwender ein Mailer‐Programm nutzt, das die Schlüssel
selber erstellt (oder es GnuPG durch einen Programmaufruf machen
lässt) und sich dabei ein Mantra ausdenkt, merkt und eintippt, muss
der Anwender dabei nichts tun.  Er kann dann die geforderte
Transparenz genießen.

Meines Wissens hat sich im Mozilla‐Mailnews‐Newgroup mal jemand
darüber beschwert, dass der Thunderbird sich das Mantra merkt und es
nicht ihn, den Anwender, eintippen lässt.  Da wollte also jemand
weniger transparentes Verhalten vom Thunderbird haben, als es der
automatisierten Methode entspricht.  Demnach ist anscheinend der
Thunderbird von Haus aus genau so transparent, wie bei
automatisierten Methoden gewünscht.

>Verstehe ich nicht: Wenn Kunde A (über einen Anbieter, der
>automatisiert Mails verschlüsselt) eine Mail an Kunden B (über
>einen Anbieter, der automatisiert Mails verschlüsselt) sendet, wie
>sollen Alice oder Bob diese verändern können?

(Nebenbei:  Die Rollennamen sind traditionell Alice als Absender,
Bob als Empfänger und Mallory als Man‐in‐the‐Middle
(<https://de.wikipedia.org/wiki/Alice_und_Bob#Rollenverteilung>,
<https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characters>),
aber meinetwegen kann ich jetzt hier auch bei A, B, Alice und Bob
bleiben.)

Alice bewirbt sich erfolgreich als Systemadministrator
(m/w/d) bei As Anbieter, oder Bob bewirbt sich erfolgreich als
Systemadministrator (m/w/d) bei Bs Anbieter.

Wenn A eine Nachricht, die an B adressiert ist, bei seinem Anbieter
einliefert, greift sich Alice als Systemadministratorin die
Nachricht, bevor sie verschlüsselt wird.  Sie kann die Nachricht
lesen und nach Belieben verändern.  Dann kann sie sie verschlüsseln
und an den Anbieter von B weiterschicken.

Wenn B eine Nachricht, die an A adressiert ist, bei seinem Anbieter
einliefert, verschlüsselt der Anbieter die Nachricht und schickt sie
an As Anbieter.  Dort wird sie entschlüsselt.  Jetzt greift sich
Alice die Nachricht, liest und verändert sie nach Belieben.  Dann
legt sie sie in As Postfach.

Weder A noch B merken etwas von diesen Man‐in‐the‐Middle‐Angriffen.


Dasselbe kann entsprechend auch Bob bei Bs Anbieter tun.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Wed, 24 Nov 2021 23:53:26 +0100, Helmut Waitzmann wrote:
>>

>> Und nicht einmal das volle Vertrauen genügt:  Angenommen, du
>> hättest so einen Anbieter (und würdest ihm voll vertrauen), so
>> könnte auch dein Anbieter nicht herausbekommen, welcher Schlüssel
>> der richtige für <oe.th...@xoxy.net> ist, ehe er nicht von mir
>> den Fingerprint meines Schlüssels unverfälscht genannt bekommt
>> oder er sich des Web's of Trust bedienen kann.
>

>Dann müsste der Benutzer gefragt werden.
>

Kannst du das bitte nochmal genauer formulieren?  Wer müsste in
deinem Beispiel wen was fragen?  Hier ist ein Formular zum
Ausfüllen:

___ müsste ___ fragen: „___?“


Ich bin hier etwas pingelig, weil die Frage an den Punkt rührt, an
dem sich meiner Meinung nach zeigt, dass automatische
Schlüsselverwaltung ohne Zutun des Anwenders genau dort an Grenzen
stößt, wo es darum geht, den öffentlichen Schlüssel des
Kommunikationspartners unverfälscht zu erhalten.

[Stefan Kanthak]

"Stefan Claas" <spam.tra...@gmail.com> schrieb:

> Ich mache es kurz und lasse es dann.

Besser so!

> Bei einem privacy email provider sind deine emails verschlüsselt mit
> deinem Schlüssel der bei Kontoerstellung erstellt wurde und durch
> deine Passphrase geschützt ist.

(D)ein Konto (samt Schluessel und Mantra) erstellt der Betreiber
(auch wenn Du das anscheinend selbst per Web-Browser machst) und hat
somit Kenntnis von beiden (bzw. kann diese ueber den Browser erlangen)
... womit Dein Sch(l)uss nach hinten losgeht!

> So kann dann kein neugieriger oder gelangweilter, bestochener oder
> als Maulwurf arbeitender Mitarbeiter deine Post lesen oder eben die
> lieben Überwacher.

Wie stellst Du fest, ob der Betreiber Deine Nachrichten verschluesselt
speichert oder sie nur beim Zugriff verschluesselt zurueckgibt?

Stefan
--
<https://www.duden.de/rechtschreibung/Kanthaken>

[Eike Rathke]

* Helmut Waitzmann, 2021-11-22 21:57 UTC:

> einen Schlüssel mit einem
> beliebigen User‐Id hochladen:  Ich musste mich dazu nicht am
> Schlüssel‐Server einloggen und auch nicht beweisen, dass die im
> User‐Id enthaltene E‐Mail‐Adresse mir gehört (so ein Beweis ist im
> Allgemeinen auch nicht möglich).

https://keys.openpgp.org/ und https://keys.mailvelope.com/ existieren.

Eike

--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/

[Stefan Claas]

Kurz gesagt. Ich selbst setze nicht auf Verschlüsselung Dritter, auch wenn
das Verfahren erklärt wird und die verwendete Implementation Open Source
ist an denen viele arbeiten, da ich ja nicht feststellen kann, ob im Nachhinein
nachgebessert werden muss. Erwähnenswert ist ggf. bei solchen Providern
das selbige schon kräftige DDOS erhalten haben und Lösegeld zahlten damit
das aufhörte und befreundete Leute aus einem anderen Land das DDOS
Problem erfolgreich lösten. Das sagt mir irgendwie das da einige solcher
Anbieter anderen ein Dorn im Auge ist, da sie weder in der EU noch in den
Vereinigten Staaten betrieben werden.

Grüße
Stefan

[Helmut Waitzmann]

Eike Rathke <erack+nu...@posteo.de>:

>* Helmut Waitzmann, 2021-11-22 21:57 UTC:
>> einen Schlüssel mit einem beliebigen User‐Id hochladen:  Ich
>> musste mich dazu nicht am Schlüssel‐Server einloggen und auch
>> nicht beweisen, dass die im User‐Id enthaltene E‐Mail‐Adresse mir
>> gehört (so ein Beweis ist im Allgemeinen auch nicht möglich).
>
>https://keys.openpgp.org/ und https://keys.mailvelope.com/ existieren.
>

Wie stehen die beiden Schlüssel‐Server zu der von mir gemachten
Aussage, dass ich mich weder einloggen noch beweisen musste, dass
die im User‐Id enthaltene E‐Mail‐Adresse mir gehört?

[Stefan Claas]

Bei Hagrid wird dein Schlüssel abfragbar anhand deiner email Adresse
wenn Hagrid dir nach hochladen deines Schlüssels eine email sendet
die Du bestätigen musst. Jedoch unterstützt Hagrid keine Signaturen
an deinem Schlüssel von Freunden.

Bei Mailvelope läuft das genauso, jedoch mit dem Unterschied das du
eine verschlüsselte email, zwecks Bestätigung, bekommst und Signaturen
deiner Freunde sind dort möglich, wenn du die Updates dann immer hochladest,
also nicht durch unerwünschte Dritte (spam sigs).

Grüße
Stefan

[Helmut Waitzmann]

Stefan Claas <spam.tra...@gmail.com>:

Siehe

Subject: Re: E-Mail-Verschluesselung und -Signierung ohne Zutun
des Anwenders?
From: Friedhelm Waitzmann <usenetf2...@spamgourmet.com>
Newsgroups: de.comp.security.misc
Date: Mon, 22 Nov 2021 13:52:54 -0000 (UTC)
Message-ID: <sng7bl$ug9$1...@gioia.aioe.org>

Die beiden Schlüssel‐Server verschicken also eine E‐Mail‐Nachricht
an die im User‐Id angegebene E‐Mail‐Adresse.  Die E‐Mail‐Nachricht
ist vermutlich für den geheimen Schlüssel verschlüsselt, dessen
öffentliches Gegenstück hochgeladen worden ist.

=> Die Nachricht kann nur vom Schlüsseleigentümer entschlüsselt
werden.  (Das ist generell gut so, genügt hier aber nicht:)

Und jetzt stelle man sich vor, Mallory erstellt sich einen Schlüssel
mit dem User‐Id

Bob <b...@mailprovider.example>

und lädt ihn auf den Schlüssel‐Server hoch.  Sie macht also den
Betrugsversuch, einen Schlüssel hochzuladen, der scheinbar Bob
gehört, in Wirklichkeit jedoch ihr selbst.

Was geschieht jetzt?


Der Schlüsselserver schickt Bob eine für Mallory's Schlüssel
verschlüsselte Nachricht, die Mallory natürlich entschlüsseln
könnte, wenn sie sie in die Finger bekommen sollte.

Wie war das gleich nochmal?  Das Medium E‐Mail ist abhörsicher. –
Nein! – Nicht? – Natürlich nicht:  Deshalb macht man doch den ganzen
Zirkus mit verschlüsselten Nachrichten.  Wäre das Medium E‐Mail
abhörsicher, bräuchte man keine Verfahren zur Verschlüsselung von
E‐Mail‐Nachrichten.

Weil das Medium E‐Mail also nicht abhörsicher ist, kann Mallory
(etwa, wenn sie Systemadministratorin bei Bob's E‐Mail‐Anbieter
ist), die zwar an Bob adressierte, aber für sie verschlüsselte
Nachricht belauschen, entschlüsseln und davon absehen, sie in Bob's
Postfach zu stellen.  Sie schickt aber die entsprechende
Antwortnachricht an den Schlüssel‐Server.

Auf diese Weise bestätigt sie, Eigentümerin der E‐Mail‐Adresse
<b...@mailprovider.example> zu sein, und keys.openpgp.org und
keys.mailvelope.com sind zufrieden.

Wenn jetzt Alice Bob eine verschlüsselte Nachricht zukommen lassen
will, aber Bob's Schlüssel nicht kennt, schaut sie auf
keys.openpgp.org und keys.mailvelope.com nach und findet Mallory's
Schlüssel, dessen User‐Id aussieht, als wäre er Bob's Schlüssel.

Weil sie weder das Web of Trust nutzt noch von Bob einen Fingerprint
erhalten hat, verlässt sie sich auf die Sicherheit der
E‐Mail‐Adress‐Prüfung der Schlüssel‐Server keys.openpgp.org und
keys.mailvelope.com und verschlüsselt ihre Nachricht an Bob fröhlich
für Mallory.

Mallory kann (als Systemadministratorin von mailprovider.example)
die Nachricht an Bob entschlüsseln.  Wenn sie (aus anderen Quellen)
Bob' öffentlichen Schlüssel kennt, kann sie die entschlüsselte
Nachricht für Bob verschlüsseln und in sein Postfach legen.

=> Alice und Bob merken nichts von dem Betrug.  Mallory ist damit
schon halb Man in the Middle (die Gegenrichtung fehlt ihr noch) und
kann alle Nachrichten an Bob, die sich auf die Schlüssel‐Server
verlassen, mitlesen.

[Stefan Claas]

On Saturday, November 27, 2021 at 9:57:44 PM UTC+1, Helmut Waitzmann wrote:
> Stefan Claas <spam.tra...@gmail.com>:
> >On Saturday, November 27, 2021 at 7:30:12 PM UTC+1, Helmut Waitzmann wrote:

Sorry das ich mal Schnipp gemacht habe.

Man kann ja mal überlegen welche Sachen man dagegen machen kann.
(Ich benutze schon lange kein OpenPGP mehr)

Würde (ich habe nicht den aktuellen Überblick) Governikus seinen
öffentlichen Schlüssel bei Mailvelope hochladen und du dein
Schlüssel mit nPA, Kartenleser (BSI zertifiziert) und AusweisApp2
zertifizieren und dann bei Mailvelope hochladen, dann müssten
doch deine (persönlichen) Kommunikationspartner sehen können
wenn dein pubkey eine Governikus Signatur hat das wohl dein
Schlüssel ist, oder? Falls nicht könntest du auch, falls du eine
eigene Webseite und Domain hast dir WKD einrichten und da
dein zertifizierter Schlüssel reinpacken und bei deiner Kontakt
Form oder im Impressum usw. darauf hinweisen.

Wo ich damals mit PGP anfing da habe ich ganz einfach per
Telefon mit meinen Freunden den Fingerprint verglichen und
Schlüssel getauscht, die waren mir aber persönlich bekannt.

Public Key Cryptography heißt ja nicht, dass man mit Hinz
und Kunz weltweit verschlüsselt kommunizieren muss,
den Herr Zimmermann hatte das damals wegen einem
gewissen Demokrat Senator Biden entwickelt damit
*in* Amerika kleine Graswurzel Organisationen, wo sich
wohl die Mitglieder kennen, kommunizieren können.

Wenn man jetzt kein Geld für ein Kartenleser hat könnte
man auch überlegen ob man sein Schlüssel, per Zeit-
stempeldienst, in der Bitcoin Blockchain bescheinigen
lässt und die nicht fälschbare Bescheinigung deines
Schlüssels auf deine Webseite als QR-Code zeigst.

Sollte dafür ein Interesse bestehen kann ich gerne
zeigen wie man das machen kann und man Ideen
(pro/contra) darüber hier austauscht.

Man könnte auch einen Fingerprint kryptografisch
an eine Handynummer binden und anstatt email
versenden das mit MMS und ein dumb phone,
anstatt smartphone machen. Auch das kann
ich erklären falls dafür Interesse besteht.

Grüße
Stefan

[Stefan Claas]

Was email und web server betrifft geht natürlich auch die Schlüsseldaten
in ein .pdf schreiben und dann mit einer eIDAS Signatur versehen. Hat den
Vorteil das das in der EU gesetzlich anerkannt ist und man global das .pdf
überprüfen kann.

Grüße
Stefan

[Arno Welzel]

Andreas Kohlbach:

> On Fri, 26 Nov 2021 14:20:47 +0100, Arno Welzel wrote:
>>
>> Andreas Kohlbach:

[...]
>>> Habe ein Video einer AOL-Software Installation für Windows 98 auf
>>> Französisch (auf die Schnelle nichts anderes gefunden) auf
>>> <https://www.youtube.com/watch?v=s7vURFhNhuw> geschaut. Ich nehme an,
>>> dass nichts vorher eingerichtet wird. Die Installation schreibt (man muss

[...]
> Jede Software *muss* eigenständig Konfigurationen vornehmen, weil
> Dummuser damit überfordert sind/waren.

Ja, es wäre der Idealfall, dass das auch immer klappt. In der Praxis war
das aber nicht immer so.

Zum verlinkten Video: da wird AOL eben *nicht* automatisch eingerichtet.
Statt dessen wird versucht, AOL über TCP/IP zu benutzen - also so, dass
ein *vorhandenes* Netz verwendet werden soll, um auf die AOL-Server
zuzugreifen.

Bei 3:17 wird die automatisch Konfiguration explizit *nicht* gewählt,
sondern abgebrochen.

Bei 3:35 wird dann die Option (sinngemäß übersetzt) "TCP/IP für die
Verbindung verwenden", was dann aber nicht klappt. Bei 3:56 sieht man
dann auch die Fehlermeldung dazu.

Der Rest soll dann wohl zeigen, wie das Schreiben einer Nachricht in AOL
prinzipiell ausgesehen hätte, wenn es denn funktionsfähig eingerichtet wäre.

[Arno Welzel]

Stefan Claas:

> On Friday, November 26, 2021 at 2:42:50 PM UTC+1, Arno Welzel wrote:

[...]

>> Sag' doch gleich, worum es geht - nicht Abhören von E-Mail durch
>> irgendwen, sondern staatliche Überwachung. Und wieso soll es dann so
>> viel besser sein, wenn die staatlichen Überwacher nur Metadaten haben
>> und sehen, wer mit wem wann kommunuziert hat?
>
> Ich mache es kurz und lasse es dann.
>
> Bei einem privacy email provider sind deine emails verschlüsselt mit
> deinem Schlüssel der bei Kontoerstellung erstellt wurde und durch
> deine Passphrase geschützt ist. So kann dann kein neugieriger oder
> gelangweilter, bestochener oder als Maulwurf arbeitender Mitarbeiter
> deine Post lesen oder eben die lieben Überwacher.

Sofern der Mailserver nicht kompromittiert wurde und die Daten beim
Entschlüsseln für den Client nicht kopiert. Denn der E-Mail-Client muss
die Daten unverschlüssel bekommen. Ein Standard, dass der Server via
IMAP oder POP3 nur verschlüsselte Mailinhalte sendet, die erst vom
Client entschlüsselt werden, gibt es nicht - und damit meine ich
explizit nicht PGP oder S/MIME sondern Verschlüsselung des Postfachs,
wie es etwa in Dovecot möglich ist. Auch da muss man letztlich darauf
vertrauen, dass der Provider keine gepatchte Dovecot-Version nutzt, die
alle Daten beim Senden an den Client für einen staatlichen Überwacher
nebenher kopiert.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>In meinem Fall fragt mich z.B. der Mailer mutt, welche der
>Signaturen eines Absenders (die er vermutlich aus den Adressen
>zieht) er nehmen soll.
>
>Wenn ich von einem vielleicht
>
>vorname....@gmx.net
>
>und
>
>vorname....@freenet.de
>
>haben, fragt mutt, welche der vorname.nachname genommen werden soll.
>

Also langsam zweifle ich an deinen Fähigkeiten, ein angesprochenes
Thema zu verfolgen:  Ich fragte, wie dein E‐Mail‐Anbieter
herausbekommen will, ob der mit dem User‐Id <oe.th...@xoxy.net>
bezeichnete Schlüssel meiner ist.  Du antwortetest, da müsste der
Benutzer gefragt werden.  Auf meine Rückfrage, wer da wen fragen
müsste, und, wie die Rückfrage aussähe, kommst du mit deinem
Mailer‐Programm mutt und ganz anderen E‐Mail‐Adressen oder User‐Ids
an.  Dabei war die Voraussetzung doch, dass du bzw. dein
Mailerprogramm nichts von Schlüsselverwaltung wissen wollen sondern
das ganz ohne Zutun des Anwenders dem E‐Mail‐Anbieter überlassen
wollen, und, dass es um die E‐Mail‐Adresse <oe.th...@xoxy.net>,
zu der es keinen E‐Mail‐Anbieter gibt, der den passenden Schlüssel
kennt, ging.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Fri, 26 Nov 2021 20:39:02 +0100, Helmut Waitzmann wrote:
>
>> Andreas Kohlbach <a...@spamfence.net>:
>>
>>>Die Schlüsselerstellung und die des Mantras sollten bei
>>>automatisierten Methoden transparent sein, um den Benutzer diese
>>>Hürde nicht aufzubeugen.
>>
>> Wenn der Anwender ein Mailer‐Programm nutzt, das die Schlüssel
>> selber erstellt (oder es GnuPG durch einen Programmaufruf machen
>> lässt) und sich dabei ein Mantra ausdenkt, merkt und eintippt,
>> muss der Anwender dabei nichts tun.  Er kann dann die geforderte
>> Transparenz genießen.
>

>$Mailprogramm fällt bereits durch. Heute nutzt man Apps auf seinem
>Smartphone, die keine PGP-Schnittstelle haben.

Selber schuld.  Ohne Nachfrage wird es Mailer‐Apps mit
Verschlüsselung nach dem OpenPGP‐Standard auch nicht geben.  Es gibt
prinzipiell keinen Grund, warum man auf dem Smartphone kein
Mailer‐Programm betreiben können sollte, das mit dem
OpenPGP‐Standard arbeitet.

>Oder das Mail-Interface im Browser.
>

Mit dem bekannten Mangel:  Die Ende‐zu‐Ende‐Verschlüsselung
erstreckt sich dann nicht auf den Bereich zwischen dem Anwender und
seinem E‐Mail‐Anbieter, und der E‐Mail‐Anbieter kann Man in the
Middle werden.

>Genau hier muss der Mail-Anbieter ansetzen. Der User macht einen
>Klick, um die ganze Chose zu aktivieren - das war es.

Das hast du jetzt oft genug gefordert.  Dass das nicht funktioniert,
weil die Verschlüsselung dann den Weg zwischen dem Anwender und dem
E‐Mail‐Anbieter nicht umfasst und – je nachdem, welche
E‐Mail‐Anbieter beteiligt sind – kaum bis gar nicht besser als ohne
Verschlüsselung ist, hat die Diskussion bereits ergeben.  Alle
Rückfragen, wie du die Ausdehnung der Sicherheit bis zu den
beteiligten Kommunikationspartnern bewerkstelligen willst, hast du
bislang nicht beantwortet.

>Alles andere überfordert de ONU von heute.
>

Tja.  Digital native und nicht technophob, aber mathematischer
Analphabet.  Das passt halt nicht zusammen.

>Dann ist es aber müßig weiter darüber zu diskutieren, weil vorher
>schon kaum ein ONU überhaupt Verständnis dafür aufbringen kann,
>warum man Mails verschlüsseln sollte.

Wer nicht verschlüsseln will, lasse es bleiben.  Nur sollte so
jemand dann davon absehen, sich darüber zu beklagen, dass jemand
anderes seine Identität gestohlen hat.

Solange es aber Leute gibt, die behaupten, E‐Mail‐Verschlüsselung
(siehe OP dieser Diskussion) könnte ohne Zutun des Anwenders
funktionieren, wenn nur die nerdigen Software‐Entwickler die
Anwender im Blick hätten, sind offensichtlich Aufklärung (und
Diskussion zur Erhärtung der entsprechenden Aussagen) nötig.

[Helmut Waitzmann]

Stefan Claas <spam.tra...@gmail.com>:
>On Saturday, November 27, 2021 at 9:57:44 PM UTC+1, Helmut
>Waitzmann wrote:

>Würde (ich habe nicht den aktuellen Überblick) Governikus seinen
>öffentlichen Schlüssel bei Mailvelope hochladen und du dein
>Schlüssel mit nPA, Kartenleser (BSI zertifiziert) und AusweisApp2
>zertifizieren

Ich verstehe <https://www.governikus.de/openpgp-schluessel/> so,
dass nicht ich mit der AusweisApp2, sondern Governikus meinen
Schlüssel zertifiziert, wenn ich mich mit der eID‐Funktion meines
Personalausweises mittels der AusweisApp2 bei Governikus anmelde und
meinen Schlüssel hochlade.

>und dann bei Mailvelope hochladen, dann müssten doch deine
>(persönlichen) Kommunikationspartner sehen können wenn dein pubkey
>eine Governikus Signatur hat das wohl dein Schlüssel ist, oder?

Zunächst werden alle sehen können, dass der Schlüssel ein von mir
erstelltes, von Governikus zertifiziertes User‐Id hat.

Was mir dabei noch nicht klar ist:  Woran sehen andere ohne, dass
sie den Fingerprint meines Schlüssels kennen, dass der Schlüssel
meiner ist und nicht etwa jemand anderem, der auch Helmut Waitzmann
heißt, oder gar jemand anderem, der nur sein User‐Id nach mir
benannt hat, gehört?

Welche Forderungen stellt Governikus an das User‐Id meines
Schlüssels, damit er es zertifiziert?  Muss es meine E‐Mail‐Adresse,
meinen Namen, die Nummer meines Personalausweises oder … enthalten?

Oder hängt Governikus eine Notation an das Zertifikat dran, in der
die Personalausweisdaten drinstehen?

[Stefan Claas]

On Sunday, November 28, 2021 at 10:51:46 AM UTC+1, Helmut Waitzmann wrote:
> Stefan Claas <spam.tra...@gmail.com>:
> >On Saturday, November 27, 2021 at 9:57:44 PM UTC+1, Helmut
> >Waitzmann wrote:
>
> >Würde (ich habe nicht den aktuellen Überblick) Governikus seinen
> >öffentlichen Schlüssel bei Mailvelope hochladen und du dein
> >Schlüssel mit nPA, Kartenleser (BSI zertifiziert) und AusweisApp2
> >zertifizieren
> Ich verstehe <https://www.governikus.de/openpgp-schluessel/> so,
> dass nicht ich mit der AusweisApp2, sondern Governikus meinen
> Schlüssel zertifiziert, wenn ich mich mit der eID‐Funktion meines
> Personalausweises mittels der AusweisApp2 bei Governikus anmelde und
> meinen Schlüssel hochlade.

Korrekt. Und zusätzlich siehst Du auf deinem Kartenleser das du dich
via ein Tunnel mit Governikus verbindest und dieses mit deiner PIN
bestätigen musst. Die Governikus WWW Seite IIRC zeigt dann noch
zusätzlich deine Daten an und fragt z.B. noch, falls du mehrere UIDs
hast welche denn bestätigt werden soll und sendet nach Abschluss
dein zertifizierten Schlüssel an die in der UID angegebenen email Adresse.

> >und dann bei Mailvelope hochladen, dann müssten doch deine
> >(persönlichen) Kommunikationspartner sehen können wenn dein pubkey
> >eine Governikus Signatur hat das wohl dein Schlüssel ist, oder?
> Zunächst werden alle sehen können, dass der Schlüssel ein von mir
> erstelltes, von Governikus zertifiziertes User‐Id hat.

Ja.

> Was mir dabei noch nicht klar ist: Woran sehen andere ohne, dass
> sie den Fingerprint meines Schlüssels kennen, dass der Schlüssel
> meiner ist und nicht etwa jemand anderem, der auch Helmut Waitzmann
> heißt, oder gar jemand anderem, der nur sein User‐Id nach mir
> benannt hat, gehört?

Nun, als Beispiel. Ich hatte auch einen Namensvetter (Stefan Claas),
Dirigent, der kürzlich verstorben ist und der hatte nicht meine email
Adresse. Will sagen, wenn Du meine Webseite besuchen würdest, oder
wo auch immer du mich mit einer email Adressenangabe im Netz siehst
und dann mein Schlüssel dir besorgst, dann machst du in GnuPG einfach
nach dem import ein IIRC 'gpg --list-sigs' und dann siehst du unter
meiner UID alles Signaturen, kryptographisch angebunden, mit
den entsprechenden Daten.

>
> Welche Forderungen stellt Governikus an das User‐Id meines
> Schlüssels, damit er es zertifiziert? Muss es meine E‐Mail‐Adresse,
> meinen Namen, die Nummer meines Personalausweises oder … enthalten?

Dein Vor und Nachname und deine email Adresse. Also wenn du z.B.
Peter Waitzmann und eine andere email Adresse angibst um eine
weitere Identität im Netz zu haben, geht das nicht, wegen dem Peter.

> Oder hängt Governikus eine Notation an das Zertifikat dran, in der
> die Personalausweisdaten drinstehen?

Nein, es wird mit der Vertrauenstufe sig3 bestätigt, dem höchsten
Level was GnuPG beim key management erlaubt.

Grüße
Stefan

[Stefan Claas]

On Sunday, November 28, 2021 at 11:24:59 AM UTC+1, Stefan Claas wrote:
> On Sunday, November 28, 2021 at 10:51:46 AM UTC+1, Helmut Waitzmann wrote:
> > Stefan Claas <spam.tra...@gmail.com>:
> > >On Saturday, November 27, 2021 at 9:57:44 PM UTC+1, Helmut
> > >Waitzmann wrote:

> > Was mir dabei noch nicht klar ist: Woran sehen andere ohne, dass
> > sie den Fingerprint meines Schlüssels kennen, dass der Schlüssel
> > meiner ist und nicht etwa jemand anderem, der auch Helmut Waitzmann
> > heißt, oder gar jemand anderem, der nur sein User‐Id nach mir
> > benannt hat, gehört?
> Nun, als Beispiel. Ich hatte auch einen Namensvetter (Stefan Claas),
> Dirigent, der kürzlich verstorben ist und der hatte nicht meine email
> Adresse. Will sagen, wenn Du meine Webseite besuchen würdest, oder
> wo auch immer du mich mit einer email Adressenangabe im Netz siehst
> und dann mein Schlüssel dir besorgst, dann machst du in GnuPG einfach
> nach dem import ein IIRC 'gpg --list-sigs' und dann siehst du unter
> meiner UID alles Signaturen, kryptographisch angebunden, mit
> den entsprechenden Daten.

Dabei ist zu sagen, dass natürlich Leute den Governikus pub key kennen
und haben müssen (wegen Fingerprint selbigens), damit sie auch wissen
das die sig3 auch CA Sinn macht ...

Grüße
Stefan

[Helmut Waitzmann]

Stefan Claas <spam.tra...@gmail.com>:

>On Sunday, November 28, 2021 at 10:51:46 AM UTC+1, Helmut Waitzmann
>wrote:
>> Stefan Claas <spam.tra...@gmail.com>:
>>> On Saturday, November 27, 2021 at 9:57:44 PM UTC+1, Helmut
>>> Waitzmann wrote:
>>
>>> Würde (ich habe nicht den aktuellen Überblick) Governikus seinen
>>> öffentlichen Schlüssel bei Mailvelope hochladen und du dein
>>> Schlüssel mit nPA, Kartenleser (BSI zertifiziert) und
>>> AusweisApp2 zertifizieren >> Ich verstehe
>>> <https://www.governikus.de/openpgp-schluessel/> so, >> dass
>>> nicht ich mit der AusweisApp2, sondern Governikus meinen >>
>>> Schlüssel zertifiziert, wenn ich mich mit der eID‐Funktion
>>> meines >> Personalausweises mittels der AusweisApp2 bei
>>> Governikus anmelde und >> meinen Schlüssel hochlade.
>
>Korrekt. Und zusätzlich siehst Du auf deinem Kartenleser das du
>dich via ein Tunnel mit Governikus verbindest und dieses mit deiner
>PIN bestätigen musst. Die Governikus WWW Seite IIRC zeigt dann noch
>zusätzlich deine Daten an und fragt z.B. noch, falls du mehrere
>UIDs hast welche denn bestätigt werden soll und sendet nach
>Abschluss dein zertifizierten Schlüssel an die in der UID
>angegebenen email Adresse.

Danke für die Erklärung.

>>> und dann bei Mailvelope hochladen, dann müssten doch deine
>>> (persönlichen) Kommunikationspartner sehen können wenn dein
>>> pubkey eine Governikus Signatur hat das wohl dein Schlüssel ist,
>>> oder? >> Zunächst werden alle sehen können, dass der Schlüssel
>>> ein von mir >> erstelltes, von Governikus zertifiziertes User‐Id
>>> hat.
>
>Ja.
>
>> Was mir dabei noch nicht klar ist: Woran sehen andere ohne, dass
>> sie den Fingerprint meines Schlüssels kennen, dass der Schlüssel
>> meiner ist und nicht etwa jemand anderem, der auch Helmut
>> Waitzmann heißt, oder gar jemand anderem, der nur sein User‐Id
>> nach mir benannt hat, gehört?
>
>Nun, als Beispiel. Ich hatte auch einen Namensvetter (Stefan
>Claas), Dirigent, der kürzlich verstorben ist und der hatte nicht
>meine email Adresse.

(Lies den folgenden Text bitte nicht als Anklage gegen dich.  Er
spiegelt meine Fragen wieder, die ich Governikus stellen würde –
oder jedem, der mir erklären kann, wie mir Governikus‐Zertifikate
bei der Schlüsselunterscheidung helfen.)

Angenommen, der Dirigent wäre auch Systemadministrator bei deinem
E‐Mail‐Provider gewesen.  Dann wäre er ja (wie in dieser Diskussion
mehrmals beschrieben) auch (Mit‐) Inhaber deiner E‐Mail‐Adresse
gewesen.  Dann hätte der sich also einen Schlüssel mit deiner
E‐Mail‐Adresse im User‐Id erstellen und ihn bei Governikus
einreichen können.

Und jetzt angenommen, du reichst auch einen Schlüssel mit deiner
E‐Mail‐Adresse im User‐Id bei Governikus zur Zertifizierung ein.

Dann hat Governikus zwei Schlüssel mit demselben User‐Id erhalten
und beide zertifiziert.  (Oder hätte Governikus deinen Schlüssel
ablehnen sollen, weil er ja zuvor schon den des Systemadministrators
zertifiziert hatte?)

>Will sagen, wenn Du meine Webseite besuchen würdest, oder wo auch
>immer du mich mit einer email Adressenangabe im Netz siehst und
>dann mein Schlüssel dir besorgst,

Solange ich nichts vom Fingerprint deines Schlüssels weiß, besorge
ich mir zwei Schlüssel: deinen und den des Systemadministrators,
denn beide tragen dasselbe User‐Id mit deiner E‐Mail‐Adresse.

>dann machst du in GnuPG einfach nach dem import ein IIRC 'gpg
>--list-sigs' und dann siehst du unter meiner UID alles Signaturen,
>kryptographisch angebunden, mit den entsprechenden Daten.

Und nun sei angenommen, dass mir keine der kryptografisch
angebundenen Fremd-Signaturen in meinem Web of Trust helfen, weil
ich niemand von den Zertifizierern in meinem Web of Trust habe.

Natürlich sehe ich dann bei beiden Schlüsseln auch das
Governikus‐Zertifikat am User‐Id mit deiner E‐Mail‐Adresse.

Wie kann ich dann erkennen, welcher der von Governikus
zertifizierten Schlüsseln nun deiner und welcher der des
Systemadministrators ist?  Heftet Governikus irgendwo an sein
Zertifikat die Personalausweisnummer oder vielleicht das
biometrische Photo oder zumindest den vollen Stammdatensatz
(Geburtsdatum, ‐ort und ‐name) oder den öffentlichen Schlüssel der
eID‐Funktion deines Ausweises, vielleicht auch nur als Hash, dran,
damit es mir möglich ist, wenn du mir deinen Ausweis zeigst, zu
entscheiden, welcher Schlüssel nun deiner und welcher der des
Systemadministrators ist?

Könnte ich dich treffen und dich nach dem Fingerprint fragen, wäre
alles klar.  Aber dann bräuchte ich das Governikus‐Zertifikat auch
nicht mehr, denn du könntest mir deinen Ausweis selber zeigen.

Irgendwie scheint mir das Governikus‐Zertifikat, so, wie ich es bis
jetzt verstanden habe, nicht weiterzuhelfen.

[Stefan Claas]

Technisch gesehen absolut korrekt, IMHO, wenn er der böse Admin ist
und ich der reguläre Kontoinhaber.

> >Will sagen, wenn Du meine Webseite besuchen würdest, oder wo auch
> >immer du mich mit einer email Adressenangabe im Netz siehst und
> >dann mein Schlüssel dir besorgst,
> Solange ich nichts vom Fingerprint deines Schlüssels weiß, besorge
> ich mir zwei Schlüssel: deinen und den des Systemadministrators,
> denn beide tragen dasselbe User‐Id mit deiner E‐Mail‐Adresse.
> >dann machst du in GnuPG einfach nach dem import ein IIRC 'gpg
> >--list-sigs' und dann siehst du unter meiner UID alles Signaturen,
> >kryptographisch angebunden, mit den entsprechenden Daten.
> Und nun sei angenommen, dass mir keine der kryptografisch
> angebundenen Fremd-Signaturen in meinem Web of Trust helfen, weil
> ich niemand von den Zertifizierern in meinem Web of Trust habe.
>
> Natürlich sehe ich dann bei beiden Schlüsseln auch das
> Governikus‐Zertifikat am User‐Id mit deiner E‐Mail‐Adresse.
>
> Wie kann ich dann erkennen, welcher der von Governikus
> zertifizierten Schlüsseln nun deiner und welcher der des
> Systemadministrators ist? Heftet Governikus irgendwo an sein
> Zertifikat die Personalausweisnummer oder vielleicht das
> biometrische Photo oder zumindest den vollen Stammdatensatz
> (Geburtsdatum, ‐ort und ‐name) oder den öffentlichen Schlüssel der
> eID‐Funktion deines Ausweises, vielleicht auch nur als Hash, dran,
> damit es mir möglich ist, wenn du mir deinen Ausweis zeigst, zu
> entscheiden, welcher Schlüssel nun deiner und welcher der des
> Systemadministrators ist?

GnuPG erlaubt dir eine Photo ID für deine öffentlichen Schlüssel
hinzuzufügen. Du nimmst z.B. ein kleines .jpeg Photo von einem
Porträt Photo von dir, wo man dein Gesicht gut erkennt, z.B.
das selbe Bild was du für dein Ausweis verwendest.

Das Photo kann man sich dann auch mit GnuPG anzeigen lassen,
und im normalen Listing IIRC sieht man das da ein UAT packet
vorhanden ist.

>
> Könnte ich dich treffen und dich nach dem Fingerprint fragen, wäre
> alles klar. Aber dann bräuchte ich das Governikus‐Zertifikat auch
> nicht mehr, denn du könntest mir deinen Ausweis selber zeigen.
>
> Irgendwie scheint mir das Governikus‐Zertifikat, so, wie ich es bis
> jetzt verstanden habe, nicht weiterzuhelfen.

Nun, GnuPG ist ja flexibel und du hast die Wahl. Das moderne sequoia-pgp
z.B. nutzt alle diese WoT Sachen gar nicht mehr und auf deren Seite
ist Herr Zimmermann unter den Testimonials abgebildet ...

Grüße
Stefan

[Stefan Claas]

Mal als kleiner Zusatz noch ... ich hatte ja hier auch eIDAS erwähnt, was
für rechtsverbindliche Digitale Signaturen in Europa anerkannt ist und auch
global online/offline überprüft werden kann.

Mal angenommen dir ist GnuPG zuviel, mit allen seinen Möglichkeiten
und du benötigst mehr Privatsphäre bei OpenPGP Kommunikation.

Du könntest dann folgendes machen, egal welche Kanäle du nutzt.

sequoia-pgp erlaubt dir auch Schlüssel ohne eine UID zu erstellen,
was GnuPG leider nicht kann.

Bei eIDAS Nutzung einfach ein .pdf Dokument mit deinen Daten und
die des Schlüssels erstellen und dann einfach mit einer eIDAS Signatur
versehen.

Grüße und Gute Nacht
Stefan

[Arno Welzel]

Andreas Kohlbach:

[...]
> Aber ich bleibe bei meiner Vermutung, dass entsprechende Software *alles*
> selbst konfiguriert, weil
>
> - Die viele Benutzer mit dem Hinzufügen des TCP/IP Moduls und anderen
> Voraussetzungen überfordert waren (und besonders auch heute noch wären)

Software konnte unter Windows 95/98 TCP/IP nicht selber hinzufügen. Das
muss schon vorhanden sein. Denn das hinzufügen geht logischerweise nicht
durch "online nachladen" sondern nur vom Installationsmedium aus. Darauf
hat entsprechende Software aber keinen Zugriff.

Deswegen gab es bei der Telekom auch umfangreiche Anleitungen, wie man
das macht inkl. der Schritte "DFÜ-Netzwerk installieren" und
"TCP/IP-Protokoll":

<https://www.telekom.de/hilfe/downloads/h_td100.pdf>

Du magst das anders in Erinnerung haben - aber einfach "installieren und
los geht's" war es oft eben *nicht*.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Sun, 28 Nov 2021 00:40:34 +0100, Helmut Waitzmann wrote:
>
>> Andreas Kohlbach <a...@spamfence.net>:
>>> On Fri, 26 Nov 2021 20:39:02 +0100, Helmut Waitzmann wrote:
>>>
>>>> Andreas Kohlbach <a...@spamfence.net>:

>>> Genau hier muss der Mail-Anbieter ansetzen. Der User macht einen
>>> Klick, um die ganze Chose zu aktivieren - das war es.
>>

>> Alle Rückfragen, wie du die Ausdehnung der Sicherheit bis zu den
>> beteiligten Kommunikationspartnern bewerkstelligen willst, hast
>> du bislang nicht beantwortet.
>

>Sicherheit = Vertrauen? Das hatte ich dann bereits gestrichen (man
>kann seinem Anbieter nicht vertrauen).

Die Anwendung der Public‐Key‐Kryptografie, bei der die geheimen und
öffentlichen Schlüssel bei den Kommunikationspartnern, nicht bei den
Anbietern, liegen und bei der die Kommunikationspartner einander die
öffentlichen Schlüssel (oder die Fingerprints derselben) auf
unverfälschbarem Weg zukommen lassen haben, dehnt die Sicherheit bis
zu den beteiligten Kommunikationspartnern aus – selbst dann, wenn
man den Anbietern nicht vertraut.

>>> Alles andere überfordert de ONU von heute.
>>>
>>
>> Tja.  Digital native und nicht technophob, aber mathematischer
>> Analphabet.  Das passt halt nicht zusammen.
>

>Verschlüsseln oder nicht hat IMO nichts damit zu tun. Vermutlich werden
>nicht mal eine Promille der privaten Mail-Schreiber verschlüsseln. Sind
>nicht alles Technophobe.

Als technophob – oder besser als vorsichtig – würde ich jemanden
bezeichnen, der von einem Smartphone die Finger lässt, weil er sich
sagt:  „Ich verstehe nicht, was da geschieht, wenn ich es verwende. 
Auf fast jeder App steht Google drauf, auch auf solchen, deren Daten
Google nichts angehen!  Am Ende stiehlt noch jemand meine Identität,
und dann sitz' ich in der Kacke“.

Als digital native und nicht technophob (sondern technophil) würde
ich jemanden bezeichnen, der von seinem Smartphone sagt:  „Geil, wie
toll das alles funktioniert!  Die Warnungen, die man immer wieder
hört, man solle aufpassen, dass einem nicht die Identität gestohlen
wird?  Ach was!  Funktioniert doch!  Mein Google macht doch alles
für mich.  Ich brauch' mich da um nichts weiter zu kümmern!“

Als mathematischen Analphabeten würde ich jemanden bezeichnen, der
bei den genannten 5 Punkten der Public‐Key‐Kryptografie abwinkt und
sagt:  Das Beispiel mit der Caesar‐Verschlüsselung?  Versteh' ich
nicht.  „Zwei Schlüssel, die zusammengehören?  Versteh' ich auch
nicht.  Und warum soll es darauf ankommen, dass ich den
Verschlüsselungssschlüssel des Nachrichtenempfängers kenne?  Ich
will seine Nachrichten doch nicht entschlüsseln!“

>>> Dann ist es aber müßig weiter darüber zu diskutieren, weil
>>> vorher schon kaum ein ONU überhaupt Verständnis dafür aufbringen
>>> kann, warum man Mails verschlüsseln sollte.
>>
>> Wer nicht verschlüsseln will, lasse es bleiben.  Nur sollte so
>> jemand dann davon absehen, sich darüber zu beklagen, dass jemand
>> anderes seine Identität gestohlen hat.
>

>Viele lernen erst, wenn es sie erwischt hat.
>

Genau.  Deshalb halte ich eine von vorne herein sichere
Vorgehensweise für besser.

Meine Hoffnung ist, dass man mathematischen Analphabetismus so weit
überwinden kann, dass die 5 Punkte der Public‐Key‐Verschlüsselung so
gut verstanden werden, dass daraus konkrete Handlungsanweisungen
(beispielsweise:  Lass dir vom Kommunikationspartner seinen
öffentlichen Schlüssel auf unverfälschbare Weise geben und gib ihm
ebenso auf unverfälschbare Weise deinen öffentlichen Schlüssel.)
entstehen.

>> Solange es aber Leute gibt, die behaupten, E‐Mail‐Verschlüsselung
>> (siehe OP dieser Diskussion) könnte ohne Zutun des Anwenders
>> funktionieren, wenn nur die nerdigen Software‐Entwickler die
>> Anwender im Blick hätten, sind offensichtlich Aufklärung (und
>> Diskussion zur Erhärtung der entsprechenden Aussagen) nötig.
>

>De-Mail existiert und macht das bereits seit Jahren. Ist alles
>dokumentiert; man muss nichts weiter aufklären. Allerdings muss der
>Anwender bei De-Mail doch selbst handeln, wenn ich das richtig
>verstehe.

De‐Mail macht zunächst nur Transportverschlüsselung zwischen den
einzelnen Haltepunkten einer Nachricht.  => Bei jedem Haltepunkt
wird die Nachricht entschlüsselt und aufs neue verschlüsselt und
kann deswegen, wenn im Haltepunkt ein Maulwurf sitzt, abgehört und
manipuliert werden.

So weit ich weiß, kann man noch Ende‐zu‐Ende‐Verschlüsselung
drunterziehen.  Ich weiß aber nicht, ob sie sich dann vom einen
Kommunikationspartner bis zum anderen oder nur vom Anbieter des einen
Kommunikationspartners bis zum Anbieter des anderen erstreckt.

Jedenfalls ist es auch da wieder dasselbe:  Die Schlüsselverwaltung
findet immer an den Enden der Ende‐zu‐Ende‐Verschlüsselung statt.

=> Soll die Ende‐zu‐Ende‐Verschlüsselung sich vom einen
Kommunikationspartner bis zum anderen erstrecken, müssen die
Kommunikationspartner die Schlüsselverwaltung selber machen.  Das
kann ihnen dann kein Anbieter abnehmen.  (Ihr Mailer‐Programm kann
sie dabei aber unterstützen.)

>Würde man sich aber auf die reine Verschlüsselung beschränken
>(Vertraulichkeit absichtlich unterschlagen),

Vertraulich ist eine Nachricht dann, wenn sie nur die beabsichtigten
Empfänger im Klartext erhalten.  Verschlüsselung ermöglicht
Vertraulichkeit dann, wenn nur die beabsichtigten Empfänger die
Nachricht entschlüsseln können und die Nachricht von anderen nicht
entziffert werden kann.

>bleibe ich dabei, dass das Anbieter fast vollständig automatisieren
>könnten.

… für geeignete Werte von „fast vollständig“.


Im Lauf der Diskussion habe ich mehrere konkrete Fragen gestellt, um
das „fast vollständig“ auszuloten.  Die letzte war die mit dem
auszufüllenden Frage‐Formular.  Keine hast du bisher beantwortet. 
Du bist am Zug.

[Helmut Waitzmann]

Stefan Claas <spam.tra...@gmail.com>:
> On Sunday, November 28, 2021 at 3:05:28 PM UTC+1, Helmut Waitzmann
> wrote:
>
>> Stefan Claas <spam.tra...@gmail.com>:

Zuvor:  Wenn es dir irgendwie möglich ist, beschaff dir einen
Newsreader und verwende den Web‐Newsreader von Google nicht weiter,
denn der zerstört die Zitatekennzeichnungen mit den führenden „>“ am
Zeilenanfang.

>>> Nun, als Beispiel. Ich hatte auch einen Namensvetter (Stefan
>>> Claas), Dirigent, der kürzlich verstorben ist und der hatte nicht
>>> meine email Adresse.
>>>

>> (Lies den folgenden Text bitte nicht als Anklage gegen dich.  Er
>> spiegelt meine Fragen wieder, die ich Governikus stellen würde –
>> oder jedem, der mir erklären kann, wie mir Governikus‐Zertifikate
>> bei der Schlüsselunterscheidung helfen.)
>>
>> Angenommen, der Dirigent wäre auch Systemadministrator bei deinem
>> E‐Mail‐Provider gewesen. Dann wäre er ja (wie in dieser Diskussion
>> mehrmals beschrieben) auch (Mit‐) Inhaber deiner E‐Mail‐Adresse
>> gewesen. Dann hätte der sich also einen Schlüssel mit deiner
>> E‐Mail‐Adresse im User‐Id erstellen und ihn bei Governikus
>> einreichen können.
>>
>> Und jetzt angenommen, du reichst auch einen Schlüssel mit deiner
>> E‐Mail‐Adresse im User‐Id bei Governikus zur Zertifizierung ein.
>>
>> Dann hat Governikus zwei Schlüssel mit demselben User‐Id erhalten
>> und beide zertifiziert. (Oder hätte Governikus deinen Schlüssel
>> ablehnen sollen, weil er ja zuvor schon den des Systemadministrators
>> zertifiziert hatte?)
>>
>
> Technisch gesehen absolut korrekt, IMHO, wenn er der böse Admin ist
> und ich der reguläre Kontoinhaber.
>

Ja, so habe ich es gemeint.

Ja, das ist mir bekannt.  Das würde mir im Fall eines Photos von
dir an deinem Schlüssel nur helfen, wenn ich dein Gesicht kenne und
wenn Governikus dein Photo‐Id an deinem Schlüssel mit dem
biometrischen Photo im Personalausweis verglichen, für
übereinstimmend befunden und zertifiziert hätte.


Die Zertifizierung von Governikus ist deshalb nötig, weil natürlich
auch der Systemadministrator Stefan Claas das Photo vom Photo‐Id von deinem
Schlüssel kopieren und als Photo‐Id an seinen Schlüssel anhängen
könnte.  Dann sehe ich zwei Schlüssel mit deinem Photo, aber nur bei
einem von ihnen wäre das Photo von Governikus zertifiziert.


Dazu ist es allerdings nötig – da du zum Zertifizieren vermutlich
nicht persönlich bei Governikus warst, um dein Gesicht vorzuzeigen –
dass Governikus Zugriff auf die biometrischen Daten im
Personalausweis hat.  Erhält Governikus Zugriff auf die
biometrischen Daten im Personalausweis?

>> Könnte ich dich treffen und dich nach dem Fingerprint fragen, wäre
>> alles klar. Aber dann bräuchte ich das Governikus‐Zertifikat auch
>> nicht mehr, denn du könntest mir deinen Ausweis selber zeigen.
>>
>> Irgendwie scheint mir das Governikus‐Zertifikat, so, wie ich es bis
>> jetzt verstanden habe, nicht weiterzuhelfen.
>>
>
> Nun, GnuPG ist ja flexibel und du hast die Wahl. Das moderne sequoia-pgp
> z.B. nutzt alle diese WoT Sachen gar nicht mehr und auf deren Seite
> ist Herr Zimmermann unter den Testimonials abgebildet ...
>

Fest steht jedenfalls:  Wer Public‐Key‐Kryptographie nutzen will,
braucht entweder selber das Wissen darüber, welchen öffentlichen
Schlüssel der Kommunikationspartner hat, oder er braucht andere,
denen er vertraut, dass sie es wissen und ihn nicht belügen (das
wäre dann das Web of Trust oder eine Zertifikatehierarchie).

[Helmut Waitzmann]

Stefan Claas <spam.tra...@gmail.com>:

>On Sunday, November 28, 2021 at 3:44:35 PM UTC+1, Stefan Claas
>wrote:
>> On Sunday, November 28, 2021 at 3:05:28 PM UTC+1, Helmut
>> Waitzmann wrote:
>
>sequoia-pgp erlaubt dir auch Schlüssel ohne eine UID zu erstellen,
>was GnuPG leider nicht kann.

Das habe ich bisher nicht vermisst:  Wenn ich meine
E‐Mail‐Adresse, meinen Namen und so weiter nicht verraten will,
nehme ich als User‐Id einfach eines, das weder meinen Namen noch
meine E‐Mail‐Adresse enthält.  Das geht auch mit GnuPG:  Ich habe
beispielsweise an meinem Schlüssel u. a. das User‐Id

(nomen nescio)

und das User‐Id

(This is not an e-mail address.)
<8958-96d2-cdba-d28d-1a3f...@fingerprint.invalid>.

Das zweite sieht sogar wie eine E‐Mail‐Adresse aus (für den Fall,
dass irgend jemand meint, User‐Ids müssten in jedem Fall eine
E‐Mail‐Adresse enthalten).  Der dabeistehende Kommentar in Klammern
erklärt, dass es keine sein soll.

Trotzdem kann es jeder guten Gewissens zertifizieren:  Dass es
tatsächlich den Fingerprint des Schlüssels nennt, kann ja jeder
nachprüfen und bestätigen.

[Stefan Claas]

On Monday, November 29, 2021 at 11:53:33 PM UTC+1, Helmut Waitzmann wrote:

> Zuvor: Wenn es dir irgendwie möglich ist, beschaff dir einen
> Newsreader und verwende den Web‐Newsreader von Google nicht weiter,
> denn der zerstört die Zitatekennzeichnungen mit den führenden „>“ am
> Zeilenanfang.

Mein zuletzt verwendeter Newsreader war das ausgezeichnete flnews,
jedoch habe ich mein workflow aus bestimmten Gründen ändern müssen,
die ich hier nicht erwähnen möchte.

> Dazu ist es allerdings nötig – da du zum Zertifizieren vermutlich
> nicht persönlich bei Governikus warst, um dein Gesicht vorzuzeigen –
> dass Governikus Zugriff auf die biometrischen Daten im
> Personalausweis hat. Erhält Governikus Zugriff auf die
> biometrischen Daten im Personalausweis?

Richtig. Ganz einfach gesagt, Lieschen Müller erhält bei Governikus
kein visuelles feedback welches ihr sagt das biometrische Daten
geprüft wurden und wenn dem so wär, dann müsste IMHO dir GnuPG
sagen 'photo-id matches UID' oder so ähnlich, richtig?

> Fest steht jedenfalls: Wer Public‐Key‐Kryptographie nutzen will,
> braucht entweder selber das Wissen darüber, welchen öffentlichen
> Schlüssel der Kommunikationspartner hat, oder er braucht andere,
> denen er vertraut, dass sie es wissen und ihn nicht belügen (das
> wäre dann das Web of Trust oder eine Zertifikatehierarchie).

Ja, im Fall von GnuPG alleine, würde ich mal sagen. Und was best practice
betrifft (hatte ich mal auf der GnuPG ML angesprochen) haben ja bei
dem demokratischen GnuPG Menschen verschiedene Möglichkeiten
wie sie das machen und ob sie dann mit jemanden der z.B. sequoia-pgp
nutzt klarkommen wäre dann vermutlich eine weitere Frage.

Grüße
Stefan

[Stefan Claas]

On Tuesday, November 30, 2021 at 12:40:13 AM UTC+1, Helmut Waitzmann wrote:
> Stefan Claas <spam.tra...@gmail.com>:
> >On Sunday, November 28, 2021 at 3:44:35 PM UTC+1, Stefan Claas
> >wrote:
> >> On Sunday, November 28, 2021 at 3:05:28 PM UTC+1, Helmut
> >> Waitzmann wrote:
> >
> >sequoia-pgp erlaubt dir auch Schlüssel ohne eine UID zu erstellen,
> >was GnuPG leider nicht kann.
> Das habe ich bisher nicht vermisst: Wenn ich meine
> E‐Mail‐Adresse, meinen Namen und so weiter nicht verraten will,
> nehme ich als User‐Id einfach eines, das weder meinen Namen noch
> meine E‐Mail‐Adresse enthält. Das geht auch mit GnuPG: Ich habe
> beispielsweise an meinem Schlüssel u. a. das User‐Id
>
> (nomen nescio)
>
> und das User‐Id
>
> (This is not an e-mail address.)
> <8958-96d2-cdba-d28d-1a3f...@fingerprint.invalid>.
>
> Das zweite sieht sogar wie eine E‐Mail‐Adresse aus (für den Fall,
> dass irgend jemand meint, User‐Ids müssten in jedem Fall eine
> E‐Mail‐Adresse enthalten). Der dabeistehende Kommentar in Klammern
> erklärt, dass es keine sein soll.

GnuPG hat ja die freeform UID Möglichkeit so das du das noch ganz
anders gestalten kannst und dich nicht an die Vorgaben halten musst.

sequoia-pgp macht das halt nach dem 'less is more' Prinzip.

> Trotzdem kann es jeder guten Gewissens zertifizieren: Dass es
> tatsächlich den Fingerprint des Schlüssels nennt, kann ja jeder
> nachprüfen und bestätigen.

Ja, genau.

Grüße
Stefan

[Arno Welzel]

Andreas Kohlbach:

> On Mon, 29 Nov 2021 15:04:54 +0100, Arno Welzel wrote:
>>
>> Andreas Kohlbach:
>>
>> [...]
>>> Aber ich bleibe bei meiner Vermutung, dass entsprechende Software *alles*
>>> selbst konfiguriert, weil
>>>
>>> - Die viele Benutzer mit dem Hinzufügen des TCP/IP Moduls und anderen
>>> Voraussetzungen überfordert waren (und besonders auch heute noch wären)
>>
>> Software konnte unter Windows 95/98 TCP/IP nicht selber hinzufügen. Das
>> muss schon vorhanden sein. Denn das hinzufügen geht logischerweise nicht
>> durch "online nachladen" sondern nur vom Installationsmedium aus. Darauf
>> hat entsprechende Software aber keinen Zugriff.
>

> Dafür gab es Floppies. Technikaffine Benutzer besaßen gar ein CD-Rom Laufwerk.

Und wie schafft es ein Setup, das Medium in das Laufwerk einzulegen?

> Soweit ich mich erinnere, legte man z.B. die Windows 95 Installations-CD
> ein, ging in die Netzwerk-Einstellungen, um z.B.TCP/IP hinzufügen. NETBEUI
> oder IPX fallen mir gerade auch noch an.
>
> Wenn der User das kann, kann das auch eine Software.

Nicht alles, was man als User manuell ausführen kann, kann auch durch
ein Setup-Programm erledigt werden.

Zur Erinnerung: den Microsoft Installer samt der damit verbundenen
Komponenten zur Systemkonfiguration gab es bei Windows 95 noch nicht.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>On Mon, 29 Nov 2021 21:19:04 +0100, Helmut Waitzmann wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net>:
>>

>>> bleibe ich dabei, dass das Anbieter fast vollständig
>>> automatisieren könnten.
>>
>> … für geeignete Werte von „fast vollständig“.
>>
>> Im Lauf der Diskussion habe ich mehrere konkrete Fragen gestellt,
>> um das „fast vollständig“ auszuloten.  Die letzte war die mit dem
>> auszufüllenden Frage‐Formular.  Keine hast du bisher
>> beantwortet.  Du bist am Zug.
>

>Vermutlich verstehst Du meine Idee nicht.

Ich weiß, dass die einzige Form des sicheren Nachrichtenverkehrs
(fast) ohne Zutun des Anwenders die ist, Transportverschlüsselung
zwischen den Anbietern und zwischen dem Anwender und seinem Anbieter
einzurichten.  Eine Ende‐zu‐Ende‐Verschlüsselung zwischen Alice und
Bob, bei der selbst die beteiligten E‐Mail‐Provider nicht
dazwischenfunken oder belauschen können, gibt es ohne Zutun von
Alice und Bob nicht.

Von nichts kommt nichts:  Man kann auf einem unsicheren Medium
keinen sicheren Nachrichtenkanal einrichten, ohne zumindest zum
Zeitpunkt der Einrichtung einen zweiten Kanal zur Verfügung zu
haben, der entweder in der einen Kommunikationsrichtung sowohl
fälschungs‐ als auch abhörsicher ist oder in beiden Richtungen
fälschungssicher ist oder in beiden Richtungen abhörsicher ist.  Auf
diesem zweiten Kanal läuft dann das Zutun der Anwender ab.  Wenn
damit dann der sichere Kanal eingerichtet ist, kann man diesen
zweiten Kanal wieder aufgeben.  Aber einfach aus dem Hut zaubern
kann man einen sicheren Nachrichtenkanal auf einem unsicheren Medium
nicht.

Nur mathematische Analphabeten glauben, zaubern zu können.

>Vergessen wir alles und versuchen es nochmal abstrakt.

Einverstanden.  Abstrakt:

Eine signierte und verschlüsselte Nachricht ist genau von dem
Startpunkt zu dem Zielpunkt sicher, an denen die folgenden beiden
Bedingungen erfüllt sind:

Am Startpunkt liegt der öffentliche Verschlüsselungsschlüssel vor,
mit dem die Nachricht verschlüsselt wird.  Am Zielpunkt liegt der
zum Verschlüsselungsschlüssel des Startpunkts gehörende geheime
Entschlüsselungsschlüssel vor.

Am Startpunkt liegt der geheime Signierschlüssel vor, mit dem die
Nachricht unterschrieben wird.  Am Zielpunkt liegt der zum
Signierschlüssel des Startpunkts gehörende öffentliche
Signaturprüfungsschlüssel vor.

Sind die Bedingungen nicht erfüllt, können folgende Defekte
auftreten:

Wenn am Startpunkt nicht Bob's sondern Eve's öffentlicher
Verschlüsselungsschlüssel verwendet wird, verliert die
verschlüsselte Nachricht an Bob die Vertraulichkeit, weil sie von
Eve statt von Bob entschlüsselt werden kann (unter der
Veraussetzung, dass Eve die Übertragung belauschen kann).

Wenn am Zielpunkt Mallory's öffentlicher Signaturprüfungsschlüssel
mit Alice's verwechselt wird, hält Bob eine von Mallory stammende
Nachricht für eine von Alice:  Mallory kann Alice's Identität
stehlen und kann einen ersten Schritt zum Man in the middle (oder
zur woman in the middle) tun.


Wenn man nun will, dass die Anwender sich nicht mit der
Schlüsselverwaltung herumschlagen müssen, müssen die Schlüssel bei
den beteiligten Anbietern liegen.  => Die Sicherung erstreckt sich
nur auf den Nachrichtenkanal zwischen den Anbietern, auch bekannt
als Transportverschlüsselung.  Bei De‐Mail oder
E‐Mail‐made‐in‐Germany ist genau das der Fall.

Damit die Nachrichten dennoch sicher zu und von den Anwenderinnen
kommen, braucht man noch entsprechende Schlüssel zwischen den
Anbietern und den Anwenderinnen.  Und es gibt sie auch: 

Die öffentlichen Schlüssel der Anbieter liegen bei der Anwenderin
als TLS‐Zertifikate auf dem Rechner, in der Regel bereits vom
Distributor des Betriebssystems mit ausgeliefert.

Die Anbieter haben keine Zertifikate der Anwenderinnen vorliegen. 
Statt dessen loggen sich die Anwenderinnen mit Kennung und Passwort
ein, bevor sie ihre Nachrichten abholen oder einliefern.

>Der Benutzer wird einmal dem Mail-Anbieter mitteilen, dass er an
>einer Verschlüsslung seiner Mails teilnehmen möchte. Der Anbieter
>richtet dann alles voll automatisch (ohne jegliches Zutun des
>Anwenders) ein.
>
>Der Anwender schreibt *im* *Web-Interface* (kein externes Programm)
>seine Mails, die meist ohne Verschlüsslung rausgehen. Sollte aber
>einer seiner Adressaten beim selben (oder ähnlichem) Anbieter
>ebenfalls eine Verschlüsslung gewünscht haben, wird seine Mail (und
>wieder ohne sein Zutun) automatisch verschlüsselt. Genauso empfängt
>er verschlüsselte Mails ohne sein Zutun.

Wenn die Nachricht im Web‐Interface verfasst wird, sitzt das
Mailer‐Programm nicht beim Anwender sondern beim Anbieter.  Es wird
vom Browser des Anwenders mittels des Web‐Interfaces ferngesteuert. 
Damit findet auch die Verschlüsselung der fertigen Nachricht erst
beim Anbieter statt.  (Wenn der Browser über https zugreift, gibt es
eine Transportverschlüsselung der Steuerbefehle vom Anwender zum
Anbieter und des sichtbaren Effekts der Steuerbefehle vom Anbieter
zum Anwender.)

Wenn (im Spezialfall) alle Empfänger einer Nachricht beim selben
Anbieter wie der Nachrichtensender sind, bleibt die Nachricht beim
Versenden anbieterintern.  => Der Anbieter kann sich die
Nachrichtenverschlüsselung sparen, weil die Nachricht den Anbieter
in diesem Fall nicht verlässt.  Und sie müsste sowieso, bevor sie
den Empfängern ins Postfach gelegt wird, entschlüsselt werden.

Sind nicht alle Empfänger beim sendenden Anbieter sondern manche bei
kooperierenden Anbietern, dann sieht es anders aus, beispielsweise
so:

Alice <Al...@anbieter1.example> schreibt an Carol
<Ca...@anbieter2.example> und Charlie <Cha...@anbieter2.example>.

Jetzt könnte der Anbieter2 für Carol und Charlie je (ohne Zutun von
Carol und Charlie) ein Schlüsselpaar angelegt haben.  Die
öffentlichen Schlüssel übermittelt er dann dem Anbieter1
(transportverschlüsselt, damit sie nicht verfälscht werden können),
damit der die Nachricht je für Carol und Charlie verschlüsselt.

Der Anbieter2 empfängt die für Carol und Charlie verschlüsselte
Nachricht, entschlüsselt sie für Carol und entschlüsselt sie für
Charlie und legt sie beiden ins Postfach.

Beobachtung:  Die für Carol entschlüsselte Nachricht gleicht der für
Charlie entschlüsselten Nachricht.

=> Der Anbieter2 kann dieselbe entschlüsselte Nachricht Carol und
Charlie ins Postfach legen.

=> Es genügt, wenn der sendende Anbieter1 eine
Transportverschlüsselung für den Nachrichtentransport zum
empfangenden Anbieter2 einrichtet, damit die Nachricht vertraulich
und unverfälscht bei ihm ankommt.  Die Nachricht für verschiedene
Empfänger beim selben empfangenden Anbieter getrennt zu
verschlüsseln und entschlüsseln, bringt keinen Sicherheitsgewinn
sondern verbrät nur unnötig ein Mehrfaches an CPU‐Zeit.

Die Transportverschlüsselung zwischen den verschiedenen Anbietern
dürfte genau das sein, was De‐Mail tut und was auch
E‐Mail‐made‐in‐Germany tat.

Beobachtung:

Wenn die Anbieter einander nicht vertrauen, hat das ganze keinen
Sinn, weil sonst ein Anbieter Missbrauch treiben kann:

>Dass der Anbieter dabei Missbrauch treiben kann, soll außen vor
>bleiben.

Wenn das umgekehrt einen Sinn haben soll, muss sichergestellt sein,
dass keiner der beteiligten Anbieter Missbrauch treibt.  =>
Unzuverlässige Anbieter dürfen sich nicht beteiligen.  => Es läuft
auf eine Club‐Lösung hinaus:  Sie funktioniert nur zwischen den
beteiligten Anbietern, die einander vertrauen.  Mit je Anwender
individueller Sicherung (beispielsweise OpenPGP), die weltumspannend
funktioniert – vorausgesetzt, die Postfachinhaber kennen die
(Fingerprints der) öffentlichen Schlüssel – hat das nichts mehr zu
tun.

=> Wer Verschlüsselung ohne Zutun des Anwenders will, muss mit
Anbieter‐Club‐Lösungen wie De‐Mail oder E‐Mail‐made‐in‐Germany
Vorlieb nehmen (und ist dabei auf Gedeih und Verderb den Anbietern
ausgeliefert).


Nochmal zitiert:

>>> bleibe ich dabei, dass das Anbieter fast vollständig
>>> automatisieren könnten.

Die Club‐Lösungen funktionieren nicht nur fast sondern ganz
vollständig ohne Zutun des Anwenders (wenn man davon absieht, dass
die Anwender sich eine Kennung und ein Passwort zum Einloggen beim
Anbieter merken müssen, aber das ist ja im Allgemeinen mit den
Passwort‐Safes kein Problem) – die anwenderindividuellen Lösungen
funktionieren dagegen nicht einmal ein bisschen ohne Zutun der
Anwenderinnen.

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

>Nochmal: *mir* geht es nicht um (Transport-) Sicherheit (Signierung
>und so).

Akzeptiert.

>Nur um das nackte Verschlüsseln des *Content* in der Annahme, dass
>Mallory mit dem verschlüsselten Inhalt selbst nichts anfangen kann.
>
>Beispiel: Ich könnte (PFUI!) hier einen Text mit Deinem Schlüssel
>verschlüsselt posten.

Dazu brauchst du meinen öffentlichen Verschlüsselungsschlüssel.


>Jeder hier sieht den "Buchsatabensalat". Aber nur Du kannst ihn in
>Klartext wandeln.

Wenn dir Mallory einen von ihr erzeugten öffentlichen
Verschlüsselungsschlüssel als meinen weis gemacht hat, ist es
Mallory, die als einzige deine für mich gedachte Nachricht in
Klartext wandeln kann.

[Helmut Waitzmann]

Stefan Claas <spam.tra...@gmail.com>:

>On Monday, November 29, 2021 at 11:53:33 PM UTC+1, Helmut Waitzmann wrote:
>
>> Zuvor: Wenn es dir irgendwie möglich ist, beschaff dir einen
>> Newsreader und verwende den Web‐Newsreader von Google nicht
>> weiter, denn der zerstört die Zitatekennzeichnungen mit den
>> führenden „>“ am Zeilenanfang.
>>
>
>Mein zuletzt verwendeter Newsreader war das ausgezeichnete flnews,
>jedoch habe ich mein workflow aus bestimmten Gründen ändern müssen,
>die ich hier nicht erwähnen möchte.
>

Brauchst du auch nicht.  Akzeptiert.

>> Dazu ist es allerdings nötig – da du zum Zertifizieren vermutlich
>> nicht persönlich bei Governikus warst, um dein Gesicht
>> vorzuzeigen – dass Governikus Zugriff auf die biometrischen Daten
>> im Personalausweis hat. Erhält Governikus Zugriff auf die
>> biometrischen Daten im Personalausweis?
>>
>
>Richtig. Ganz einfach gesagt, Lieschen Müller erhält bei Governikus
>kein visuelles feedback welches ihr sagt das biometrische Daten
>geprüft wurden und wenn dem so wär, dann müsste IMHO dir GnuPG
>sagen 'photo-id matches UID' oder so ähnlich, richtig?
>

Das Photo‐Id am Schlüssel müsste von Governikus beglaubigt sein, so,
wie ein Text‐User‐Id auch.  Die Bedeutung könnte dann die folgende
sein:  Governikus hat das Photo‐Id mit dem Foto im Personalausweis
verglichen und ist überzeugt, dass beide dieselbe Person zeigen. 
Leider ist das aber nicht der Fall:


Ich habe Governikus geschrieben und Antwort erhalten:  Governikus
erfragt vom Personalausweis nur die Vor‐ und den Nachnamen und den
Doktorgrad und gleicht sie gegen den PGP‐Schlüssel ab.


Gemeint ist mit dem Begriff Abgleichen wohl folgendes:  Governikus
schaut, ob das zu beglaubigende User‐Id am Schlüssel zu den
abgefragten Daten passt.


Dann schickt Governikus den Schlüssel mit der Beglaubigung an die im
User‐Id enthaltene E‐Mail‐Adresse.


Das biometrische Foto im Personalausweis vergleicht Governikus
demnach nicht mit einem eventuell vorhandenen Foto‐Id am
OpenPGP‐Schlüssel.  Schade eigentlich.


Das wäre interessant für Leute, die an ihren Schlüssel als Foto‐Id
ein Foto von sich anheften wollen und mit einer Beglaubigung des
Fotos beweisen wollen, dass das Foto dieselbe Person wie ihr
Personalausweis zeigt.  (Damit hängt dann am Schlüssel fast so etwas
wie eine digitale von Governikus beglaubigte Kopie des
Personalausweises.)

[Stefan Claas]

On Friday, December 3, 2021 at 7:50:07 PM UTC+1, Helmut Waitzmann wrote:

> Das biometrische Foto im Personalausweis vergleicht Governikus
> demnach nicht mit einem eventuell vorhandenen Foto‐Id am
> OpenPGP‐Schlüssel. Schade eigentlich.
>
>
> Das wäre interessant für Leute, die an ihren Schlüssel als Foto‐Id
> ein Foto von sich anheften wollen und mit einer Beglaubigung des
> Fotos beweisen wollen, dass das Foto dieselbe Person wie ihr
> Personalausweis zeigt. (Damit hängt dann am Schlüssel fast so etwas
> wie eine digitale von Governikus beglaubigte Kopie des
> Personalausweises.)

Interessant wäre das sicherlich für einige Anwendungsfälle und wenn
diese Möglichkeit auch in anderen (EU) Ländern vorhanden wär, dann
könnten deren CAs mit Governikus gegenseitig ihre öffentlichen Schlüssel
signieren und Lieschen Müller wüsste dann von ihrer online Freundschaft
Alice das ihr Schlüssel auch ihr gehört.

Und würde z.B. Werner Koch auch eine Governikus Signatur an seinem
Schlüssel haben und mit seiner kommerziellen Firma gnupg.com mit
Governikus da etwas ausarbeiten, könnte man ggf. in z.B. .de den Crypto
Markt und eID etwas pushen. Frage wäre jedoch ob auch Schwergewichte
wie die Vereinigten Staaten da mitmachen würden, was eID und Co betrifft.
Sieht man ja auch bei eIDAS, obwohl US-Firma Adobe mit seinem
kostenlosen Adobe Reader, das unterstützt.

Grüße
Stefan

[Stefan Claas]

Mir fällt gerade etwas ein. :-D Was du auch mal spaßeshalber ausprobieren
kannst ist bei der Deutschen Post dir Briefmarken mit deinem Foto (deiner
photo-id) zu bestellen und dann dein Schlüssel per Briefpost versenden.

Ich hatte damals mal auf der GnuPG ML ein Pilotprojekt vorgestellt und
dort 5 Freiwillige in der EU dafür gesucht. Dort beschrieb ich dann wie
man mit einem NFC Sticker Leser (offline Nutzung) NFC tags mit einer
GnuPG Nachricht beschreibt und dann diese NFC Sticker auf eine
Postkarte klebt. Für die Postkarten hatte ich als Adressaufkleber mir
das MacPGP 2.6.2 Agentenmännlein mit meiner Anschrift bestellt
und bei der Deutschen Post dann internationale Briefmarken mit
einem Foto von mir. So hatten dann die Teilnehmer ein quasi
Sammlerstück von mir, falls da jemand Briefmarken oder Postkarten
sammelt. Das Projekt konnte ich erfolgreich abschließen und der
Deutsche Hardware Händler, auf den ich verwies, hatte nach kurzer
Zeit einen Lagerbestand von null ...

Grüße
Stefan

[Stefan Claas]

On Friday, December 3, 2021 at 10:07:46 PM UTC+1, Stefan Claas wrote:

> Mir fällt gerade etwas ein. :-D Was du auch mal spaßeshalber ausprobieren
> kannst ist bei der Deutschen Post dir Briefmarken mit deinem Foto (deiner
> photo-id) zu bestellen und dann dein Schlüssel per Briefpost versenden.
>
> Ich hatte damals mal auf der GnuPG ML ein Pilotprojekt vorgestellt und
> dort 5 Freiwillige in der EU dafür gesucht. Dort beschrieb ich dann wie
> man mit einem NFC Sticker Leser (offline Nutzung) NFC tags mit einer
> GnuPG Nachricht beschreibt und dann diese NFC Sticker auf eine
> Postkarte klebt. Für die Postkarten hatte ich als Adressaufkleber mir
> das MacPGP 2.6.2 Agentenmännlein mit meiner Anschrift bestellt
> und bei der Deutschen Post dann internationale Briefmarken mit
> einem Foto von mir. So hatten dann die Teilnehmer ein quasi
> Sammlerstück von mir, falls da jemand Briefmarken oder Postkarten
> sammelt. Das Projekt konnte ich erfolgreich abschließen und der
> Deutsche Hardware Händler, auf den ich verwies, hatte nach kurzer
> Zeit einen Lagerbestand von null ...

Telefax geht natürlich auch, wenn man die richtige Software für den
armor und OCR hat, damit das fehlerfrei übertragen wird.

Grüße
Stefan

[Stefan Claas]

On Friday, December 3, 2021 at 10:17:55 PM UTC+1, Stefan Claas wrote:

> Telefax geht natürlich auch, wenn man die richtige Software für den
> armor und OCR hat, damit das fehlerfrei übertragen wird.

Für alle Fans von DJB's NaCl library mal eine kleine Idee, was
public key transfer betrifft.

https://groups.google.com/g/sci.crypt/c/z5R_efAaHY4

Regards
Stefan

[Stefan Claas]

Ich habe den thread mal aufgefrischt, für Leute die etwas Geld für
ihre Kommunikation haben und nicht immer alles auf lau machen,
wie man so bei kostenlosen Internet Diensten lernt.

Grüße und schöne Feiertage
Stefan

[Stefan Claas]

On Friday, December 3, 2021 at 10:17:55 PM UTC+1, Stefan Claas wrote:
> On Friday, December 3, 2021 at 10:07:46 PM UTC+1, Stefan Claas wrote:
>
> > Mir fällt gerade etwas ein. :-D Was du auch mal spaßeshalber ausprobieren
> > kannst ist bei der Deutschen Post dir Briefmarken mit deinem Foto (deiner
> > photo-id) zu bestellen und dann dein Schlüssel per Briefpost versenden.

> Telefax geht natürlich auch, wenn man die richtige Software für den
> armor und OCR hat, damit das fehlerfrei übertragen wird.

Faxgeräte sind wohl gefragt und für Nachschub ist gesorgt ... :-)

<https://www.amazon.de/Brother-FAX-2840-Laser-Faxger%C3%A4t-grau-wei%C3%9F-Schwarz/dp/B008LUK10A/ref=pd_lpo_1?pd_rd_i=B008LUK10A&th=1>

Grüße
Stefan