# Verschlüsseln von Daten: Was ist die bessere Möglichkeit

## JoHo42

Hi Leute,

ich würde gerne mehrere Verzeichnisse verschlüsseln in denen Daten liegen.

Bisher wurde von mir die Festplatte immer in einem Verschlüsselten Bereich aufgeteilt.

Dabei muss ich schon vom ersten Tag an wissen wie groß die Datenmenge ist oder werden kann.

Sonst verschenke ich unnützen Speicher.

Gibt es eine Möglichkeit die Daten in eine Virtuelle Festplatte zu packen.

Einfach nur eine Verschlüsselte Datei, die sich aber genauso verhält wie eine Festplatte.

Eine Datei die dynamisch sich der größe anpasst?

Gruss Jörg

----------

## kernelOfTruth

eCryptFS hört sich nach dem an, was du suchst

https://de.wikipedia.org/wiki/ECryptfs

https://wiki.archlinux.org/index.php/ECryptfs

----------

## mv

Oder sys-fs/encfs.

Oder mit halbwegs aktuellem Kernel auch die ext4-eigene Verschlüsselung.

Erfahrung (gute) habe ich diesbezüglich bislang nur mit encfs: Hauptvorteil ist, dass das auf so ziemlich allen Rechnern läuft, auch auf weniger aktuellen.

----------

## JoHo42

Hi Leute,

danke für die schnellen Vorschläge.

Das ist genau das was ich suche. Jetzt habe ich die Wahl welches ist das bessere. Der zweite Vorschlag mit encfs ist schonmal nicht im Portage gemask.

Also ich stabile Zweig aufgenommen und es gibt dazu eine KDE Oberfläche obwohl ich diese nicht brauchen werde.

Gruss Jörg

----------

## kernelOfTruth

Hi,

teste besser mal sys-fs/encfs an,

über eCryptFS hab ich nicht so gutes gelesen und vor ein paar Kernel Releases gab es Daten-Integritäts- oder -Korruptions-Probleme,

wenn ich mich richtig erinner

----------

## l3u

encfs benutze ich selbst, und es funktioniert gut.

Scheinbar hat es aber ein paar prinzipielle Designschwächen, also evtl. ist es nicht für super-geheime Daten geeignet. Was definitiv der Fall ist: Die Metadaten der verschlüsselten Verzeichnisse sind sichtbar, also die Anzahl der Verzeichnisse und Dateien, sowie deren Größe, Änderungsdaten etc.

Stört mich persönlich jetzt nicht für meinen Einsatzzweck, ich wollte es bloß mal gesagt haben ;-)

----------

## mv

 *l3u wrote:*   

> Die Metadaten der verschlüsselten Verzeichnisse sind sichtbar, also die Anzahl der Verzeichnisse und Dateien, sowie deren Größe, Änderungsdaten etc

 

Das ist m.W. auch bei den anderen beiden Möglichkeiten (ecryptfs bzw. dessen "Nachfolger" ext4-intern) der Fall.

Es wird sozusagen "filewise" versclüsselt, wobei der Filename allerdings auch verschlüsselt wid.

Ja, es gab mal irgendeinen Bericht, wo encfs auf Sicherheit analysiert wude, und einige theoretische Schwächen aufgezeigt wurden. Aber m.E. nichts Ernsthaftes, was bei einem solchen Verfahren nicht sowieso zu erwarten wäre; keine konkreten Implementierungsfehler oder echt Problematisches wie die Wahl eines schwacen Algorithmus. Sondern eben so Dinge wie die Sichtbarkeit der Metadaten und dass man durch die Namensveschlüsselung möglicherweise einen gewissen known-plaintext hat u.ä. - was ohne echte Brechung des Algorithmus kein Problem sein sollte.

----------

## l3u

Nachdem ich jetzt mal nachgelesen habe, ist wahrscheinlich die ext4-interne Verschlüsselung in Zukunft das, was man nehmen will. Aber die e2fsprogs, die man dafür braucht, sind leider noch nicht einmal veröffentlicht. Ob man da mit git-Versionen experimentieren will, sei jedem selbst überlassen. Liest sich jedenfalls sehr vielversprechend.

----------

## mv

 *l3u wrote:*   

> Nachdem ich jetzt mal nachgelesen habe, ist wahrscheinlich die ext4-interne Verschlüsselung in Zukunft das, was man nehmen will.

 

Im Moment kann man das halt auf vielen Systemen nicht bekommen. Beispielsweise wird vermutlich rescuecd die Sache noch nicht unterstützten (wenn Du nicht selbst vorher an der CD rumbastelst, natürlich). Oder wenn Du eine Festplatte auf Reisen mit dieser Verschlüsselung mitnimmst, kannst Du z.B. auf einem aktuellen Ubuntu/Debian/...-Rechner sicher auch nichts mit den verschlüsselten Daten anfangen.

Das sind zumindest für mich Gründe, weshalb ich noch nicht einmal ernsthaft an eine Umstellung denke. Vielleicht in ein paar Jahren... wenn ich dann immer noch nicht btrfs benutzen will...

----------

## l3u

Deswegen ja auch „in Zukunft“ ;-)

----------

## mv

Gerade habe ich den Link zu den encfs-Problemen wieder gefunden: https://defuse.ca/audits/encfs.htm

Die Problematik bei der angeblich großen Lücke der Stream-Cipher im letzten Block erschließt sich mir nicht (solange die 1-way-Funktion sicher ist).

----------

## py-ro

Der Vollständigkeit halber, ext4 kann theoretisch per Directory Verschlüsselung, leider in der Praxis noch nicht nutzbar. Sollte man aber für die Zukunft im Kopf behalten.

Bye

Py

----------

## l3u

Wenn's ein Release der e2fsprogs gibt, das das kann (momentan müsste man git master bauen), dann könnt man's ja zumindest mal antesten … aber momentan ist mir das auch noch zu heiß. Die entsprechende Kerneloption ist jedenfalls im aktuellen Stable-Mainline-Kernel drin.

----------

