Benutzer:W01f: Unterschied zwischen den Versionen

Aus C3D2
Zur Navigation springen Zur Suche springen
K (Änderung 24707 von W01f (Diskussion) rückgängig gemacht.)
Zeile 62: Zeile 62:


==== Welche Probleme sind noch offen ====
==== Welche Probleme sind noch offen ====
Wenn an Teilnehmer per BCC gesendet wird, kann man die IDs wahlweise verbergen. Dann haben die Empfänger ein Problem sobald sie mehr als nur einen Schlüssel nutzen, denn das Mailprogramm kann den Schlüssel nicht autmatisch auswählen und der Nutzer muss dies gezielt tun.


Es gibt Nutzer, die aus Trotz keine Öffentlichen Schlüssel weitergeben möchten. Denen kann ich auch nicht helfen.
Es gibt Nutzer, die aus Trotz keine Öffentlichen Schlüssel weitergeben möchten. Denen kann ich auch nicht helfen.

Version vom 21. Februar 2017, 23:10 Uhr

about me

  • Nichtraucher
  • gut darin blöde Fragen zu formulieren

Interessen

  • ein bisschen coden/scripten und viel debuggen/absichern - bin aber kein Guru in irgendwas
  • ITSec,DSch (eher esoterisch mit Planung denn konkret mit Umsetzung)
  • Bitcoin
  • (La)TeX

Warum bin ich hier?

plain: Ich erhoffe mir einiges zu lernen und mit einigermaßen Gleichgesinnten Kontakt zu haben und gemeinschaftlich mehr als allein zu erreichen…

War das Absicht?

"Deine letzten E-Mails an $Mailingliste waren verschlüsselt, so dass nicht jeder sie lesen konnte. War das Absicht?"

Ja, ich verschlüssle seit einer Weile an Listen sofern es nicht explizit offene Informationen sind oder große Eile bei der Weitergabe von mir gewünscht ist. Das ist leider noch nicht so trivial wie man sich das wünscht. Unter anderem weil Nutzer einer Mailingliste nicht einfach eine Liste von Fingerabdrücke der Empfänger erhalten können.

Wenn man immer fordert möglichst viel zu verschlüsseln und dann eigentlich nur offene Mails durch die Kante schiebt, fand ich das sehr inkonsequent. Und deshalb verfolge ich einfach: Verschlüsseln wir doch was geht.

Dazu habe ich einfach die Empfängerregeln (per-recipient rules) eingesetzt. Genauer in der Datei pgprules.xml für Icedove (bzw. Thunderbird) weil group in der Datei gpg.conf mir – in Verbindung mit den dann notwendigen (lokalen) Signaturen – zu anstrengend war. Letzteres ist aber insbesondere eine Option für alle Programme die den Agent noch so verwenden. Ich glaube so kann z.B. Daniel mit seinem Emacs trotz fehlender/falschen E-Mail Adresse in einer UID komfortabel Menschen erreichen.

Sollte jemand mal wissen wollen an wen eine verschlüsselte Mail alles ging, kann er sich die Päckchen mit KeyIDs auflisten lassen:

gpg2 --list-packets /tmp/file.eml

Und ja, mir ist bewusst, dass diese Möglichkeit noch nicht sonderlich bequem ist und mancher glaubt offene Listen sollten offen sein. Andere rechnen mir vor, dass das nicht skaliere weil die Größe der Mails mit jedem weiteren Empfänger um x KB steigt. Naja, wenn ich sehe wie das Web MB-weise verhunzt wird, ist das für mich kein ausschlaggebendes Argument. Vor nicht allzu langer Zeit haben Serverbetreiber bezüglich TLS noch argumentiert: "Ich hoste nur Informationen oder scheue die höheren Betriebskosten." Das will man ja auch nicht.

Allerdings hat mein Vorgehen auch erwünschte Effekte:

  • manche Menschen verlängern abgelaufene Schlüssel
  • andere Menschen legen sich Schlüssel zu
  • oder senden mir ihren öffentlichen ob der Abneigung gegen Keyserver
  • … also Menschen nutzen PGP und ihre Schlüssel
  • mach einer probiert sogar PEP oder K9/PEP für Android aus
  • der Wunsch nach Smartcards für den Einsatz auf fremden und mobilen Geräten steigt :D
  • Entschleunigung von Mails
  • Bugs in Enigmails per-recipient rules (beim editieren) wurden gefixt \o/


Bis die Tage.

Warum nicht Schleuder?

Top Antwort: Weil dann der Server an die Empfänger verschlüsselt und nicht der Sender.

Auch: Es wird an den Server verschlüsselt, dort liegen die Informationen im Klartext vor. Das wiederspricht dem Ansatz Ende-zu-Ende.

Oder: Beim Verfahren, sind die Schlüssel grundsätzlich nur dem Server bekannt. Die Idee ist aber mehr Verschlüsselung (auch abseits der Mailingliste zu verbreiten. Wenn mehr Menschen Schlüssel haben und die Software eingerichtet wurde, wird die Verwendung damit antrainiert und nach der Adoption die Akzeptanz gesteigert.

Was kommt als nächstes?

"Willst du echt Leute zu ihrem Glück zwingen?"

Machmal ja. D.h. ich nutze PGP im Zweifel auch mit symmetrischer Verschlüsselung um Menschen mit Informationen, die sie brauchen zum Einsatz zu bewegen. Das kann der- oder diejenige als Zwang wahrnehmen und ich lebe gut damit.

Und mancher stehen hin und wieder vor der Herausforderung, dass ich PGP oder sogar eine Assurance für CAcert voraussetze.

Welche Probleme sind noch offen

Wenn an Teilnehmer per BCC gesendet wird, kann man die IDs wahlweise verbergen. Dann haben die Empfänger ein Problem sobald sie mehr als nur einen Schlüssel nutzen, denn das Mailprogramm kann den Schlüssel nicht autmatisch auswählen und der Nutzer muss dies gezielt tun.

Es gibt Nutzer, die aus Trotz keine Öffentlichen Schlüssel weitergeben möchten. Denen kann ich auch nicht helfen.

Es gibt Nutzer, die nicht wissen was da gerade für ein komischer Spam auf der ML aufschlägt. Die fragen zumeist und sind ein Grund für diese Hinweise hier. Schöner wäre eine Lösung durch Multipart-Mails, sodass ein Klartext Part angezeigt wird wenn der Empfänger kein PGP hat. Sofern hierfür jemand eine gute Lösung oder einen handhabbaren Weg kennt, bin ich ganz Ohr.

Keylists

Mal als Beispiel der am 08.12.2016 gewählte Vereinsvorstand; andere Listen könnt ihr euch entsprechend zusammenstellen:

pgprules.xml (f. Enigmail, hier Version 1.9.6)
<pgpRule email="{vorstand@c3d2.de}" keyId="
0xA5EE826D645DBE35F9B0993358512AE87A69900F,
0x1165F2971CCAF1A2E0F2A20E514788F2D7740B69,
0xFB679EB2D2FF4ADE24CACC7D5EF26D9AB6871342
" sign="2" encrypt="2" pgpMime="2" negateRule="0"/>
~/.gnupg/gpg.conf
group vorstand@c3d2.de = 0xA5EE826D645DBE35F9B0993358512AE87A69900F 0x1165F2971CCAF1A2E0F2A20E514788F2D7740B69 0xFB679EB2D2FF4ADE24CACC7D5EF26D9AB6871342