Verschlüsselung

[Sascha]

Als Anlehnung an den "Use-Cases"-Thread

Ich würds optional machen, ob ein Node oder der Client die Datei
verschlüsselt. Da theoretisch jeder einen Node erstellen kann (/
darf), kann dieser auch sagen: jo, Datei ist ver schlüsselt, obwohl er
dies nicht getan hat. Natürlich kann jeder seinen Client selbst
programmieren und auch selbst die Datei vor dem Upload verschlüsseln.
Auch wenn der Server dies ein weiteres mal macht oder nicht.

Desweiteren können wir hier das Verschlüsselungsverfahren
ausdiskutieren.

Ich werfe einfach mal als erste Idee in den Raum: PGP

Ist mitlerweile in fast jeder Sprache integriert und hat sich doch
grundlegend auch für etliche andere Dienste bewährt.

[Robert Kummer]

Ich glaube hier müssen wir nochmal die rechtliche Seite betrachten.
Klar haben wir nur Chunks auf einem Node, wenn aber ein MP3-File oder
ähnliches Datenformat damit schon schützenswerten Content in Teilen
bereitstellt ist das rechtlich mit einem Serverstandort in Deutschland
nicht ganz ohne.
Hierbei würde ich folgende Strategie einfach empfehlen: Nodes
verschlüsseln ihre Chunks auf jedenfall, damit innerhalb des Grids
keine Daten eingesehen werden. Dazu kann man ja jedem Client einer PKI
unterziehen (privaten und öffentlichen Schlüssel), so dass jede Datei/
jeder Teil mit dem Node passend verschlüsselt weitergegeben wird. Dann
ist es egal, ob zuvor mittels Client eine verschlüsselte oder
unverschlüsselte Datei hochgeladen wurde, in den Nodes kann keiner
daraus lesen. Wenn man die PKI-Systematik entsprechend neben dem
Protokoll erklärt, können auch nicht so versierte Entwickler in dem
Thema Mitarbeit leisten. Ich würde mich da programmiertechnisch auch
eher outen und sagen, dass ich das bisher nur theoretisch betrachtet
habe, das aber durchaus mal mit PHP umsetzen wollen würde.

[dennis]

Mag sein, dass ich zu den weniger versierten Developern gehöre was
Verschlüsselung betrifft oder einfach nur auf dem Schlauch stehe, aber
wie wollt ihr das machen, dass jeder Node seine Chunks verschlüsselt?

Angenommen ein Node erhält Daten (egal ob verschlüsselt oder
unverschlüsselt) und wir arbeiten mit einem Public/Private Key
verfahren. Wenn ich als Node die Daten nun mit meinem Public Key
verschlüssle sind sie erstmal sicher. Denn zum entschlüsseln brauche
ich meinen Private Key - und den kenne nur ich. Aber wie gebe ich die
Daten jetzt weiter? Wenn ich den Chunk verschlüsselt weitergebe, dann
kann mein Nachbar Node die Chunks nicht lesen, denn er kennt meinen
Private Key nicht. Wenn ich dann aber als sozusagen "Master-Node"
dieses Chunks vom Netz gehe und mein Private Key für immer verloren
geht, wird es uns innerhalb des Grids nie wieder möglich sein diesen
Chunk zu entschlüsseln.
Verschlüsselung mit dem Private Key macht keinen Sinn ... dann kann es
jeder entschlüsseln.
Wo ist hier mein Denkfehler? Oder redet ihr hier nur davon, dass jeder
Chunk seine Daten vor der Ablage auf der Platte verschlüsselt? Dann
vergesst meinen Kommentar ;)

Was ich mir zzt. vorstellen würde: Der Client verschlüsselt seine
Daten selbst mit seinem Public Key. Dann kann nur er die Daten
entschlüsseln, so wie es sein soll. Der erste Node der die Daten
erhält signiert sie mit seinem Private Key. Damit gewährleisten wir
Datenintegrität.
Wenn wir jetzt einen "bösen" Node im Netz haben kann der höchstens die
Daten kaputt machen, lesen kann er sie aufgrund von Client-seitiger
Verschlüsselung sowieso nicht. Außerdem können wir Chunks von "bösen"
Clients anhand der Signatur erkennen sobald wir den "bösen" Node
identifiziert haben.

[dennis]

Noch eine Ergänzung: Wenn wir das Protokoll so auslegen, dass wir die
eigentlichen Daten zwar nur zu einem Node schicken, aber die Hashs der
Chunks an mehrere Nodes, können wir böse Nodes sofort finden und aus
dem Netz ausschließen (Ich denke dabei jetzt an ein Prinzip wie
Dropbox).

[Client] => [Node1]
=> [Node 2]
=> [Node 3]
=> [Node 4]

Dieses Szenario mal durchgespielt:
Der Client sendet seine verschlüsselte Daten an Node1, die Checksummen
seiner Chunks auch an Node2, 3 und 4. Wenn Node1 jetzt böse ist und
die Chunks verändert (= mit anderer Checksumme) weiter verteilt,
erkennen wir ihn sofort als bösen Node im Netz und können ihn
aussperren.

P.S.: Dieses Szenario schließt nicht aus, dass Client und Node der
gleiche Rechner sind und das Chunks von einer Datei an verschiedene
Nodes gehen. Aber es hilft böse Nodes zu entdecken.

[Christian Kaps]

Am 24.08.2011 12:44, schrieb dennis:
> Mag sein, dass ich zu den weniger versierten Developern geh�re was
> Verschl�sselung betrifft oder einfach nur auf dem Schlauch stehe, aber
> wie wollt ihr das machen, dass jeder Node seine Chunks verschl�sselt?
>
> Angenommen ein Node erh�lt Daten (egal ob verschl�sselt oder
> unverschl�sselt) und wir arbeiten mit einem Public/Private Key

> verfahren. Wenn ich als Node die Daten nun mit meinem Public Key

> verschl�ssle sind sie erstmal sicher. Denn zum entschl�sseln brauche

> ich meinen Private Key - und den kenne nur ich. Aber wie gebe ich die

> Daten jetzt weiter? Wenn ich den Chunk verschl�sselt weitergebe, dann

> kann mein Nachbar Node die Chunks nicht lesen, denn er kennt meinen
> Private Key nicht. Wenn ich dann aber als sozusagen "Master-Node"

> dieses Chunks vom Netz gehe und mein Private Key f�r immer verloren
> geht, wird es uns innerhalb des Grids nie wieder m�glich sein diesen
> Chunk zu entschl�sseln.
> Verschl�sselung mit dem Private Key macht keinen Sinn ... dann kann es
> jeder entschl�sseln.

> Wo ist hier mein Denkfehler? Oder redet ihr hier nur davon, dass jeder

> Chunk seine Daten vor der Ablage auf der Platte verschl�sselt? Dann
> vergesst meinen Kommentar ;)
>
> Was ich mir zzt. vorstellen w�rde: Der Client verschl�sselt seine

> Daten selbst mit seinem Public Key. Dann kann nur er die Daten

> entschl�sseln, so wie es sein soll. Der erste Node der die Daten
> erh�lt signiert sie mit seinem Private Key. Damit gew�hrleisten wir
> Datenintegrit�t.
> Wenn wir jetzt einen "b�sen" Node im Netz haben kann der h�chstens die

> Daten kaputt machen, lesen kann er sie aufgrund von Client-seitiger

> Verschl�sselung sowieso nicht. Au�erdem k�nnen wir Chunks von "b�sen"
> Clients anhand der Signatur erkennen sobald wir den "b�sen" Node
> identifiziert haben.

Jeder Node/Client hat einen �ffentlichen und eine privaten Schl�ssel.
Der private Schl�ssel bleibt auf dem Node/Client. Sendet jetzt ein
anderer Node/Client eine Datei so l�dt er vom Ziel den �ffentlichen
Schl�ssel herunter. Danach verschl�sselt er die Datei und schickt Sie
zum Ziel. Das Ziel kann die Datei jetzt mit dem privaten Schl�ssel
entschl�sseln.

Gru� Christian

[Michael Kliewe]

Das löst aber nicht das Grundproblem von Robert: Wenn mein Node seinen
Speicherplatz zur Verfügung stellt, und jemand anderes lädt geschützte
Daten auf meinen Node, dann liegen diese Dateien auf meiner
Festplatte. Nehmen wir an es sind Kinderbildchen. Das möchte ich
natürlich verhindern, da bringt es nichts wenn ich selbst diese Daten
verschlüssele, denn ich kann (und muss) sie ja auch wieder
entschlüsseln können. Ich muss also sicherstellen, dass die Daten, die
ich auf meiner Festplatte speichere, bereits verschlüsselt sind, und
ich sie nicht entschlüsseln kann. Ich kann also nicht wissen was da
jemand anderes auf meine Festplatte geladen hat.

Ich brauche also eine Möglichkeit der Erkennung, ob die Daten die ich
zugeschickt bekomme bereits verschlüsselt sind (nämlich vom
ursprünglichen Client, der die Datei hochgeladen hat). Wenn jemand
eine unverschlüsselte Datei bei mir hochladen möchte verweigere ich
das, um mich nicht möglicherweise strafbar zu machen. Beim Beispiel
PGP müßte ich also sicherstellen dass die entsprechenden Header da
sind a la
-----BEGIN PGP MESSAGE-----
...
...
-----END PGP MESSAGE-----

Ähnliches sollte mit jedem Verfahren möglich sein.

Die Idee mit der Signatur finde ich auch gut, um sicherzustellen dass
nicht ein böser Node (oder ein schlecht programmierter) verfälschte
Daten verbreitet.

Über eine Art Reputationsliste hatte ich auch schon nachgedacht, also
wenn sich ein Node komisch/böse verhält bekommt er eine niedrigere
Priorität/Reputation/Karma oder was auch immer, und wird ab dann wenn
es geht gemieden. So könnte ich auch beispielsweise Nodes, die 24/7
online sind, eine höhere Priorität geben als Nodes die öfter mal
offline sind. Oder ich programmiere meinen Client so dass er meinen
zweiten Node, der auf meinem Rootserver läuft, immer bevorzugt, und
alle anderen Nodes erst danach gefragt/kontaktiert werden.

[Matthias Dunkel]

Wieso PGP?

Ich wäre für eine "klassische" Verschlüsselung.

Ich nehme meine Datei(en), verschlüssele sie mit meinem Schlüssel
(Passwort) und lade sie in das "Grid". Dort ist es ja dann egal was
mit der Datei (dem Dateistückchen) passiert. Niemand kann es einsehen.
Wenn ich die Datei dann wieder will, entschlüssle ich sie einfach
wieder mit meinem Schlüssel...

Oder mache ich einen Denkfehler?

Dann kann "ich" als Client selbst entscheiden was ich für
Verschlüsselungen verwenden will, und wie aufwändig diese sein
sollen...

P.S.: Wie wollt ihr überprüfen, ob eine Datei verschlüsselt ist oder
nicht?

[Flyingmana]

Ich denke PGP ist durch das Publik/Private Key Prinzip recht gut geeignet.
Das könnte man dann später noch weiter ausbauen, dass man bestimmten Datein mit anderen Schlüsseln verschlüsselt, und so was wie Gruppen-storage ermöglicht.
Die Identifizierung ob einem die Datei gehört, wäre dann über Signaturen die mittels PGP erstellt werden möglich. Somit könnte man auch so was wie signierte löschbefehle ins Grid schicken, falls man seine Datei wieder löschen will.

Die Verschlüsselung sollte in jedem Fall aber schon im Clienten passieren, da sie sonst simpel keinen Sinn macht. Schließlich könnte der Inhalt ja schon auf dem Weg abgefangen werden oder von einem bösen Storage Node unverschlüsselt gespeichert werden.
Die rechtliche Sache solltet ihr aber in einer extra Diskussion besprechen(wobei ich der Meinung bin, die kann allgemein bis später warten.)

[Robert Kummer]

Also PGP halte ich auch für sinnvolll. Es geht auch GnuPG.
Bzgl. meinem ersten Beitrag mit PKI-Struktur hatte ich in der Tat
einen Denkfehler, wie dennis bemerkte.

Aber grundsätzlich sind wir uns einig, dass wir nur verschlüsselte
Sachen physisch speichern wollen, oder? Zur Datenintegrität kann noch
eine Signatur ergänzt werden, fertig. Der Upload ist derzeit das
Problem. Nun kenne ich mich da nicht so weit aus im rechtlichen,
stelle aber hier einfach mal die Frage: kann ein Client beim Upload
des Nutzers nicht einfach eine Stromverschlüsselung a la rot13 oder
sowas machen? Würde das nicht ausreichen um "Kinderbilder" nicht mehr
lesbar zu haben?

[Robert Kummer]

On 24 Aug., 14:36, Michael Kliewe <michael.kli...@googlemail.com>
wrote:

> Über eine Art Reputationsliste hatte ich auch schon nachgedacht, also
> wenn sich ein Node komisch/böse verhält bekommt er eine niedrigere
> Priorität/Reputation/Karma oder was auch immer, und wird ab dann wenn
> es geht gemieden. So könnte ich auch beispielsweise Nodes, die 24/7
> online sind, eine höhere Priorität geben als Nodes die öfter mal
> offline sind. Oder ich programmiere meinen Client so dass er meinen
> zweiten Node, der auf meinem Rootserver läuft, immer bevorzugt, und
> alle anderen Nodes erst danach gefragt/kontaktiert werden.

So eine Reputationsliste ist recht wichtig. Damit können wir die
Dienstequalität unterschiedlicher Nodes in Erfahrung bringen. Da ja
das gesamte Grid dezentral organisiert ist, ist solch eine
Auskunftsliste schon sehr wichtig.

[dennis]

> Jeder Node/Client hat einen ffentlichen und eine privaten Schl ssel.
> Der private Schl ssel bleibt auf dem Node/Client. Sendet jetzt ein
> anderer Node/Client eine Datei so l dt er vom Ziel den ffentlichen
> Schl ssel herunter. Danach verschl sselt er die Datei und schickt Sie
> zum Ziel. Das Ziel kann die Datei jetzt mit dem privaten Schl ssel
> entschl sseln.

Damit sicherst du aber nur die kommunikation zwischen den Nodes. Dafür
kannst du auch SSL nutzen, dass sollte weniger Arbeit sein.
Es ging hier aber wohl eher darum, dass die Nodes die Daten
verschlüsselt lagern.
Wichtig ist dass aus 2 Gründen:
1.) Niemand soll meine Daten lesen können
2.) Ich als Nodebetreiber will mich nicht strafbar machen wenn ich
rechtlich fragwürdige Dateien speichere.

Ich gebe mal ein +1 für Clientseitige Verschlüsselung und die Nodes
nehmen nur verschlüsselte Daten an. Damit senkt man die Komplexität
eines Nodes. Die Verbindung kann dann entweder mit SSL gesichert
werden oder über Public/Private Key Verfahren die Chunks signiert
werden. Damit ist die Kommunikation zwischen beiden Nodes gesichert
und die Integrität wird gewahrt. Eine zusätzliche Verschlüsselung auf
dem Node könnten wir später hinzunehmen, bzw wäre dass dann Aufgabe
des jeweiligen Node Betreibers (obwohl ich mir noch nicht sicher bin
ob das überhaupt irgendeinen Sinn hat dann noch einmal auf dem Node zu
verschlüsseln wenn die Daten zuvor eh schon verschlüsselt sind).

[MKuckert]

Eine Verschlüsselung der Dateien am Node finde ich super wichtig -
sonst würde ich nie Dateien in das Netz legen. Wenn PGP als Verfahren
genutzt werden soll haben wir direkt die Möglichkeit Empfänger für
Dateien zu implementieren, d.h. auch andere Nodes können Dateien
wieder entschlüsseln und das Netz kann nicht nur als Speicher sondern
auch zum Transfer genutzt werden. Wenn die Dateien verschlüsselt sind,
muss die Übertragung nicht mehr zwingend verschlüsselt werden - wenn
jeder Node denn eine Signatur an die Nachricht anfügt, um die
Integrität der Übertragung zu gewährleisten. Man könnte sich
allerdings darüber streiten, ob die Header schützenswert sind.

[dennis]

Ich glaube wir sollten erst einmal ein paar Begriffe klären - sonst
reden wir am Schluss noch aneinander vorbei und merken es garnicht.
Können wir uns auf die Begriffe Node und Client wie folgt einigen:

Client: Ein Client ist ein Teilnehmer des Netzwerkes der selbst keine
Daten speichert, sondern nur Daten ins Netzwerk schieben möchte. Er
ist sozusagen die lokale Schnittstelle des jeweiligen Benutzers.

Node: Ein Node ist ein Teilnehmer des Netzwerkes, der Daten speichern
kann, Daten an andere Nodes versendet, Node listen austauschen kann
etc/pp.

Client und Node können durchaus auf dem gleichen physikalischen Gerät
laufen (das soll in diesem Projekt sogar so sein), aber es sind
erstmal zwei unterschiedliche Entitäten. Zum Beispiel könnte man sich
den Client als "GUI" auf dem lokalen Rechner denken, den Node als
Dienst im Hintergrund.
Wenn die Semantik jetzt soweit geklärt ist zurück zur Verschlüsselung.

Ich fände eine _Clientseitige_ Verschlüsselung am sinnvollsten. D.h.
das ein Node erhält niemals eine unverschlüsselte Datei, dass passiert
alles schon im Client. Damit muss auch niemand Angst haben, dass seine
Daten unverschlüsselt ins Netz gelegt werden. Wir müssen uns weiter
keine Sorgen darüber machen, dass die Daten wieder entschlüsselt
werden können und dass die Schlüssel dafür verloren gehen - dies liegt
alles in der Verantwortung des Clients und damit letztlich beim User.
Die Nodes sind nur Verteiler.

[Flyingmana]

+1 dennis

[MKuckert]

Die Differenzierung in Client und Node macht in der Tat Sinn und
erleichtert die Überlegungen, wann und wo verschlüsselt wird.
Generelle Voraussetzung für einen Client ist dann, dass eine
ausreichende Verschlüsselung auf die Chunks angewendet wird, so dass
sich kein Node über Urheberrechte oder solche Geschichten sorgen muss.
Das nimmt die Verschlüsselung aus dem eigentlichen Protokoll heraus
und macht die Sache einfacher.

[Sascha Ohms]

Naja, dass die Verschlüsselung nicht ins Protokoll gehört, außer evtl. die Überprüfung, ob oder ob nicht, war ja grundlegend von Anfang an klar. Man kann ja einfach eine Supported-Liste machen und diese durchprüfen. Mit "file dateiname" kann man ja relativ einfach herausfinden, mit was die Datei verschlüsselt wurde. Jedenfalls bei den Gängigsten.

Mfg
Sascha

[corvus]

wie wärs mit mime-type erkennung um zu checken ob ein file nicht
verschlüsselt ist?

http://de.wikipedia.org/wiki/Internet_Media_Type

On 25 Aug., 19:26, Sascha Ohms <sasc...@gmail.com> wrote:
> Naja, dass die Verschlüsselung nicht ins Protokoll gehört, außer evtl. die Überprüfung, ob oder ob nicht, war ja grundlegend von Anfang an klar. Man kann ja einfach eine Supported-Liste machen und diese durchprüfen. Mit "file dateiname" kann man ja relativ einfach herausfinden, mit was die Datei verschlüsselt wurde. Jedenfalls bei den Gängigsten.
>
> Mfg
> Sascha

>

>  smime.p7s
> 5KAnzeigenHerunterladen

[corvus]

am anfang würde ich sagen sollte man eine verschlüsselungsmethode für
die chunks fest vorgeben (z.B. AES).
würde man das nicht machen würde ein wildwuchs an clients mit
verschiedenen verschlüsselungsmethoden entstehen und man kann schlecht
die dateien von client A mit client B herunterladen.

szenario:
user A ladet mit client A mit verschlüsselung AES eine datei XYZ für
user B hoch.
user A teilt user B mit welche datei er laden soll (XYZ) und welches
passwort zum entschlüsselung verwendet werden soll.
user B ladet nun mit client B die datei XYZ kann sie aber nicht
entschlüsseln da client B nur PGP beherrscht. also muss sich user B
erstmal client A besorgen damit er das file laden kann.

macht das sinn??

[Sascha Ohms]

Ein wenig OT: Nur damit wir uns hier richtig verstehen. Hier sind nämlich die ersten "offiziellen" Ansätze, dass man unter mehreren Nutzern Dateien austauschen kann. Bislang war _ausschließlich_ die Rede davon, dass ein einzelner Nutzer, seine Dateien ins Grid hauen kann und sie ggf. an anderer Stelle selbst auch wieder herunterladen kann. das Prinzip, was du gerade ansprichst deutet nämlich am Ende auf ein Anonymes Filesharing Netz, was absoluter Crap ist und ich mich persönlich dann sofort aus dem Projekt ausklinken werde! Natürlich ist es klar, dass mehrere Nutzer einen einzelnen Public / Private Key nutzen können, und somit auch Filesharen können. Aber das ist immernoch ein anderes Thema.

Sascha

[corvus]

man kann es dann dafür zweckentfremden. egal ob man dateiaustausch
direkt implementiert oder nicht! denn jeder kann die chunks laden wenn
er will, nicht nur ich, denn über die masterserver kann man sich ja
die chunklisten geben lassen. außer man implementiert das protokoll so
das nur ich mit meinem key zugriff auf die chunkliste/chunks bekomme!

deshalb direkt sich ausklinken find ich persönlich etwas
übertrieben...

>  smime.p7s
> 5KAnzeigenHerunterladen

[MKuckert]

Möglich ist das Erkennen einer Verschlüsselung sicherlich. Zu
entscheiden wäre, ob eine Verschlüsselung vom Protokoll zwingend
erfordert werden soll, oder ob diese optional ist. Sicherlich wird
nicht jeder öffentliche Node unverschlüsselte Dateien annehmen wollen
- eben genau aufgrund möglicher Urheberrechtsverletzungen, etc.

On 25 Aug., 19:26, Sascha Ohms <sasc...@gmail.com> wrote:

>  smime.p7s
> 5KAnzeigenHerunterladen

[MKuckert]

Muss der Master denn eine gesamte Chunkliste bereitstellen? Das Suchen
nach eigenen Chunks sollte sicher ausreichen und verhindert, das jeder
Client beliebige Chunks herunterladen kann. Der Vorteil einer
Gesamtliste wäre, dass alle Chunks eines Nodes ohne Probleme
repliziert werden können, indem die Liste und anschließend die Chunks
heruntergeladen werden.

[Markus]

Verschlüsselung ist allein Sache des Clienten. Einem Node kann man
nicht trauen. ;-)
Verschiedene Standard-Verschlüsselungen (AES und co) gibt es wohl in
jeder Programmiersprache, das dürfte unproblematisch sein. Will man
sich da auf eine mit einer bestimmten Schlüsselstärke einigen oder
verschiedene erlauben? Soll Leute geben die sind paranoid. ^^

Ein Node kann zwar bis zu einem gewissen Grad erkennen ob er
verschlüsselte Daten bekommt aber auch nicht 100%. Wenn ein Node nur
verschlüsselte Daten speichern will, soll/muss er es eben nochmal
verschlüsseln, nur so kann er sicher sein. Ein Client kann da immer
behaupten die Daten seien verschlüsselt, und dann sind es
"Kinderbildchen". Dem kann man auch nicht trauen.

Die Frage ob ein Node explizit unverschlüsselte Daten annehmen können
soll müsste man mal diskutieren. Gibt es da sinnvolle Use-Cases für?

Auch sollen (und sollten) die Daten in Chunks zerlegt werden, wenn nur
der Client weiß wie die zusammengehören (ist das so?) kann man mit den
Datenhäppchen, wo ein Node vielleicht auch nicht alle Teile hat,
wahrscheinlich auch weniger anfangen. Selbst wenn er die nicht
nochmals verschlüsselt (was aufgrund der rechtlichen Problematik schon
Blöd wäre).

Ein PKI-System wäre natürlich toll: zu ermitteln woher Daten kamen,
Daten löschen/updaten können, Reputationslisten etc, aber für den
Anfang (erste Version des Protokolls?) braucht man das denke ich
erstmal nicht. Das hebt enorm die Einstiegshürde meiner Meinung nach.
Erstmal klein anfangen. :)
Ich hab das auch eher als Spaß-Aktion verstanden und nicht um ein 2.
Bittorrent oder freenet nachzubauen.

[corvus]

On 25 Aug., 22:53, Markus <masel...@googlemail.com> wrote:
> Verschlüsselung ist allein Sache des Clienten. Einem Node kann man
> nicht trauen. ;-)

jepp da stimm ich zu.
zudem sollte man auch bedenken: wenn ein Node nochmal alles
verschlüsselt auf der HDD ablegt was er bekommt dann kann das evtl.
auf die performance gehn. denn bei jedem download von chunks muss die
CPU erstmal entschlüsseln (außer man hat z.B. ein i3/5/7 system mit
extra AES chip. aber die will auch erstmal angesprochen werden...).
das würde ich den nodebetreiber selbst wählen lassen...

der nodebetreiber kann die chunks auch in ein TrueCrypt container
legen oder ne TrueCrypt partition. So muss der Node sich nich um
verschlüsselung kümmern und die chunks sind sicher verschlüsselt ;)
(mein i7 system schafft bei 500KB buffer ohne AES accel "nur" etwas
über 200MB/s und mit AES accel etwas über 600MB/s... das is
wahrscheinlich schneller als jede selbst integrierte verschlüsselung.)

[Markus]

Das stimmt natürlich, das kostet Leistung.
Habs mal eben in PHP 5.3.8 getestet, Intel Xeon E5620 @ 2.40GHz
(vServer)
128 bit blocksize, 192bit Keysize

Twofish ~100 Mbyte/s
AES (Rijndael) ~ 53 MByte/s
Serpent ~46 MBytes/s

Scheint mir nicht so das PHP die AES-NI der CPU nutzt?

[Markus]

Der Test war per mcrypt 1 MByte Zufallsdaten, da gibt es wohl noch
kein AES-NI.

OpenSSL per PHP 5.3.8, kommt auf dem selben System auf 100 / 70 Mbyte/
sec für AES-192-CBC, und da gibt es bald offiziell AES-NI support, was
dann etwa Faktor 3-5 schneller sein dürfte.

Das ist auch alles Singlethread gemessen.
Die Verschlüsselung ist jetzt also nicht unbedingt ein Problem, vorher
lastet man wahrscheinlich eher die Anbindung aus. ^^