Linux / Windows

Eine kleine Story zu TrueCrypt (unter Windows), Backups und warum man sich ein paar Gedanken machen sollte.

Gestern war es dann endlich so weit. Nach einem Start und mehrmaliger Eingabe des TrueCrypt Passworts kam das, was im TrueCrypt Manual so beschrieben wird: "If you repeatedly enter the correct password but TrueCrypt says that the password is incorrect, it is possible that the master key or other critical data are damaged". In diesem Fall muss die TrueCrypt Rettungs-CD zum Einsatz kommen, um die Schlüsseldaten wiederherzustellen, die während der Systemverschlüsselung über ein ISO Image erstellt und gebrannt werden kann. "Kann" – denn man kann das Image auch mit einem der Tools für virtuelle Laufwerke auf eine virtuelle CD schreiben, wie das einige Nutzer machen, die der Brennvorgang nervt. Ich nehme als Tool die bekannten Daemon Tools (ohne Adware) und hatte das auch so gemacht. Das ISO Image hatte ich in TrueCrypt Containern auf USB-Stick und Partition gespeichert, aber mit dem Hintergedanken, das bei Bedarf zu brennen, nicht gebrannt. Ein falscher Hintergedanken, wenn man nur einen CD/DVD Brenner im Rechner hat.

Zum Beginn der Beschäftigung mit und dem Einsatz von TrueCrypt hatte ich mir außerdem überlegt, wie man für Windows und TrueCrypt Backups und/oder Images machen kann, die selbst wiederum mit TrueCrypt gesichert sind, denn verschlüsselte Partitionen und unverschlüsselte Backups/Images sind unsinnig und deshalb auch in ein paar Webforen nachgelesen, wie es andere Nutzer damit halten. Dafür gibt's verschiedene Vorgehensweisen. Meine ist folgende:

Ich habe eine WD SATA Festplatte in dem externen MX-1 Gehäuse von Antec, mit dem ich übrigens sehr zufrieden bin. Auf der befinden sich wie auf der internen Festplatte TrueCrypt verschlüsselte Partitionen. Eine Windows BartPE/XPE Boot-CD enthält das Image-Programm TrueImage von Acronis, TrueCrypt und verschiedene andere Sachen. Mit der boote ich regelmäßig und entschlüssle/mounte mit TrueCrypt die Partitionen auf der externen Festplatte. Dann werden von interessierenden Partitionen der internen Festplatte mit TrueImage Images ohne Komprimierung und die Acronis eigene Verschlüsselung in die TrueCrypt Partitionen auf der externen Festplatte erstellt, damit es schnell geht. Für die verschlüsselte Systempartition gibt es zwei "TrueImages" in zwei TrueCrypt Partitionen: Eines per "Sektor-für-Sektor" der Systempartition im verschlüsselten Zustand in die eine externe TrueCrypt Partition und eines nach gemounteter Systempartition ohne Pre-Boot Authentifizierung, bei dem der entschlüsselte Inhalt komplett in das Acronis Image auf der anderen externen TrueCrypt Partition gespeichert wird. Da sich das erste Image bereits im verschlüsselten Zustand befindet, könnte man das Image auch auf einer unverschlüsselten Partition ablegen, das zweite Image dient dazu, zumindest und immer an Daten zu kommen, wenn es mit dem ersten Image nicht hinhaut.

Eigentlich unverzeilich, bin ich diesem Schema gefolgt, ohne jemals selbst ausprobiert zu haben, ob eine Wiederherstellung mit Acronis, dessen Images, der Boot-CD und TrueCrypt überhaupt funktioniert, weil diverse Leute ausführlich berichtet hatten, dass es funktioniert. Man sollte sich aber trotzdem nicht darauf verlassen.

Der zweite DAU Fehler war, wie bereits angedeutet, die nicht gebrannte TrueCrypt Rettungs-CD, denn mit dem nachträglichen Brennen wurde es nichts über meine BartPE/XPE und eine Knoppix-CD, denn mit nur einem Laufwerk muss man natürlich die Boot-CD mit einem Rohling wechseln und danach ging nichts mehr mit Brennen – falls es da nicht eine Vorgehensweise oder einen Trick gibt, der mir nicht eingefallen ist. Damit auch keine Möglichkeit, das beschädigte Schlüsselmaterial wiederherzustellen.

Um mir zu behelfen und zum Brennen zu kommen, habe ich dann ein weiteres Image der aktuellen unzugänglichen Systempartition erstellt, wieder per Sektor-für-Sektor. Danach habe ich das alte Acronis Image der Systempartion wiederhergestellt, das per Sektor-für-Sektor erzeugt wurde. Für diejenige, die das auch so mit Acronis machen wollen oder müssen: Man muss wiederum die Sektor-für-Sektor Methode aktivieren, dann zuerst die Partition und als weitere "Partition" den MBR auswählen. Danach löscht Acronis zuerst die existierende Partition, stellt sie aus dem Image wieder her und danach wird der MBR wiederhergestellt.

Danach kam der Zeitpunkt, ob das alles so klappt mit der Vorgehensweise und den Acronis Images. Nach einem Neustart ging es aber wie gewohnt mit der TrueCrypt Pre-Boot Authentifizierung nebst Entschlüsselung der Systempartition und erfolgreichem Booten des "alten" Windows weiter – die zu späte Bestätigung der Vorgehensweise. Mit dem "alten" Windows habe ich dann das ISO Image der TrueCrypt Rettungs-CD auf eine CD-RW gebrannt und danach den ganzen Zauber erneut durchgeführt, sprich Booten mit der BartPE/XPE CD, Wiederherstellen des Images der unzugänglichen Systempartition mit Acronis, Einlegen der TrueCrypt Rettungs-CD, Neustart und Reparatur des TrueCrypt Schlüssels der Systempartition mit der Restore Key data Funktion im Menü der Rettungs-CD. Tja und danach war wieder alles in Butter. Abgesehen von der rot angelaufenen Stirn aufgrund der Zusammenstöße mit dem Schreibtisch

Für die GnuPG Anwender, die es benötigen.

David Shaw, einer der Entwickler im GnuPG Team, hat für *nix und Windows Version 1.0 des Paperkey Programms veröffentlicht.

Um ein Backup des eigenen Schlüsselpaares in Datenform zu pflegen, kann man entweder die Schlüsselringdateien komplett als Kopie oder den geheimen Schlüssel als Datei exportieren und ihn auf einem Datenträger speichern. Da ein Datenträger verloren gehen, beschädigt werden oder nach längerer Zeit seine Lesbarkeit verlieren kann, ist es ggf. sinnvoll, für ein zusätzliches Backup auf das gute alte Papier und Drucker auszuweichen.

Um ein Backup des eigenen Schlüsselpaares in Papierform anzulegen, könnte man einfach den geheimen Schlüssel mit ASCII Hülle exportieren und den Inhalt ausdrucken. Zum späteren Wiederherstellen des Schlüsselpaars kann dann der Ausdruck entweder per OCR eingelesen oder abgetippt und das Ergebnis wieder mit GnuPG importiert werden. Der Nachteil bei dieser Methode ist die Menge an Zeichen, die der Export enthält, denn darin ist alles enthalten, was einen Schlüssel ausmacht, inklusive des öffentlichen Schlüsselmaterials.

Das bedeutet, dass sich der Ausdruck unter Umständen auf mehrere Seiten Papier verteilt bzw. die Schriftgröße stark verkleinert werden muss und sich damit die Wahrscheinlichkeit erhöht, dass sich beim Einlesen und Abtippen Fehler einstellen und deshalb eine Wiederherstellung fehlschlägt.

Hier setzt Paperkey an, das aus dem exportierten geheimen Schlüssel in Binärform nur die relevantesten Anteile extrahiert und sie ebenfalls in ASCII Zeichen auswirft, die dann zu einem komprimierten Ausdruck auf Papier führen, der viel besser zur späteren Wiederherstellung geeignet ist. Zur vollständigen Wiederherstellung des Schlüsselpaars ist neben dem eingelesenen oder abgetippten Ausdruck der öffentliche Schlüssel nötig, der sich bei den meisten GnuPG Anwendern auch nach einem Schlüsselverlust auf einem Schlüsselserver befindet, auf einer Webpage angegeben wird oder in anderer Form bereits existiert.

Zu Paperkey gibt es eine kurze Anleitung, die aber nicht vollständig ist und zu keinem vollständigen Ergebnis führt, deshalb hier die "vollständige" Version:

Erstellung des Paperkey Backups

1. Export des geheimen Schlüssels in Binärform in die Datei SchlüsselIDsec:
   
   gpg -o SchlüsselIDsec --no-armor --export-options no-export-clean,export-minimal --export-secret-keys Schlüssel-ID
   
   
2. Erzeugung der komprimierten Version der relevanten Schlüsselbestandteile des geheimen Schlüssels für den Ausdruck:
   
   paperkey --secret-key SchlüsselIDsec --output SchlüsselIDpaper.txt
   
   Für meinen zurückgezogenen Schlüssel 0x0A146804 reduziert sich das auf folgenden Output:

   # Secret portions of key 5AB6B450D8CC132B80B17F24431C6A350A146804
   # Base 16 data extracted Fri Jan 23 10:21:51 2009
   # Created with paperkey 1.0 by David Shaw
   
   # File format:
   # a) 1 octet:  version of the paperkey format (currently 0).
   # b) 1 octet:  OpenPGP key version (currently 4)
   # c) n octets: Key fingerprint (20 octets for a version 4 key)
   # d) 2 octets: 16-bit big endian length of the following secret data
   # e) n octets: secret data: an OpenPGP secret key or subkey as specified in
   #              RFC 4880, starting with the string-to-key usage octet and
   #              continuing until the end of the packet.
   # Repeat fields b through e as needed to cover all subkeys.
   # To recover, use the fingerprint to match an existing public key with the
   # corresponding secret data, then append field e to the public key to
   # create a secret key.
   # Each base 16 line ends with a CRC-24 of that line.
   # The entire block of data ends with a CRC-24 of the entire block of data.
   
     1: 00 04 5A B6 B4 50 D8 CC 13 2B 80 B1 7F 24 43 1C 6A 35 0A 14 68 04 0C08F6
     2: 00 53 FE 0A 03 08 24 28 E0 0F 13 57 BB 10 60 3B 5B 31 C9 7B F3 69 08B4F5
     usw.
    17: 4B AD 65 E2 E9D940
    18: 5B7490
   

   Das ist doch im Gegensatz zur anfangs erwähnten Methode erheblich weniger, gut einzulesen und zur Not auch gut abzutippen. Genauso wie beim tatsächlichen geheimen Schlüssel ist auch die Ausdruckversion durch die Passphrase geschützt, denn natürlich ist die Verschlüsselung durch die Passphrase und den gewählten symmetrischen Algorithmus ebenfalls Bestandteil im Ausdruck.
   
   Ist die Passphrase nicht im "Susi" Style gewählt, sondern ausreichend lang, in ihrer Zusammensetzung ausreichend komplex und ein starker symmetrischer Algorithmus gewählt, kann auch ein Ausdruck in die Hände der Möchtegern-Cracker des BKA, BND oder anderer Geheimdienste fallen, wenn es sich nicht verhindern lässt. Sollte man spätestens seit Annes Story mit dem PGP Schlüssel wissen und beherzigen. Wer es etwas paranoider haben möchte und sich selbst im Umgang mit GnuPG nicht vertraut, kann ja noch eine symmetrische Verschlüsselungsschicht um das Paperkey Backup legen und den Ciphertext ausdrucken (aber zusätzliche Passphrase nicht vergessen!)
   
   gpg --cipher-algo TWOFISH --s2k-digest-algo SHA256 -ac SchlüsselIDpaper.txt
   
   
3. Die SchlüsselIDpaper.txt Datei ausdrucken, den Ausdruck abheften, verbuddeln, verstecken usw. und danach wie die SchlüsselIDsec Datei "rückstands- und spurenlos" löschen, wie es immer so schön in den Sicherhheitsgesetzen heißt.

Wiederherstellung des Schlüsselpaares mit Paperkey

1. Davon ausgehend, dass man nicht mehr über die GnuPG Schlüsselring- oder Schlüsseldateien verfügt, wird der eigene öffentliche Schlüssel über die oben genannten Quellen bezogen.
2. Da der öffentliche Schlüssel meistens in ASCII Form vorliegt oder erhalten wird, konvertiert man die Datei mit dem öffentlichen Schlüssel in seine Binärform:
   
   gpg --dearmor SchlüsselID.asc (mit SchlüsselID.asc.gpg als Resultat)
   
   
3. Wiederherstellung des geheimen Schlüssels in seine Binärform mit dem Paperkey "Ausdruck" (entweder bereits auch als Datei vorliegend oder eingelesen/abgetippt) und dem öffentlichen Schlüssel:
   
   paperkey --pubring SchlüsselID.asc.gpg --secrets SchlüsselIDpaper.txt --output SchlüsselIDsec
   
   
4. Import der Dateien mit dem geheimen und öffentlichen Schlüssel:
   
   gpg --import --import-options no-import-clean,import-minimal SchlüsselIDsec
   gpg --import --import-options no-import-clean,import-minimal SchlüsselID.asc.gpg
   
   
5. Vetrauenswert für eigenen Schlüssel wiederherstellen und aktuelle Fremd-Zertifikate von Schlüsselserver importieren:
   
   gpg --edit-key SchlüsselID
   trust
   5
   
   gpg --refresh-keys SchlüsselID

Danach kann das Schlüsselpaar wie gewohnt mit GnuPG genutzt werden. Die Vorgehensweise habe ich auch mit einem aktuell aktiven Schlüssel anwenden können.

Die --*armor Option, Import- und Export-Optionen dienen dazu, jenseits möglicher Optionen, die bereits in der gpg.conf vom Nutzer oder anderen Programmen gesetzt wurden, doppelte Zertifikate im Schlüssel zu vermeiden und die für Paperkey benötigte Binärform anzuwenden. Die Änderung des Vetrauenswerts des Schlüssels nach Wiederherstellung kann unterbleiben, wenn zuvor beim Export/Backup des geheimen Schlüssels auch die Vetrauenswerte mit gpg --export-ownertrust > mytrust.asc exportiert wurden, so dass sie nach Wiederherstellung des Schlüssels mit gpg --import-ownertrust mytrust.asc wieder importiert werden können. Die Vetrauenswertedatei kann man natürlich ebenfalls als Backup ausdrucken.

Bisher nutzte ich unter Windows für Downloads mit Firefox immer die FlashGot Erweiterung (vom Programmierer stammt auch NoScript) mit dem Free Download Manager, der Feedreader brachte auch noch seinen eigenen Download-Manager für Podcasts, Movies usw. mit. Mal direkt oder über Tor, I2P und JonDonym für anonymisierte Downloads. Die beiden Download-Manager hatten die meiste Zeit nichts zu tun und so etwas gefällt mir nicht. Auch wenn ich mir bei den niedrigen Speicherpreisen jetzt den Arbeitsspeicher aufgerüstet habe, um demnächst etwas mit Virtualisierung herumzuspielen.

Da ich Wget in der Konsole ebenso gerne für Downloads nutze und es zu dessen Einbindung in FlashGot auf der Features Seite ein Beispiel gab (was mir nicht ausreichte), habe ich mir mit ein paar Batchdateien, der Wget Portierung des GnuWin32 Projekts und ein paar weiteren Sachen einen minimalen Wget "Download-Manager" gebastelt, der dann im FlashGot Kontextmenü von Firefox so aussieht: Die "NoProxy" Menüeinträge rufen, wie der Name schon sagt, Wget für den Download ohne Proxy und Weiterleitung an Tor, I2P oder JonDonym auf, bei den "Proxy" Menüeinträgen werden Downloads über den Privoxy Proxy und ggf. einen Anondienst abgewickelt, für FTP Downloads statt Privoxy über JonDonym, da Privoxy kein FTP unterstützt.

"NoSSLcheck" ist für SSL/TLS verschlüsselte Downloads von Servern da, die nur selbst signierte Zertifikate anbieten und deshalb nicht gegen die CA-Zertifikate geprüft werden können bzw. bei CA-Zertifikaten, die man noch nicht einer Datei mit einem Paket aller CA-Zertifikate hinzugefügt hatte, aber wo man trotzdem etwas herunterladen möchte. Bei Menüeinträgen ohne "NoSSLcheck" werden immer Server-Zertifikate gegen die CA-Zertifikate geprüft und deshalb ein Download abgebrochen, wenn etwas nicht mit den Host- und Zertifikatangaben stimmt. Was aufgrund von Angriffsmöglichkeiten und Schlampereien bei den CAs auch nicht unbedingt eine Garantie bietet, wie man immer wieder erfahren muss.

Natürlich kann man die Liste beliebig für weitere Zwecke und Funktionen von Wget erweitern.

Für die Datei mit dem Paket aller CA-Zertifikate habe ich mich der Zertifikatespeicher der Browser und OpenSSL bedient. Man kann natürlich auch selbst alle CA Sites absurfen und sich die Zertifikate selbst besorgen und "behandeln". Weitere Methoden werden in der readme Datei genannt.

Falls es jemanden interessiert oder für diejenigen, für die das Ganze nützlich sein könnte, habe ich die Batchdateien und eine eingerichtete wgetrc Datei in ein Archiv gepackt. In der readme Datei steht auch alles Weitere ausführlich erklärt. Verbesserungsvorschläge und Tipps sind wie immer willkommen.

Vermutlich kommen ein paar Leser angerannt, die mir sagen wollen, das sei alles zu kompliziert und Download-Manager XY viel besser, schöner, bunter und mächtiger. Aber genau die wollte ich eben nicht. Was die Wget Geschichte nicht kann – wie zum Beispiel der Free Download Manger, ist die automatische Konvertierung von Filmchen, die man bei YouTube herunterlädt. Aber dafür gibt es dann auch wieder einfache Tools.

Siehe auch:
WackGet

Zur Liste der IP-Adressen auf WikiLeaks, die dem BND gehören sollen, über die u. a. Heise in der Meldung BND-Mitarbeiter haben angeblich Wikipedia-Einträge geändert berichtete und Fefe hinwies, hatte mir jemand seine IP Blockliste zugeschickt, die neben den "BND" IP-Bereichen aus der WikiLeaks Veröffentlichung und den whois Informationen auch IP-Bereiche für diverse Landes- und Bundesministerien, sowie Landeskriminalämter und das BKA enthält, aber die auskommentiert und ohne Verbotsanweisung.

Das Ganze ist für die Unix/BSD Portierung des DenyHosts Daemon gedacht, der /etc/hosts.deny aktualisiert, könne aber auch für Firewalls, Paketfilter und Filteranwendungen verwendet werden, wie der Einsender dazu schreibt. DenyHosts setzen Anwender dazu ein, um Login- und Einbruchsversuche bei ihren SSH Servern zu unterbinden. Wer damit etwas anfangen kann oder will, kann sich die Liste herunterladen.

Nun ist es ja nichts Neues und sollte spätestens seit Einrichtung der von Polizei- und Geheimdienstbehörden gemeinsam betriebenen Zentren zum Monitoring von Webseiten, Webforen, Weblogs, IRC-Channels usw. bekannt sein, dass Polizei- und Geheimdienstbehörden "im Internet auf Streife gehen", sich Inhalte anschauen und automatisiert analysieren lassen, Plattformen und Dienste beobachten oder auch verdeckt teilnehmen.

Sofern es mein Weblog oder meine Homepage betreffen könnte, wäre es vielleicht interessant, wie Fefe schrieb, nachzuschauen, ob mich der BND, der Verfassungschutz, ein LKA, das BKA, irgendein ausländischer Dienst oder andere Behörden und Ministerien "besuchen". Aber auf der anderen Seite interessiert es mich auch nicht brennend. Nicht, weil ich alle Ansätze der Sicherheitsbehörden zur Überwachung von Internetdiensten und -nutzern legitim finde, sondern weil sie sich meinetwegen anschauen und durchlesen können, was ich hier schreibe. Themen, Inhalte und Aussagen, die zu einer engeren Fokusierung, sprich harten Überwachung führen würden, würde ich eh anders und anderswo präsentieren.

Ich könnte einen möglichen Besuch auch nicht mit IP Blocklisten verhindern, jedenfalls nur so lange, wie solche IP-Adressen und Bereiche dafür genutzt werden. Was mich zur Frage bringt, wie dämlich eigentlich Behörden wie der BND sind, wenn sie für ihre Recherchen keine Tools wie den TCP Onion-Router (Tor) benutzen, für die sie anfänglich auch gedacht waren. Wenn sie es aber machen oder über einen anderen anonymisierenden Dienst gehen oder sich verdeckt zusätzliche Anschlüsse bei einem Internetzugangsanbieter besorgen, wie es jeder machen kann oder mal was privat erledigen ("Karl-Heinz, kannst Du das heute Abend bei Dir erledigen, wir haben ja gleich Feierabend"), dann kann ich Besuch und Beobachtung erst recht nicht mit IP-Listen und -Filtern verhindern oder bemerken.

Etwas anders verhält es sich, wenn ich Server betreibe, für die ich als Betreiber identifizierbar bin und die öffentlich zugänglich sind. Dann kann es schon interessant sein, staatliche und kommerzielle Interessenten und Schnüffler auszusperren – wenn es auch dabei nicht die erwähnten Umgehungsmöglichkeiten gäbe, die man umgekehrt als Internetnutzer anwendet, um Überwachung, Kontrolle und Zensur zu unterlaufen. Von der potentiellen Gefahr, legitime Besucher und Nutzer ganz auszusperren, wenn man Filter- und Blockiersysteme nicht prüft und pflegt oder die IP-Adressen und -Bereiche auf eine andere Person oder Organisation übergehen (das meinte ich damit).

Wirklich interessant und bedenklich wird die Geschichte mit den BND IPs, wenn Geheimdienst- und Polizeibehörden mit ihnen oder anderen IPs im Netz aktiv werden: um Inhalte wie in der Wikipedia zu ändern, zu manipulieren oder selbst einzustellen, um in fremde Rechnersysteme einzudringen, um dort "den Bundestrojaner" für das Abfangen von Passwörtern, Gesprächsinhalten und Abgreifen oder Vernichten von Daten unterzubringen, um als Undercover Agents in extremistischen Umfeldern zu operieren mit der Gefahr, als Agent Provocateur zu wirken und wenn ihnen dazu die Befugnisse und Mittel von Sicherheitspolitikern per Gesetz in die Hände gelegt werden. Ich denke nicht, dass Kontrollinstanzen wie das Parlamentarische Kontrollgremium solche "Anwendungen" ausreichend auf ihrem Kontrollschirm haben und wenn, erfahren wir nichts darüber.

P. S.: Klar, Angebote wie WikiLeaks, Cryptome oder andere Informationsverbreiter, interessante Mailsendungen und ihre Inhalte sind immer wichtig. Nicht das es zu Missverständnissen kommt

SOCKS-Wrapper, Tor und Remailer

Seit Service Pack 3 für Windows XP funktionierten (bei mir – wie es bei anderen Usern ausschaut, weiß ich nicht) die verschiedenen SocksCap Versionen nicht mehr, die im Netz umlaufen. SocksCap stammt ursprünglich von NEC, bei denen das SOCKS 4 Protokoll auch entwickelt wurde, dann erfolgte der Verkauf an Permeo und der Weiterverkauf an Blue Coat, die es in ihre Proxyprodukte integrierten, die man kaufen muss.

SocksCap ist eine, eigentlich die originäre SOCKS-Wrapper Anwendung für Windows, um Verbindungen von Internetanwendungen, die keine Schnittstelle zur Nutzung von SOCKS-Proxys aufweisen, abzufangen und an einen SOCKS-Proxy bzw. Server umzuleiten. Braucht man fast nie für die Anonymisierung über Tor, der auf SOCKS basiert, da mittlerweile die meisten Internetanwendungen unter Windows SOCKS direkt unterstützen. Braucht man aber für Stunnel, um verschlüsselte SSL / TLS Tunnel durch Tor zu leiten. Das braucht man wiederum, wenn man als Remailer Programm Quicksiler nutzt und verschlüsselte Verbindungen zu Remailern aufnehmen will, da Quicksilver kein SSL / TLS eingebaut hat und Tor nur in Teilen unterstüzt.

Die übrigen SOCKS-Programme und -Wrapper unter Windows, die mir zum Test auf die Platte kamen, versagten alle ihren Dienst für den obigen Zweck. Dann habe ich es mit der SOCKS Anwendnung von Hummingbird versucht. Für den Download muss man sich anmelden. Wer damit Probleme hat, kann mit speziellen E-Mail Adressen und einer anderen Identität die gwünschten Daten liefern, was ja auch für andere Formulare gilt. Für die Anmeldung bekommt man einen kostenlosen SOCKS-Wrapper, der ohne Tricks wie bei SocksCap ohne Zeitlimit funktioniert und auch noch neben Stunnel mit Tor harmoniert.

Das Ding hat ein paar Haken: 1. Hummingbirds SOCKS 5 versteht Tor nicht, Tors SOCKS 4A hat es nicht, bleibt also nur SOCKS 4. Das damit einhergehende "Problem" direkter Namensauflösungen statt Namensauflösung über den SOCKS-Proxy (Tor) stellt aber kein Problem dar, wenn man sowieso die Namensauflösung über TorDNS -> Tor abwickelt. 2. Hummingbirds Socks gräbt sich so tief ein, dass automatisch alle Internetverbindungen "socksifiziert" werden. Also auch für Internetanwendungen, wo das nicht erwünscht oder unnötig ist. Wer aber immer alle Verbindungen automatisch über Tor laufen lassen will, braucht sich wohl bei keiner Internetanwendung mehr Gedanken machen, denn Hummingbird fängt's ab Wer das nicht will, kann oder muss das "Modul" (sprich ∗.exe, ∗.dll) der Internetanwendung, das "socksifiziert" werden soll, extra angeben und dafür alle anderen "Module", für die das nicht gelten soll, manuell in eine Liste eintragen oder Verbindungen als "direkt" ausschließen.

Das ist mal wieder alles unheimlich kompliziert und technisch, wird aber anders aufbereitet nochmals in der kommenden Remailer Anleitung auftauchen, die ich bis Ende 2008 fertig haben will. Unter Linux hat man es einfacher und mehr Möglichkeiten, alles zu realisieren, aber es geht darum, wie man's unter Windows machen kann. Bestes Beispiel ist der heutige Hinweis auf den Torsocks Socks-Wrapper für Linux auf der Tor Mailingliste, der alle Patches für tsocks und ein paar Verbesserungen integriert.

Jabber, Tor, OpenPGP, OTR und die VDS

Der Anonymisierung dient auch meine schrittweise Rückkehr zum jabber.ccc.de Jabber Server. Der swissjabber.ch Jabber Server, den ich ebenfalls nutzte, ist zwar auch ein guter Jabber Server, verbindet man sich aber über Tor, gab es bei diesem Jabber Server für mich zu viele Verbindungsunterbrechungen – auch während laufender Chats, die ich bei jabber.ccc.de nicht beobachten konnte. Jabber Verbindungen sind zwar nicht in der EU-Richtlinie und im Gesetz zur Vorratsdatenspeicherung aufgeführt und demnach Jabber Server von der Vorratsdatenspeicherung ausgeschlossen, aber ich will, dass die Nutzung eines Anonymisierungsdienstes funktioniert.

Mehr mit Verschlüsselung hat es auf sich, dass ich nun statt OpenPGP die OTR Verschlüsselung nutze, auch wenn ich kein Fan von OTR bin. Dafür gibt es zwei Gründe: 1. Immer weniger Kontakte nutzen – wenn überhaupt – Clients, die OpenPGP jabberkonform unterstützen oder OpenPGP an sich. Dafür setzt sich OTR immer mehr durch. 2. Jabber Server machen (u. U.) Probleme bei der OpenPGP Nutzung, dies umso mehr, je länger die eingesetzten GnuPG Schlüssel sind. Mit OTR gibt es keine Probleme.

GIMP, IrfanView, ImageMagick, Exif und CC

Unter Windows nutze ich für die Bild- und Fotobearbeitung gerne und oft GIMP und IrfanView. Demnächst will ich alle Fotos in der Galerie und die auf der Platte dümpelnde Fotos überarbeiten und anders abspeichern. Die Batchfunktionen sind dafür bei IrfanView ganz nett – die benutze ich zum Beispiel für Bilderfolgen wie hier. Mit GIMP kann man das wohl auch mit Skripten, aber die finde und schreibe man erst.

Mir kam wieder ImageMagick in den Sinn, das bei Serendipity zur Skalierung benutzt wird und dessen convert Anwendung auch in der Serendipity Konfiguration auftaucht. Außerdem kannte ich das noch unter Linux und prächtig ausprobieren, spielen kann man mit ImageMagick allemal. Eigentlich sollte oder kann man einem einzelnen Foto seine ganze Aufmerksamkeit widmen, aber für eine "Knips-Galerie" möchte ich es einfach haben und Vieles in einem Rutsch machen können. Aus dem Dickicht der ImageMagick Operatoren, Optionen, Tests mit ein paar Bildern und Seiten wie Sharpening using Image Magick habe ich mir ein erstes ImageMagick Kommando zusammengebastelt, besser gesagt zusammengereimt, das mir in einer Batchdatei alle JPEGs in einem Verzeichnis bearbeitet: mogrify -path LW:\output -monitor -compress jpeg -interlace line -comment "(CC) BY-SA Kai Raven" -quality 85 -density 72 -resample 100 -filter Sinc -resize 640x -sampling-factor 1x1,1x1,1x1 -unsharp 0.66x0.5+1.0+0.0.

Das ist und wird nicht der Weisheit letzter Schluß sein, ich will ja noch weiter spielen, aber vielleicht gibt es noch Ideen und Anregungen von ImageMagick Nutzern, was man sonst noch benötigt und machen kann. Zur Creative Commons Lizenzgeschichte gibt es noch die informative Seite Commons:Manipulation von Metadaten, die auf den Gebrauch von exiftool eingeht, das ich mir neben der ExifToolGui installiert habe, um Lizenzangaben nicht nur als JPEG Kommentar zu speichern. Für die Windowsversion von GIMP tauchte übrigens gestern in der GIMP Plugin Registry das Exif Viewer Plugin auf, das mit meiner GIMP 2.6.0 Version läuft.

Dies und Das

Tja – und wenn ich nicht am Rechner bin, um etwas zu bearbeiten oder auszuprobieren, auch nicht draußen in der Realwelt im Meatspace, dann lese ich u. a. gerade Hawthornes "Haus mit den sieben Giebeln". Deshalb gilt für mich in Zukunft an den Wochenenden Blog-Enthaltsamkeit, auch wenn ich mir heute selbst widerspreche

Alexander berichtet im Beitrag The Datagram Onion Router über die Entwicklung des "Tdor" durch den Studenten Camilo Viecco an der Indiana Universität. Der Tdor ist wie Tor, der "TCP Onion Router" ein Onion Router System zur Anonymisierung, das aber im Gegensatz zu Tor nicht auf dem verbindungsorierentierten, zuverlässigen Transmission Control Protokoll (TCP) basiert, sondern dem verbindungslosen, nicht-zuverlässigen User Datagramm Protokoll (UDP).

UDP wird für Anwendungen bevorzugt, bei denen man während des Transports verlorengehende Datenpakete in Kauf nehmen kann und sich der komplexere Aufbau der TCP/IP Datenpakete, die gegenseitigen Nachrichten und Signale während des Aufbaus und der Existenz einer Verbindung bei TCP als störend auswirkt, wobei die "Störung" aus Zeitverzögerungen besteht, die für den Anwender als Unterbrechungen und "Ruckeln" der Internetanwendung in Erscheinung tritt. Das Anonymisierungssystem I2P verwendet zum Beispiel ebenfalls UDP für die Verbindungen zwischen den Knoten im Netzwerk, der I2P "Proxy" kann aber auch eingehende TCP Pakete entgegennehmen, wenn man I2P entsprechend einstellt.

Neben dem Überladen des Tor Netzwerks mit Daten der Filesharing-Nutzung kann die Verwendung von TCP auch ein Grund sein, warum es mit Tor auch mal "ruckeln" kann und ein Grund, warum ich mir gerade wieder eine kleine "paysafecrad" für JonDonym gekauft habe, das ich immer ergänzend zu Tor einsetze, wenn ich es im WWW eilig habe und über Tor die Daten wieder tröpfeln. Im Tor Projekt wurde deshalb schon öfters diskutiert und angekündigt, neben TCP UDP zu integrieren.

Der Tdor Datagramm Onion Router ist, wie Alexander schreibt, der erste Ansatz, um mit UDP die Wartezeiten in Onion Router basierten Anonymierungsdiensten zu verbessern. Tdor kann bereits unter unixoiden Betriebssystemen kompiliert und eingesetzt werden, ist aber in einem frühen Experimentierstadium und noch weniger für den produktiven Einsatz gedacht als Tor. Das Tdor Netz besteht zur Zeit auch nur aus sechs Tdor Knoten. In der man Page von Tdor schreibt der Entwickler deshalb: "Tdor is eine Machbarkeitsnachweis für einen Datagramm basierten Onion Router. Das Ziel ist die Bereitstellung ausgewogenerer Transportmechanismen für Onion Router als in Implementationen wie Tor." Ob sich aus Tdor eine eigene Onion Router Umsetzung ergibt oder die Anregungen, Funktionen und der Code von Tdor in Tor integriert werden, wird sich zeigen. Ich denke, wir werden dazu vom Tor Projekt noch einiges vernehmen.

Alexander kann jedenfalls berichten, dass die Tdor Version, die er testete, verwendbar und ziemlich schnell ist und er keinen Unterschied zwischen normalen und Tdor-basierten Internetverbindungen feststellen konnte. Wer Tdor selbst testen und unterstützen kann, sollte es tun.

Ein lang erwartetes Feature – die Verschlüsselung der Windows Vista/XP/2003 Systempartition und die Pre-Boot Authentifikation – ist nun auch mit Version 5.0 der freien und quelloffenen Verschlüsselungsanwendung TrueCrypt verfügbar, die gestern veröffentlicht wurde. Laut der Dokumentation zur Verschlüsselung der Systempartition muss man dazu Windows nicht neu installieren, sondern soll die Verschlüsselung während des laufenden Betriebs durchführen können.

Bereits mit TrueCrypt verschlüsselte Partitionen können mit der neuen Version weiterbenutzt werden, bei ihnen wird dann aber nicht der XTS Modus zur Verschlüsselung von Festplatten verwendet. XTS wurde als ein Modus in die P1619 Standards zur Verschlüsselung von blockorientierten Speichermedien des Institute of Electrical and Electronics Engineers aufgenommen.

Weitere Neuerungen: Durch Pipeline Operationen soll sich die Lese-Schreib Geschwindigkeit unter Windows bis zu 100% erhöhen, für Mac OS X gibt es eine Version und für Linux eine grafische Benutzeroberfläche. Unter Linux wird eine bestehende TrueCrypt Installation nicht mehr beeinflusst, wenn ein neuer Kernel installiert oder kompiliert wird. Bei neuen TrueCrypt Partitionen oder Containerdateien kann nur noch SHA-512 statt SHA-1 verwendet werden.

Bei 0er Versionen muss man zwar vorsichtig sein, aber mit TrueCrypt 5 steht Windows Nutzern nun eine Alternative zu kommerziellen Festplattenverschlüsselungslösungen wie Utimacos SafeGuard oder PGPs Whole Disk Encryption zur Verfügung. Durch die komplette Verschlüsselung der Systempartition erübrigen sich auch bisherige Basteleien zur Verschlüsselung von Swapdateien und Benutzerprofilen. Darüber hinaus kann man die Veröffentlichung und Verbreitung von TrueCrypt angesichts von Rechner-Beschlagnahmungen und den Online-Durchsuchung Albträumen unserer Terroristenjäger nur begrüßen.

Mit einigen Erfahrungsberichten ist im Laufe des Tages im Heise-Forum zu rechnen.

Siehe auch:
Stefans Home - Warum Truecrypt 5 kein Allheilmittel gegen den Bundestrojaner ist

Also wenn es um die Öko-Bilanz von Ubuntu bzw. Linux geht, scheint Ubuntu nicht so gut abzuschneiden Jedenfalls nach dem nach eigener Aussage "nichtwissenschaftlichen" Linux vs. Windows Stromverbrauchstest von Phoronix.