News Linux: Verschlüsselung für Dateisystem Ext4 und Android

Was wir generell mal brauchen ist ein Dateisystem für Daten welches auch auf 1 Platte ausreichend Fehlerkorrektur besitzt und kippende Bits usw. ausgleichen kann.
 
fethomm schrieb:
Das liegt an den nicht "nativen" Verschlüsselungsmethoden der externen Programme. eCryptfs legt innerhalb des Dateisystems verschlüsselte Container an, während dm-crypt die Verschlüsselung auf einer anderen Ebene unterhalb des Dateisystems vornimmt. Somit sind diese Methoden denen einer internen Verschlüsselung, wie jetzt bei ext4, unterlegen was die Performance angeht.

Gibt es schon einen Performance Vergleich der drei Implementierung?
Meine Suche lieferte keine Zahlenwerte.
 
cbtestarossa schrieb:
Was wir generell mal brauchen ist ein Dateisystem für Daten welches auch auf 1 Platte ausreichend Fehlerkorrektur besitzt und kippende Bits usw. ausgleichen kann.

ZFS mit copies=2? Oder reicht das normale Checksumming schon?
 
gibt es ZFS für Windows/Linux?
naja man muss sich dann halt ein NAS mit BSD/ZFS basteln
ReFS soll ja auch schon besser sein aber geht ja nicht für das System selber mWn.
 
Es gibt ZFSonLinux, und es gibt neben Solaris auch diverse Distris, die auf ein NAS zugeschnitten sind. Ich hab aber Solaris im Einsatz. Und auf meinem Hauptrechner ein Linux mit Ext4 und dm-crypt...was eigentlich ganz gut geht, aber beim gelegentlich verschwindenden Kartenleser nervts, da wär eine native Implementierung in Ext schon schöner.
 
@cbtestarossa:

http://open-zfs.org/wiki/Main_Page

DaBzzz schrieb:
ZFS mit copies=2? Oder reicht das normale Checksumming schon?

Mirror (à la Raid 1) und ditto blocks (so nennt sich das Feature)

ist einfach die beste Kombination.


Ich hatte vor ein paar Wochen eine massive Datenkorruption (Ursache: PEBKAC, Entwicklung am Dateisystem) und ZFS hat's damit gerichtet

t4522.gif


Was macht man dann mit ext4 und der Verschlüsselung ?

man erstellt einige riesige Dateien, die wenig Wert sind, benennt sie mit blablablaPR0N und verschlüsselt sie, damit die wirklich wichtigen verschlüsselten Dateien in der Masse untergehen ? :evillol:
 
Zuletzt bearbeitet:
@freak01

Für den Gelegenheitsdieb sollte es schon reichen wenn die Dateien verschlüsselt sind, damit die privaten Dokumente/Bilder/Videos nicht in einer Cloud öffentlich präsentiert werden.
 
@ Hallo32:

gutes Argument, ja - da bringt das ganze auf jeden Fall etwas !


@cbtestarossa:

meinte ich auch

Raid1/Mirror + copies=2

ist eben 4-fach auf 2 Datenträgern,

aber auch nicht für jeden etwas

Wegen dem Windows-Treiber: bei Paragon Software nachfragen, evtl. machen die es ja ;)

Wenn es aktiv weiterentwickelt würde, wäre Co-Linux eine Möglichkeit: http://de.wikipedia.org/wiki/Cooperative_Linux - aber so wie das ausschaut, wird da nicht so viel gemacht


Bei meinen externen Backup-Datenträgern (1 HDD - das sollte also deinem Szenario entsprechen) liegen die wichtigsten Ordner und Dateien via copies=2 doppelt vor, und durch die sha256 Prüfsummen sollte die Wahrscheinlichkeit, dass man korrekt auf die Daten zugreifen kann um einiges erhöht sein (vorausgesetzt natürlich, dass die Platte nicht gerade in dem Moment einen Schaden hat - dafür sind dann aber die anderen Platten da :evillol: )


Für Btrfs hält man das für (noch ?) nicht relevant, bei Ext4 gibt es sowas leider nicht - journal & metadata checksums (https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums) aber keine Data checksums
 
Zuletzt bearbeitet:
Schön zu hören. Werd dann wohl meine EXT4 + Luks Partitionen ersetzen können!
 
Ist da tatsächlich der Schlüssel bzw. der Algorithmus mit AES-256 fest vorgegeben? Das kann man nicht ändern?

Und noch eine Sache: wer ist denn nun verantwortlich in diesem Kontext für die Verschlüsselung? Der Kernel, oder? Werden dann auch die AES-Extensions moderner CPUs genutzt?
 
Ich nehme weiterhin truecrypt und sehe keine Geschwindigkeitseinbußen im Vergleich zu einem unverschlüsselten FS.
 
Verschlüsselung wird ja von so mancher Hardware wie SSDs, CPUs, etc. in Echtzeit sehr gut angeboten. Dazu gesellt sich natürlich noch die System-Power und die Menge der Daten.
 
fethomm schrieb:
Das liegt an den nicht "nativen" Verschlüsselungsmethoden der externen Programme. eCryptfs legt innerhalb des Dateisystems verschlüsselte Container an, während dm-crypt die Verschlüsselung auf einer anderen Ebene unterhalb des Dateisystems vornimmt. Somit sind diese Methoden denen einer internen Verschlüsselung, wie jetzt bei ext4, unterlegen was die Performance angeht.

Ob die Verschlüsselung jetzt filesystem-unabhängig über ein block device wie bei dm-crypt oder im Filesystem erfolgt, sollte keine spürbaren Performance-Unterschiede bringen. Beide Methoden nutzen die selben Resourcen.
Ein ext4 braucht auch weiterhin ein block device. Ob die Verschlüsselung nun auf FS-Ebene oder auf Device-Ebene erfolgt, macht von der Performance her keinen Unterschied. Die Algorithmen werden fast identisch sein.

Ich sehe jetzt keinen Vorteil darin, die Verschlüsselung in den FS Treiber einzubauen. Vermutlich will Google nur wieder irgendeine Hürde einbauen, damit ja niemand mehr mit Android machen kann, also Google zuläßt.
 
Zurück
Oben