# Homedir zu verschlüsseln (oder: dmcrypt vs. encfs)

## ChrisM87

Hi,

ich wollte mal wieder mein Homedir verschlüsseln und schwanke momentan zwischen dmcrypt und encfs.

Der Nachteil von dmcrypt wäre, dass ich meine momentane /-Partition, die dummerweise xfs ist und sicher daher nicht verkleinern lässt (oder doch?) löschen müsste und alles neu anlegen müsste.

Der Nachteil von encfs wäre aber, dass ein einfacher Rettungszugriff per LiveCD oder ähnlichem ziemlich erschwert wird, weil ja immer encfs installiert sein muss, während dmcrypt bei den meisten LiveCDs im Kernel dabei ist.

Was würdet ihr nehmen und wie sieht es auch performancetechnisch aus?

ChrisM

PS: An der Stelle auch gleich noch die Frage, ob jemand weiß, was an persönlichen Dateien außerhalb von /home gespeichert wird, jetzt mal /etc und /root außer Acht gelassen. Bisher kenne ich nur /tmp und /var/tmp/ und bin am Überlegen, ob ich z.B. KDE irgendwie dazu bringen kann, den Tempordner im Homedir unter ~/.kde/cache-hostname und ~/.kde/tmp-hostname zu verwenden, indem ich einfach die bestehenden Symlinks dort lösche und dort normale Ordner anlege.

----------

## slick

Habs mal nach Diskussionsforum verschoben, da eher Diskussion als Supportanfrage.

----------

## l3u

Weil sich's grad anbietet: https://forums.gentoo.org/viewtopic-t-405928.html

Abgesehen davon: Ich glaub nicht, daß hochsensible persönliche Daten nach /tmp wandern ... aber vielleicht bin ich da einfach zu non-paranoid ;-)

----------

## slick

Was AFAIK Sinn macht beim Einsatz von Verschlüsselung ist immer die zusätzliche Verschlüsselung der Swap weil nicht ausgeschlossen werden kann dass hier sensible Daten landen.

----------

## l3u

Mag sein ...

... aber da ich weder BND- noch CIA-Mitglied bin, begnüge ich mich damit, meine pseudo-sensiblen Daten in nem EncFS-Verzeichnis zu speichern (nicht das ganze /home-Verzeichnis). Sollte wirklich eine Sturmtruppe schwarz maskierter Geheim-Agenten meine Wohnung stürmen, mich überwältigen und meinen Computer stehlen, um an meine Geheimdaten zu kommen, dann muß ich mich halt damit abfinden, wenn auf meiner Swap-Partition top-secret-Daten liegen ... ;-)

Ähhh ... nichts für ungut, Leute :-)

----------

## ChrisM87

Hi,

nochmal zurück zum Thema, was würdet ihr jetzt nehmen? dmcrypt oder encfs? Bei was ist die Performance besser?

ChrisM

----------

## l3u

Die Performance gibt sich nicht viel. dm-crypt ist ein bißchen schneller, aber das schlägt (jedenfalls hier) kaum ins Gewicht. So ca. 1 MB/s. Nett an encfs ist halt, daß man die Daten in verschlüsselter Form backuppen kann, ohne daß man das entsprechende Verzeichnis mounten muß. Man kann's z.B. einfach so auf eine CD brennen, etc ... ist nur meine Meinung, aber das ist, abgesehen davon, daß ich eben gezielt verschlüsseln kann und nicht pauschal alles verschlüssele ein riesengroßer Vorteil von encfs.

----------

## ChrisM87

Hi,

naja, /home wäre bei mir eh immer gemounted, wenn der PC an ist, insofern wäre das kein Problem.

Vorteil von dmcrypt wäre halt, dass es fast jede LiveCD unterstützt, während encfs auf so gut wie keiner drauf ist, d.h. wenn ich mal was retten muss, bin ich mit encfs aufgeschmissen.

ChrisM

----------

## l3u

Tja, deswegen liegt diese schwerwiegende Entscheidung allein bei DIR, mein Freund ;-)

Allerdings kannst du deine Daten, wenn du sie mit encfs verschlüsselt hast, auch "einfach so" retten, weil du ja auch die verschlüsselten Daten "einfach so" von deiner Festplatte runterkopieren kannst. Und dazu muß die Live-CD ledigleich das Dateisystem unterstützen, das du verwendest. Und das tun sie glaub ich alle. Wohingegen du natürlich vollends aufgeschmissen bist, wenn du deine komplett verschlüsselte Partition erst gar nicht mounten kannst ...

----------

## ChrisM87

Hi,

ok, hab mich jetzt doch für dmcrypt entschieden, danke trotzdem!

ChrisM

----------

## nic0000

 *Libby wrote:*   

> Allerdings kannst du deine Daten, wenn du sie mit encfs verschlüsselt hast, auch "einfach so" retten, weil du ja auch die verschlüsselten Daten "einfach so" von deiner Festplatte runterkopieren kannst. Und dazu muß die Live-CD ledigleich das Dateisystem unterstützen, das du verwendest. Und das tun sie glaub ich alle.

 

Das ist auch ein verdammt guter Einwand. Klasse!

Fuse gehört wegen der libntfs Treibern bald auch zu jeder Livecd, so lange die Treiber nicht in den Kernel kommen. (Ist das nicht schon so bei Knoppix4?)

Jetzt noch die nötigen Tools zu installieren ist nicht wirklich das Problem. Zu Not auf USB-Stick einfach mitführen.

just my 2¢

----------

## Anarcho

Benutzt encfs die Kernel-Crypto-API?

Falls nein wäre das für mich schon ein Grund dagegen.

Denn ab dem 2.6.13er Kernel ist der AES Code für x86_64 in angepasstem Assembler geschrieben und dadurch bis zu 30% schneller als der C-Code.

Bei mir war es eine Leistungssteigerung von 20% (von 33MB/s auf 40MB/s).

----------

## l3u

Aha ... also afaik benutzt encfs NICHT die Kernel-API. Da ich aber ohnehin nicht Rijndael sondern Blowfish zum Verschlüsseln benutze, is mir das relativ wurscht ;-)

Aber wie kommst du auf so hohe Werte? Bei meiner Mühle (Athlon XP 1800+, 512MB RAM) gurken sowohl encfs als auch dm-crypt bei ca. 8-12 MB/s rum ... ich komm ja OHNE Verschlüsselung grad mal auf knapp 40 MB/s:

```
# hdparm -Tt /dev/hda

/dev/hda:

 Timing cached reads:   1072 MB in  2.00 seconds = 535.97 MB/sec

 Timing buffered disk reads:  120 MB in  3.01 seconds =  39.84 MB/sec
```

----------

## Anarcho

Da ich ja sagte das es sich um den Code für x86_64 handelt habe sind das Werte meines AMD64 Systems.

Es handelt sich um einen Athlon 64 3000+ der auf 2Ghz übertaktet ist (also 3200+).

Die Werte sind mittels hdparm ermittelt:

hdparm -tT /dev/mapper/test

Auf meinem Server sind die Datenplatten ebenfalls verschlüsselt. Dabei handelt es sich um einen Athlon 2000+.

Dabei schaffe ich laut hdparm ca. 20 MB/s von der mittels AES verschlüsselten Partition. Übers Netzwerk (Gbit) bleiben davon ca. 15MB/s übrig.

Das ist auch der Grund warum ich dringend im Januar einen weiteren Athlon 64 holen werde!

EDIT:

Die verschlüsselten SATA Platten schaffen ohne Verschlüsselung:

```
server maz # hdparm -tT /dev/sda

/dev/sda:

 Timing cached reads:   876 MB in  2.01 seconds = 436.10 MB/sec

 Timing buffered disk reads:  172 MB in  3.01 seconds =  57.06 MB/sec

server maz # hdparm -tT /dev/sdb

/dev/sdb:

 Timing cached reads:   876 MB in  2.01 seconds = 436.54 MB/sec

 Timing buffered disk reads:  176 MB in  3.02 seconds =  58.23 MB/sec
```

Das Verschlüsselte Device:

```
server maz # hdparm -tT /dev/mapper/small 

/dev/mapper/small:

 Timing cached reads:   984 MB in  2.01 seconds = 490.11 MB/sec

 Timing buffered disk reads:   62 MB in  3.07 seconds =  20.21 MB/sec
```

Wie gesagt, das sind Werte des Servers (Athlon 2000+), meine Workstation (Athlon 64) ist aus, daher komm ich per ssh nicht drauf.

----------

## ChrisM87

Hi,

so, mein /home ist jetzt mit encfs verschlüsselt.

Jetzt wäre es aber bequem, beim Hochfahren oder Einloggen automatisch nach dem Passwort gefragt zu werden.

Ich hab mir mal pam_encfs, aber erstens funktioniert das bei mir gar nicht richtig (Readme natürlich gelesen, aber obwohl es richtig in /etc/pam.d/system-auth eingetragen ist, fragt er beim Konsolenlogin [X-Login hab ich mich gar nicht gewagt zu probieren] zweimal nach dem PW, mountet aber trotzdem nichts).

Und zweitens muss dazu ja mein Userpasswort gleich dem encfs-Passwort sein, was ungünstig ist, weil ich ein möglichst kurzes Userpasswort haben will (muss ich immer zum Beenden vom Bildschirmschoner eingeben) und sicherheitstechnisch dem Userpasswort ja eher keine so große Bedeutung mehr zukommt, weil spätestens nach dem Runterfahren mein /home nur noch verschlüsselt vorhanden ist.

Ideal wäre es, einfach beim Hochfahren nach dem Passwort gefragt zu werden, das Problem ist nur, dass ich ja als User mounten will und deshalb ein Init Script nicht in Frage kommt. Außerdem "geht" ja während der Init Script-Ausführung die Tastatureingabe noch nicht, also kommt sowas nicht in Frage.

Wie soll ich das aber dann machen? Immer erst auf Konsole einloggen, mounten und dann bei X11 einloggen ist nicht so das Wahre...

ChrisM

PS: Kann es sein, dass KDE nicht damit klarkommt, dass /tmp als tmpfs gemountet ist? Crasht beim Starten...

----------

## l3u

Ich hab gedacht, es ist dm-crypt geworden? Na, auch gut ;-)

Und

```
su dein_user -c "encfs /home/.dein_user.enc /home/dein_user"
```

(oder sowas) funktioniert nicht, wenn du's in local.start reinschreibst?

----------

## ChrisM87

Hi,

lol, auf su bin ich Depp gar nicht gekommen. Funktioniert auf jeden Fall danke!

Was mich nur verwundert hat, ist, dass die Tastatureingabe einwandfrei funktioniert. Ich meine mich erinnern zu können, mal andere Befehle in Initscripts gehabt zu haben, die ich mit STRG + C nicht abbrechen konnte.

Chris

----------

## l3u

Hmmm ... also ich hatt das auch schon mal, daß ich ein init-Script abbrechen wollte, und das ging nicht. Aber woran das liegt, weiß ich auch nicht ... vielleicht geht's weil der Befehl erst in local.start, also ganz am Schluß drinsteht?

----------

