Benutzer:W01f: Unterschied zwischen den Versionen

Aus C3D2
Zur Navigation springen Zur Suche springen
K (Verschlüsseln von Mailinglisten)
K (Korrekturen)
Zeile 18: Zeile 18:
: "Deine letzten E-Mails an $Mailingliste waren verschlüsselt, so dass nicht jeder sie lesen konnte.  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 gewünscht ist. Das ist leider noch nicht so trivial wie man sich das wünscht. Unter anderem weil Nutzer einer ML nicht einfach eine Liste von Fingerprints der Empfänger erhalten können. Auch ist die anzahl der zu pflegenden Schlüssel schnell anstrengend. Und man muss bei abgelaufenen Schlüsseln Empfänger manuell entfernen bzw. zur Verlängerung oder bei Zurückziehen dann zur Neuausstellung auffordern.
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.
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.
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 pgprules.xml für Icedove weil group in der gpg.conf mir – in Verbindung mit den dann notwenidgen (lokalen) Sigaturen – 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.
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:
Sollte jemand mal wissen wollen an wen eine verschlüsselte Mail alles ging, kann er sich die Päckchen mit KeyIDs auflisten lassen:
Zeile 29: Zeile 29:
gpg2 --list-packets /tmp/file.eml
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 garkein Argument. Vor nicht allzu langer Zeit haben Serverbetreiber bezüglich TLS noch argumentiert: Ich hoste nur Informationen und scheue die höheren Betriebskosten.
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:
Allerdings hat mein Vorgehen auch erwünschte Effekte:
Zeile 40: Zeile 40:
* der Wunsch nach Smartcards für den Einsatz auf fremden und mobilen Geräten steigt :D
* der Wunsch nach Smartcards für den Einsatz auf fremden und mobilen Geräten steigt :D
* Entschleunigung von Mails
* Entschleunigung von Mails
* Bugs in Enigmails per-recipient rules wurden gefixt \o/
* Bugs in Enigmails per-recipient rules (beim editieren) wurden gefixt \o/
 
 
Bis die Tage.


==== Was kommt als nächstes? ====
==== Was kommt als nächstes? ====

Version vom 11. Oktober 2016, 09:17 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.

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.