verschlüsselte dateisysteme mal wieder...

soul_rebel

ist immer auf der flucht
also...
wenn ich ein verschlüsseltes dateisystem in einer datei anlege dann würde ich das in openbsd mit vnconfig mounten (über ein virtuelles device) und in linux über die loopback-schnittstelle (also auch ein virtuelles device), wie kriege ich das in freebsd hin? bis jetzt habe ich was freebsd angeht nur posts über cfs gelesen... in den man-pages steht dass freebsd 5.x mdconfig verwendet statt vnconfig... die eigentliche frage ist:
egal ob durch loopback, vnconfig oder mdconfig, das prinzip ist doch dasselbe, erst eine eine leere datei erstellen (oder eine voll mit müll(urandom)), dann ein virtuelles gerät erstellen dass eine schnittstelle zur datei darstellt und einen verschlüsselungs algorithmus verwendet (aes, des, blowfish...) und dann auf diesem gerät ein dateisystem erstellen, dieses später mounten und benutzen.
heißt das nicht das wenn ich ein dateisystem wähle dass openbsd, freebsd und linux verstehen (ufs wäre meine wahl dass kann linux standardmäßig inzwischen lesen und ist unter dem primär betriebssystem debian gnu/kfreebsd oder openbsd - mal gucken - am schnellsten) und einen algorithmus wähle der von allen standardmäßig unterstützt wird (welcher wäre das?/egal?), dass dann die verschlüsselte datei auf allen drei system gleichermaßen benutzt werden könnte(also linux nur lesen)?
 
ich hab mit mit dd und /dev/null ne leere datei erstellt, mit new_fs ein ffs-filesystem aus der datei gemacht, und die dann mit gnupg verschlüsselt

ist aber wahrscheinlich nicht das, was du suchst

MfG
 
Zu FreeBSD:
truncate -s1G crypted
mdconfig -a -u 1 -t vnode -f crypted
gbde init /dev/md1
gbde attach /dev/md1
mount /dev/md1.bde /mnt
..
umount /mnt
gbde detach /dev/md1.bde
mdconfig -d -u 1

oder so aehnlich, guck dir die manpages an.

Zur Interoperabilitaet: http://www.crypto.com/software/ also security/cfs

aber ob das was taugt kann ich dir nicht sagen.
 
hm danke für die info als erstes. also wie ist das denn mit gnupg? kann ich dass als entschlüsselungschnittstelle vor eine partition oder eine datei hängen oder muss ich immer entschlüsseln/verschlüsseln? wäre unpraktisch bei einer partition/einem disk image von ca 240GB....

ja über gdbe habe ich auch einige sachen gelesen aber das scheint nur auf fbsd zu funktionieren...
cfs scheint sowohl für fbsd als auch für obsd zu geben; das ist schon mal ein anfang... ist das denn von der geschwindigkeit her akzeptabel "user-space-nfs-server" hört sich ein bisschen gefrickelt an... bringt das komplikationen wenn ich die dadurch gemountete partition/disk image dann durch den richtigen nfs-fileserver freigebe (hab irgendwo gelesen dass das problemem gibt)?
danke für die hilfe
 
hm ich hab jetzt dazu einen neuen plan:
ich setz ein debian-xen wirtssystem auf das beim starten eine mit aes-loop (der soweit ich weiß im moment stärkste verschlüsselungs algorithmus für physische laufwerke - leider nur für linux) verschlüsselte partition mountet und diese seinen netbsd und freebsd domänen (hoffentlich kommt obsd irgendwann dazu) per nfs freigibt.
das wirtssystem bekommt keine netzwerk anbindung nach außen, stattdessen gibt die freebsd domäne über ihr virtuelles interface daten der verschlüsselten partition über einen eigenen nfs server ans netzwerk...
macht das sinn oder wird dann der zugriff auf die festplatte durch die kombination (netzwek-> virtuelles interface-> nfs-server-auf-freebsd-in-datei-> nfs-server-auf-domäne0-> aes-loopdevice-> festplatte) zu einer endlosen warterei?
ich meine im endeffekt sollen home verzeichnisse vom server exportiert werden...
 
Ich hab hier schon länger auf meinem Notebook, die /home-Partition mit gbde verschlüsselt. Ist praktisch, weil das Betriebssystem automatisch erkennt, dass es ein verschlüsseltes Laufwerk ist und beim ersten mounten nach dem Passwort fragt.

gbde ist auch AES-128 basierend und akzeptabel schnell. Die Installation und die Vorbereitung ist ziemlich einfach. Ich habe leider kein Linux und weiß nicht, ob das System damit etwas anfangen kann.

gbde ist keine Frickelei, wie ich den Präsentationspapieren entnehmen kann. Da gibt es viele Ideen, damit der Angreifer über die Daten und ihre Reihenfolge möglichst wenig weiß und alles trotzdem effizient bleibt. Ich spüre hier auf dem Notebook fast keinen Unterschied gegenüber nicht-verschlüsselten Dateisystemen im täglichen Gebrauch. Ich vermute aber, dass bei konstantem Lesen der Geschwindigkeitsverlust messbar wäre.
 
hm aesloop ist aber aes-256 und gbde funktioniert nciht auf linux (wäre nicht so schlimm auf das ding kommen eigentlich nur bsds aber falls mal was tierisch schief läuft würde ich gerne mit ner knoppix hochbooten können und daten rettenbackups sind ja nciht sonderlich einfach wenns verschlüsselt sein soll und teuer wenn man ~400gb backuppen will) - das doofe mit gdbe ist aber das es nicht mal von den anderen bsds unterstützt wird , mit dem linux wirt würden die daten auf allen system verfügbar sein...
 
loopaes verwendet aber IIRC einen Schluessel fuer alle Sektoren, damit gibst du einem Bruteforce-Angreifer ordentlich was an Ciphertext. Bei GBDE ist der Masterschluessel 2048 Bit und jeder Sektor wird mit einem eigenen 128 Bit Schluessel gesichert. Wenn ein Angreifer nun den Schluessel fuer einen Sektor erraet, dann hat er ganze 512 Bytes gewonnen. Fuer die naechsten 512 Bytes muss er wieder einen 128 Bit Schluessel knacken ...

Viel Spass damit.
 
MrFixit schrieb:
loopaes verwendet aber IIRC einen Schluessel fuer alle Sektoren, damit gibst du einem Bruteforce-Angreifer ordentlich was an Ciphertext. Bei GBDE ist der Masterschluessel 2048 Bit und jeder Sektor wird mit einem eigenen 128 Bit Schluessel gesichert. Wenn ein Angreifer nun den Schluessel fuer einen Sektor erraet, dann hat er ganze 512 Bytes gewonnen. Fuer die naechsten 512 Bytes muss er wieder einen 128 Bit Schluessel knacken ...

Viel Spass damit.

Soweit ich weis nicht komplett richtig. Wie man in der README lesen kann ist auch Loop-AES multikey faehig


Loop-AES supports three different on-disk formats: v1, v2 and v3. v1 is from
old loop-AES-v1.X versions and it uses a single key to encrypt all data
sectors. v2 is from loop-AES-v2.X versions and it uses 64 keys to encrypt
data sectors. v3 is from loop-AES-v3.X versions and it uses 65 keys, first
64 are used to encrypt data sectors and 65th key is used as additional input
to MD5 IV computation.
 
hoppel schrieb:
ich hab mit mit dd und /dev/null ne leere datei erstellt, mit new_fs ein ffs-filesystem aus der datei gemacht, und die dann mit gnupg verschlüsselt

Statt GnuPG würde ich cgd nehmen, dann musst du nicht entschlüsseln, benutzen, verschlüsseln, wipen ;-)
 
Zurück
Oben