IDEA Crypto Filesystem

[taylor]

Moin!

Keine Frage, wollte nur kurz Berichten:

Ich habe heute per internationalem Kernel-Patch von http://kerneli.org eine mit dem IDEA Algorithmus verschlüsselte Partition angelegt.

Es läuft zwar, aber mit meiner betagten Rechenpower von 500Mhz macht das keinen Spass. Die Load steigt ziemlich hoch, die Maus wird ruckelig...

Ich werde jetzt mal AES versuchen.

Achja, Schlagworte: idea crypto filesystem verschlüsselte partition loop :)

[taylor]

Ich hab's jetzt nicht ausgiebig getestet.

Rein gefühlsmässig machen IDEA, AES und Twofish wenig Leistungsunterschied.

IDEA ist ja mit einem Patent belegt, also wende ich mich mal vorzugsweise AES und Twofish zu und werde mit einer Leistungseinbuße leben.

Gruß,
Taylor

[Flightbase]

also loop-aes lüppt sehr gut bei mir....
mußt ja nicht gerade games drauf installen - aber für keys oder mails isses doch echt ok.

wo wir dabei sind - ich vermisse nen tool, womit man partitionen unter linux und windoze lesen kann - also crypt disk`s ;)

greets, Nik

[taylor]

Original geschrieben von Flightbase
also loop-aes lüppt sehr gut bei mir....
Das (http://www.pl-forum.de/t_system/loop-aes.html) habe ich noch nicht gemacht, weil ich dann mein util-linux Paket wieder hätte umpatchen müssen.
Mal davon abgesehen, unterscheidet sich unsere Rechenpower auch "unwesentlich" ;)

Ich habe den AES Cipher aus dem Int-Patch genommen.

Gruß,
Taylor

[taylor]

So, ich habe jetzt doch noch einen kleinen Test gemacht.
Allerdings nicht unter Laborbedingungen, sprich kein Single User Mode,
und bis auf eine Ausnahme jeweils nur einen Durchgang.

Falls es jemanden interessiert:


Vergleich der Geschwindigkeit verschiedener Cipher
--------------------------------------------------

Testsystem:

Pentium3, 500Mhz
Linux 2.4.20
loop-jari-2.4.20.0.patch
patch-int-2.4.20.1


Kopiert wird eine 569MB grosse Datei auf eine verschlüsselte
und über das LoopbackDevice mit der Option "sync" gemountete
Partition.

Mit diesen Befehlen habe ich getestet:

---snip---
losetup -e <cipher> /dev/loop0 /dev/hdb12
mkfs.ext2 /dev/loop0
mount /dev/hdb12 /mnt -t ext2 -o loop,sync,encryption=<cipher>
time cp /space/569MB.avi /mnt/
losetup -d /dev/loop0
---snap---


Alle Chiper wurden mit einer Schlüssellänge von 128bit getestet.


OHNE CIPHER:

CPU Last durch cp: ~ 10-15 %

real 3m47.854s
user 0m0.350s
sys 0m25.480s

TWOFISH:

CPU Last durch cp: ~ 40-50 %

real 6m54.091s
user 0m0.460s
sys 2m52.020s


IDEA:

CPU Last durch cp: ~ 65-70 %

real 11m28.071s
user 0m0.290s
sys 7m43.700s


AES:

CPU Last durch cp: ~ 40-50 %

real 6m36.762s
user 0m0.330s
sys 3m5.020s


Das Ergebnis vom IDEA test hat mich sehr verblüfft, darum habe ich diesen Druchgang (mit ~ selbem Ergebnis) wiederholt.

Falls mir jetzt niemand erzählt, dass ich irgendwas total falsch getestet habe (z.B. dass die "sync" Option eine doofe Idee war[1]), greife ich für meinen Teil zu AES.

Gruß,
Taylor



[1] Ohne die "sync" Option kam ich bei unverschlüsseltem Ext2 Dateisystem auf diese Zeit:


real 0m50.210s
user 0m0.160s
sys 0m6.080s

[taylor]

Ich habe nun doch noch loop-AES probiert, wie es bei Pro-Linux beschrieben wird.

Die Ergebnisse sind sehr gut:


real 5m37.646s
user 0m0.300s
sys 2m4.030s

Dabei bleibt die CPU Last ziemlich genau bei 40%.

Ein weiterer Vorteil dieser Methode ist der Wegfall des International Kernel Patches,
da hier nur mit einem gepatchten loop.o Kernelmodul (sowie natürlich gepatchtem mount und losetup) gearbeitet wird.

Allerdings setzt loop-AES zwingend (ohne eigene Hacks am Source) ein Passwort mit mindestens 20 Zeichen vorraus, was mir ansich ein wenig zu viel Komforteinbuße ist.
Sicherheitstechnisch gesehen ist das natürlich optimal :)

Gruß,
Taylor