die raven homepage
Anonym Mailen und Posten mit Remailern unter Linux

Version 1.4

Inhalt
Vorwort

Diese Anleitung beschreibt die Verwendung des Mixmaster und Mixminion Remailers als Client zur Versendung anonymer E-Mails und Usenet Postings.
Mixmaster verwendet das Type II Protokoll, der Nachfolger mit Type III Protokoll namens Mixminion ist in der Entwicklung. Mixminion und seine Anwendung wird weiter unten beschrieben.

Für Mixmaster wird das ncurses Menü verwendet, damit auch Anfänger einen leichten Einstieg haben. Bei Mixminion ist eine Bedienung über Kommandos in der Konsole oder Scripte, die man in seinen MUA einbinden kann, nötig. Zudem gibt es für Linux keine grafischen Remailer- und Nymserverclients.
In der Anleitung wird für Mixmaster ausschließlich der Editor vi benutzt. Wer einen andere Editor verwendet, muss selbst die Abläufe auf seinen Editor übertragen.

Außerdem soll nach Möglichkeit ein Nickname in Form "Nickvorname Nicknachname" verwendet werden, um etwaige Killfilter zu umgehen (was natürlich nicht die Killfilter nach E-Mail Adresse des Remailers ausschaltet).
In welcher Form der Anwender von Mixmaster den From: Header beeinflußen kann, ist abhängig von der Konfiguration, die der Administrator des Mixmasterremailers festgelegt hat. Wie From: Header von den einzelnen Remailern gehandhabt werden, muss der Anwender über die jeweilige Remailer Konfiguration in Erfahrung bringen, die man z. B. über Remailer Thesaurus Listen einsehen kann. Auf der Seite From Headers kann man nachsehen, welche From: Header die Remailer setzen, bzw. welche Remailer benutzerdefinierte From: Header weiterreichen.

Bei Mixminion kann man direkt beim Versand über eine Option im From: Header einen Nickname unterbringen, aber niemals eine vollständige E-Mail Adresse. Auch bei Mixminion wird die Verwendung eines Nicknames nicht von allen Mixremailern unterstützt. Welcher Mixminion Remailer einen Nickname im From: Header unterstützt ist in der Anzeige der aktiven Remailer ablesbar.

Remailer "Netiquette"

Remailer und die Möglichkeit des Versands anonymer Nachrichten dienen dazu, frei von Verfolgung und Beobachtung die eigene Meinung zu äußern bzw. miteinander zu kommunizieren und basieren auf der Arbeit und der Freiwilligkeit der Remailer Betreiber. Deshalb muss vom Benutzer dieser Dienste ein gewisses Maß an Verantwortung und Selbstkontrolle an den Tag gelegt werden. Zahlreiche Verstöße – besonders im Usenet – zeugen davon, dass einige Versender anonymer Nachrichten dies vermissen lassen.

Damit schaden sie den Remailer Betreibern, die fälschlicherweise für die Äußerungen verantwortlich gemacht werden, dem Dienst selbst und denjenigen, die Remailer verantwortungsvoll benutzen. Denn wenn aufgrund des Missbrauchs anonymer Remailer E-Mail und Usenet Benutzer Nachrichten, die von Remailern stammen, automatisch und unterschiedslos ausfiltern, wird die Benutzung von Remailern für alle Anwender sinnlos und anonyme Nachrichten mit wichtigen und sinnvollen Inhalten werden nicht mehr gelesen. Deshalb sollten folgende Regeln im eigenen Interesse befolgt werden:

  1. In weiten Teilen des Usenets und für E-Mail gilt, ob sinnvoll oder nicht, die Realnamenspflicht. Anonyme Remailernachrichten sollten nur aus gegebenem Anlass (Verfolgung, Beobachtung, ungerechtfertigte Sanktionen, Profiling) verwendet werden und nicht für jedes Posting. Alternativ kann ein Versand auch pseudonym und nicht anonym erfolgen.
  2. Auch bei anonymen Usenet Postings und E-Mails gilt es, die allgemeinen Regeln zu beachten - keine Crosspostings in mehr als 2 Newsgroups, keine Dateianhänge in Non-Binary Newsgroups, kurze Signaturen, Zeilenumbruch/Leserlichkeit usw.
  3. Remailer dürfen nicht zum Versand von Drohungen, Beleidigungen, Spam und Rufschädigungen verwendet werden. Dementsprechend ist der Inhalt höflich und sachlich zu halten. Bei Verfehlungen kann man sich genauso entschuldigen, wie man das bei normalen Nachrichten tun würde.
  4. Anonyme Nachrichten, die sich eines gefälschten From: Absenderheaders bedienen, bzw. über einen Remailer versendet werden, der solche Header zuläßt, dürfen unter keinen Umständen die Absenderadresse eines realen E-Mail Accounts verwenden. Der gefälschte From: Header ist möglichst so zu gestalten, dass für den Empfänger oder Leser mindestens nach dem zweiten Blick erkennbar ist, dass es sich um keine reale, zustellbare E-Mail Adresse handelt (z. B. durch Begriffe wie "fake", "invalid", "noreal", "intern" in der E-Mail Adresse).
  5. Flooding von Newsgroups und E-Mail Accounts sind zu unterlassen.
  6. Gibt man über Remailer anonyme Nachrichten vertraulichen Inhalts weiter, ist die Anonymität des ursprünglichen Absenders genauso zu wahren wie die Eigene und vor der Weitergabe die Erlaubnis des ursprünglichen Absenders einzuholen.
Mixmaster
Voraussetzungen

Bei den meisten Distributionen sind außer Mixmaster (bei Debian enthalten) meistens alle Komponenten enthalten, ansonsten bei den obigen Quellen besorgen oder für RPM's bei Rpmfind.net.
PCRE und zlib finden sich auch als Source im Mixmasterarchivverzeichnis und können während der Installation kompiliert und installiert werden.

Mixmaster installieren
  1. Kopieren von mixmaster-version.tar.gz in ein temporäres Verzeichnis und mit "tar -xzf mixmaster-version.tar.gz" entpacken.
  2. Mit "cd mixmaster-version" in das Verzeichnis der entpackten Quellen wechseln.
  3. ./Install
  4. Das Installationsverzeichnis bei der Abfrage mit /home/user/.mix angeben.
  5. Die Frage Do you want to set up a remailer? [n] mit Enter bestätigen.
  6. Bei einer OpenSSL Version ohne IDEA Unterstützung erfolgt eine Warnung. Die Installation wird mit
    Continue anyway? [y] Enter
    weiter fortgesetzt.
  7. "Client installation complete" meldet uns, dass Mixmaster erfolgreich installiert wurde.

Wenn wir jetzt im Installationsverzeichnis './mixmaster' eingeben, sollte das folgende Menü erscheinen:

Mixmaster Eingangsmenü
Die Mixmaster Konfigurationsdatei mix.cfg
SENDMAIL /pfad/sendmail -t Versand der Mixmaster Nachrichten über den eigenen, lokalen Mailserver.
SENDMAIL outfile Mixmaster Nachrichten werden zum nachträglichen Versand mit einem anderen Mailclient als lokale Dateien im pool Verzeichnis abgespeichert.
SMTPRELAY
HOSTNAME
SMTPUSERNAME
SMTPASSWORD
mail.server.tld
hostname
Username
Passwort
Statt der Übergabe an den eigenen Mailserver oder Abspeicherung werden die Nachrichten direkt an den Mailserver des Providers übergeben.
Zur Zeit wird nur AUTH LOGIN unterstützt.
NAME Vorname Nachname Realname für nicht-anonyme Versendungen
ADDRESS user@domain.tld Reale E-Mail Adresse für nicht anonyme Versendungen
CHAIN *,*,remailer Die Reihenfolge und Anzahl der verwendeten Remailer der Remailerkette.
* Mixmaster wählt zufällig einen Remailer aus,
remailer Mixmaster benutzt den manuell vom User bestimmten Remailer.
Sollen Attachments versendet werden, muss mindestens ein zufällig ausgewählter Remailer '*' Bestandteil der Kette sein!
NUMCOPIES n Anzahl der Kopien, die Mixmaster von der gleichen Nachricht versendet,
sollte mindestens auf 2 stehen.
DISTANCE 2 Wie viele andere Remailer zwischen einem Remailer und seiner 2. Verwendung innerhalb der gleichen Kette liegen müssen.
MINREL n Die Uptime (%), die alle verwendeten Remailer *mindestens* aufweisen müssen.
RELFINAL n Die Uptime (%), die der letzte Remailer der Kette aufweisen muss.
Der Wert wird überschrieben, wenn man den letzten Remailer selbst bestimmt, z. B. *,*,tonga.
Je größer MINREL und RELFINAL sind, desto kleiner der Pool der möglichen Remailer, die verwendet werden können.
MAXLAT nh Maximale Stundenanzahl (Latency Time), die ein verwendeter Remailer die Nachricht vor der Weiterversendung aufbewahren darf.
PGPPUBRING
PGPSECRING
/pfad/pubring.gpg
/pfad/secring.gpg
Vollständige Pfade zum öffentlichen und geheimen OpenPGP Schlüsselring.
MAILtoNEWS Standard: mail2news@nym.alias.net
mail2news@shinn.net
mail2news@dizum.com
Das zu verwendende Mail2News Gateway, über das der letzte Remailer das Posting in die Usenet Newsgroup absetzt.
Remailerstatistiken und -schlüssel

Damit Mixmaster arbeiten kann, benötigt er möglichst aktuelle Daten zur Erreichbarkeit, unterstützten Funktionen und Schlüssel der zu verwendenden Remailer. Zu diesem Zweck werden so genannte "Pinger" Programme eingesetzt, die automatisch die Werte für jeden Remailer ermitteln und anfordern.
Bei der Installation wird ein Standardsatz dieser Dateien im Mixmasterverzeichnis abgelegt:

  • mlist.txt
    Liste der Mixmaster Remailer mit Uptime, Latency Time
  • pubring.asc
    Schlüsselring der Cypherpunk Remailer
  • pubring.mix
    Schlüsselring der Mixmaster Remailer
  • rlist.txt
    Liste der Cypherpunk Remailer mit Uptime, Latency Time
  • type2.list
    Liste der Mixmaster Remailer mit Remailer E-Mail Adresse, Schlüssel-ID, Mixmasterversion, Kürzel der unterstützten Funktionen.
    Die Datei kann man sich mit "mixmaster -T" anzeigen lassen.

Man kann sich entweder selbst einen Pinger wie Echolot installieren, oder es werden die Daten benutzt, die andere Pinger bereits gesammelt und auf Websites bereitgestellt haben. Letzteres ist einfacher und belastet das Netzwerk nicht.

Statistik Sites
  • All Pingers Index [TXT]
    Auflistung aller Pinger URL's, über die Remailerstatistik- und keydaten heruntergeladen werden können.
    Die gleiche Auflistung als HTML Übersicht.
  • Remailer-Thesaurus
    Remailername und E-Mail Adresse, Traffic, Konfiguration, Kurzhilfe, Schlüssel, verarbeitete Nachrichten, Administratorschlüssel

Man kann auch nähere Informationen zu einem Remailer per E-Mail einholen.
Dazu schreibt man eine E-Mail an den Remailer (Adressen werden z.B. mit 'mixmaster -T' angezeigt) und gibt als Subject ein:

  • remailer-help - Kurzhilfe zur Bedienung
  • remailer-conf - aktuelle Konfiguration des Remailers
  • remailer-stats - Anzahl verarbeiteter Messages der letzten 24h/Monate
  • remailer-key - Remailerschlüssel
Aktualisierung der Statistiken

Zur regelmäßigen Aktualisierung der Statistikdateien kann man sich z. B. die Dateien per wget herunterladen.
Dazu legt man eine Datei staturls an, in die man die URL's aus dem All Pingers Index einträgt, eine URL pro Zeile.

Beispiel statsurl

http://www.noreply.org/echolot/rlist.txt
http://www.noreply.org/echolot/mlist.txt
http://www.noreply.org/echolot/pgp-all.asc
http://www.noreply.org/echolot/pubring.mix
http://www.noreply.org/echolot/type2.list

Für wget legt man ein Shellscript statget mit folgendem Inhalt an und macht es mit chmod u+x ausführbar

#!/bin/sh
MIX=~/Mix

wget -b -nv -t 3 -N -r -w 10 --random-wait -nd -nH -P $MIX -i $MIX/staturls -o $MIX/wgetlog

und legt als User einen cron Eintrag mit crontab -e an, der z. B. alle 6 Stunden die Statistiken aktualisiert:

0 0-23/6 * * * /home/user/Mix/statget
Mixmaster Statistikanzeige

Ausgabe der Mixmasterstatisitk mit "cat ~/Mix/mlist2.txt | less"
Vorlagen

Die folgenden Vorlagen in das Mixmaster Programmverzeichnis ablegen
Wie man sieht, gehört immer eine Leerzeile zwischen Body und Header.

E-Mail (Vorlage 'email')

From: 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Body

Usenet Posting (Vorlage 'usenet')

From: 
Followup-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Body

Die Followup-To: Zeile wird nur bei einem Crossposting benötigt, oder wenn man Antworten auf das Posting in eine andere Newsgroup umleiten möchte, kann also ansonsten bei der Bearbeitung der Nachricht gelöscht werden.
To: und Subject: fehlen, weil Mixmaster die Angaben am Anfang der Erstellung einer Nachricht selbst abgefragt.

Mixmaster mit geladener E-Mail Vorlage

Mixmaster mit geladener E-Mail Vorlage
Nachrichten erstellen

Durch Eingabe von buchstabe) löst man bestimmte Funktionen, Untermenüs oder Aktionen aus.

Anonyme E-Mail mit Nickname schreiben
  1. In der mix.cfg legt man entweder mit CHAIN *,*,Remailer einen ständigen, letzten Remailer fest, der From: Nick Name unterstützt, oder man ändert die Mixmasterkette während der Erstellung selbst ab (s. u.).
  2. m)ail
    To: E-Mail Adresse des Empfängers eintragen
    Subject: Subject eintragen
    • Mit pgp encry)ption veranlasst man die OpenPGP Verschlüsselung des Textkörpers an den Empfänger (dazu muss sich der öffentliche Schlüssel des Empfängers im öffentlichen Schlüsselring des OpenPGP Programmes befinden)

      Bei zusätzlicher OpenPGP Verschlüsselung wird von Mixmaster der From: und Subject: Header in den Ciphertext übernommen, treten also bis zur Entschlüsselung durch den Empfänger nicht in Erscheinung. Sollen die Header erhalten bleiben, muss der Textkörper zuvor erstellt, mit dem OpenPGP Programm verschlüsselt und anschließend in die Mixmasternachricht als Body eingefügt werden.
    • Mit c)hain kann man die in der mix.cfg vorgegebene Mixmasterkette abändern.
      Nach Anklicken der Taste c gelangt man in ein Menü, in dem man für einen beliebigen Remailer * drückt oder für einen bestimmten Remailer den Buchstaben, der dem Remailernamen vorangestellt ist.
      Kommata müssen nicht eingegeben werden.
    • Mit r)edundancy kann man die Anzahl der Kopien der Nachricht verändern.
    • Mit s)ubject kann man das Subject ändern.
    • Mit d)estination kann man die E-Mail Adresse ändern.
  3. e)dit message ruft den Texteditor auf.
  4. Mit 2x dd die Leerzeilen löschen, so dass sich der Cursor auf dem 'S' der Subject: Zeile befindet.
  5. Mit Eingabe von :r email wird die E-Mail Vorlage geladen.
  6. Mit i wird danach in den Eingabemodus gewechselt.
  7. From: Zeile ausfüllen und ab Body den Text der Nachricht schreiben.
  8. Mit ESC wird die Eingabe verlassen.
  9. Mit :wq wird die Nachricht für den Versand gespeichert, oder mit :q! abgebrochen.
    • m)ail message speichert die Nachricht zur Versendung im Pool Verzeichnis.
    • e)dit message ruft wieder den Texteditor auf.
    • Über f)ile kann man der Nachricht ein Attachment anhängen.
    • Mit q)uit wird Mixmaster beendet und der Nachrichtenversand abgebrochen.
  10. d)ummy message erzeugt Dummynachrichten zur Erschwernis von Trafficanalysen.
  11. s)end messages from pool versendet die Nachricht über den Mailserver, der in der mix.cfg angegeben wurde.
Anonymes Usenet Posting schreiben
  1. In der mix.cfg legt man entweder mit CHAIN *,*,Remailer einen ständigen, letzten Remailer fest, der From: Nick Name unterstützt, oder man ändert die Mixmasterkette während der Erstellung selbst ab (s. u.)
  2. p)ost to Usenet
    Newsgroups: Newsgroup1[,Newsgroup2,Newsgroup3] # keine Leerzeichen in der Aufzählung
    Subject: Subject eintragen
    • Mit c)hain kann man die in der mix.cfg vorgegebene Mixmasterkette abändern.
      Nach Anklicken der Taste c gelangt man in ein Menü, in dem man für einen beliebigen Remailer * drückt oder für einen bestimmten Remailer den Buchstaben, der dem Remailernamen vorangestellt ist.
      Kommata müssen nicht eingegeben werden.
    • Mit r)edundancy kann man die Anzahl der Kopien der Nachricht verändern
    • Mit s)ubject kann man das Subject ändern
    • Mit d)estination kann man die Newgroup(s) ändern
  3. e)dit message ruft den Texteditor auf.
  4. Mit 2x dd die Leerzeilen löschen, so dass sich der Cursor auf dem 'S' der Subject: Zeile befindet.
  5. Mit Eingabe von :r usenet wird die Posting Vorlage geladen.
  6. Wird die Followup-To: Zeile nicht benötigt, den Cursor auf die Zeile setzen und mit dd löschen.
  7. Mit i wird danach in den Eingabemodus gewechselt.
  8. From: und ggf. Followup-To: Zeile ausfüllen und ab Body den Text des Postings schreiben.
  9. Mit ESC wird die Eingabe verlassen.
  10. Mit :wq wird die Nachricht gespeichert, oder mit :q! abgebrochen.
    • m)ail message speichert die Nachricht zur Versendung im Pool Verzeichnis.
    • e)dit message ruft wieder den Texteditor auf.
    • Über f)ile kann man der Nachricht ein Attachment anhängen.
    • Mit q)uit wird Mixmaster beendet und der Nachrichtenversand abgebrochen.
  11. d)ummy message erzeugt Dummynachrichten zur Erschwernis von Trafficanalysen.
  12. s)end messages from pool versendet die Nachricht über den Mailserver, der in der mix.cfg angegeben wurde.
Anonyme Usenet Reply erstellen

Um ein Reply Posting zu erstellen, dass sich an die richtige Stelle im Thread einfügt, müssen wir eine zusätzliche References: Zeile angeben, die die Message-ID's der Nachrichten aufnimmt, auf die Bezug genommen werden soll. Das Subject des Postings wird übernommen.

Beispiel

Wenn wir auf ein Posting antworten, dem bereits zwei Postings vorangegangen sind, enthält das Posting, auf das wir antworten wollen

  1. eine eigene Message-ID Zeile in der Form
    Message-ID: <posting3@domain.tld>
  2. eine References Zeile in der Form
    References: <posting1@domain.tld> <posting2@domain.tld>
In unserem Reply muss dann eine References: Zeile stehen in der Form
References: <posting1@domain.tld> <posting2@domain.tld> <posting3@domain.tld>

Deshalb ist in diesem Fall etwas mehr Handarbeit angesagt.

  1. Das Posting wird aus dem Newsreader als Datei in das Mixmaster Verzeichnis gespeichert.
  2. p)ost to Usenet
    Newsgroups: Newsgroup
    Subject: leer lassen und mit ENTER bestätigen
  3. e)dit message ruft den Texteditor auf.
  4. Mit 3x dd die Leerzeilen und die Subject: Zeile löschen, so dass sich der Cursor auf dem 'N' der Newsgroups: Zeile befindet.
  5. Mit Eingabe von :r posting wird die gespeicherte Postingdatei geladen.
  6. Nun setzen wir auf jede Zeile, die nicht benötigt wird, den Cursor und löschen sie mit Eingabe von dd.
    Die From:, Subject:, Message-ID:, References:, Mime-Type:, Content-Type: und Content-Transfer-Encoding: Zeilen lassen wir unberührt.
  7. Den Cursor in die Message-ID: Zeile setzen und 1x yy drücken.
  8. Den Cursor in die References: Zeile setzen und 1x p drücken - damit haben wir die Message-ID Zeile unter die References: Zeile kopiert.
  9. Nun die überzählige Message-ID Zeile, die vor der References: Zeile steht mit dd löschen.
  10. Mit i in den Eingabemodus wechseln und hinter der letzten Message-ID der References: Zeile alle Zeichen löschen, bis die letzte Message-ID in der oben angegebenen Form in die References: Zeile gerückt ist.
  11. From: durch den eigenen Nicknamen abändern und den Body editieren. Wie immer nicht vergessen, eine Leerzeile zwischen Header und Body zu lassen.
  12. Mit ESC wird die Eingabe verlassen.
  13. Mit :wq wird die Nachricht gespeichert, oder mit :q! abgebrochen.
    • m)ail message speichert die Nachricht zur Versendung im Pool Verzeichnis.
    • e)dit message ruft wieder den Texteditor auf.
    • Über f)ile kann man der Nachricht ein Attachment anhängen.
    • Mit q)uit wird Mixmaster beendet und der Nachrichtenversand abgebrochen.
  14. d)ummy message erzeugt Dummynachrichten zur Erschwernis von Trafficanalysen.
  15. s)end messages from pool versendet die Nachricht über den Mailserver, der in der mix.cfg angegeben wurde.
Mixmaster Aktionen für Sylpheed-Claws

Da es keinen eigenständigen, grafischen Mixmaster Client unter Linux gibt und ich Sylpheed-Claws als MUA einsetze, habe ich mir für S-C vier Aktionen bzw. vier Scripte mit Xdialog Eingaben überlegt, mit denen man relativ komfortabel aus dem S-C Editor heraus E-Mails per Mixmaster versenden kann.
Das /tmp Verzeichnis sollte dabei auf einem Dateisystem ohne Journal liegen, damit sichergestelt ist, dass wirklich keine Spuren auf dem Rechner verbleiben.

Ich lasse Mixmaster die Mixmasternachrichten an den lokalen Mailserver Postfix weiterleiten, der sie per TLS und Relayhost an den Mailprovider ausliefert, der sie an den ersten Remailer weitersendet.
Der Schönheitsfehler: S-C unterstützt (noch) keine Variablen in Aktionen für die Inhalte von Headern, so dass man Header manuell eintragen muss.

Beispiel
Aktionsmenü

Im Editor wird nur der Nachrichtentext verfasst und anschließend die gewünschte Aktion ausgewählt.

Headerauswahl

Im Xdialog Fenster werden die erforderlichen Angaben eintragen.

Versand

Ausgabe des Versandvorgangs. Der Versand erfolgt PGP/Inline verschlüsselt an die angezeigte User-ID und mit dem vergebenen Pseudonym, mit drei Dummy Nachrichten und in drei Kopien der eigentlichen Nachricht über den Mixremailer banana, der from: Header zulässt.
Verschlüsselung per GnuPG PGP/Inline mit Mixmasterversand

Menüname:
Mixer/Mixer-GPG

Kommandozeile:

|gpg --no-tty --encrypt -r %u --output /tmp/syltmp ; cd ~/.mixmaster/ ; ./mixmaster -t %u < /tmp/syltmp; shred -fuz /tmp/syltmp

Oder als Script mit Xdialog Eingaben: syl-mixmaster-pgpinline.

Beschreibung:
Verschlüsselt zuerst die Nachricht mit GnuPG.
Die GnuPG Verschlüsselung mit dem GnuPG Schlüssel des Empfängers erfolgt PGP/Inline. Anschließend wird der verschlüsselte Body mit Mixmaster verschlüsselt und versendet. Zum Abschluss wird die temporäre Nachrichtendatei gelöscht.

Verschlüsselung per Mixmaster OpenPGP PGP/MIME mit Mixmasterversand

Menüname:
Mixer/Mixer-encrypt

Kommandozeile:

|cat > /tmp/syltmp ; cd ~/.mixmaster/ ; ./mixmaster --header='Content-Type: text/plain; charset=UTF-8' --header='Content-Transfer-Encoding: 8bit' --encrypt -t %u < /tmp/syltmp; shred -fuz /tmp/syltmp

Oder als Script mit Xdialog Eingaben: syl-mixmaster-pgpmime.

Beschreibung:
Die Nachricht wird zuerst mit Mixmasters OpenPGP Implementation PGP/MIME mit dem GnuPG Schlüssel des Empfängers verschlüsselt und anschließend per Mixmaster versendet.

Klartext mit Mixmasterversand

Menüname:
Mixer/Mixer-clear

Kommandozeile:

|cat > /tmp/syltmp ; cd ~/.mixmaster/ ; ./mixmaster --header='Content-Type: text/plain; charset=UTF-8' --header='Content-Transfer-Encoding: 8bit' -t %u < /tmp/syltmp; shred -fuz /tmp/syltmp

Oder als Script mit Xdialog Eingaben: syl-mixmaster-cleartext.

Beschreibung:
Versendet die Nachricht per Mixmaster, aber ohne zusätzliche OpenPGP Verschlüsselung des Nachrichtenkörpers, so dass die Nachricht im Klartext an den Empfänger ausgeliefert wird.

Für anonymes Bloggen per invisiblog

Menüname: Mixer/Invisiblog

Kommandozeile:

|gpg-sign-invisiblog ; cd ~/.mixmaster/ ; ./mixmaster --subject='%u' --header='Content-Type: text/plain; charset=UTF-8' --header='Content-Transfer-Encoding: 8bit' -t post@invisiblog.com < /tmp/syltmp; shred -fuz /tmp/syltmp

Oder als Script mit Xdialog Eingaben: syl-mixmaster-invisiblog.

Beschreibung: Dient der Nutzung der anonymen Weblogplattform invisiblog.
Zuerst wird die Nachricht mit dem eigenen invisiblog GnuPG Schlüssel signiert und anschließend für die anonyme Veröffentlichung im Weblog per Mixmaster an invisiblog gesendet.
Das gpg-sign-invisiblog Script (mit dem syl-mixmaster-invisiblog Script unnötig) dient der Signierung in einem xterm Terminal:

#!/bin/sh
TMPFILE=`mktemp $HOME/.iXXXXXX` || exit 1
TMPFILE2=`mktemp $HOME/.oXXXXXX` || exit 1
cat - > $TMPFILE
xterm -T "GnuPG - Message Signing" -geometry 80x8 -e gpg -u invisiblog --clearsign --yes -o $TMPFILE2 $TMPFILE
cat $TMPFILE2 > /tmp/syltmp
rm $TMPFILE
rm $TMPFILE2
Mixminion

Mixminion ist wie Mixmaster die Bezeichnung für eine Applikation wie für ein Netz aus Mix-Remailern, über die anonym E-Mails versendet werden können (Usenet noch nicht). Mixminion zielt darauf ab, Angriffsmethoden gegen das Mixmasternetz auszuräumen und den Mixmasteransatz weiterzuentwickeln. Mixminion wird deshalb auch als Typ III des anonymen Remailerprotokolls bezeichnet, während man bei Mixmaster vom Typ II spricht.

Neben dem eigenen Protokoll kennzeichnet Mixminion, dass hier – ähnlich wie bei Tor – die Liste der verfügbaren Mixremailer von Verzeichnis-Servern verwaltet wird und der Empfänger einer anonymen Mixminionnachricht dem Absender per SURB (Single-Use Reply Block) antworten kann, wenn der Absender dem Empfänger zuvor einen oder mehrere SURBs übermittelt hat.

Voraussetzungen
  1. Entpacken des Sourcecodes mit

    $ tar -xzf mixminion-version.tar.gz
  2. In das Sourcecodeverzeichnis wechseln mit

    $ cd mixminion-version
  3. $ make
  4. $ make test
  5. $ su
  6. $ make install
  7. $ mixminion unittests

Um die Mixminion Konfigurationsdatei ~/.mixminionrc und das ~/.mixminion/ Verzeichnis anzulegen und das Verzeichnis der Mixminionremailer zu laden, sendet man sofort nach der Installation eine erste "Initialisierungsnachricht":

$ mixminion send -t reale@mailadresse
Texteingabe
Strg+D

Umfangreiche Anpassungen der Konfigurationsdatei sind nicht nötig. Am wichtigsten sind noch die Optionen zur Bestimmung der zu verwendenden Mixremailer und die Pfadlänge, d. h. wieviele Mixremailer am Versand beteiligt sein sollen. Desweiteren Optionen für die SURBs.

SURBAddress reale@mailadresse Eigene, reale E-Mail Adresse, an die bei Nutzung von SURBs letztendlich Nachrichten von Kommunikationspartnern ausgeliefert werden.
SURBLifetime n hours | days | weeks |
months | year
Gültigkeitsdauer eines SURB. Beim Standard von 7 Tagen kann ein Kommunikationspartner einen SURB im Zeitraum von einer Woche "verbrauchen".
ForwardPath Remaileraufzählung Anzahl und Namen der Remailer bei einfachen Mixminion Nachrichten.
ReplyPath Remaileraufzählung Anzahl und Namen der Remailer bei Antworten per SURB. Werden dem Pfad des SURBPath vorangestellt
SURBPath Remaileraufzählung Anzahl und Namen der Remailer, die in einem SURB gespeichert sind, über die der Ersteller des SURB Antworten an ihn erhalten will.
Pfade und Nicknames

Für den ForwardPath schreibt Mixminion mindestens zwei Remailer vor, für Reply- und SURBPath mindestens einen Remailer. Ich würde wie bei Mixmaster für den ForwardPath mindestens drei Remailer festlegen und für die beiden anderen Pfade mindestens zwei Remailer. Da immer mindestens ein Remailer involviert ist, erhöht sich die Pfadlänge auch bei Replys bzw. Nachrichten an SURBs auf mindestens drei Remailer. Standardmäßig werden aktuell fünf zufällig ausgewählte Remailer für einen Pfad verwendet. Wenn nicht vom Anwender erzwungen, werden keine Remailer ausgewählt, die vom Verzeichnis nicht empfohlen werden (Status: not recommended). Die Remaileraufzählung kann mit folgender Syntax erfolgen:

~Anzahl wählt ca. Anzahl Remailer
*Anzahl wählt genau Anzahl Remailer
? wählt genau einen zufällig ausgewählten Remailer
Name wählt Remailer mit Namen Name
Beispiele

*Path ~5

Mixminion wählt ca. fünf zufällig ausgewählte Remailer.

*Path *4

Mixminion wählt genau vier zufällig ausgewählte Remailer.

*Path ?,?,?,antani

Mixminion wählt drei zufällig ausgewählte Remailer und als Exit Server den Remailer antani. Der Exit Server ist der letzte Remailer im Pfad, d. h. derjenige, der an den Empfänger die Nachricht als E-Mail ausliefert.

Der Exit Server entscheidet auch darüber, ob ein angegebener Nickname im From: Header auftaucht oder nicht. Deshalb sollte man – wenn man einen Nickname verwenden will – immer selbst den letzten Remailer im Pfad angeben, weil nicht alle Remailer einen Nickname im From: Header zulassen.

Welcher Mixminion Remailer modifizierte From: Header zulassen, kann man sich mit folgendem Kommando anzeigen lassen:

$ mixminion list-servers -r -s " | " -J -F delivery/smtp:allow-from | grep yes

Mixminion version 0.0.8alpha2
This software is for testing purposes only. Anonymity is not guaranteed.
Dec 13 19:15:32.317 +0100 [WARN] This software is newer than any version on the recommended list.
antani :yes
banana :yes

Wie bei Mixmaster ist es auch bei Mixminion wichtig, eine aktuelle Liste der aktiven Remailer zu verwenden. Man kann die Überprüfung entweder Mixminion überlassen – dann prüft Mixminion vor jedem Versand, ob der lokale Verzeichniscache aktuell ist und lädt ggf. zuerst ein aktuelles Verzeichnis oder man lässt z. B. per cronjob regelmäßig ein aktuelles Verzeichnis herunterladen. In diesem Beispiel alle vier Stunden:

0 */4 * * * /usr/bin/mixminion update-servers

Damit braucht Mixminion selbst keine Aktualisierung mehr vorzunehmen, so dass es zu keinen Verzögerungen bei der Auslieferung kommt.

Eine ausführliche Anzeige des aktuellen Verzeichnisses, die nur die empfohlenen, aktiven und mit bestimmten Fähigkeiten (wie dem direkten Versand an den Empfänger per SMTP, Zulassen eines Nicknames) ausgestatteten Remailer berücksichtigt, erhält man z. B. mit dem Kommando:

$ mixminion list-servers -r -s " | " -J -F caps,status,software,delivery/smtp:allow-from | grep smtp

Mixminion Anzeige

Von links nach rechts sieht man den Namen des Remailers, danach, ob der Remailer per SMTP an den Empfänger ausliefert (smtp) und / oder an eine Mailbox beim Remailer (mbox), nur Pakete an andere Remailer weiterleitet (relay) oder auch die Zusammenfügung fragmentierter Nachrichten übernimmt (frag). In der folgenden Spalte wird der Onlinestatus wiedergegeben ((ok)), dann folgt die vom Remailer verwendete Mixminionversion und zum Schluß, ob der Remailer vom Absender modifizierte From: Header, sprich Nicknames zulässt.
Bedienung

Der Mixminion Client des Mixminion Source ist eine Referenzimplementation des Mixminion Protokolls. An sich sollten die Funktionen in einen eigenständigen oder existierende MUAs integriert werden. Da diese außer für Windows (Mixminion Message Sender) nicht existieren, muss Mixminion in der Konsole über Kommandos bedient werden.

  • $ mixminion send --from="Mein Nickname" -t empfänger@adresse --subject="Mein Subject" -i Maildatei

    Optional sind --from und --subject. Der zu versendende Nachrichtentext steht in der Datei Maildatei. Über die ebenfalls optionalen --references="String" und --in-reply-to="String" kann auf vorangegangene Nachrichten Bezug genommen werden.
  • $ mixminion send --from="Mein Nickname" -t empfänger@adresse --subject="Mein Subject"

    Texteingabe

    Strg+D

    Ohne die Angabe einer Maildatei erfolgt die Eingabe des Nachrichtentextes in der Konsole. Mit der Tastenkombination Strg+D wird die Eingabe abgeschlossen und die Mixminion Nachricht versendet.

Bei einer einfachen Nachricht, wie sie oben erstellt und verschickt wird, hat der Empfänger keinerlei Möglichkeiten, dem anonymen Absender eine Antwort (Reply) zu schicken, da höchstens der Nickname mit übertragen wird. Das ist auch nicht nötig, wenn z. B. die Nachricht eine einmalige Mitteilung erhält, auf die keine Antwort erwartet wird.

Anders sieht es aus, wenn eine Antwort bzw. wechselseitige Kommunikation zwischen Absender und Empfänger beabsichtigt ist, die ebenfalls anonym durchgeführt werden soll. Dies wird bei Mixminion durch die SURBs (Single-Use Reply Blocks) erreicht, Antwortblöcke für den einmaligen Gebrauch.

Die SURBs enthalten in verschlüsselter Form die reale E-Mail Adresse des Erstellers der SURBs und den Remailerpfad, über den Antworten an den Ersteller zurückgeschickt werden sollen.
Die SURBs werden in einer Datei abgespeichert, die entweder einen oder mehrere Antwortblöcke enthält. Hat man eine SURB Datei erstellt, wird sie dem Kommunikationspartner mit einer Mixminionnachricht übermittelt, der dann bei einer Datei mit mehreren SURBs wie bei den bekannten TAN-Listen der Banken jeweils für eine Nachricht einen SURB verbrauchen kann. Ein einmal verwendeter SURB wird als benutzt gekennzeichnet und kann nicht noch einmal benutzt werden.

Wenn Person A ihre SURBs an Person B gesendet und Person B ihre SURBs an Person A übermittelt hat, können beide Kommunikationsteilnehmer anonym und beiderseitig miteinander per "Mixminion E-Mail" kommunizieren.

Im Mixminion Projekt denkt man auch an die Nutzung der SURBs für Mixminion-Nymserver. In diesem Fall würde ein Anwender bei einem Mixminion-Nymserver einen festen Account erhalten, der mit einer Liste von SURBs verknüpft ist, die der Anwender beim Nymserver hinterlegt. Der Anwender würde dann mit einer "festen" Nym-Email-Adresse in Erscheinung treten und unter dieser Adresse über die Mixminion Remailer schreiben und Antworten über die hinterlegeten SURBs an seinen realen E-Mail Account zugestellt bekommen. Kann ein Mixminion Nymserver Mailboxen unterhalten, ist es auch denkbar, dass der Anwender gar keinen E-Mail Account mehr verwendet, mit dem Angaben zu seiner realen Identität verknüpft sind.

Bedienung

$ mixminion generate-surb -v -n Nummer -t reale@mailadresse --identity="Ein Name" -o identity_Nsurb

Mit -n Nummer wird die Anzahl der SURBs (Standard: 1) festgelegt, die in der SURB Datei ident_surb gespeichert werden, -t reale@mailadresse legt die E-Mail Adresse fest, an die eine Mixminionantwort letztendlich zugestellt wird, mit --identity werden die SURBs einer pseudonymen Identität zugeordnet.

Man sollte sich sofort angewöhnen, Identitäten zu nutzen und auch der abgespeicherten SURB Datei einen entsprechenden Namen zu geben. Sinnvoll ist es auch, für --from="Mein Nickname" und --identity="Ein Name" das gleiche Pseudonym zu verwenden. Das erleichtert bei einer großen Anzahl auszutauschender Mixminion Nachrichten die Übersicht und Verwaltung der SURBs.

Hinzukommt, dass bei der Dekodierung einer Antwortnachricht angezeigt wird, für welche Identität der vom Absender verwendete SURB Block gedacht war. Schreibt nun der Absender in einer Nachricht zum Beispiel "Hallo Bob", angezeigt wird aber, dass der SURB für "Alice" gedacht war und der SURB Ersteller SURBs für die beiden pseudonymen Identitäten "Bob" und "Alice" unterhält, weiß der SURB Ersteller, dass der Absender versucht herauszubekommen, ob hinter "Alice" und "Bob" ein und dieselbe Person steckt.

Anschließend erfolgt eine zweimalige Abfrage der Passphrase für den geheimen Schlüssel, mit dem der Mixminion SURB-Schlüsselring verschlüsselt wird und mit dem SURB Nachrichten entschlüsselt werden.

Beispiel:

$ mixminion generate-surb -v -n 3 -t kairaven@arcor.de --identity="Max Pain" -o ~/.mixminion/surbs/max_pain_3surb

Mixminion version 0.0.8alpha2
This software is for testing purposes only. Anonymity is not guaranteed.
[INFO] Setting entropy source to '/dev/urandom'
[DEBUG] Configuring client
[DEBUG] Configuring server list
[DEBUG] Directory is up to date.
[WARN] This software is newer than any version on the recommended list.
[INFO] Selected path is yog,antani,banana,geonosis
[INFO] Selected path is frell2,Rivendell,pboxlevel3,geonosis
[INFO] Selected path is antani,dantooine,osem,straylight
Enter new passphrase for client keyring:
Verify passphrase:
[INFO] Creating new key for identity 'Max Pain'
[DEBUG] Building reply block for path ['yog', 'antani', 'banana', 'geonosis']
[DEBUG] Delivering to 0100:'kairaven@arcor.de'
[DEBUG] Building reply block for path ['frell2', 'Rivendell', 'pboxlevel3', 'geonosis']
[DEBUG] Delivering to 0100:'kairaven@arcor.de'
[DEBUG] Building reply block for path ['antani', 'dantooine', 'osem', 'straylight']
[DEBUG] Delivering to 0100:'kairaven@arcor.de'

Die erzeugte SURB Datei max_pain_3surb wird per Mixminion als "Max Pain" an den Empfänger gesendet, mit dem man als "Max Pain" kommunizieren möchte:

$ mixminion send --from="Max Pain" -t empfänger@adresse --subject="SURBs for you" -i Maildatei

In die Maildatei kopiert man den Inhalt der SURB Datei und schreibt zum Beispiel davor:

Hallo X,
Anbei die SURB Datei "max_pain_3surb" mit 3 SURBs für 7 Tage.

=== cut ===
-----BEGIN TYPE III REPLY BLOCK-----
Version: 0.2

U1VSQgABQ6ibAE6QL+o2fWkNzkrP244uEAs63PzzFlObTT52E9Dk/l1vNTGrdMps
(…)
-----END TYPE III REPLY BLOCK-----

Der Empfänger der Nachricht speichert die SURB Datei unter max_pain_3surb (wenn er will). Mit dem Kommando

$ mixminion inspect-surbs -v max_pain_3surb

kann sich der Empfänger einige Details ansehen:

Mixminion version 0.0.8alpha2
This software is for testing purposes only. Anonymity is not guaranteed.
Dec 14 20:45:26.295 +0100 [INFO] Setting entropy source to '/dev/urandom'
Dec 14 20:45:26.296 +0100 [DEBUG] Configuring client
Dec 14 20:45:26.308 +0100 [DEBUG] Opening SURB log database at /home/user/.mixminion/surbs/log ==== max_pain_3surb
Reply block hash: f5d65b6bea42c5a6b76a4ac85f21126b7664946c
Expires at: 2005-12-21 00:00:00 GMT
First server is: server at nowwhat.lateralis.org:48100
Used: no
Reply block hash: 352b0205f39cc5a4051d0fed0beab926c60aa54f
Expires at: 2005-12-21 00:00:00 GMT
First server is: server at testmix2.hypernet.deepspacetrading.com:48099
Used: no
Reply block hash: ef4e89552ba81738964f7967783bc07a80f75b08
Expires at: 2005-12-21 00:00:00 GMT
First server is: server at serverone.firenze.linux.it:48099
Used: no

Wichtig sind hier die Angaben, wie lange die SURBs gültig sind und ob sie bereits benutzt bzw. verbraucht wurden.

Nun will der Empfänger eine Nachricht oder eine Antwort an "Max Pain" senden:

$ mixminion send -v --from="Mad Max" --subject="Thx" -R max_pain_3surb

Mixminion version 0.0.8alpha2
Enter your message. Type Ctrl-D when you are done.
Hi Max, habe Deine SURBs erhalten. Ich sende Dir meine morgen zu.

Bis dann
Mad Max
[INFO] Selected path is osem,cassandra,wiredyne,nixon
[INFO] Generating packet...
[DEBUG] Encoding reply message for 28672-byte payload
[DEBUG] Using path ['osem', 'cassandra', 'wiredyne', 'nixon']/??
[TRACE] Queueing packets
[INFO] Packet queued
[INFO] Connecting...
[TRACE] Looking up phobos.osem.com...
[TRACE] Result for getIP('phobos.osem.com'): inet:65.254.45.209 (2 others dropped)
[DEBUG] Opening client connection to 'osem' at phobos.osem.com:48099 (fd 3)
[DEBUG] Completed MMTP client connection to 'osem' at phobos.osem.com:48099 (fd 3)
[TRACE] Remembering valid certificate for 'osem' at phobos.osem.com:48099 (fd 3)
[DEBUG] KeyID is valid from 'osem' at phobos.osem.com:48099 (fd 3)
[TRACE] Wrote 10 bytes to 'osem' at phobos.osem.com:48099 (fd 3)
[DEBUG] Sent MMTP protocol string to 'osem' at phobos.osem.com:48099 (fd 3)
[TRACE] Read got 10 bytes from 'osem' at phobos.osem.com:48099 (fd 3)
[DEBUG] MMTP protocol negotiated with 'osem' at phobos.osem.com:48099 (fd 3): version 0.3
[TRACE] Queueing new packet for 'osem' at phobos.osem.com:48099 (fd 3)
[TRACE] Wrote 16384 bytes to 'osem' at phobos.osem.com:48099 (fd 3)
[TRACE] Wrote 16384 bytes to 'osem' at phobos.osem.com:48099 (fd 3)
[TRACE] Wrote 26 bytes to 'osem' at phobos.osem.com:48099 (fd 3)
[TRACE] Read got 30 bytes from 'osem' at phobos.osem.com:48099 (fd 3)
[DEBUG] Packet delivered to 'osem' at phobos.osem.com:48099 (fd 3)
[DEBUG] Successfully relayed all packets to 'osem' at phobos.osem.com:48099 (fd 3)
[TRACE] Shutdown returned zero -- entering read mode.
[DEBUG] Read returned 0; shutdown to 'osem' at phobos.osem.com:48099 (fd 3) done
[DEBUG] Got a completed shutdown from 'osem' at phobos.osem.com:48099 (fd 3)
[INFO] ... 1 sent
[TRACE] Removing 1 successful packets from queue

Eine erneute Inspektion der SURB Datei zeigt, dass ein SURB verbraucht wurde:

$ mixminion inspect-surbs max_pain_3surb

Mixminion version 0.0.8alpha2
This software is for testing purposes only. Anonymity is not guaranteed.
==== max_pain_3surb
Reply block hash: f5d65b6bea42c5a6b76a4ac85f21126b7664946c
Expires at: 2005-12-21 00:00:00 GMT
First server is: server at nowwhat.lateralis.org:48100
Used: yes

Wenn der SURB Ersteller "Max Pain" eine Nachricht bzw. eine Antwort erhält, die an einen seiner SURBS gerichtet war, sieht der Body der E-Mail so aus:

This is a Type III anonymous message, sent to you by the Mixminion
server at straylight.snikt.net. If you do not want to receive
anonymous messages, please contact ADMIN. For more information about
anonymity, see URL.

This message is not in plaintext. It's either 1) a reply; 2) a forward
message encrypted to you; or 3) junk.

-----BEGIN TYPE III ANONYMOUS MESSAGE-----
Message-type: encrypted
Decoding-handle: AjsTwyO63W+mfPyekIEwJl+H12E=

H83ffjJXIi93qv11qwaPP+UTBA6ARb5LAwgKj6IO7oKDCtGcJo+sXoXJVVHn9h93
(…)
-----END TYPE III ANONYMOUS MESSAGE-----

Um den Klartext der Mixminion Nachricht zu lesen, speichert "Max Pain" den Mailbody und gibt das folgende Kommando ein:

$ mixminion decode -i nachrichtdatei [-o klartextdatei]

Mit -o wird der Klartextinhalt in eine Ausgabedatei geschrieben, ansonsten erfolgt die Anzeige in der Konsole.

$ mixminion decode -i nachrichtendatei

Mixminion version 0.0.8alpha2
This software is for testing purposes only. Anonymity is not guaranteed.
Enter passphrase for keyring:
Dec 14 22:39:18.484 +0100 [INFO] Decoded reply message to identity 'max pain'
FROM:Mad Max
SUBJECT:Thx

Hi Max, habe Deine SURBs erhalten. Ich sende Dir meine morgen zu.

Bis dann
Mad Max

Mixminion Scripte für Sylpheed-Claws

Die folgenden Scripte können als Aktionen im MUA Sylpheed-Claws verwendet werden. Informationen zur Verwendung sind in jedem Script enthalten.

  1. syl-mixminion-cleartext

    Zum Versand einer Mixminion Nachricht im Klartext.
  2. syl-mixminion-decode

    Zur Dekodierung einer Mixminion SURB Nachricht.
  3. syl-mixminion-decodegpg

    Zur Dekodierung einer Mixminion Nachricht und anschließender Entschlüsselung des enthaltenen GnuPG Ciphertextes.
  4. syl-mixminion-pgpinline

    Zum Versand einer Mixminion Nachricht mit zusätzlicher PGP/Inline Verschlüsselung des Nachrichtenkörpers mit dem öffentlichen GnuPG Schlüssel des Empfängers.
  5. syl-mixminion-surb

    Zum Versand einer Mixminion Nachricht mit dem bzw. an den SURB des Empfängers.

Vielen Dank an Peter Palfrader und Tim Bartel für Korrekturen und Tipps.

Weitere Links