Welchen Anonymisierer?

Anonymisierer

  • Tor

    Stimmen: 23 85,2%
  • JAP

    Stimmen: 4 14,8%
  • Psiphon

    Stimmen: 0 0,0%
  • Freenet

    Stimmen: 2 7,4%
  • I2P

    Stimmen: 2 7,4%
  • Sonstige

    Stimmen: 1 3,7%

  • Umfrageteilnehmer
    27

lockdoc

Well-Known Member
Hallo Leute,
ich plane demnächst auch eine Anonymisierungssoftware einzusetzen
und wollte hier einfach mal in einer Umfrage schauen, ob eine bestimmte Software besonders heraussticht. Sozusagen als Leithilfe.

Ich würde mich auch freuen, wenn wir hier über die Pros und Cons diskutieren könnten.


Meine Frage wäre auch noch, ob der der Dienst direkt auf dem Server (welcher ins Internet routet) liegen sollte oder sollten die Clients anonymisieren?
 
Ich hab nur Tor bis jetzt verwendet. Das funktioniert so ganz gut. Die Geschwindigkeit variiert halt sehr stark.
 
Anonymisierungssoftware...

Mal ein paar Erklärungen:
Freenet ist keine Anonymisierungssoftware ala "ich surfe anonym im Netz". Es handelt sich dabe um ein sogenanntes Darknet - ein sicheres, anonymes, abgeschlossenes Netz im Internet (basierend auf (wahlweisen) F2F). Um genauer zu sein schickt man Daten (z,B. Freesites, die eine statische Alternative zum WWW sind) hinein, welche dann auf deinem und anderen Knoten verschlüsselt gelagert werden. Du kannst sie nur öffnen wenn du den Key hast. Diese Keys sind praktisch die URLs zum Content.

Der Vorteil an Freenet ist, dass Daten nicht einfach gelöscht/zensiert werden können. Was einmal drin ist ist kaum wieder raus zu bekommen und verschwindet erst mit der Zeit wieder. Jeder Node hat einen Store und niemand weiß, was sich in dem Store befindet. Du kannst zwar theoretisch darauf kommen, was drin ist, wenn du den Key/URI hast und nicht mit anderen verbunden bist, aber Freenet speichert auch Daten, die so vorbeikommen und Daten, die man einfügt müssen nicht zwangsweise komplett auf deinem Node verfügbar sein.

Das System ist äußerst resistent gegen diverse Angriffe und durch den Aufbau des Systems ist es so gut, wie unmöglich herauszufinden, wer was hineingeladen oder heruntergeladen hat. Wenn es darum geht gegen Zensur vorzugehen ist Freenet wohl die beste Wahl. Es gibt auch schon viele Ansätze dynamische Inhalte zu erlauben oder zu simulieren. Toll ist auch, dass man auch ohne viel Wissen keine allzu gravierenden Fehler machen sollte. Selbst wenn man sich dumm verhält ist man relativ sicher. Durch das web interface ist die Bedienung nicht so schwer.

Zu den Schwächen: Die Geschwindigkeit ist nicht gerade hoch und die Software ist in Java, falls das stört. Freenet hat statische Inhalte, aber es gibt viele Möglichkeiten damit umzugehen. Vor allem weil die Daten ja grundsätzlich verschlüsselt sind und man deshalb so etwas, wie Client-Server simulieren kann.


Tor ist wenn es darum geht ein anonymer Client oder Server (Hidden Service) zu sein eine gute Wahl. Der größte Nachteil ist, dass man sich wirklich mit Tor, dem Client (zB. Browser) oder den Server, den man verwendet auskennen sollte. Ansonsten kann man seine Anonymität schnell verlieren. Das geht übrigens über Cookies, Javascript, Plugins, etc. deaktivieren hinaus (auch, wenn das ein guter Anfang ist). Es gibt viele Kleinigkeiten zu beachten, wenn man wirklich anonym sein will. Außerdem ist es (im Verhältnis zu Freenet) anfällig für diverse möglichen Attacken, die nicht explizit auf die Anonymität abzielen. Man muss auf viele Arten von Angriffen aufpassen und hoffen, dass der Exitnode gutmütig ist, d.h. wissen, was man tut. Allerdings hat man im Gegenzug die Möglichkeit jede TCP-basierte Kommunikation zu nutzen. Wenn man anonym surfen will empfehle ich stark das vorgefertigte Bundle zu nutzen oder im Browser ein neues Profil zu erstellen, dass nichts (Cookies, Scripts, Plugins, ..) aktiviert hat, auch keine Updates von Plugins, Addons, Suchmaschinen. Desweiteren muss man hoffen, dass weder der Exit Node, noch die Website einen Exploit für den Browser kennt. Auf keinen Fall sollte man sich irgendwo einloggen. Am besten auch nicht über HTTPS!

IMO bräuchte man mehr auf Tor optimierte Software (IMs, Browser, etc.) und nicht nur vorkonfigurierte und mit Plugins ausgestattet Software. Vieles sollte Hardcoded oder nicht einmal möglich sein. Das würde sowohl die Geschwindigkeit, als auch um die Sicherheit zu erhöhen.

Gegen diverse Attacken kann man sich schützen, wenn Tor nicht nur als Client, sondern auch als Server läuft. Wenn man Angst vor Hausdurchsuchungen hat, dann einfach den Middlemanmodus verwenden.

Tor ist in C geschrieben und äußerst portabel. Durch den Einsatz von Bridges kann Tor auch von Leuten in zensierten Ländern verwendet werden. Allerdings ist es viel anfälliger auf Zensur, als Freenet. Sowohl was Inhalte, als auch das Entdecken von Verbindungen ins Netz betrifft.


JAP ist was das anonyme Surfen betrifft ähnlich. Der Vorteil und Nachteil zugleich ist, dass JAP weniger, aber vertrauenswürdigere Serverbetreiber. Generell ist es auf viele Angriffe anfälliger, als Tor und besitzt nicht so viele Features Es gibt keine Hidden Services und kaum Schutz davor, dass jemand die Verbindungen zu den Servern bzw. die Server selbst deaktiviert.

Bei Psiphion geht es eigentlich nicht um Anonymität, sondern um das Tunneln einer Verbindung, damit eine Website so erscheint, wie sie jemand anders sieht. Allerdings ist es in den meisten Fällen besser Tor (mit Bridges) zu verwenden. Ich nehme an, dass es in Sachen Geschwindigkeit besser sein wird. Um ehrlich zu sein halte ich nicht besonders viel davon.

I2P hat Ähnlichkeiten mit Tor. Es ist allerdings in Java geschrieben, man ist immer auch ein Node/Server. Die Kommunikations erfolgt im Gegensatz zu Tor über UDP. Es wird wie Freenet über ein Webinterface gesteuert. Von den Zielen her ist es eine Kreuzung aus Freenet und Tor. Es ist ähnlich, wie Freenet bzw. Tor mit Hidden Services ein eigenes Netz. Es gibt zwar ein paar wenige (1-4) Exits, aber das meiste tut sich im Netz. I2P ist generell sehr einfach zu verwenden. Man installiert und startet es und eigentlich war es das schon. Ins Webinterface sind sogar schon der ebenfalls enthaltene Webserver und ein Bittorrentclient integriert. Eigentlich alles sehr einfach. Zu konfigurieren gibt es vor allem das Portforwarding und den Proxy um *.i2p-Sites aufrufen zu können.



Es kommt also drauf an, was man will:

Tor für das Surfen im WWW und wenn man was haben will was überall läuft und nicht so ressourcenhungrig ist. Generell eine gute Wahl um kompatibel mit dem Internet und diversen Anwendungen (egal, ob Server oder Client) zu bleiben. Wenn man nur Client sein kann.

Freenet ist die beste Wahl, wenn man sich vor starker Überwachung und Zensur schützen will. Das heißt, wenn man denkt, dass 1984 oder ähnliche Szenarien zu großen Teilen wahr werden bzw. vor einem Staat, wie China oder einem generell zensiertem und überwachtem Internet schützen will. Auch das Beste zum reinen Austausch von Informationen, wie Texte, Audio, Video, Bilder, Programme, etc. Auch wenn man Nachrichten austauschen will. Ersatz für Email, Usenet und Foren gibt es bereits.

I2P: Wenn ich ein Freenet will und wirklich keine Möglichkeit habe um dynamische Inhalte bzw. Server zu umgehen. Bzw., wenn mir Tor oder Freenet aus irgendwelchen Gründen nicht gefallen.


Ich würde mir die drei generell alle ansehen und dann entscheiden, was man will. Allerdings nacheinander, da man nur Tor als client-only verwenden kann/will (sollte man aber nicht bzw. nur in bestimmten Situationen - wer kein Exit sein will kann einfach Middleman sein). Bei allen dreien ist es sinnvoll die Programme offen zu halten. Das erhöht die Geschwindigkeit und Sicherheit.

Wichtig: Kein System kann euch vor der eigenen Dummheit schützen. Generell gilt, dass ihr um so sicherer seid umso mehr ihr darüber wisst. Deshalb unbedingt alles darüber lesen! Am Besten auch den source code.

Generell nähern sich die Projekte an. Tor wird resistenter und soll UDP unterstützen. Freenet soll eine Art Hidden Services bekommen, damit es nicht nur statisches gibt.

Gut sind sie alle drei, aber perfekt noch lange nicht!
 
Braucht man für freenet nicht so etwas wie eine Einladung? Habe mich mal früher damit beschäftigt. Die Idee gefällt mir sehr gut. Vielleicht kann dort das Internet sein, was es mal vor 10 Jahren war: Frei von Zensur und Kommerz.
 
Wie beschrieben ist Freenet eigentlich ein F2F(Friend-to-Friend)-Netz.

Früher war es üblich im IRC-Channel nach einer "Einladung" zu fragen bzw. gab es Bots, die man laufen lassen konnte und selbst die Informationen austauschten. War irgendwie nett dabei zuzusehen bzw. mit ihnen zu interagieren.

Wie gesagt war das früher so. Seit einiger Zeit gibt es das sogenannte Opennet, das extra für Leute ist, die (noch) keine Freunde haben. Es ist praktisch eine automatisierte und vor allem deutlich besser gesicherte Version von dem, was früher im IRC-Channel statt fand. Selbstverständlich ist es deutlich sicherer vertrauenswürdige Personen zu haben, was aber nicht heißt, dass man im Opennet unsicher ist. Es geht ja natürlich darum starke Zensur umschiffen zu können. Es ist zwar aufwendig, aber möglich das Opennet abzugrasen und damit zu erfahren, wer Freenet verwendet. Es ist natürlicher auch anfälliger für Attacken, aber man sollte nicht glauben, dass es anfälliger ist, als irgendein anderes Netz, das nicht auf F2F-Basis läuft. Man sollte _mindestens_ fünf Freund eingetragen haben (die auch ständig verbunden sein sollten) bevor man Opennet deaktiviert. Am Besten ist wohl zuerst zu schnuppern und wenn man Leute hat denen man vertraut diese hinzuzufügen. Bei Freenet kann man auch einstellen, wie sehr man jemanden vertraut. Das heißt, du bist auch zu Freunden keineswegs komplett offen. Generell gibt es viele Möglichkeiten Sicherheit gegen Performance abzuwiegen. Für gewöhnlich wird es mit der Anzahl der Nutzer schneller. Hat man mal bemerkt, als es auf Slashdot war :)

Noch ein Tipp: Es ist besser I2P und Freenet in seinem (oder einem eigenem) Homeordner zu halten. Das ist für gewöhnlich der Standard und macht vieles deutlich einfacher. Vor allem bei Freenet wäre es gut die internen Diskussionen (z.B. in FMS) zu folgen. Da kommt man oft an brauchbare Informationen zur Software und Neuerungen. Die Autoupdates würde ich übrigens bei beiden Systemen aktivieren/aktiviert lassen. Die Updates sind selbstverständlich anonym, aus dem Netz und signiert.
 
Wichtig bei den Anonymisieren ist auf jeden fall https oder eine andere Verschlüsselung, da eben jeder zwischen Knoten sonst mitlesen kann, das wurde und wird gemacht.

Freenet hatte ich mal aus Interesse kurz ausprobiert, hab das aber ganz schnell wieder gelöscht, nachdem die "Freenetseiten" zu der Zeit zum Großteil aus Inhalten bestanden, die für die Ursula interessant sein sollten...
 
Zu HTTPS: Ich würde generell davon abraten private Daten über anonyme Netze zu übertragen. HTTPS sollte man auch im normalen Inet verwenden, wenn es um sensible Daten geht. Ich habe bei Tor explizit geschrieben, dass es um Anonymität geht. Es wird/wurde auch davon abgeraten HTTPS zu verwenden. Es gibt glaube ich ein paar Attacken. Mittlereweile werden aber verschlüsselte Verbindungen empfohlen und nur für Hidden Services sollte man sie nicht nutzen. Da sind die Daten ohnehin durch den Tunnel geschützt sund und es weiß niemand wer was aufruft.

Was Freenets Inhalte betrifft. Mir kommt es eher so vor als gäbe es viel Diskussion darüber, aber ich bin noch nie über derartige Inhalte gestoßen. Aber generell sollte man davon ausgehen, dass es sie in jedem anonymen Netz gibt, genau so wie im Internet.
 
Zuletzt bearbeitet:
Es wird/wurde auch davon abgeraten HTTPS zu verwenden. Es gibt glaube ich ein paar Attacken. Mittlereweile werden aber verschlüsselte Verbindungen empfohlen und nur für Hidden Services sollte man sie nicht nutzen. Da sind die Daten ohnehin durch den Tunnel geschützt sund und es weiß niemand wer was aufruft.

Der Technical Correctness halber möchte ich hier einige Dinge klarstellen. HTTPS ist eine Protokollfamilie, und kein Verschlüsselungsverfahren (und strenggenommen noch nicht mal ein kryptographisches Protokoll). HTTPS regelt nur, wie kommuniziert wird, wie Verbindungen initiiert und terminiert werden, und welche kryptographischen Protokolle (wie z. B. SSLv2, SSLv3, TLSv1) eingesetzt werden sollen/dürfen.

In den kryptographischen Protokollen wiederum ist spezifiziert, welche Verfahren zum Schlüsselaustausch, zur Authentifizierung und zur (symmetrischen) Verschlüsselung des Datenstroms verwendet werden (wiederum mehrere, über die Wahl müssen sich beide Seiten einer Verbindung erst verständigen => "negotiate"). Die gängigsten kryptographischen Protokolle sind derzeit SSLv2, SSLv3, TLSv1 und SSHv2. Der schlechte Ruf von HTTPS rührt übrigens aus Zeiten, als noch SSLv1 eingesetzt wurde, das so unsichere symmetrische Algorithmen wie DES-56 im ECB-Mode zur Verschlüsselung des Datenstroms zugelassen hat.

Nun zur Sicherheit: SSLv2 und SSHv1 gelten als unsicher, haben "Macken" schon im Protokoll-Design (wohlgemerkt nicht in den darunter liegenden kryptographischen Algorithmen!). SSLv3, TLSv1 und SSHv2 (wird bei HTTPS nicht verwendet) gelten als sicher, solange sie mit ausreichend großen (asymmetrischen) Schlüsseln und als sicher geltenden Algorithmen (z. B. RSA + Blowfish-CBC oder AES256-CBC) betrieben werden. Wie sicher die ausgehandelte Verbindung ist, hängt vor allem an der serverseitigen Konfiguration: sicherheitsbewusste Admins können schlicht und ergreifend unsichere Algorithmen und Protokolle ausschließen. Das führt vielleicht in Einzelfällen dazu, dass Uralt-Browser (z. B. IE4, Netscape 4.7) nicht mehr funktionieren, aber bei sicherheitskritischen Web-Applikationen (z. B. Online-Banking etc.) sollte man bereit sein, diesen Preis zu zahlen.

Moderne Webserver und -browser sollten bei korrekter Konfiguration bei einer HTTPS-Verbindung TLSv1 als Protokoll und entsprechend sichere Algorithmen aushandeln. Im übrigen ist es ein weit verbreiteter Irrglaube, dass "Tunnel" wie OpenVPN & Co. andere Verfahren einsetzen. Auch diese verwenden entweder OpenSSL (und damit die dort implementierten Protokolle), GnuTLS oder SSHv2 (z. B. aus libssh). Die Tunnel von Tor, JAP & Co. bedienen sich also exakt derselben kryptographischen Protokolle wie eine HTTPS-Verbindung.
 
Also ich hab jetzt Dank der Antworten auch eine ganze Menge über die verschiedenen Anonymisierungsverfahren gelernt.

Leider hatte ich da auch eine falsche Vorstellung, evtl. gibt es aber ein derartiges Tool. Hier mal die Beschreibung wie ich mir das gedacht hätte:


Code:
----------     ----------
|Internet|-----| Server | ------|HUB| ---- diverse PCs
----------     ----------

Der Server[FreeBSD] wählt sich via PPPoe ins Internet ein und verteilt via NAT (oder korrekterweise PAT) Internet an die Computer im LAN.
Nun sollte es so sein, dass der Server sich schon eine verschlüsselte Internetverbindung holt und die Clients keinerlei Konfiguration benötigen und automatisch "anonym" im Netz surfen können unabhängig von dessen OS.

Gibt es dafür ein Tool für FreeBSD was das kann?
 
Code:
----------     ----------
|Internet|-----| Server | ------|HUB| ---- diverse PCs
----------     ----------

Der Server[FreeBSD] wählt sich via PPPoe ins Internet ein und verteilt via NAT (oder korrekterweise PAT) Internet an die Computer im LAN.
Nun sollte es so sein, dass der Server sich schon eine verschlüsselte Internetverbindung holt und die Clients keinerlei Konfiguration benötigen und automatisch "anonym" im Netz surfen können unabhängig von dessen OS.

Gibt es dafür ein Tool für FreeBSD was das kann?

Mit einem einzelnen Tool wird das nix - aber man kann so etwas realisieren. Der Server müsste als transparenter Proxy fungieren; dazu muss der Paketfilter Pakete mit Destination http an einen auf dem Server laufenden Proxy (z. B. Privoxy) weiterreichen, statt sie mit NAT zu forwarden. Dieser stellt dann die Anfrage über eine Tor-Verbindung und gibt die entsprechende Antwort an den Client im LAN.
 
Mit einem einzelnen Tool wird das nix - aber man kann so etwas realisieren. Der Server müsste als transparenter Proxy fungieren; dazu muss der Paketfilter Pakete mit Destination http an einen auf dem Server laufenden Proxy (z. B. Privoxy) weiterreichen, statt sie mit NAT zu forwarden. Dieser stellt dann die Anfrage über eine Tor-Verbindung und gibt die entsprechende Antwort an den Client im LAN.

Das geht schon. Tor kann inzwischen als transparenter proxy fungieren, wo der ganze Traffic dann durch geht und die clients nichts mehr einstellen müssen:
http://wiki.noreply.org/noreply/TheOnionRouter/TransparentProxy
 
@Ogion: Das ist schon klar. Ich meinte aber nicht Attacken auf HTTPs selbst, sondern Attacken (bzw. Schwachstellen) auf die Anonymität, wenn man eine HTTPS-Verbindung durch das Tornetz aufbaut.

Wer glaubt im übrigen, dass OpenVPN, Tor, etc. nicht auf (open)SSL setzen? Es ist ja mehr oder minder Standard derartige Anwendungen auf Basis von OpenSSL zu implementieren. Ich finde es nur schade, dass Algorithmen, wie Tiger und Serpent nicht dabei sind. Deshalb werden die beiden auch in kaum einem Protokoll verwendet. :(
 
@Ogion: Das ist schon klar. Ich meinte aber nicht Attacken auf HTTPs selbst, sondern Attacken (bzw. Schwachstellen) auf die Anonymität, wenn man eine HTTPS-Verbindung durch das Tornetz aufbaut.
OK, sorry, hatte das falsch interpretiert. Sehe jetzt aber, dass Du eine HTTPS-Verbindung im TOR-Tunnel meintest...

Wer glaubt im übrigen, dass OpenVPN, Tor, etc. nicht auf (open)SSL setzen? Es ist ja mehr oder minder Standard derartige Anwendungen auf Basis von OpenSSL zu implementieren.
Ooch, da könnte ich so einige Dinge erzählen... Admins, die eine SSL-Verbindung (es ging nicht um HTTPS, sondern um MySQL sowie diverse Applikationsserver, DMSe und ein Backup-System) für unsicher hielten und mir dann stolz erzählen, dass sie dafür OpenVPN einsetzen, weil das ja so sicher sei - I rest my case :ugly: Komischerweise denken offenbar auch immer noch viele IT-Profis (im Sinne von "beruflich mit IT befasst") automatisch an hohe Sicherheit, wenn irgendwo die Abkürzung "VPN" benutzt wird, während dieselben Leute sofort zu Reichsbedenkenträgern mutieren, wenn die Abkürzung "SSL" lautet ("Man-in-the-Middle Attacke", "ihh, da muss man ja mit Zertifikaten rumhantieren").

Ich finde es nur schade, dass Algorithmen, wie Tiger und Serpent nicht dabei sind. Deshalb werden die beiden auch in kaum einem Protokoll verwendet. :(
Yupp, wobei Twofish/Serpent nicht gerade ein Hexenmeister an Geschwindigkeit ist - und bei einer Transportverschlüsselung mit flüchtigen Daten und flüchtigen Schlüsseln sollte AES256 eigentlich dicke ausreichen ;) (ok, die verschlüsselten Daten sind nur flüchtig, wenn niemand lauschangreift, aber die Klartext-Daten sind zumindest beim Empfänger i. d. R. flüchtig und die Schlüssel werden mit jeder Verbindung neu ausgehandelt - Known Plaintext / Chosen Cipher als normalerweise vielversprechendster Angriffsvektoren sind damit ziemlich sinnlos).
 
OK, sorry, hatte das falsch interpretiert. Sehe jetzt aber, dass Du eine HTTPS-Verbindung im TOR-Tunnel meintest...
Ich habe das auch ein bisserl blöd geschrieben. Achja, offiziell nennt man es Tor, auch wenn es sich um ein Akronym handelt. Nur falls du mal in deren IRC Channel bist ;)


Ooch, da könnte ich so einige Dinge erzählen... Admins, die eine SSL-Verbindung (es ging nicht um HTTPS, sondern um MySQL sowie diverse Applikationsserver, DMSe und ein Backup-System) für unsicher hielten und mir dann stolz erzählen, dass sie dafür OpenVPN einsetzen, weil das ja so sicher sei - I rest my case :ugly: Komischerweise denken offenbar auch immer noch viele IT-Profis (im Sinne von "beruflich mit IT befasst") automatisch an hohe Sicherheit, wenn irgendwo die Abkürzung "VPN" benutzt wird, während dieselben Leute sofort zu Reichsbedenkenträgern mutieren, wenn die Abkürzung "SSL" lautet ("Man-in-the-Middle Attacke", "ihh, da muss man ja mit Zertifikaten rumhantieren").
Ouch! Und wie kommen die zu ihrer Arbeit als Admin und auf die Idee, dass OpenVPN keine Zertifikate brauchen? Die verwenden wohl irgendeine andere VPN-Software und Router, wo man das nicht so sieht.

Yupp, wobei Twofish/Serpent nicht gerade ein Hexenmeister an Geschwindigkeit ist - und bei einer Transportverschlüsselung mit flüchtigen Daten und flüchtigen Schlüsseln sollte AES256 eigentlich dicke ausreichen ;) (ok, die verschlüsselten Daten sind nur flüchtig, wenn niemand lauschangreift, aber die Klartext-Daten sind zumindest beim Empfänger i. d. R. flüchtig und die Schlüssel werden mit jeder Verbindung neu ausgehandelt - Known Plaintext / Chosen Cipher als normalerweise vielversprechendster Angriffsvektoren sind damit ziemlich sinnlos).
Es ist allseits bekannt, dass Serpent nicht so schnell ist. Aber zum einen würde es, wenn es Standards gäbe sicher optimierte Versionen geben (vor allem für 64bit Systeme soll es möglich sein viel mehr rauszuholen, als bei AES) und zum Anderen denke ich da eher an Anonymizer und IM/Email-Verschlüsselung, wo es sicher kein Flaschenhals ist. Außerdem kann man ja für gewöhnlich Präferenzen einstellen und somit das Problem lösen. Nur gällt mir kein Standard ein, wo Serpent überhaupt erwähnt wird. Das ist der Grund, warum GnuPG und OpenSSL keinen Serpent-Support haben. Auch, wenn ich weiß, dass es für GnuPG Patches gibt.

AES traue ich einfach nicht: nur auf Grund von Geschwindigkeit genommen, die NSA hat ihre Finger im Spiel und vor allem bröckelt er:
https://cryptolux.org/FAQ_on_the_attacks

Tut mir leid, aber ich verstehe nicht, warum sich im Berich Kryptographie alles so in Richtung Geschwindigkeit, statt Sicherheit entwickelt.

Bei den meisten Anwendungen, wo man Kryptographie braucht wäre auch die Geschwindigkeit von Serpent mehr als ausreichend. Ich hatte auch eine weile (mind. 1 1/2 Jahre) ein mit Serpent verschlüsseltes System, weil ich mal wissen wollte, wie lahm das wirklich ist. War ein Linux (Arch) mit XFS als Filesystem (verwende ich praktisch immer, wenn ich Lin nutze) und ich muss erwähnen, dass ich mit ziemlich viel experimentiere.

Außerdem war das auf einem System mit einem Celeron D 331 (also ein abgespeckter, einkerniger Prescott) und auf der größten SATA-Platte, die ich bei deren Kauf auftreiben konnte (2000GB - 16MB Cache). Die Teile sind allesamt aus den Jahren 2002-2004. Nicht gerade das perfekte System, aber Serpent hat mich nicht gestört. Auch nicht, als ich als ich meine YaCy-Node (eine verteilte Suchmaschine, die ziemlich festplattenintesiv ist) betrieb, welcher ca. 10-25% an Geschwindigkeit gegenüber dem unverschlüsselten System verlor.

Damit sollte man eigentlich leben können, aber ich werde schon wieder OT. :o
 
Hach, wenn wir schon grade so schön OT sind, mach ich einfach mal weiter ;)

Auf Serpent gibt es ebenfalls einen Angriffsvektor (XLS), der aber mehr theoretischer Natur ist (siehe http://eprint.iacr.org/2002/044). Mein persönlicher Favorit ist ja Twofish - er hat zwar "nur" 16 Runden (statt 32 wie Serpent), arbeitet dafür aber mit schlüsselabhängigen S-Boxen, was einen kryptoanalytisch getriebenen Angriff ungemein erschwert.

Zum Thema Speed vs. Security: IMO muss man sich eben sehr genau anschauen, wofür eine Verschlüsselung* benötigt wird. Wenn es um persistente Daten geht (also z. B. Verschlüsselung von Datenträgern, Archivierung etc.) muss man ans Maximum des technisch machbaren gehen - schließlich soll diese Verschlüsselung noch einige Jährchen durchhalten und steigender Rechnerleistung für Brute Force trotzen können. Hier halte ich Algorithmen wie Serpent, Twofish, MARS oder notfalls Blowfish für angebracht.

Im Grunde genommen muss man ähnlich hohe Ansprüche auch an Systeme zur Transportverschlüsselung stellen, wenn denn durch die Transportverschlüsselung langfristig schützenswerte Informationen geschützt werden sollen (z. B. Geschäftsgeheimnisse, die per VPN ausgetauscht werden) - es besteht ja die Gefahr, dass die Daten mitgeschnitten werden, und schon wären wir wieder beim Persistenz-Problem von oben.

Häufig werden jedoch durch Transportverschlüsselungssysteme Informationen geschützt, die nur für einen relativ begrenzten Zeitraum von Wert sind (z. B. eine TAN, Login Credentials, etc). Zieht man hier den Aspekt hinzu, dass Rijndael trotz der von Dir angesprochenen Schwächen in der Praxis (noch) nicht gebrochen werden kann (und in Echtzeit wohl auch auf absehbare Zeit nicht brechbar sein wird), dann wäre Rijndael in vielen Übertragungsszenarien immer noch ein hinreichend guter Kandidat für eine Transportverschlüsselung.

* Ich gehe mal davon aus, dass Verschlüsselung nur sinnhaft eingesetzt wird, wie etwa hier beschrieben
 
Zurück
Oben