E-Mail digital unterschreiben als Schutz vor Phishing? (was: [Lösung Subjectwechsel])

[Helmut Waitzmann]

Zunächst:  Ich schlage den Umzug zu de.comp.security.misc vor, weil
mir das ein vom Mailer‐Programm unabhängiges Thema zu sein scheint.

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?

Beispielsweise gibt es mehrere öffentliche Schlüssel auf
Schlüsselservern, die ein User‐Id mit meinem Namen tragen, aber nur
einer ist der richtige.  Welcher es ist, findet der heraus, der von
mir meinen Fingerprint auf unverfälschbarem Weg – beispielsweise in
direkter Begegnung – erhält oder über das Web of Trust anderen
vertraut.

So könnte ein auf breiter Front stattfindendes Signieren von
E-Mails das Phishing-Problem möglicherweise entschärfen.

Das glaube ich eher weniger.  Kürzlich habe ich folgende
Phishing‐Nachricht erhalten – die E‐Mail‐Adressen habe ich
verfälscht, weil sie echt zu sein scheinen.  Die Nachricht kam als
Multipart‐Nachricht mit HTML‐Inhalt zu mir.  Ich gebe den Text
eingerückt wieder mit uneingerückten Erläuterungen von mir.

Subject: [POSTDE] Aktualisierung des KundenStatus!
From: POST DE <***@a-fqdn.example>
Reply-To: COS <***@another-fqdn.example>
To: COS <***@my-email-address-fqdn.example>

Aktualisierung des KundenStatus,

Sehr geehrter Kunde Wir wallen lhnen dass Ihr Konto nicht
uhemrutt wurde, wir unser System verhessem das Einfneren
Ihres Kontos zu vermeden.loggen Sie sich hitte aut unserer
WehSeite an, damt wr lhren Account uhemrufen konnen.

https://banking.postbank.de/rai/login

Hinter dem Text in der vorangehenden Zeile, der tatsächlich den URL
für das Online‐Banking bei der Postbank wiedergibt, verbirgt sich
jedoch ein Link auf
<https://postbank.arumpobentonite.com.au/DE/d41d8cd98f00b20/>.

Wir entschuldigen uns die Unannehmlichkeiten.

Danke, dass Sie und ausgewahlt hahen.

Herzliche GrüBe.

Ihre Posthank Online

Dann folgt noch ein PNG‐Bild, das das Postbank‐Logo zeigt, und
eines, das eine händische Unterschrift zeigt.

Soweit das Zitat der Phishing‐Nachricht.  (Ich glaub', der Phisher
sollte mal wieder das Vorlagenglas seines Scanners putzen.)


Ich gehe mal davon aus, dass solche Nachrichten Erfolg haben, sonst
würden sie nicht verschickt werden.

Diese unsignierte Phishing‐Nachricht hätte auch korrekt signiert
sein können; ihrer Wirksamkeit hätte das keinen Abbruch getan: 
Wirksam wird sie genau dann, wenn der Empfänger die Aufforderung,
sich bei der Postbank einzuloggen, ernst nimmt und ihr entspricht,
indem er dem in der Nachricht enthaltenen Link folgt.

Wenn diese Nachricht also Wirkung zeigt, folgt daraus:  Es sind
genug Leser leichtgläubig, obwohl der Absender nicht in der
Domain‐Hierarchie der Postbank liegt.  Solche Leser wird es nicht im
geringsten interessieren, ob die Nachricht signiert ist oder nicht –
ihnen genügt es, eine Kopie des Postbank‐Logos und einer
Unterschrift zu sehen.

Falls eines Tages Mailerprogramme vor unsignierten Nachrichten
generell warnen, werden Phisher ihre Nachrichten einfach korrekt mit
ihrem eigenen Schlüssel signieren.  Dann wird folglich kein
Mailerprogramm eine gebrochene oder fehlende Signatur anmerken.

Die Leser, die keine Schlüsselverwaltung selber machen (hier: die
Schlüssel anderer zertifizieren) wollen, sondern das lieber etwa
ihrem E‐Mail‐Provider überlassen, werden sowieso nicht wissen,
welche öffentlichen Schlüssel ihre Kommunikationspartner – die
Postbank eingeschlossen – haben.  Sie schlucken alles, was keine
gebrochene Signatur aufweist, ohne nachzuprüfen, wer denn da
signiert hat.  Und da sie keine Schlüsselverwaltung machen, weiß
auch der E‐Mail‐Provider nicht, welche Absender die Leser für
vertrauenswürdig halten und welche nicht.

Der sicherheitsrelevante Punkt in der angeführten Phishing‐Nachricht
ist dabei noch nicht einmal, ob der Absender tatsächlich die
Postbank ist und die Nachricht signiert ist oder nicht – das Problem
besteht bereits darin, dass der Leser nicht seinen
Online‐Banking‐Link für die Postbank aus seinen Bookmarks holt,
sondern statt dessen den betrügerischen Link in der Nachricht
anklickt, ohne zumindest zuvor mit dem Kontext‐Menü herauszufinden,
dass der Link nicht zur Postbank führt.

[Andreas Kohlbach]

Post by Helmut Waitzmann
Zunächst:  Ich schlage den Umzug zu de.comp.security.misc vor, weil
mir das ein vom Mailer‐Programm unabhängiges Thema zu sein scheint.

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?
Beispielsweise gibt es mehrere öffentliche Schlüssel auf
Schlüsselservern, die ein User‐Id mit meinem Namen tragen, aber nur
einer ist der richtige.  Welcher es ist, findet der heraus, der von
mir meinen Fingerprint auf unverfälschbarem Weg – beispielsweise in
direkter Begegnung – erhält oder über das Web of Trust anderen
vertraut.

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.

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

Weil niemand einen "transparenten" Service anbietet, wird sich die
Verschlüsselung von E-Mail nie durchsetzen.

Ich habe gerade zwei Leute, mit denen ich verschlüsselt maile...

[...]

[Helmut Waitzmann]

Post by Andreas Kohlbach

Post by Helmut Waitzmann

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?

[…]

Post by Andreas Kohlbach
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?

[Andreas Kohlbach]

Post by Helmut Waitzmann

Post by Andreas Kohlbach

Post by Helmut Waitzmann

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?

[…]

Post by Andreas Kohlbach
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?

Phishing geht über Webseiten. Natürlich könnte er auch eine signierte
und/oder verschlüsselte Nachricht senden. Wie jeder andere auch. Nur sich
per Mail nicht als jemand anderes dabei ausgeben.

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

[Andreas Kohlbach]

[...]

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.

Ging mir ähnlich mit Arcor vor mehr als zehn Jahren. Ich hatte im Usenet
damals einen Spammer entblößt (ein Profil aus sonst auf mehreren
öffentlich zugänglich Seiten aus den Daten zusammengestellt. Der Spammer
hat sich vermutlich beschwert, und mir wurde der komplette Zugang ohne
Warnung gesperrt. Der Support hat zwar direkt geantwortet, aber auch
nicht mit sich reden lassen, auch nachdem ich meinen "Fehler" (den ich
heute immer noch nicht als Fehler ansehe, da alle Daten des Spammers ja eh
im Internet zu finden waren) eingestand. Dummerweise hatte ich Kopien von
Urlaubsfotos auf deren FTP Server hochgeladen, bevor die Foto-CD kaputt
ging.

Die waren offenbar noch da und ich hatte das Gefühl, der Support wollte
mit mir spielen. Nach Tagen meinte er, er habe keine Lust mehr zu
diskutieren und meinen Account "unwiederbringlich" entfernt. Damit waren
die Bilder weg. Ich hatte mich dann noch bei seinem Vorgesetzten
beschwert, aber auch keine Antwort bekommen. Warum sollte Kunden, die den
kostenlosen Service nutzen (und durch Anschauen von Werbung "zahlen")
Hilfe vom Support 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.

Wie auch Du wohl gelernt hast, sollte man wichtige Dinge nicht über
kostenlose Services machen.

Nachdem Arcor nun Vodafone ist, wollte ich mit denen auch keinen Vertrag
über Telefon- oder Internet-Service abschließen wollen. Die haben die
dabbischen Mitarbeiter bestimmt von Arcor übernommen.

Post by Andreas Kohlbach
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. In Österreich soll ich gar
Besitzer einer Firma sein. Sogar ein Bach und eine Gemeinde trägt dort
meinen Nachnamen. Wer aber meine PGP-Schlüssel holt und eine Mail damit
sendet, kann nur ich sie entschlüsseln; niemand in Österreich.

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

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

[Christian Garbs]

Mahlzeit!

Post by Andreas Kohlbach
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

[Marco Moock]

Am Wed, 27 Oct 2021 07:55:23 -0000 (UTC)

Post by Christian Garbs
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.

[Helmut Waitzmann]

Post by Andreas Kohlbach

Post by Andreas Kohlbach
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.

[…]

Post by Andreas Kohlbach
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.)

Post by Andreas Kohlbach

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

[Andreas Kohlbach]

Post by Helmut Waitzmann

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

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

Post by Helmut Waitzmann
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.)

Ja, das ist ein Nachteil. Man muss dem Schlüssel-Verwalter unbedingt
vertrauen.

Post by Helmut Waitzmann

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

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

[Helmut Waitzmann]

Post by Andreas Kohlbach

Post by Helmut Waitzmann

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

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?

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

[Juergen Nieveler]

Post by Helmut Waitzmann
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.

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.

Naja, muß er schon - es sei denn das der "Automat" nur dem
Schlüsselserver
seines Betreibers vertraut, und dieser pro Email-Adresse nur EINEN
Schlüssel zulässt.

Sowas hat es schon öfter gegeben... Ciphire zum Beispiel schon vor
einer
Ewigkeit, heutzutage PEP. Ersetze Email durch die Handynummer, und
iMessage/Signal/whatever sind das gleiche.

Funktioniert, aber halt nur als geschlossenes System... und natürlich
muß
man in der Regel dem Betreiber vertrauen das der öffentliche Schlüssel
auch der richtige ist (und nicht durch den einer TLA ausgetauscht wurde
die MitM spielt). Manche Systeme erlauben einem die Schlüssel zu
verifizieren, andere nicht...

[Stefan Claas]

Post by Helmut Waitzmann
Könntest du bitte ausführen, wie automatisierte Verschlüsselung und
Unterschrift funktionieren könnte? Besonders interessiert bin ich
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

[Stefan Claas]

Post by Stefan Claas

Post by Helmut Waitzmann
Könntest du bitte ausführen, wie automatisierte Verschlüsselung
und Unterschrift funktionieren könnte? Besonders interessiert bin
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.

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

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]

Post by 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

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.

Post by Stefan Claas
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.

Post by Stefan Claas
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.)

Post by Stefan Claas
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]

Post by Helmut Waitzmann

Post by Andreas Kohlbach

Post by Helmut Waitzmann

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

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
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 <***@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?

Post by Helmut Waitzmann
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…

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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.)

Post by Helmut Waitzmann
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!»

[Andreas Kohlbach]

Post by Helmut Waitzmann

Post by Helmut Waitzmann
Könntest du bitte ausführen, wie automatisierte Verschlüsselung und
Unterschrift funktionieren könnte?  Besonders interessiert bin ich
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.

Ja, daher sagte ich, man müsse ihm dann vertrauen. Und wenn ich
unverschlüsselt sende, kann er eben falls mitlesen.

Post by Helmut Waitzmann
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.

Mit "Automat" meinte ich den Provider. Du bist vermutlich kein
Mail-Provider; hast also keinen "Automat".

Post by Helmut Waitzmann
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.

Ja, und?

Abstrakt: *Beide* Parteien (Sender und Empfänger) sind bei einem
Anbieter, der einen "Automat" hat, der Mail-Verschlüsselung
anbietet. Wenn der Sender eine Mail an jemandem schreiben will (der beim
selben Provider oder einem, der dieselbe Methode einsetzt ist), erkennt
das System dieses, und verschlüsselt die Mail automatisch.

Abstrackter: Es ist wie PGP, S/MIME oder andere Methoden, nur dahingehend
automatisiert, dass der Nutzer sich nicht selbst um die Erstellung der
Schlüssel oder des Mantras kümmern muss.

Post by Helmut Waitzmann

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

Warum nicht? Der Provider kennt die Schlüssel *beider* Parteien. Niemand
anders kann in meinem oder Deinem Namen eine Mail verschlüsseln oder auch
nur signieren.

Und vormals erwähntes "DE-Mail" macht doch genau dies, wenn ich das
richtig verstanden habe.

Post by Helmut Waitzmann
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.

Wenn jemand kein Konto beim selbem (oder einem, der dieselbe Methode
verwendet) hat, geht es natürlich nicht.

Post by Helmut Waitzmann

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?

Gar nicht. Er liegt beim Provider. Weder Sender noch Empfänger müssen auch
nur ihre Schlüssel selbst kennen.

Abstrakt: Das Handling der Verschlüsselung wird *komplett* über den
Provider abgewickelt. Und wie erwähnt funktioniert das nur, wenn Sender
und Empfänger beim selben Provider sind (oder einem, der dieselbe Methode
einsetzt).

Post by Helmut Waitzmann

Post by Helmut Waitzmann
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
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.

Mallory kann meiner Meinung nach Alice als Absender eintragen. Dazu
müsste Mallory beim Provider mit der Kennung von Alice eingeloggt sein,
was nicht sein kann, außer sie hat Kenntnis von der ID und des Passworts
des Mail-Providers. Hmm, vielleicht kann man das ID- und Passwortpaar in
diesem Fall als "Mantra" ansehen.

Post by Helmut Waitzmann
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…

Genau, das Vertrauen ist das Problem. Aber angenommen, Kunden vertrauen
großen Anbietern wie GMX, Vodafone, Gmail, welche ggf. die von mir
vorgeschlagene Methode einsetzten. Dann sollte das funktionieren.

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.

Ich habe beispielsweise Deinen Schlüssel, wenn ihm auch nicht voll

Post by Helmut Waitzmann

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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.

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.

[...]

Post by Helmut Waitzmann

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.

Diese haben IMO mit dem WWW genau so wenig zu tun wie das Usenet. Sie sind
eigenständige Anwendungen, die Daten über das Internet austauschen.

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

Wer Smartphones oder Tablets benutzt, kann sich die Sicherheit
abschminken. Ich habe zwar auch zwei Androiden, mache aber mit der
aufgezwungenen Bank-App (2-Factor-Authentification wird benötigt) nichts
Sicherheitsrelevantes.

Post by Helmut Waitzmann

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!»

Zumindest ist dies in Thunderbird bereits integriert. Der Benutzer muss
trotzdem Schlüsselpaare erzeugen. Das schreckt auch die Mehrheit seiner
Benutzer ab.

[Helmut Waitzmann]

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
Ich habe beispielsweise Deinen Schlüssel, wenn ihm auch nicht voll

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?

Post by Andreas Kohlbach

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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 <***@gmx.de>
Newsgroups: de.comm.software.mozilla.mailnews
Date: Sat, 23 Oct 2021 09:17:15 +0200
Message-ID: <***@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.

[Andreas Kohlbach]

[...]

Post by Andreas Kohlbach
Ich habe beispielsweise Deinen Schlüssel, wenn ihm auch nicht voll

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

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

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

[...]

Post by Andreas Kohlbach
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]
Newsgroups: de.comm.software.mozilla.mailnews
Date: Sat, 23 Oct 2021 09:17:15 +0200
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. 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.

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.

[Helmut Waitzmann]

Post by Andreas Kohlbach
[...]

Post by Helmut Waitzmann

Post by Andreas Kohlbach
Ich habe beispielsweise Deinen Schlüssel, wenn ihm auch nicht

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

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
[...]

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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]
Newsgroups: de.comm.software.mozilla.mailnews
Date: Sat, 23 Oct 2021 09:17:15 +0200
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.

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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]

Post by Helmut Waitzmann
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

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.

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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.

Post by Helmut Waitzmann
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.

Post by Helmut Waitzmann

Post by Andreas Kohlbach
[...]
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.

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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

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.

[Andreas Kohlbach]

Post by Helmut Waitzmann

Post by Helmut Waitzmann
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.

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

[...]

Post by Helmut Waitzmann

Post by Helmut Waitzmann
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.

Nicht nur <https://de.wikipedia.org/wiki/De-Mail#De-Ident>. Der Dienst
wäre sonst ziemlich sinnlos.

Post by Helmut Waitzmann
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.

[...]

[Helmut Waitzmann]

Post by Andreas Kohlbach

Post by Helmut Waitzmann

Post by Helmut Waitzmann
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.

Post by Andreas Kohlbach
Ich könnte sagen, "Ich muss mal einen Schlüssel mit der User-Id
"Thomas Meyer" hochladen.
| 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.

Post by Andreas Kohlbach
[...]

Post by Helmut Waitzmann

Post by Helmut Waitzmann
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.]

Post by Andreas Kohlbach

Post by Helmut Waitzmann
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.

[Andreas Kohlbach]

Post by Andreas Kohlbach

Post by Helmut Waitzmann

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.

Post by Andreas Kohlbach
Ich könnte sagen, "Ich muss mal einen Schlüssel mit der User-Id
"Thomas Meyer" hochladen.
| 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?

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

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

[...]

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

Wer den Anbietern kein unbegrenztes Vertrauen schenkt (wie ich, Du, und
die meisten anderen hier), hat mit einer automatisierten Methode nichts am
Hut.

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. Das scheint mir besser, als gar keine Verschlüsselung.

Und nochmal: Das Vertrauen an den/die Anbieter ist dann bereits im
Ausguss. Muss man dann hinnehmen. Das wird den meisten Interessenten aber
nicht mal bewusst sein, weil sie die Materie nicht verstehen.

[Arno Welzel]

[...]

Post by Andreas Kohlbach

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.

[Helmut Waitzmann]

Post by Andreas Kohlbach

Post by Helmut Waitzmann

Post by Andreas Kohlbach

Post by Helmut Waitzmann

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.

Post by Andreas Kohlbach

Post by Helmut Waitzmann

Post by Andreas Kohlbach
Ich könnte sagen, "Ich muss mal einen Schlüssel mit der User-Id
"Thomas Meyer" hochladen.
| 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 <***@usenet.ankman.de> gezeigt hattest:

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

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

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

gezeigt hast.  Er zeigt das User‐Id «Helmut Waitzmann
(Anti-Spam-Ticket.b.qc3c) <***@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 ‹***@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 <***@xoxy.net> mit dem damit benannten
Schlüssel zu verschlüsseln.

Post by Andreas Kohlbach

Post by Helmut Waitzmann
[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.

Post by Andreas Kohlbach
[...]

Post by Helmut Waitzmann
=> 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]

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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.

[Stefan Kanthak]

Post by Andreas Kohlbach

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!

Post by Andreas Kohlbach
War der Annahme, dass jede Email-Adresse nur ein Mal existieren kann.

Welche ZENTRALE Instanz sollte das pruefen und garantieren?

Post by Andreas Kohlbach
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!

[...]

Post by Andreas Kohlbach
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

[Andreas Kohlbach]

Post by Stefan Kanthak

Post by Andreas Kohlbach
War der Annahme, dass jede Email-Adresse nur ein Mal existieren kann.

Welche ZENTRALE Instanz sollte das pruefen und garantieren?

Jeder Keyserver könnte einfach prüfen, ob die ID mit der Mail-Adresse
bereits existiert (bekannter Fingerprint) und es dann verweigern. Außer
sie wird geupdatet.

Post by Stefan Kanthak

Post by Andreas Kohlbach
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!
[...]

Post by Andreas Kohlbach
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!

Ich weiß. "Ungesichert" sollte als Beispiel dienen, dass man trotzdem
einen darüber (und lasse es Rauchzeichen sein) verschlüsselten Inhalt
sicher übertragen kann.

[Helmut Waitzmann]

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?

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

Siehe

Subject: Re: E-Mail-Verschluesselung und -Signierung ohne Zutun
des Anwenders?
From: Friedhelm Waitzmann <***@spamgourmet.com>
Newsgroups: de.comp.security.misc
Date: Mon, 22 Nov 2021 13:52:54 -0000 (UTC)
Message-ID: <sng7bl$ug9$***@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 <***@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
<***@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]

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.

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

[Helmut Waitzmann]

On Saturday, November 27, 2021 at 9:57:44 PM UTC+1, Helmut
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]

Post by Helmut Waitzmann

On Saturday, November 27, 2021 at 9:57:44 PM UTC+1, Helmut
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.

Post by Helmut Waitzmann

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.

Post by Helmut Waitzmann
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.

Post by Helmut Waitzmann
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.

Post by Helmut Waitzmann
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]

Post by Stefan Claas

On Saturday, November 27, 2021 at 9:57:44 PM UTC+1, Helmut

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]

Post by Stefan Claas

On Saturday, November 27, 2021 at 9:57:44 PM UTC+1, Helmut
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.

Post by Stefan Claas

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?)

Post by Stefan Claas
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.

Post by Stefan Claas
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]

Post by Helmut Waitzmann

Post by Stefan Claas

On Saturday, November 27, 2021 at 9:57:44 PM UTC+1, Helmut
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.

Post by Stefan Claas

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?)

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

Post by Helmut Waitzmann

Post by Stefan Claas
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.

Post by Stefan Claas
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.

Post by Helmut Waitzmann
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]

Post by Stefan Claas

Post by Helmut Waitzmann
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 ...

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

[Helmut Waitzmann]

On Sunday, November 28, 2021 at 3:44:35 PM UTC+1, Stefan Claas

On Sunday, November 28, 2021 at 3:05:28 PM UTC+1, Helmut

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-e265-9a98-3091-dccb-***@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.

[Helmut Waitzmann]

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.

Post by Stefan Claas

Post by Helmut Waitzmann

Post by Stefan Claas
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.

Post by Stefan Claas

Post by Helmut Waitzmann
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.

Post by Stefan Claas
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.

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?

Post by Stefan Claas

Post by Helmut Waitzmann
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).

[Stefan Claas]

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

[Paul Muster]

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

[Helmut Waitzmann]

Post by Paul Muster

Post by Helmut Waitzmann
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
gesendet werden soll, die Datenbank bei GMX abfragen. Und Schlüssel

Ja, richtig.  Es genügt auch, wenn der E‐Mail‐Provider von
<***@ihr-provider.example> eine eigene Datenbank pflegt und
Alice's Mailclient die Datenbank des Providers von
<***@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.

[Andreas Kohlbach]

Post by Helmut Waitzmann

Post by Paul Muster

Post by Helmut Waitzmann
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
gesendet werden soll, die Datenbank bei GMX abfragen. Und Schlüssel

Ja, richtig.  Es genügt auch, wenn der E‐Mail‐Provider von
Alice's Mailclient die Datenbank des Providers von
Bob verschlüsseln will.  Allerdings schafft das das Problem der
mangelnden Gewissheit über die öffentlichen Schlüssel auch nicht aus

Das ist in diesem Fall auch nicht gewollt; der User kann und will sich
mit dem Hintergrund der Verschlüsslung nicht beschäftigen. Wollte er das,
braucht er das "automatisierte System" nicht. Er würde PGP andernfalls eh
selbst einrichten.

Post by Helmut Waitzmann
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.

Ich auch nicht. Aber ein automatisiertes System ist IMO der einzige Weg,
technophobe User zum Verschlüsseln zu bringen. Das die Sicherheit nicht
optimal ist muss vom User akzeptiert werden.

[Helmut Waitzmann]

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

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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?

Post by Andreas Kohlbach
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.

[Andreas Kohlbach]

Post by Helmut Waitzmann
[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.

Post by Helmut Waitzmann

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.

Der Unterschied zwischen "selbst PGP machen" und einer automatisierten
Methode liegt IMO darin, seine Keys vom Anbieter (statt selbst lokal)
erzeugt zu haben. Man muss dazu diesem Anbieter (statt nur sich selbst)
voll und ganz vertrauen.

Ohne kann man immer Man-in-the-Middle-Angriffen ausgesetzt sein. Das
Vertrauen in einen externen Anbieter scheint mir das kleinere Übel zu sein.

Post by Helmut Waitzmann

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. Wie erwähnt, muss man dem Anbieter aber
dabei unbedingt vertrauen. Allerdings wird diese aber nur bei der
Kommunikation über sein Web-Interface funktionieren.

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.

Post by Helmut Waitzmann
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.

Klar. Aber wie gesagt, muss man andernfalls dem Anbieter einer
automatisierten Methode vertrauen. Kann oder will man das nicht, sollte
man davor absehen.

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

[Helmut Waitzmann]

Post by Andreas Kohlbach

Post by Helmut Waitzmann
[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.]

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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
<***@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:
<83tuh4c1ua.fsf_-***@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.

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
Man muss dazu diesem Anbieter

nicht nur diesem Anbieter sondern auch den Anbietern der
Kommunikationspartner

Post by Andreas Kohlbach
(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.

Post by Andreas Kohlbach
Das Vertrauen in einen externen Anbieter scheint mir das kleinere
Übel zu sein.

Ich sage nur «Yahoo».

Post by Andreas Kohlbach

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
Wie erwähnt, muss man dem Anbieter aber dabei unbedingt vertrauen.

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

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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]

Post by Helmut Waitzmann
Was ist dir bei
Subject: E-Mail-Verschluesselung und -Signierung ohne Zutun des
Anwenders? (was: [Lösung Subjectwechsel]) From: Helmut Waitzmann
de.comm.software.mozilla.mailnews, de.comp.security.misc
Followup-To: de.comp.security.misc Date: Mon, 25 Oct 2021

Autsch.  Das hätte so aussehen sollen:


Subject: E-Mail-Verschluesselung und -Signierung ohne
Zutun des Anwenders? (was: [Lösung Subjectwechsel])
From: Helmut Waitzmann <***@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: <83tuh4c1ua.fsf_-***@helmutwaitzmann.news.arcor.de>

[Andreas Kohlbach]

[...]

Post by Helmut Waitzmann

Post by Andreas Kohlbach

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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
de.comm.software.mozilla.mailnews, de.comp.security.misc
Followup-To: de.comp.security.misc Date: Mon, 25 Oct 2021
nicht verständlich?

So ziemlich alles. 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).

Post by Helmut Waitzmann
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.

Sender und Empfänger müssen sich nur Klicken nur einmalig einverstanden
erklären, de Verschlüsselungs-Service nutzen zu wollen.

Der Anbieter braucht es nur einmalig aufzusetzen. Alles andere sollte
vollautomatisch ablaufen.

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.

DE-Mail macht genau das (meines Wissens). Es funktioniert also. Dass es
wenig genutzt wird liegt am Desinteresse möglicher Kunden. Ggf. kostet
DE-Mail auch, dass dieses ein weiterer Grund für die Nichtbenutzung ist.

Post by Helmut Waitzmann
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.

Post by Helmut Waitzmann
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.

[...]

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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.

Post by Helmut Waitzmann

Post by Andreas Kohlbach
(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.

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

Außer den Anbietern kann es dann auf dem restlichen Transportweg keinen
Man-in-the-Middle-Angriff geben.

Post by Helmut Waitzmann
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.

Genau mein Punkt: *Vertrauen*.

[Helmut Waitzmann]

Post by Andreas Kohlbach
[...]

Post by Helmut Waitzmann
Was ist dir bei
Subject: E-Mail-Verschluesselung und -Signierung ohne Zutun des
Anwenders? (was: [Lösung Subjectwechsel]) From: Helmut Waitzmann
de.comm.software.mozilla.mailnews, de.comp.security.misc
Followup-To: de.comp.security.misc Date: Mon, 25 Oct 2021
nicht verständlich?

So ziemlich alles.

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

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach

Post by Helmut Waitzmann
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:]

Post by Andreas Kohlbach

Post by Helmut Waitzmann
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.

Post by Andreas Kohlbach
[...]

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
*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.

[Andreas Kohlbach]

Post by Helmut Waitzmann
Da böte sich ein Followup von dir auf jene Nachricht an.

Post by Andreas Kohlbach
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.

Meiner Meinung nach versuchst Du *alle* möglichen Blickwinkel eines
Problems in einem Absatz zu beleuchten. Das wird Deine Leser (zumindest
mich) überfordern. Das mag in einem Essay wissenschaftlich gut sein. Im
Usenet aber zu Verwirrungen führen.

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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.

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

Post by Helmut Waitzmann

Post by Andreas Kohlbach

Post by Helmut Waitzmann
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.

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? Sie könnten diese allenfalls abfangen, damit sie nicht
zugestellt werden. Aber das können sie auch bei nicht verschlüsselten Mails.

[...]

[Helmut Waitzmann]

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

[Andreas Kohlbach]

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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. Oder das Mail-Interface im
Browser. Genau hier muss der Mail-Anbieter ansetzen. Der User macht einen
Klick, um die ganze Chose zu aktivieren - das war es. Alles andere
überfordert de ONU von heute.

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.

[Helmut Waitzmann]

Post by Andreas Kohlbach

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
Alles andere überfordert de ONU von heute.

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

Post by Andreas Kohlbach
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.

[Andreas Kohlbach]

Post by Andreas Kohlbach

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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.

Doch, die Bequemlichkeit das zu verwenden, was bereits installiert ist. Bei
Dir, mir und vielen andern hier wird das anders sein. Die Masse bevorzugt
aber nun mal die Bequemlichkeit.

[...]

Post by Andreas Kohlbach
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.

"Kaum" ist mit zu relativ.

Und ich halte irgendeine Verschlüsselung, und wenn es rot13 ist, besser
als keine.

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

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

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.

Würde man sich aber auf die reine Verschlüsselung beschränken
(Vertraulichkeit absichtlich unterschlagen), bleibe ich dabei, dass das
Anbieter fast vollständig automatisieren könnten.

[Helmut Waitzmann]

Post by Andreas Kohlbach

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach

Post by Andreas Kohlbach
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!“

Post by Andreas Kohlbach

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach

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

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

[Arno Welzel]

Andreas Kohlbach:

[...]

Post by 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".

Post by Andreas Kohlbach
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.

[Andreas Kohlbach]

Post by Arno Welzel
[...]

Post by 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".

[Arno Welzel]

Post by Andreas Kohlbach

Post by Arno Welzel
[...]

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

[Andreas Kohlbach]

Post by Arno Welzel

Post by Andreas Kohlbach

Post by Arno Welzel
[...]

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

[Arno Welzel]

Post by Andreas Kohlbach

Post by Arno Welzel

Post by Andreas Kohlbach

Post by Arno Welzel
[...]

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

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

Post by Andreas Kohlbach
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.

[Andreas Kohlbach]

Post by Arno Welzel

Post by Andreas Kohlbach
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.

Ich hatte nie AOL oder T-Online per beigelegter Software konfiguriert,
würde aber vermuten, dass die auch für Windows alles Notwendige
einrichtet. ONU wäre sonst überfordert gewesen.

Post by Arno Welzel

Post by Andreas Kohlbach
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.

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
Installation von Modems/ISDN und TCP/IP wären ~99 % der Klientel
aufgeschmissen gewesen. Sie wären nie ins Internet gekommen. "Dank" AOL
oder T-Online, mit der vollautomatischen Installation, sind sie aber
online gekommen.

Leider. ;-)

Post by Arno Welzel

Post by Andreas Kohlbach
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.

Ich sehe keine Problem, wenn man in der Lage ist, PGP zu
konfigurieren. Das eigentliche Problem scheint also, überhaupt in der
Lage zu sein, das zu können. Siehe "AOL-Problem" in der Annahme, dass die
AOL (oder T-Online) Software auch in Windows Modem bzw. ISDN einrichtet.

Habe ein Video einer AOL-Software Installation für Windows 98 auf
Französisch (auf die Schnelle nichts anderes gefunden) auf

geschaut. Ich nehme an,
dass nichts vorher eingerichtet wird. Die Installation schreibt (man muss
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.

[Arno Welzel]

[...]

Post by Andreas Kohlbach

Post by Arno Welzel
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.

[...]

Post by Andreas Kohlbach
Habe ein Video einer AOL-Software Installation für Windows 98 auf
Französisch (auf die Schnelle nichts anderes gefunden) auf
http://youtu.be/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.

Post by Andreas Kohlbach
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]

Post by Arno Welzel
[...]

Post by Andreas Kohlbach

Post by Arno Welzel
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.
[...]

Post by Andreas Kohlbach
Habe ein Video einer AOL-Software Installation für Windows 98 auf
Französisch (auf die Schnelle nichts anderes gefunden) auf
http://youtu.be/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.

Post by Andreas Kohlbach
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.

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

Ab 3:45 http://youtu.be/s7vURFhNhuw 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]

[...]

Post by Andreas Kohlbach
Habe ein Video einer AOL-Software Installation für Windows 98 auf
Französisch (auf die Schnelle nichts anderes gefunden) auf
http://youtu.be/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.

[Andreas Kohlbach]

Post by Arno Welzel
[...]

Post by Andreas Kohlbach
Habe ein Video einer AOL-Software Installation für Windows 98 auf
Französisch (auf die Schnelle nichts anderes gefunden) auf
http://youtu.be/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.

Dieses Beispiel von mir war nicht optimal, ich fad aber auch die Schnelle
nichts anderes.

Hat jemand hier noch frische Erinnerungen, in den 90ern mal
AOL/T-Online/Compuserve/... über die Software von der CD auf einem
andernfalls nicht für das Internet konfigurierten Windows 95/98 PC
eingerichtet zu haben?

Ich nicht; als ich dann doch mal AOL ausprobierte, hatte ich das schon
eingerichtet.

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)
- Jeder User war Admin (ging nicht anders). Wenn ein User diese Dinge
selbst konfigurieren kann, kann das auch eine (AOL) Software
automatisieren.

[Andreas Kohlbach]

[...]

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

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.

Deswegen gab es bei der Telekom auch umfangreiche Anleitungen, wie man
das macht inkl. der Schritte "DFÜ-Netzwerk installieren" und
<https://www.telekom.de/hilfe/downloads/h_td100.pdf>

Dort wird die *manuelle* Installation beschrieben. Die Suche nach
"T-Online" gab zwar einige Treffer. Die sagten aber etwa, die eigenen
Zugangsdaten von der T-Online CD bereitzuhalten.

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

Bezweifle ich weiter. Hat niemand eine VM, eine Windows 95
Installations-CD (die Registrations-Nummer ist eine beliebige Zahl, deren
Quersumme 7 ist) und AOL-CD bereit, dass man zu eruieren?

[Friedhelm Waitzmann]

Post by 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

Post by Helmut Waitzmann
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>)

Post by Helmut Waitzmann
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

[Stefan Claas]

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

[Arno Welzel]

Post by Stefan Claas

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

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

[Stefan Claas]

Post by Arno Welzel

Post by Stefan Claas

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

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.

Grüße
Stefan

[Stefan Claas]

[...]

Post by Stefan Claas

Post by Arno Welzel
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 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

[Arno Welzel]

On Tuesday, November 23, 2021 at 3:46:13 PM UTC+1, Arno Welzel

[...]

Post by Stefan Claas

Post by Arno Welzel
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.

[Stefan Claas]

Post by Arno Welzel

[...]

Post by Stefan Claas

Post by Arno Welzel
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.

Genau.

Post by Arno Welzel
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

[Arno Welzel]

[...]

Post by Stefan Claas

Post by Arno Welzel
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]

Post by Arno Welzel
[...]

Post by Stefan Claas

Post by Arno Welzel
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?

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

[Stefan Kanthak]

Post by Stefan Claas
Ich mache es kurz und lasse es dann.

Besser so!

Post by Stefan Claas
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!

Post by Stefan Claas
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

[Stefan Claas]

Post by Stefan Kanthak

Post by Stefan Claas
Ich mache es kurz und lasse es dann.

Besser so!

Post by Stefan Claas
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!

Post by Stefan Claas
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?

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

[Volker Delf]

Post by Stefan Kanthak

Post by Stefan Claas
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?

Es gibt doch nichts sichereres als die Ende-zu-Ende Verschlüsselung mit
PGP/INLINE und dem persönlichen Schlüsselaustausch ;-)

mfg Volker

[Arno Welzel]

[...]

Post by Stefan Claas

Post by Arno Welzel
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.

[Friedhelm Waitzmann]

Demonstriere bitte, wie Du eine E-Mail an mich von einem von mir
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]

Post by Friedhelm Waitzmann

Demonstriere bitte, wie Du eine E-Mail an mich von einem von mir
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.

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]

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

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

[Andreas Kohlbach]

Post by Arno Welzel

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

Post by Arno Welzel
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.

[Stefan Claas]

Post by Andreas Kohlbach

Post by Arno Welzel

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

Post by Arno Welzel
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.

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

[Andreas Kohlbach]

Post by Stefan Claas

Post by Andreas Kohlbach

Post by Arno Welzel
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.

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

Es wäre aus Zeitgründen fast halbfertig liegen geblieben, als ein Senator
namens Joe Biden es für Uncle Sam einfacher machen wollte, Mailverkehr
abzuhören. Das spornte Zimmermann an, es trotzdem in einen
gebrauchsfähigen Zustand zu bringen.

<https://www.wired.com/2012/12/joe-biden-private-email/>

Allgemein dient es der Verschlüsselung. "Nebenbei" verhindert es damit
MITM, den Biden gerne genutzt hätte.

Post by Stefan Claas
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.

Vielleicht "zwischen zwei Punkten"? Wo genau Peter, Paul oder Mary
abhören wollen, ist bei einer eingekapselten Verschlüsselung (auch über
eine Klartext-Schnittstelle) nicht von Belang.

Anderes Beispiel. Ich nutze den Multi-Messenger Pidgin. Der kann
verschiedene Protokolle. Einige sind über den ganzen Transportweg
verschlüsselt, andere nicht. Hier gibt es u.a. das Plugin "Off-the-Record
(OTR) Messaging". Wenn mein Gegenüber das kann, verschlüsselt mein Client
meine Nachrichten, sendet sie (und ich brauche mir keine Sorgen zu
machen, ob die Verbindung nach meinem Client verschlüsselt ist oder
nicht), und der Client des Empfängers entschlüsselt sie.

[Arno Welzel]

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

Post by Arno Welzel
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.

[Helmut Waitzmann]

Post by Andreas Kohlbach
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 <***@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.

Post by Andreas Kohlbach
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.

[Andreas Kohlbach]

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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
meines Schlüssels unverfälscht genannt bekommt oder er sich des
Web's of Trust bedienen kann.

Dann müsste der Benutzer gefragt werden. Ich habe das hier auch, wenn ich
an jemand antworte, von dem ich mehrere Email-Adressen habe.

Post by Helmut Waitzmann

Post by Andreas Kohlbach
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.

Worin liegt der Unterschied?

[Enrik Berkhan]

Post by Andreas Kohlbach

Post by Helmut Waitzmann
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.

[Andreas Kohlbach]

Post by Enrik Berkhan

Post by Andreas Kohlbach

Post by Helmut Waitzmann
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.

Danke.

[Helmut Waitzmann]

Post by Andreas Kohlbach

Post by Enrik Berkhan

Post by Andreas Kohlbach

Post by Helmut Waitzmann
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.

Danke.

Schau noch mal im Beispiel aus der Nachricht (mit Message‐Id
<83tuh4c1ua.fsf_-***@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.

[Helmut Waitzmann]

Post by Andreas Kohlbach

Post by Helmut Waitzmann
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
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.

[Andreas Kohlbach]

Post by Andreas Kohlbach

Post by Helmut Waitzmann
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
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
___ 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.

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

***@gmx.net

und

***@freenet.de

haben, fragt mutt, welche der vorname.nachname genommen werden soll.

[Helmut Waitzmann]

Post by Andreas Kohlbach

Post by Helmut Waitzmann

Post by Andreas Kohlbach

Post by Helmut Waitzmann
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
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
___ 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.

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
und
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 <***@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 <***@xoxy.net>,
zu der es keinen E‐Mail‐Anbieter gibt, der den passenden Schlüssel
kennt, ging.

[Andreas Kohlbach]

Post by Helmut Waitzmann

Post by Andreas Kohlbach

Post by Helmut Waitzmann

Post by Andreas Kohlbach

Post by Helmut Waitzmann
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
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
___ 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.

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
und
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
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
der es keinen E‐Mail‐Anbieter gibt, der den passenden Schlüssel kennt,
ging.

Du fragtest, wer wen im Zweifel (mehrere mögliche Schlüssel können
infrage kommen) fragt. Als Beispiel hatte ich meinen Mailer genannt, der
in diesem Fall nachfragt.

Genauso würde ein Webinterface, was sonst transparent für den User
verschlüsselt, dann doch nachfragen. Das würde der einzige Fall sein, der
mir gerade einfällt, wo das System den Nutzer doch fragt.

[Christian Garbs]

Mahlzeit!

Ich war beispielsweise früher mit der E‐Mail‐Adresse
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?

[Chr. Maercker]

Post by Andreas Kohlbach
"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.

[Christian Garbs]

Mahlzeit!

Post by Chr. Maercker
... 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

[Chr. Maercker]

Post by Christian Garbs
Mahlzeit!

Post by Chr. Maercker
... 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. ;-)

[Chr. Maercker]

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

[Christian Garbs]

Mahlzeit!

Post by Helmut Waitzmann
Zunächst:  Ich schlage den Umzug zu de.comp.security.misc vor, weil
mir das ein vom Mailer‐Programm unabhängiges Thema zu sein scheint.

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.

Wenn ein Schlüsselpaar einem Anwender (und nicht etwa einem Gerät,
einer Telefonnummer oder einer E‐Mail‐Adresse) zugeordnet sein soll,
muss der Anwender den Fingerprint selber prüfen.  Das geht ohne
Zutun des Anwenders nicht.
Wenn E‐Mail‐Verschlüsselung (und Signierung) ohne Zutun des
Anwenders läuft, macht er die Schlüsselverwaltung nicht mehr selber.
Beispielsweise könnten die Ver‐ und Entschlüsselung und die
Signatur‐Erstellung und ‐Prüfung vom E‐Mail‐Provider vorgenommen
werden, damit sich der Anwender nicht mehr darum kümmern muss.  Das
bedeutet, dass der private Schlüssel beim E‐Mail‐Provider liegen
muss.

Hier kann man glaube ich abkürzen und sagen, dass das grob¹ auf TLS
zwischen den beteiligten Mailservern hinausläuft, also ungefähr den
Status quo, den es zu verbessern gilt ;-)

Gruß
Christian

¹ Das bisherige Server-Zertifikat entspräche dann vielleicht einem
Intermediate, unter dem pro Mailadresse ein Zertifikat generiert wird.
Da der Empfänger-Server aber maximal das Intermediate "kennt" (falls
es ihm sein Admin manuell eingetragen hat), bleibt alles beim alten.