Warum TrueCrypt bei mir nix auf der Dropbox zu suchen hat [Update]

Wenn es um die Frage geht, wie man Dateien, die man auf seiner Dropbox gespeichert hat, verschlüsseln, bekommt man unisono TrueCrypt empfohlen.

Aus meiner Sicht hat TrueCrypt jedoch für diesen Anwendungsfall gravierende Nachteile und das Tool meiner Wahl ist EncFS.  

TrueCrypt verschlüsselt keine einzelnen Dateien, sondern stellt ein Volume (ähnlich einer Festplattenartition) zur Verfügung, in dem ein eigenes Dateisystem liegt. Das Volume liegt in einer Containerdatei. (TrueCrypt kann auch ganze Partitionen oder Speichermedien verschlüsseln, aber diese Funktion ist im Zusammenhang Dropbox nicht verwendbar.)

Die Größe es Container ist fest, d.h. man muss sich vorher entscheiden, wie viel Daten man Verschlüsseln möchte. (Liegt der Container physikalisch auf einem NTFS-Dateisystem, kann man wohl auch einen wachsenden Container erstellen, aber die Variante ist auf einer Dropbox nicht möglich.)

Bei einer Verwendung auf einer Dropbox muss nach der Generierung der gesamte Container auf die Dropbox gesynct werden, was je nach Größe und Anbindung erhebliche Zeit in Anspruch nehmen kann. Es gibt Beschreibungen, dass Dropbox später nur noch die sich ändernde Teile des Containers synct, sofern TrueCrypt so konfiguriert ist, dass der Zeitstempel der Containerdatei bei einer Änderung unverändert bleibt. (Was IMHO wiederum interessante Fragen über den Sync-Mechanismus von Dropbox aufwirft…)

Dadurch, dass alle zu schützenden Dateien in einem Container stecken, kann ein Angreifer ohne TrueCrypt zu knacken nicht feststellen, ob und wie vielen Dateien mit welcher Größe sich im Container befinden.

Nach meinen Feststellungen speichert TrueCrypt die geänderten Daten erst, wenn man die Containerdatei aushängt. Ein Speichern von Änderungen der im Container enthaltenen Dateien hat zumindest nicht zu einem sofortigen Sync der in der Dropbox liegenden Containerdatei geführt (Details siehe unten).

Das Bündeln der verschlüsselten Datei in einer Containerdatei und das „späte“ Schreiben bzw. Syncen des Containers führt zu massiven Problemen, wenn man verschlüsselten Dateien von verschiedenen Rechnern aus lesen oder schreiben möchte. Und gerade deshalb verwendet man ja die Dropbox.

Ich habe testweise – genauer um meine Vermutungen zu dieser Thematik zu überprüfen – einen TrueCrypt-Container via Dropbox auf auf mehreren Rechnern genutzt (zwei Rechner unter Ubuntu mit aktuellem TrueCrypt 7.0a und aktuellem Dropbox-Client 1.1.35). Hier meine Erkenntnisse:

Schritt 1:

  • Erstellen eines Containers auf dem Rechner A im Dropbox-Verzeichnis.
  • Anlegen einer Datei A1 mit Rechner A.
  • Rechner A sieht Datei A1.
  • Aushängen des Containers auf Rechner A.
  • TrueCrypt schreibt den Container.
  • Dropbox synct.

Alles o.k. 🙂

Schritt 2:

  • Öffnen des Containers auf Rechner B.
  • Rechner B sieht Datei A1. – Jepp! 🙂
  • Anlegen einer Datei B1 auf Rechner B.
  • Aushängen des Containers auf Rechner B.
  • TrueCrypt schreibt den Container.
  • Dropbox synct.

Weiterhin Alles o.k. 🙂

Schritt 3:

  • Öffnen des Containers auf Rechner A.
  • Rechner A sieht Dateien A1 und B1. Yeah! 😉
  • Anlegen einer Datei A2 auf Rechner A.
  • Container auf Rechner A nicht aushängen!
  • Öffnen des Containers auf Rechner B.
  • Rechner B sieht Dateien A1 und B1, aber nicht A2! – Fuck!
    (War aber zu erwarten…)
  • Anlegen einer Datei B2 auf Rechner B.
  • Aushängen des Containers auf Rechner B.
  • TrueCrypt schreibt den Container auf Rechner B.
  • Dropbox synct.
  • Auf Rechner A taucht im Dropbox-Verzeichnis eine Kopie der Containerdatei auf, deren Name auf einen Konflikt auf Rechner A verweist („… (In Konflikt stehende Kopie von A 2011-06-12)“). Scary! 🙁
  • TrueCrypt auf Rechner A zeigt noch immer den Original-Container als Ziel an.
  • Container auf Rechner A aushängen.
  • TrueCrypt auf Rechner A schreibt in die Kopie des Containers
    (Vermutung: Der Dateizugriff erfolgt nicht über den Namen, sondern über ein Handle. Dieses Handle zeigt auf die Original-Datei. Diese wurde jedoch beim Auftreten des Konflikte umbenannt und die „Original-Datei“ (besser: die Datei mit dem Original-Namen) wurde von Dropbox neu angelegt.
  • Die „Kopie“ wird von Dropbox gesynct.

Ergebnis:

In der Dropbox liegen zwei Containerdateien mit verschiedenen Inhalten.

  • Container mit Original-Namen mit Dateien A1, B1 und B2.
  • „Kopie-Container“ mit Dateien A1, B1 und B2.

Das ist genau das Ergebnis, dass ich beim Sync zwischen zwei Rechnern nicht haben  möchte.

Ursache für die Fuck up ist, dass TrueCrypt die verschlüsselten Dateien in einer verschlüsselten Datei hält. Bei gleichzeitigem Zugriff kommt es zu Inkonsistenzen. Wenn man TrueCrypt auf einer Dropbox nutzen möchte, dann darf man den TrueCrypt-Container jeweils nur auf einem Rechner öffnen und muss ihn schließen, bevor man ihn auf einem anderen Rechner öffnet.

Dies verträgt sich für mich nicht mit dem Anwendungsfall von Dropbox: Mit diesem Tool synce ich die Dateien über mehrere, ggf. gleichzeitig laufende Rechner hinweg. Dabei möchte ich nicht darauf achten müssen, ob ein Dateicluster auf einem anderen Rechner geöffnet ist. Bei mir laufen meistens mehr als ein Rechner und ich könnte nicht sicher stellen, dass der Container immer ausgehängt ist. Ich erwarte sogar, dass ich eine Datei mehreren Rechnern gleichzeitig lesend öffnen kann (dass es beim schreibenden Zugriff Probleme gibt, ist klar).

Daher ist aus meiner Sicht TrueCrypt keine Werkzeug zur Verschlüsselung auf der Dropbox. (Tatsächlich habe ich TrueCrypt eher aus einem Bauchgefühl heraus nie produktiv auf der Dropbox eingesetzt; die obigen Probleme sind mir erst vor Kurzem deutlich geworden.)

Von Beginn an habe ich für die Verschlüsselung auf der Dropbox auf EncFS gesetzt. EncFS ist ein auf FUSE aufsetzendes Krypto-Filesystem, bei dem auf dem Datenträger unterhalb eines Verzeichnisses die verschlüsselten Daten physikalisch abgelegt sind und über FUSE an einer anderen Stelle im Dateisystem ein Verzeichnis mit den entschlüsselten Daten eingehängt wird. Die Daten in dem eingehängten Verzeichnis kann man ganz normal bearbeitet, sie sind jedoch nicht physikalisch vorhanden, sondern werden on-the-fly ent- bzw. verschlüsselt. Dabei ist es egal, ob das Verzeichnis mit den verschlüsselten Daten auf der lokalen Festplatte, im Netzwerk oder halt bei einem Storage-Dienstleister wie Dropbox liegt. Damit eignet sich EncFS hervorragend dafür, Dateien, die in der Cloud liegen, vor neugierigen Augen zu schütze. Einzige Voraussetzung ist, dass sich der Online-Storage irgendwie ins Dateisystem mounten lässt.

Im Gegensatz zu TrueCrypt schützt EncFS die Daten nicht vollständig vor neugierigen Blicken: Es werden zwar die Daten und die Dateinamen verschlüsselt, jedoch liegen die Dateien offen im Dateisystem, sodass man – die entsprechenden Systemrechte vorausgesetzt – die Zahl der Dateien, die Dateigrößen, die Metadaten (wie z.B. die Zeitstempel) sowie die Verzeichnisstruktur sehen kann. Aus meiner Sicht ist das jedoch akzeptabel.

Dadurch dass die Dateien physikalisch einzeln im Dateisystem liegen, kann man sie getrennt schreiben. Die oben beschriebenen Probleme treten nicht auf, solange man nicht gleichzeitig schreibend auf eine Datei zugreift (wie in jedem Netzwerkdateisystem).

EncFS kommt aus der Ecke der unixoiden Betriebssysteme (Linux, Mac OS X, BSD). Es gibt auch einen Port für Windows (encfs4win), über den ich mangels eigener Erfahrungen keine Aussage machen kann.

Unter Linux installiert man EncFS über den Paketmanager. Unter OS X baut man es am besten mit Homebrew.

Update (22.06.2011, 22:53 Uhr):

Wie Tom in seinem Kommentar völlig richtig beschreibt, liegt das verzögerte Syncen des Containers nicht an TrueCrypt, sondern an Dropbox (vgl. auch Web Upd8).

TrueCrypt schreibt Änderungen des Container sofort, sodass die lokale Instanz des Containers (praktisch) immer aktuell ist.

Dropbox hingegen wartet mit dem Syncen die Datei gechlossen wird. Das ist kein Fehler oder bzw. keine Designschwäche, sondern sinnvoll und notwendig.

  • Es ist effizient, weil Dateiteile, die während der Bearbeitung mehrfach geändert werden, nur einmal im Endzustand gesynct werden.
  • Es beugt Inkonsistenzen vor, weil beim Schließen die Datei in sich konsistent sein sollten. Vorher kann die Datei in sich (logisch) inkonsistent sein, weil nur ein Teil der geänderten Daten geschrieben ist.

38 Gedanken zu „Warum TrueCrypt bei mir nix auf der Dropbox zu suchen hat [Update]

  1. Hi, interessanter Artikel. Ich finde gerade die Stelle in der TrueCrypt-Dokumentation nicht, aber ich bin der Meinung, dass geänderte Dateien sofort beim Speichern in den offenen TrueCrypt-Container geschrieben werden, dieser aber weiterhin zum Schreiben geöffnet bleibt, so dass Dropbox ihn erst nach dem Unmounten synchronisiert. Das bringt zwar in dem von Dir beschriebenen Szenario nichts, aber immerhin geht bei einem Absturz o.ä. die Änderung nicht verloren, wenn schon gespeichert wurde.

  2. Hmm, Caschy von stadt-bremerhaven.de hat grade gebloggt, dass es kein Problem gäbe im Zusammenspiel zwischen Dropbox und Truecrypt. Aber bei ihm fehlt eben auch genau der Hinweis auf eine Konstellation wie bei mir: Mind. zwei oder drei beteiligte Rechner. Ich vertrau denn mal hier 🙂

  3. Ich habe das selbe Problem mit TrueCrypt (obwohl ich davon ein Fan bin (-; ) und werden mal die EncFS Linux/Win Ports in Kombination ausprobieren. hehe, genial!

    • Zuerst Mal Danke dafür, dass Du meine Analyse bestätigst. Auch „Danke“ dafür, dass Du es im tatsächlichen Betrieb hast (auch wenn es für Dich ein Problem darstellt), denn ich dachte langsam, dass ich der Einzige wäre, der auf seine verschlüsselten Datei gleichzeitig (schreibend) mit mehreren Rechnern zugreifen möchte.

      In einem Kommentar zum oben von Frank angesprochenen Posting bei Cachy findet sich ein Hinweis auf das „EncFS-kompatible“ Windows-Tool BoxCryptor. Das könnte evtl. problemloser als der Win Port sein. (Berichte doch bitte, falls Du es ausprobierst.)

        • Hast Du schon mal versucht, EncFS 1.7 aus den den Quellen bei arg0.net selbst zu compilieren?

          Die notwendigen Packages sind unter Ubuntu 10.04 auf dem richtigen Stand. Sofern sie beim Deinstallieren von EncFS aus dem System fliegen, müsste man die manuelll über den Paketmanager wieder aufspielen.

          • Nein, Kompilieren hab ich noch nicht versucht. Guter Tipp mit den Abhängigkeiten. Die werden nicht automatisch entfernt.

            Und danke für das Zurechtrücken meines Beitrages. Es gab keine Vorschau und ich konnte ihn leider nicht editieren 🙂

  4. Interessant, aber ich bevorzuge dennoch TrueCrypt, denn es ist unabhängig vom Betriebsystem. Von EncFS gibt es zwar einen Windows-Port, aber wer schon mehrfach Probleme mit solchen Ports hatte, der weiß was ich meine: Häufig sind Ports einfach nur Schrott, hinken total der Version hinterher und haben zahllose Bugs. Von Emulatoren will ich erst garnicht anfangen… Ich habe EncFS nicht probiert, aber ich vertraue einfach lieber auf ein Programm, dass es vom Hersteller selbst für alle Plattformen gibt.

  5. Pingback: Cloud Dienste verschlüsseln mit BoxCryptor - ITrig

  6. Hi, ich finde deinen Artikel sehr hilfreich. Ich habe aber festgestellt, dass manche Sachen mit encfs4win (vielleicht auch encfs unter Linux) nicht funktionieren.
    Da ich speziell meine Daten zwischen mehreren Rechner synchronisieren wollte, habe ich versucht das komplette Firefoxprofil in die Cloud zu bringen. So weit, so gut. Als ich dann aber versucht habe, den Profilordner für meine Firefoxinstallation zu verwenden, habe ich immer nur ein leeres Browserfenster bekommen, keine plugins, keine bookmarks mehr. Die Profildaten waren aber definitiv am konfigurierten Ort (Laufwerk war ‚gemounted‘) vorhanden und ich konnte auch mit einem Dateimanager darin herumsuchen.
    Ich habe das Spielchen sowohl mit BoxCryptor (als Laufwerk) als auch mit encfs4win (sowohl Laufwerk wie auch Ordner) probiert, ohne Erfolg.
    Vielleicht kann mir jemand erklären, warum sich Firefox (und andere Programme??)
    so komisch anstellen wenn es in den virtuellen Ordner/Laufwerk geht..

    Gruss

    • Hier kann ich nicht helfen. Ich würde aufgrund der Besonderheiten von Dropbox (egal ob mit zusätzlicher Verschlüsselungsschicht oder nicht) nur bedingt als Platz für Settings nehmen. Spätestens, wenn man gleichzeitig mit mehreren Rechnern arbeitet – was bei mir eher der Regelfall ist – könnten Probleme auftreten. (Man beachte, dass die Daten erst gesynct werden, wenn sie geschlossen werden. Damit ist der Endzustand der Settings IMHO eher zufällig, weil sich die einzelnen Instanzen gegenseitig überschreiben…)

      Evtl. kann man das in den Griff bekommen, aber das ist nicht mein Ding…

  7. Das Dropbox-Truecrypt-Problem, welches du oben sehr anschaulich beschrieben hast, habe ich für mich entschärft, indem ich die Container nur jeweils an einem Rechner mit Schreibrechten mounte, da ich an den anderen Geräten nur lesen möchte. Windows beispielsweise ändert nämlich sonst immer etwas, auch ohne, dass ich eine Datei aktiv verändere, und somit ensteht eine Konfliktdatei, was extrem nervt.
    Das ist der Truecrypt-Befehl fürs schreibgeschützte mounten:
    /m -ro
    Quelle: http://www.truecrypt.org/docs/?s=command-line-usage

  8. Ich empfehle Kuala zu benutzen anstatt Dropbox.
    Wichtigster Grund für meine Wahl ist:
    Im Gegensatz zu anderen Anbietern von Online Speicher werden alle Dateien direkt auf dem Computer verschlüsselt, so dass niemand – nicht einmal die Mitarbeiter von Wuala oder LaCie – auf Ihre privaten Dateien Zugriff hat. Ausserdem verlässt Ihr Passwort zu keinem Zeitpunkt Ihren Computer.

    Zweiter Grund ist dass die Server in Deutschland, der Schweiz und Frankreich stehen.

    Siehe Webseite: http://www.wuala.com/de/learn/technology

      • hmm… blöd ist nur, dass LaCie, zu dem Wuala gehört, 2012 von Seagate Technology gekauft wurde, welche wiederum in den USA (Scotts Valley, Kalifornien) sitzen. D.h. die Server von Wuala gehören nun einer US-Firma.

        Dadurch habe ich bei Wuala nun folgendes Problem:
        „Die Bestimmungen des Patriot Acts erlauben US-Behörden wie dem FBI, der NSA oder der CIA nicht nur den Zugriff ohne richterliche Anordnung auf die Server von US-Unternehmen. Auch ausländische Töchter sind nach dem US-Gesetz verpflichtet, Zugriff auf ihre Server zu gewähren; selbst dann, wenn lokale Gesetze dies untersagen.“ (http://de.wikipedia.org/wiki/USA_PATRIOT_Act#Auswirkungen_auf_den_Schutz_personenbezogener_Daten_und_geistigen_Eigentums)

        Da bringt es mir dann wenig, wenn die Server in Europa sind. 🙁 Dadurch ist Wuala keine Option mehr für mich. Oder übersehe ich was? hoff 🙂

    • Den Hinweis habe ich zum Anlass genommen, mir doch noch mal Wuala anzusehen. Seit ich es mir zuletzt angesehen habe, hat sich viel getan, sodass der Eindruck nun deutlich besser ist.

      Aber auch weiterhin deckt Wuala nicht das ganze Funktionsspektrun von Dropbox ab, sodass es kein Ersatz für Dropbox ist (es fehlt weiterhin die nahtlose Einbindung in iOS-Apps).

      Es könnte aber ein zuätzliches Standbein werden.

    • Das Thema BoxCryptor hatten wir schon einige Kommentare weiter oben.

      Das Problem ist, dass BoxCryptor nur eingeschränkt abwärtskompatibel ist (ab Version 1.7). Viele ältere, aber noch maintainte Linux-Distributionen (z.B. bis Ubuntu 10.10) bringen ein EncFS mit, dass zu alt ist. (Habe auch noch so ein Legacy-System am Laufen)

  9. –> Problem Rechtevergabe

    Hi,

    hab mir EncFS für Win installiert und die Synchrnisierung läuft soweit.
    Aber das Problem ist, dass alle Dokumente, sobald sie im gemounteten Laufwerk liegen, eine neue Rechtevergabe bekommen.
    Word und PDF Dokumente kann man so garnicht mehr öffnen. Auch mit einer erweiterten Freigabe und „als Admin“ öffnen hat nicht weitergeholfen.

    funktioniert bei euch alles normal? Hat jemand einen Tipp wie man das beheben kann?? EncFS ist eingentlich perfekt, bringt aber unter den oben beschrieben Umständen rein garnichts!!

    Gruß Mark

  10. Hallo,

    stehe vor folgendem Problem – ich habe eine Festplatte, auf der haufenweise Dokumente liegen und unter anderem zwei Programme, die auf mdb-Datenbanken zugreifen. Das ganze ist auch netzwerktauglich.

    Jetzt würde ich gerne die Sachen in Richtung DropBox/GoogleDrive schieben – zur Sicherheit vor physikalischen Festplattenschäden. Kriege ich das ganze irgendwie verschlüsselt drauf, so dass ich wie im herkömmlichen Dateisystem parallel arbeiten kann? Mit TrueCrypt wohl nein, aber ein anderer Weg?

    Danke!

    • Mir ist die Fragestellung mir nicht ganz klar. Geht es um die gleichzeitige Arbeit mit einem oder mehreren Computern?

      Wenn man mit mehreren Computern gleichzeitig arbeitet, ist mit Sync-Diensten wie Dropbox kein sicherer Parallelbetrieb möglich. Übrigens auch nicht mit EncFS. Man könnte vielleicht Erfolg haben, wenn nur ein Rechner den verschlüsselten Container auf der Dropbox mountet und das Volume – sofern das überhaupt geht – per Netzwerkshare dem zweiten Rechner zur Verfügung stellt. Aber die Betonung liegt auf vielleicht.

      Arbeitet man mit nur einem Computer und wird die Datei nur wechselweise von den beiden Programmen genutzt, dann sollte es auch mit einem TrueCrypt-Container auf dem einen Rechner gehen. Denn die Datei würde dann ja nur lokal gelesen und geschrieben werden.

      Die beschriebenen Beschriebenen Probleme treten nur dann auf, wenn man die Dropbox als „Übertragungsmedium“ zwischen zwei Rechnern nutzt.

      • Hallo Sven, sicheren, verschlüsselten Parallelbetrieb bekommt man nur mit Online-Speichern hin, die CIFS/SMB oder Webdav Zugriff ermöglichen (keine Sync-Plattformen). Obiger Link zeigt eine für Studies kostenfreies Tool, das man annonym downloaden kann. Etwas Ähnlliches habe ich bei Securstar.com als ShareCrypt gefunden – funzt aber seit der Version 5 nicht mehr so gut. Leider ist alles überhaupt nicht passend mit EncFS für andere Plattformen.

        • Mmh, da kann ich mich nicht voll anschließen.

          Zunächst mal die Frage, was „Parallelbetrieb“ bedeutet. Wenn das gleichzeitige Nutzung mit zwei Programmen bedeutet, dann geht das – verschlüsselt oder nicht – per CIFS & Co auch nicht. Entweder beherrscht das System Locking, dann kommt die zwei Applikation nicht oder nur lesen an die Dateien, oder es gibt kein Locking und dann kann es auch hier zu Kollisionen kommen.

          Wenn man nicht gleichzeitig, sondern immer schön nacheinander arbeitet, dann kann es auch per Sync-Dienst gehen. Ist aber riskant.

          Ich schließe mich Dir aber an, dass ein Netzwerkdateisystem wie CIFS grundsätzlich für die Zusammenarbeit mehrerer Nutzer besser geeignet ist.

          BTW: Beherrscht WebDAV Locking? Wenn nein, ist es auch nicht geeignet.

  11. Echt interessanter Artikel.

    Nur ein Hinweis:

    Truecrypt unterstützt von Hause aus auch nicht das MEHRFACHE Mounten von Containern im RW-Modus.

    Soll heißen: Damit genau das geschilderte Szenario NICHT passiert überprüft Truecrypt in der Regel vor dem Mounten eines Containers immer, ob dieser bereits von anderer Stelle (bspw. einem anderen COmputer im Netzwerk) geöffnet ist. Ist dies der Fall, wird IMMER im RO (read-only) Modus gemounted.

    Deshalb KANN das geschilderte Experimant auch nicht glücken. Dieses Szenario ist nicht vorgesehen.

    Offensichtlich kann von Truecrypt aufgrund des Setup v. Dropbox nicht überprüft werden, ob der Container schon irgendwo gemounted ist. Somit glauben beide Truecrypts, dass sie schreiben dürfen. Das KANN NICHT funktionieren. Dafür wurde Truecrypt nie geschaffen – ein derartiger Modus ist nicht implementiert.

    Ich nutze Truecrypt schon lange und stieß recht früh auf dieses Problem, da ich die Container im Netzwerk auf mehreren Rechnern gleichzeitig nutzen wollte. Da dies nie auf allen Rechnern im RW Modus klappte musste ich die Countainer immer auf einem Rechner im RW Modus mounten und dann das entschlüsselte Dateisystem für die anderen freigeben. Das klappt mit Dropbox eben nicht …

    • Es ist mir völlig klar, dass die Ursache für die Probleme nicht ursächlich bei Truecrypt zu suchen ist, sondern, dass das Programm hier eindeutig „jenseits seiner Spezifikation“ genutzt wurde.

      Bei dem Posting geht es auch nicht darum, TrueCrypt zu kritisieren oder madig zu machen.

      Es ging mir nur darum, vor der (zu) oft empfohlenen Kombination von Dropbox und TrueCrypt zu warnen. Beide Produkte für sich sind gut, nur die Kombination von beiden kann in besonderen Anwendungsfällen zu unguten Ergebnissen führen.

      Aus meiner Sicht kann TrueCrypt auf einer Dropbox in diesen Fallgestaltungen keine Chande zu erkennen, ob der Container schon gemountet ist. Ich könnte mir zwei Strategien vorstellen, wie dies geprüft wird, aber beide funktionieren schlichtweg nicht auf einer Dropbox:

      1. TrueCrypt verlässt sich aus das File-Locking. Bekommt es aufgrund eines Lock keinen RW-Zugriff auf die Container-datei, dann mountet es halt read-only. Wäre aus meiner Sicht nicht die beste Startegie, weil zu viele Dazeisysteme oder Protokolle für netzwerklaufwerke Filelocking nicht unterstützen. Dropbox tut dies – aus IMHO guten Gründen – auch nicht. (Details kannst Du meinem Posting zur in Konflikt stehenden Kopie entnehmen.)
      2. TrueCrypt schreibt sich beim Mounten ein Merkmal in den Container. Zieht bei der Nutzung von Dropbox auch nicht, weil Veränderungen erst nach dem Schließen der Datei (also dem Unmounten des Containers) gesynct werden.
  12. Wegen der aktuellen Sicherheitslücken in EncFS gibt es jetzt ein neues Open Source Projekt, das sogar noch ein paar weitere Vorteile bietet (z.B. verschlüsselt es auch Dateigrößen und Ordnerstruktur), es aber trotzdem schafft, die im Artikel beschriebenen Synchronisationskonflikte von TrueCrypt zu vermeiden:
    https://www.cryfs.org

    • Da CryFS grundsätzlich den gleichen Weg wie EncFS geht, werden die beschriebenen Probleme in der Form wohl auch bei diesem KryptoFS nicht auftreten.

      Das Projekt sieht interessant aus, ist aber leider für mich noch in einem zu frühen Stadium. Mir ist das Projekt mit wohl nur einem Entwickler auch etwas zu schmal aufgestellt. Auch fehlt noch die Unterstützung von OS X (auch nicht minimal in Form eines Homebrew Packages).

  13. Pingback: „in Konflikt stehende Kopie“ bei Dropbox | ThoSch:Blog

  14. Pingback: Anforderungen an eine Dropbox-Alternative | ThoSch:Blog

  15. Pingback: Cryptomator – Lösung für Verschlüsselung in der Cloud? | ThoSch:Blog

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kommentare abonnieren

Es erfolgt keine Weitergabe von Daten an externe Dienste wie WordPress.com.

eMail-Benachrichtigung bei weiteren Kommentaren.
Auch möglich: Abo ohne Kommentar.