Welche cyphers werden derzeit von den „public“-rheinufer-supernodes unterstützt?
salsa2012+umac und salsa2012+gmac sind mir bekannt.
Gibt es noch irgendwelche AES-varianten oder auch nur „null“?
Ich lese aus folgendem Post, die wären identisch zum Ruhrgebiet:
Hmm…
Sieht leider nicht so aus (wobei die Frage nach dem AES noch offen wäre)
Mon Mar 2 13:16:06 2015 daemon.warn fastd[12216]: Handshake with 5.45.97.8:10040 failed: sending error: no common methods are configured
Mon Mar 2 13:16:06 2015 daemon.warn fastd[12216]: Handshake with 37.120.160.50:10040 failed: sending error: no common methods are configured
AES frisst zuviel Rechenleistung, deswegen gibts die schlanke Streamcipher Salsa2012.
Die Rheinufer-Supernodes können AES in Hardware und für manche VPN-Offloader wäre das auch interessant. In diesem Fall ist AES auf jeden Fall vorzuziehen, da das dann weniger Last erzeugt als Salsa2012
Wenn die Admins das beschlossen haben, dann muss ich das halt respektieren.
d.h. „Null“ können sie nicht, aber AES?
Welchen denn davon?
„aes128-ctr+poly1305“
„aes128-gcm“
oder/und
„aes128-ctr+umac“
sorry, wenn ich so explizit nachfrage, aber ich möchte es schlicht verwenden.
Ich bin jetzt verwirrt, aber wenn das Zutriff was @freifunker sagt, dann muss ich ja nimmer groß herumtesten.
Ich denke die wenigsten Supernodes können aes in Hardware, auch bei uns kann es nur die Hälfte. Trotzdem ist für eine typische Server CPU aes viel leichter zu verarbeiten als der auf die Plaste Router optimierte Salsa2012. Man muss halt den auf dem schwächsten Gerät am besten laufenden Algorithmus verwenden um das beste aus der Situation heraus zu holen.
Wir haben das in Aachen auch noch nicht, ich denke aber wir werden das in den kommenden Tagen aktivieren.
Davon verspreche ich mir dass Offloader bei größeren Installationen einerseits performanter sind und zusätzlich die Supernodes weniger belasten.
Worauf beruht Deine Aussage? Jedenfalls nicht auf Fakten. In fastd wird AES128 im CTR Mode benutzt. In dieser Tabelle sind auf einer Intel Core 2 1.83 GHz CPU verschiedene Verfahren getestet worden, ohne Offloading. Und da outperformt Salsa2012 den AES128-CTR mal locker um das 4,6 Fache aus was den Durchsatz betrifft. Ebenso braucht Salsa2012 nur 2 Prozess Cycles gegenüber 12,6 bei AES um ein Byte zu verarbeiten.
Was bedeutet das? Wenn ihr euren Supernodes was gutes tun wollt, und ihr kein AES Offload habt, dann sperrt alles ausser Salsa2012. Denn jeder andere Cipher belastet die CPU eures Supernodes mehr als Salsa2012.
Worauf beruht Deine Aussage? Jedenfalls nicht auf Fakten. In fastd wird AES128 im CTR Mode benutzt. In dieser Tabelle1 sind auf einer Intel Core 2 1.83 GHz CPU verschiedene Verfahren getestet worden, ohne Offloading. Und da outperformt Salsa2012 den AES128-CTR mal locker um das 4,6 Fache aus was den Durchsatz betrifft.
Intel Core 2 ist doch aber auch fast schon antik… Zumindest alt genug, dass die noch keine AES-Erweiterungen haben.
Fast alles was i3/i5/i7 oder Xeon heißt kann AES-NI (aka AES in Hardware). Kann ich gerne noch einmal genauer raussuchen. Müsste aber auf der Wikipediaseite zu AES-NI schon draufstehen.
Ich denke die wenigsten Supernodes können aes in Hardware, auch bei uns kann es nur die Hälfte.
Ich hätte präzisieren sollen, ich sprach von Rheinufer. Da wurde doch jetzt auf ein einheitliches V-Server-Produkt umgestellt.
(Edit: Wobei es sein kann, dass ich mich geirrt habe, ich dachte an diesen Post, wo aber wie ich jetzt sehe nicht explizit von AES-NI gesprochen wurde, aber immerhin, dass es besser performt)
d.h. „Null“ können sie nicht, aber AES?
Ne, hab nur davon gesprochen, was die Hardware (mutmaßlich) kann, nicht was der fastd aktiviert hat 
Auf eigenen Tests.
Für die Verbindung zwischen den Supernodes verwenden wir, wie meines Wissens nach die meisten Domänen aes128-ctr+umac.
Mit diesem Verfahren habe ich weniger CPU Last/MBit auf der Supernode CPU beobachtet als mit salsa2012+umac.
Vielleicht hat ja der AMD Opteron 6176 ein Feature das diese Beschleunigung bewirkt, bei den anderen Supernodes habe ich es gar nicht erst getestet, da diese aes in Hardware unterstützten.
Ich habe ja auch geschrieben:
Wenn es also AES Offload gibt, dann ist natürlich die CPU Belastung geringer. Aber reine Knoten sollten nix anderes fahren als Salsa2012. Und ob sich ne gestandene x86 bzw. AMD64 CPU mit AES-NI als Offloader eignet um nen 50er VDSL auszulasten, obwohl das ne Atom CPU ohne AES Offload mit Salsa2012 schaffen könnte bei weniger Stromverbrauch muss jeder selber wissen.
Schade, dass ich nach wie vor nicht herausgefunden habe, ob ich „null“ nur nicht nutzen kann, weil meinem fastd dazu etwas fehlt oder ob es bei den Rheinufer-Supernodes explizit gesperrt wurde.
Wir unterstützen die folgenden Methods:
method "aes128-gcm";
method "salsa2012+umac";
method "salsa2012+gmac";
method "null+salsa2012+umac";
2 „Gefällt mir“
„null“ wird halt nicht unterstützt da wir sonst keine Authentifizierung haben. (Wir können dann kein Nodes Blacklisten wenn diese z.b. Probleme verursachen)
„null+salsa2012+umac“ funktioniert allerdings problemlos, dies ist nur geringfügig langsamer als „null“ aber bietet Authentifizierung der Clients.
Hier eine Liste der Methods und eine Erklärung dazu:
http://fastd.readthedocs.org/en/latest/manual/methods.html
3 „Gefällt mir“
Wir bieten „null“ auch nicht an, da wir uns verpflichtet sehen den Traffic vom Anschluss des Knoten Aufstellers bis zu unserem Schweden Exit Server nur verschlüsselt zu übertragen.
AES habe ich evaluiert und befinde, dass es sich nicht lohnt. Da der fastd-Dienst im Userspace läuft und auch mit Optimierungen für jedes Paket eine vielzahl von CPU-Zyklen zu durchlaufen ist, steigt der maximale Datendurchsatz nicht über ein paar hundert Mbit/s, obwohl mehr möglich sein müsste.
Ein Kollege hat das gleiche bei OpenVPN beobachtet, als er ebenso AES für CPU-Unterstützung konfiguriert hat. Im Gegensatz dazu hat er bei IPSEC durchaus 1 Gbit/s verschlüsselt übertragen bekommen.
Wir nehmen mit dem salsa2012+umac Rücksicht auf die Nodes, da diese den Flaschenhals bei der Übertragung bilden. Die derzeit zehn Supernodes haben noch reichlich Luft und sind bei 10-60% CPU-Auslastung (in der Spitze, ungleich verteilt) auch beim derzeit starken Wachstum noch für eine Weile nicht ausgelastet.