Benchmark: Festplattenverschlüsselung mit GBDE und GELI

Dr.Sweety

Fnord!
Hallo zusammen!

Ich habe aus aktuellem Bedarf Festplattenverschlüsselung unter FreeBSD mit GBDE und GELI (ist ziemlich neu) einem Benchmark unterzogen und die Ergebnisse online gestellt. Die Resultate finde ich noch interessant, ich werde sicher noch mit dem Maintainer von GELI Kontakt aufnehmen um einige Dinge zu klären. Unter http://www.dr.sweety.li/temp/bsdforen/encryption_benchmark.html könnt ihr euch den Vergleich anschauen, Kritik und Kommentare sind natürlich herzlich willkommen :)
 
Respekt, das ist ein sehr ausführlicher und aussagekräftiger Test. Ich werde demnächst ein neues verschlüsseltes RAID 5 mit FreeBSD 6.0 aufsetzen, dein Vergleich hat mir die Entscheidung GBDE/GELI einfach gemacht.
 
Jo, geli ist auch rein vom Gefühl schneller. Ich habe meine Platte von gbde auf geli migriert.

Eines stört mich nur. Wenn geom die verschlüsselte Partition findet, dann verlangt es nach einem Passwort. Dann aber findet es ein DVD-Laufwerk und macht die erste Eingabe des Passworts unbrauchbar, falls man sie schon vor dem Ausgabe über das gefundene Laufwerk angefangen hat. Es ist kein gravierender Fehler... aber unschön.

Sonst gibt es bis jetzt nichts zu meckern. Mich hat aber eher nicht der Benchmark überzeugt, sondern die Zusicherungen über die konsistenten Zustände auf der verschlüsselten Platte und dass es von NetBSD-Entwicklern(!) gelobt wurde (im Gegensatz zu gbde).
 
noch eine frage: wird aus dem benchmark ersichtlich welcher algorithmus am besten performt?
oder gibts dazu allgemein bekannte meinungen (wie "bei 256bit ist xyz immer schneller als plq!").
habe jetzt nämlich shcon eine platte in aes256 kodiert und bin sehr zufrieden mit der performance, habe aber überlegt die zweite platte vielleicht in etwas anderem zu kodieren...

noch was bezüglich geli: einen keyfile zu benutzen der auf dem rechner unverschlüsselt liegt(wie in dem besipiel aus dem handbuch) ist doch ziemlich sinnlos, oder? den dollte man dann schon auf nem usbstick haben, oder?
 
soul_rebel schrieb:
noch eine frage: wird aus dem benchmark ersichtlich welcher algorithmus am besten performt?

Soweit ich mich entsinnen kann, wurden für die Benchmarks die selben Algorithmen für gbde und geli verwendet, so dass es nicht ersichtlich wurde.

oder gibts dazu allgemein bekannte meinungen (wie "bei 256bit ist xyz immer schneller als plq!").
habe jetzt nämlich shcon eine platte in aes256 kodiert und bin sehr zufrieden mit der performance, habe aber überlegt die zweite platte vielleicht in etwas anderem zu kodieren...

Im Allgemeinen hat Blowfish eine bessere Performance als AES, das kann aber abhängig von der Implementation des Algorithmus, der verwendeten Compiler-Optimierungen und der Hardware variieren. 3DES kannst du vergessen, der ist wesentlich langsamer.

Du kannst aber mittels eines Benchmarks von openssl herausfinden, wie die theoretische Leistung auf deinem Rechner ist:

Code:
$ openssl speed aes blowfish

Im Zweifelsfalle würde ich es einfach selber testen.

noch was bezüglich geli: einen keyfile zu benutzen der auf dem rechner unverschlüsselt liegt(wie in dem besipiel aus dem handbuch) ist doch ziemlich sinnlos, oder? den dollte man dann schon auf nem usbstick haben, oder?

Nein, ein Angreifer muss immer noch das Passwort knacken, wenn er das Keyfile hat. Mit dem Keyfile auf einem externen Medium erhöhst du zwar die Sicherheit, hast aber natürlich mehr Aufwand. Es hängt ganz von den Anforderungen an Sicherheit und Benutzerfreundlichkeit ab, welche Variante man wählen sollte.
 
Du kannst aber mittels eines Benchmarks von openssl herausfinden, wie die theoretische Leistung auf deinem Rechner ist:
cool!
ja das ist gut, aber wie stark ist blowfish im verhältnis zu aes-256. blowfish hat ja eine variable schlüsselänge, was genau heißt das wenn man es mit anderen algorithmen vergleicht?
danke
 
soul_rebel schrieb:
cool!
ja das ist gut, aber wie stark ist blowfish im verhältnis zu aes-256.

Das hängt von der Schlüssellänge ab, bei einer Schlüssellänge von 256 bit lassen sich beide Algorithmen per brute force nur in Zeiträumen knacken, welche die menschliche Vorstellungskraft weit übersteigen.

Nachdem für beide Algorithmen momentan kein Angriffspunkt bekannt ist, kann man schwerlich behaupten, dass einer sicherer sei als der andere.

blowfish hat ja eine variable schlüsselänge, was genau heißt das wenn man es mit anderen algorithmen vergleicht?

Das heisst nur, dass du mit Blowfish innerhalb bestimmer Parameter eine beliebige Schlüssellänge (32-448 bit) wählen kannst, während AES nur für "gängige" Schlüssellängen spezifiziert ist (128, 192 und 256 bit).
 
azazyel schrieb:
Das heisst nur, dass du mit Blowfish innerhalb bestimmer Parameter eine beliebige Schlüssellänge (32-448 bit) wählen kannst
hm das hatte ich aus der doku auch so verstanden, aber zumindest beim geschwindigkeitstest von openssl kann ich für blowfish keine schlüssellänge angeben (für aes schon).
danke!
 
soul_rebel schrieb:
hm das hatte ich aus der doku auch so verstanden, aber zumindest beim geschwindigkeitstest von openssl kann ich für blowfish keine schlüssellänge angeben (für aes schon).

Die Standardlänge des Schlüssels für Blowfish ist 128 bit. Nachdem aber höchstwahrscheinlich die Festplatte der limitierende Faktor ist, dürfte es ziemlich egal sein, welchen Algorithmus du verwendest. Mit der Frage, welcher der beiden Algorithmen nun besser ist, kannst du Glaubenskriege auslösen.
 
Azaazyel schrieb:
Nachdem aber höchstwahrscheinlich die Festplatte der limitierende Faktor ist, dürfte es ziemlich egal sein, welchen Algorithmus du verwendest.
wieso? ich nehme doch an dass aes-256 bessere kryptografie bietet als aes-128, dann wird es bei blowfish ja auch so sein, oder?
und wenn blowfish bei 256 schneller ist als aes bei 256, dann ist blowfish doch besser, oder? (also wenn ich jetzt nicht anfang die algorithmen selbst zu bewerten, was ich nicht kann und was mir - da beide als 'sicher' gelten - auch sinnlos erscheint)
 
soul_rebel schrieb:
wieso? ich nehme doch an dass aes-256 bessere kryptografie bietet als aes-128, dann wird es bei blowfish ja auch so sein, oder?
und wenn blowfish bei 256 schneller ist als aes bei 256, dann ist blowfish doch besser, oder?

Vielleicht, vielleicht auch nicht. Deine Anforderungen werden offensichtlich von beiden erfüllt. Ich empfehle dir eine Münze zu werfen, oder nach dem cooleren Logo zu entscheiden.

Hah, nein, ich weiß was: In AES könnten dem NSA bekannte Designfehler sein, da dieser ja AES (oder damals noch Rijndael) durchgesehen hat und als Advanced Encryption Standards empfohlen hat. Denen wäre ein Cryptostandard, der von Ihnen geknackt werden kann, natürlich sehr recht.
 
soul_rebel schrieb:
wieso? ich nehme doch an dass aes-256 bessere kryptografie bietet als aes-128, dann wird es bei blowfish ja auch so sein, oder?

Bei Brute-Force-Angriffen könnten mit AES-128 die Daten noch kurz vor dem Ableben unserer Sonne entschlüsselt sein, bei AES-256 wohl eher danach.

Gleiches gilt für Blowfish.

und wenn blowfish bei 256 schneller ist als aes bei 256, dann ist blowfish doch besser, oder? (also wenn ich jetzt nicht anfang die algorithmen selbst zu bewerten, was ich nicht kann und was mir - da beide als 'sicher' gelten - auch sinnlos erscheint)

Nachdem bei dir Blowfish schneller ist, spricht nichts gegen dessen Verwendung. Je nach Systemumgebung (z.B. Via C3 mit Hardware-AES-Support) kann es umgekehrt sein.

Zum Thema NSA: Beim Auswahlverfahren von AES war es eines der vielen Kriterien, dass der Algorithmus von der NSA gebilligt wird. Die NSA hat Rijndael (der schließlich der neue Advanded Encryption Standard wurde) ihr OK gegeben, was die üblichen Bedenken hervorgerufen hat.
 
Azazyel schrieb:
Bei Brute-Force-Angriffen könnten mit AES-128 die Daten noch kurz vor dem Ableben unserer Sonne entschlüsselt sein, bei AES-256 wohl eher danach.
Das hat man sich vermutlich auch von DES oder dem Vigenaire erwartet. Das Knacken kann bedeutend früher passieren, bspws. durch einen Quantenrechner, oder durch eine mathematische Spitzfindigkeit.

Azazyel schrieb:
Zum Thema NSA: Beim Auswahlverfahren von AES war es eines der vielen Kriterien, dass der Algorithmus von der NSA gebilligt wird. Die NSA hat Rijndael (der schließlich der neue Advanded Encryption Standard wurde) ihr OK gegeben, was die üblichen Bedenken hervorgerufen hat.
Genau so ist es. Nicht selten sind verschwörungstheoretische Argumente überaus wichtig für die Entscheidungsfindung, deswegen die Erwähnung. (Wohlgemerkt, der Wahrheitsgehalt läßt sich (weder so noch so) aus meiner Aussage ableiten!)
 
thyrver schrieb:
Das hat man sich vermutlich auch von DES oder dem Vigenaire erwartet. Das Knacken kann bedeutend früher passieren, bspws. durch einen Quantenrechner, oder durch eine mathematische Spitzfindigkeit.

Sollten brauchbare Quantenrechner Realität werden, spielt es auch keine Rolle mehr, ob man mit 128 oder 256 bit verschlüsselt hat...

Genau so ist es. Nicht selten sind verschwörungstheoretische Argumente überaus wichtig für die Entscheidungsfindung, deswegen die Erwähnung. (Wohlgemerkt, der Wahrheitsgehalt läßt sich (weder so noch so) aus meiner Aussage ableiten!)

Richtig, siehe die Debatte um 56/64 bit damals bei DES.
 
Hi, hab ein vinum raid 0 mit 3 Festplatten und geli aes 128 Verschlüsselung.
Von der Systemplatte zum raid hab ich einen ungefähren Durchsatz von 9,5MB/sec. Für meine Zwecke ist das jedenfalls völlig ausreichend.
Prozessor: P3 mit 1GHZ + 512MB RAM
Hab es dann auch mal mit Hardware Raid0 probiert und kam auf etwa gleiche Werte.
Ist ein SATA Raid Controler von Dawicontrol mit der Bezeichnung DC-154 RAID.
Geli mag aber nicht, wenn sich die Festplatte für paar Sekunden zum Reorganisieren aus dem raid disconnectet und FreeBSD stürzt ab. Werde das in paar Wochen mit nem vinum Raid5 testen und das Ergebnis veröffentlichen.
Was habt ihr denn noch für Erfahrungen?
 
thyrver schrieb:
Das hat man sich vermutlich auch von DES oder dem Vigenaire erwartet. Das Knacken kann bedeutend früher passieren, bspws. durch einen Quantenrechner, oder durch eine mathematische Spitzfindigkeit.

Quantencomputer verringern meines Wissens die Komplexität von Brute-Force-Angriffen um ^2, d.h. XY-256 ist mit einem Quantencomputer so schwer zu brechen wie XY-128 mit der "normalen" Rechentechnik. (Und es gibt irgendwo die schöne Rechnung, daß bis zum Brute-Force-Brechen eines 128-Bit Algorithmus das Silizium ausgeht und das Universum veglüht oder so ähnlich - die "mathematischen Spitzfindikeiten" (schöner Begriff :) ) sind eher interessant, aber die sind zur Zeit für alle drei genannten Algorithmen jenseits von realisierbar.)

Nebenbei bemerkt - die NSA hat vermutlich auf diesem Planeten die meiste Ahnung und Erfahrung, was Krypto angeht - also ist es verständlich, daß das NIST dort um ein Urteil anfragt. Wie gut die Algorithmen wirklich sind wird die Zeit zeigen. DES war z.B. gegen differentielle Kryptanalyse optimiert (von der NSA), nicht aber gegen lineare. Man muß mit dem arbeiten, was da ist ;)

Zudem ist das Brechen der Algorithmen schon seit langem sehr aufwendig - in fast allen Fällen gibt es einfachere Methoden (oder wie es mal jemand formuliert hat: Computersicherheit scheitert nicht an der Verfügbarkeit hochwertiger Kryptoalgorithmen) ;)

Viele Grüße
 
raver-softi schrieb:
Ist ein SATA Raid Controler von Dawicontrol mit der Bezeichnung DC-154 RAID.
Geli mag aber nicht, wenn sich die Festplatte für paar Sekunden zum Reorganisieren aus dem raid disconnectet und FreeBSD stürzt ab. Werde das in paar Wochen mit nem vinum Raid5 testen und das Ergebnis veröffentlichen.
Welches FreeBSD verwendest du? 6.0?
Wenn ja, aktualisiere mal auf 6.1, in 6.0 hatte GEOM noch hier und da ein Problemchen. Dem Geom-Raid10 hier hat das Update auch sehr geholfen.
 
Ich weiss nicht ob man das so pauschalisieren kann.
Auf stable@ gibt es gerade einen Bericht über einen Livelock mit dem neuen graid3.
 
Zurück
Oben