ubuntuusers.de

DM-Crypt Cipher Performance

Status: Ungelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |

raptor2101

Anmeldungsdatum:
8. Juni 2009

Beiträge: 1249

Wohnort: Stuttgart, Deutschland

Da ich die Frage häufig in Foren rumgeistern sehe und gestern selber vor der Frage stand, welchen Cipher ich verwenden soll und was der an Leistung Kostet, hab ich mir mal die Nacht um die Ohren geschlagen,

Ich hab mal alle DM-Crypt Cipher durchprobiert. Serpent hab ich außen vor gelassen. Bei 32 Runden pro Block war die Performance signifikant schlechter als AES und Twofish. TrueCrypt hab ich mal außen vor gelassen, da dies nicht RAID-Tauglich ist (ein TC-Container kann nicht vergrößert/verkleinert werden) und die hier zusammengestellten Informationen eher Cipher denn Tool-Abhängig sind.

Als Testbasis diente ein 2.5 GHz Core 2 DUO mit 4 GB Ram. Als RAID-Controler kam ein 3Ware 9650 zum Einsatz der unter "Normalbedingungen" seine 300 MByte/s auf den RAID 5 schaufelt. Dieser wurde anschließend mit jedem der aufgeführten Ciphers verschlüsselt und mit XFS formiert. Anschließend durfte bonnie++ jeweils 8 GByte Testdaten aufspielen und auswerten. Die Testdaten ergeben dann folgendes Bild:Diagramm

Testdaten im ODS-Format Alle angaben sind in KByte/s. Standart-Client, SMB-Client und 1GBit-Lan sind Referenzwerte um die benötigte Leistung abzuschätzen.

Interessanteste Information für alle die über Festplattenverschlüsselung nachdenken: der Leistungsverlust der durch die Verschlüsselung erzeugt wird skalliert nicht linear. Es sind nicht immer X%. Jeh nachdem wie stark die CPU unterdimensioniert ist kann man durchaus 80% und mehr verlieren. Ein blick auf die Cipher-Performance ist ratsam. In einigen Bereichen ist der Verlust aber auch kleiner als 5%

Eine ausführlichere Auswertung hab ich hier zur Verfügung gestellt.

Red_Radish

Anmeldungsdatum:
7. September 2007

Beiträge: 770

Raptor 2101 schrieb:

Warum testet du Ciphern, die sowieso keiner einsetzen wird? aes-xts-essiv:sha256 und ähnliches ist nicht vorgesehen. Es gibt aes-cbc-essiv:sha256, aes-lrw-benbi oder aes-xts-plain. Vieles andere wird zwar ärgerlicherweise geschluckt, führt aber teilweise zu überraschenden Ergebnissen,... Zudem fehlen entscheidende Angaben:

- welches Architektur: 32bit vs. 64bit - das macht hier einen Unterschied

- welches Verschlüsselungs-Modul hast du verwendet: es gibt jeweils zwei gängige für aes und twofish: einmal die C-Variante (etwa: aes.ko) und einmal die in Assembler (etwa: aes-i586) ( Für Via neue Intelprozessoren und andere es nochmals Spezialversionen,... )

- welche Kernel-Version? Neuere Kernel sollen Parallelisierung unterstützen, alte nicht.

raptor2101

(Themenstarter)

Anmeldungsdatum:
8. Juni 2009

Beiträge: 1249

Wohnort: Stuttgart, Deutschland

die angaben hab ich tatsächlich vergessen, wobei ich davon ausging, das bei einem Core2Duo 64 Bit als standart angenommen wird 😉

Hier nochmal der Nachtrag: 64 Bit, Ubuntu 9.04 Server

Kernel 2.6.28-15

Als AES modul kam das standart aes_x86_64 zum Einsatz. Das Assembler Modul will ich heute mal testen 😉

Wenn du mir noch erklärst worum gewisse Kombinationen nicht "genutzt" werden sollen, wär ich dankbar. Informationsgewinn ist immer gut 😉

Red_Radish

Anmeldungsdatum:
7. September 2007

Beiträge: 770

Raptor 2101 schrieb:

die angaben hab ich tatsächlich vergessen, wobei ich davon ausging, das bei einem Core2Duo 64 Bit als standart angenommen wird 😉

Hier nochmal der Nachtrag: 64 Bit, Ubuntu 9.04 Server

Kernel 2.6.28-15

Als AES modul kam das standart aes_x86_64 zum Einsatz. Das Assembler Modul will ich heute mal testen 😉

Das ist das Assembler-Modul. Bei neueren Ubuntu-Versionen wird in der Regel automatisch das Richtige geladen - das klappt aber nicht immer,...

Wenn du mir noch erklärst worum gewisse Kombinationen nicht "genutzt" werden sollen, wär ich dankbar. Informationsgewinn ist immer gut ;

Manche Dinge sind standardisiert bzw. werden allgemein benutzt - das legt den Schluss nahe, dass es Leute gibt, die sich darüber Gedanken haben. Bei Konstrukten ala 'aes-xts-essiv:sha256' dagegen ist überhaupt nicht so klar, was damit erreicht werden soll. Weißt du das? Essiv wird normalerweise verwendet, um einen besseren Initalisierungsvektor für cbc zu bekommen. xts ist aber eine ECB-Variante - da braucht man keine Initialisierungsvektor. Und xts hat schon Mechanismen eingebaut, um das gleiche zu erreichen für das essiv im Zusammenhang mit cbc eingesetzt wird. Die zusätzliche Hash-Operation kann man sich also sparen - das kostet nur Geschwindigkeit. Und dass das Konstrukt wie 'aex-xts-essiv:sha256' von cryptsetup bzw. Kernel geschluckt wird sagt noch gar nichts. Die schlucken auch noch ganz andere Dinge:

echo 'test' | cryptsetup -s 512 -c arc4-cbc-essiv:sha256 create test /dev/sda1
head -c 256k /dev/mapper/test | sha1sum  
head -c 256k /dev/mapper/test | sha1sum  
head -c 256k /dev/mapper/test | sha1sum # Huch? - Warum kommt da nur jedesmal was anderes? Es wurde doch gar nichts geändert,...

edit:

Kernel 2.6.28-15

Schneller wird es ab Kernel 2.6.30 ( dual core oder mehr vorausgesetzt ) http://www.heise.de/open/artikel/Flotter-verschluesseln-schneller-starten-Sicherheits-Framework-Tomyo-224636.html

raptor2101

(Themenstarter)

Anmeldungsdatum:
8. Juni 2009

Beiträge: 1249

Wohnort: Stuttgart, Deutschland

ok hab den aes-lrw-benbi und aes-xts-plain noch getestet und eingetragen

raptor2101

(Themenstarter)

Anmeldungsdatum:
8. Juni 2009

Beiträge: 1249

Wohnort: Stuttgart, Deutschland

Red Radish schrieb:

Wenn du mir noch erklärst worum gewisse Kombinationen nicht "genutzt" werden sollen, wär ich dankbar. Informationsgewinn ist immer gut ;

Manche Dinge sind standardisiert bzw. werden allgemein benutzt - das legt den Schluss nahe, dass es Leute gibt, die sich darüber Gedanken haben. Bei Konstrukten ala 'aes-xts-essiv:sha256' dagegen ist überhaupt nicht so klar, was damit erreicht werden soll. Weißt du das? Essiv wird normalerweise verwendet, um einen besseren Initalisierungsvektor für cbc zu bekommen. xts ist aber eine ECB-Variante - da braucht man keine Initialisierungsvektor. Und xts hat schon Mechanismen eingebaut, um das gleiche zu erreichen für das essiv im Zusammenhang mit cbc eingesetzt wird. Die zusätzliche Hash-Operation kann man sich also sparen - das kostet nur Geschwindigkeit. Und dass das Konstrukt wie 'aex-xts-essiv:sha256' von cryptsetup bzw. Kernel geschluckt wird sagt noch gar nichts. Die schlucken auch noch ganz andere Dinge:

echo 'test' | cryptsetup -s 512 -c arc4-cbc-essiv:sha256 create test /dev/sda1
head -c 256k /dev/mapper/test | sha1sum  
head -c 256k /dev/mapper/test | sha1sum  
head -c 256k /dev/mapper/test | sha1sum # Huch? - Warum kommt da nur jedesmal was anderes? Es wurde doch gar nichts geändert,...

Ich gestehe, in kryptografische Untiefen hab ich mich bis jetzt noch nicht eingearbeitet. Ich hab mir einfach die Konstrukte rausgekrallt die mir beim Lesen über das Thema am meisten über den weg gelaufen sind. Die Informationen im Gentoo Wiki hatten mir fürs erste gereicht. Leider hat mir ein klarer Hinweis, welche die Standart-Verschlüsselungen sind gefehlt hätte mir ca 2 Stunden Testarbeit gespart. Danke für den Hinweis. Wenn du das aber weißt, erweitere doch die Ubuntu-WIki-quellen. Damit nicht noch andere Reintrampen. Denn so wie die meisten Einträge geschrieben sind, geben sie nur einen Algorithmus vor oder legen den Schluss nahe, dass man sich seinen Wunsch-Algorithmus basteln kann.

Das mit dem 30er Kernel hab ich schon gelesen gehabt, bloß werde ich auf meinem Server definitiv nur Ubuntu-Hauptquellen einbinden. Dann mal warten bis, die eingespielt werden... 😉

adun Team-Icon

Avatar von adun

Anmeldungsdatum:
29. März 2005

Beiträge: 8606

Durch den ganzen Bloat wirds irgendwie unübersichtlich. 😉

Interessant fände ich noch den "Ubuntu-Standard" mit ecryptfs mit aes und twofish.

raptor2101

(Themenstarter)

Anmeldungsdatum:
8. Juni 2009

Beiträge: 1249

Wohnort: Stuttgart, Deutschland

Hab den Bloat mal entfernt. So sollte mal schneller finden was mach sucht. Diagramm

Antworten |