Cipher noch einmal ...

Geschrieben von Dirk Deimeke am Samstag, 25. September 2010

Auf Nachfrage von Alex in den Kommentaren dieses Artikels, habe ich den Test auch noch mit Localhost gemacht.

Mit diesem Skript:

#!/bin/bash

for cipher in 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr arcfour128 arcfour256 arcfour blowfish-cbc cast128-cbc
do
echo ${cipher}
for i in {1..3}
do
dd if=/srv/iso/ubuntu-10.04.1-server-i386.iso 2>/dev/null | ssh -o "Ciphers ${cipher}" localhost dd of=/dev/null 2>&1 | tail -1
done
echo
done

Der beste mittlere Wert ist wieder hervorgehoben:

3des-cbc 705077248 bytes (705 MB) copied, 43.7986 s, 16.1 MB/s 705077248 bytes (705 MB) copied, 46.7042 s, 15.1 MB/s 705077248 bytes (705 MB) copied, 43.7314 s, 16.1 MB/s aes128-cbc 705077248 bytes (705 MB) copied, 9.3959 s, 75.0 MB/s 705077248 bytes (705 MB) copied, 9.46145 s, 74.5 MB/s 705077248 bytes (705 MB) copied, 9.94794 s, 70.9 MB/s aes192-cbc 705077248 bytes (705 MB) copied, 10.3159 s, 68.3 MB/s 705077248 bytes (705 MB) copied, 10.6935 s, 65.9 MB/s 705077248 bytes (705 MB) copied, 10.9322 s, 64.5 MB/s aes256-cbc 705077248 bytes (705 MB) copied, 11.2965 s, 62.4 MB/s 705077248 bytes (705 MB) copied, 11.8836 s, 59.3 MB/s 705077248 bytes (705 MB) copied, 11.4744 s, 61.4 MB/s aes128-ctr 705077248 bytes (705 MB) copied, 13.4396 s, 52.5 MB/s 705077248 bytes (705 MB) copied, 13.4175 s, 52.5 MB/s 705077248 bytes (705 MB) copied, 12.8931 s, 54.7 MB/s aes192-ctr 705077248 bytes (705 MB) copied, 16.1927 s, 43.5 MB/s 705077248 bytes (705 MB) copied, 13.1323 s, 53.7 MB/s 705077248 bytes (705 MB) copied, 15.8256 s, 44.6 MB/s aes256-ctr 705077248 bytes (705 MB) copied, 15.2297 s, 46.3 MB/s 705077248 bytes (705 MB) copied, 17.889 s, 39.4 MB/s 705077248 bytes (705 MB) copied, 18.0179 s, 39.1 MB/s arcfour128 705077248 bytes (705 MB) copied, 7.51314 s, 93.8 MB/s 705077248 bytes (705 MB) copied, 7.46925 s, 94.4 MB/s 705077248 bytes (705 MB) copied, 7.40912 s, 95.2 MB/s arcfour256 705077248 bytes (705 MB) copied, 7.43831 s, 94.8 MB/s 705077248 bytes (705 MB) copied, 7.47133 s, 94.4 MB/s 705077248 bytes (705 MB) copied, 7.52313 s, 93.7 MB/s arcfour 705077248 bytes (705 MB) copied, 7.16657 s, 98.4 MB/s 705077248 bytes (705 MB) copied, 7.33755 s, 96.1 MB/s 705077248 bytes (705 MB) copied, 7.10961 s, 99.2 MB/s blowfish-cbc 705077248 bytes (705 MB) copied, 14.8319 s, 47.5 MB/s 705077248 bytes (705 MB) copied, 18.36 s, 38.4 MB/s 705077248 bytes (705 MB) copied, 15.9737 s, 44.1 MB/s cast128-cbc 705077248 bytes (705 MB) copied, 21.3008 s, 33.1 MB/s 705077248 bytes (705 MB) copied, 25.2206 s, 28.0 MB/s 705077248 bytes (705 MB) copied, 19.5291 s, 36.1 MB/s

Und, was sagt das ganze nun?

Es gibt nicht den einen perfekten Cipher-Algorithmus, manche Cipher verlangen viel Power auf dem Server, andere viel Power auf dem Client. Man muss je nach Anwendungsgebiet den richtigen auswählen.

Trackbacks

Trackback-URL für diesen Eintrag

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

crazypeanut am Samstag, 25. September 2010:

TIPP: Schaut euch mal die Padlock Engine von VIA an. Damit laufen die Cipher in Hardware und sind um ein Vielfaches schneller. Unterstützt wird das Ganze z.B. vom Samsung NC20 AnyNet und von den meisten Mainboards mit VIA C7, VIA Eden und VIA Nano Prozessoren. Natürlich gibts die entsprechenden Kernelmodule out of the Box, und OpenSSH/SSL macht da auch mit...

Dirk Deimeke am Samstag, 25. September 2010:

Danke Dir für den Tipp. Das bedingt aber, dass solche Hardware an Quelle und Ziel vorhanden ist, oder? Für bestehende Hardware bringt das vermutlich nichts.

Alex am Samstag, 25. September 2010:

Danke für den Artikel!

Dirk Deimeke am Sonntag, 26. September 2010:

Gerne!

Flyingmana am Samstag, 25. September 2010:

ich glaub du hast bei dem ganzen Thema einen Punkt vergessen.
Die Sicherheit, um die es bei SSH ja gewissermaßen geht.

Geschwindigkeit ist ja gut und schön, aber wenn der Inhalt oder die Verbindung dadurch an Sicherheit verlieren würden, wäre das doch unschön.

Betz Stefan am Samstag, 25. September 2010:

Ich finde den Test so vollkommen OK. Es zeigt aber auch das veraltete Verfahren wie 3DES absolut sinnfrei sind.

Das 3DES einfach nur lahm ist wundert mich übrigens nicht, man verschlüsselt es halt 3x mit dem alten DES Chiper!

Die Standardreihenfolge von OpenSSH ist z.B. aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour womit bei einem OpenSSHd in Standardkonfiguration wohl immer aes128ctr gewählt werden sollte. AES gilt als relativ sicher und ist noch dazu im Test von Dirk auch noch im Mittelfeld vertreten was die Performance angeht.

mfg Betz Stefan

Dirk Deimeke am Sonntag, 26. September 2010:

Im lokalen Netz ist arcfour sicher eine gute Alternative und den einen besten Weg gibt es nicht.

Das Problem ist, wenn Du einen leistungsschwachen Client - auf CPU bezogen -hast, musst Du schauen, dass Du einen Cipher benutzt, der auf dem Client nicht so viel Last erzeugt. Umgedreht, wenn Du einen CPU schwächeren Server hast, musst Du auch da die entsprechende Variante wählen.

Ich habe bei mir jetzt als erstes blowfish und danach die AES-Ciphers, angefangen bei "256", in die ssh-Optionen eingetragen.

Dirk Deimeke am Sonntag, 26. September 2010:

Wenn Du mal in den Ursprungsartikel schaust, findest Du den Satz: "Wichtig: Das sagt nur etwas über Übertragungszeiten und nicht über die Qualität der Ciphers aus!"