die raven homepage
Version 1.4
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 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:
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.
Wenn wir jetzt im Installationsverzeichnis './mixmaster' eingeben, sollte das folgende Menü erscheinen:
| 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. |
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:
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.
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:
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
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.
Durch Eingabe von buchstabe) löst man bestimmte Funktionen, Untermenüs oder Aktionen aus.
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
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.
Menüname:
Mixer/Mixer-GPG
Kommandozeile:
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.
Menüname:
Mixer/Mixer-encrypt
Kommandozeile:
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.
Menüname:
Mixer/Mixer-clear
Kommandozeile:
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.
Menüname:
Mixer/Invisiblog
Kommandozeile:
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:
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.
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. |
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 |
*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
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.
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.
$ 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
Die folgenden Scripte können als Aktionen im MUA Sylpheed-Claws verwendet werden. Informationen zur Verwendung sind in jedem Script enthalten.
Vielen Dank an Peter Palfrader und Tim Bartel für Korrekturen und Tipps.
