Hallo zusammen, ich hangele mich gerade durch alte Backups, die ich deduplizieren will. In diesen Backups finden sich unter anderem TrueCrypt- oder VeraCrypt-Container, deren Inhalt sich anscheinend nur selten geändert hat. Hinein schauen kann ich nicht, will ich auch nicht. Das Problem ist: Die Container sind recht groß, es sind viele, und entsprechend lange dauert es, den Hash über die komplette Datei zu berechnen. Es würde sehr viel Zeit sparen, wenn man sich z.B. auf einen Block bestimmter Größe beschränken könnte, um festzustellen, ob sich der Inhalt geändert hat, z.B. die jeweils ersten 100 MB. Die meisten Volumes werden wohl NTFS-formatiert sein. Die Spezifikation des Datenformats ist offen dokumentiert. ( https://veracrypt.eu/en/VeraCrypt%20Volume%20Format%20Specification.html ), allerdings hilft mir das wenig weiter. Ich weiß zu wenig über Dateisysteme. An welchen Stellen ändern sich die Daten in der Containerdatei, wenn in einer Datei auf dem Gast-Dateisystem sich etwas ändert? Wahrscheinlich ja nicht überall, ansonsten wären die verschlüsselten Volumes ja unglaublich langsam. Ich gehe aber auch nicht davon aus, dass das Dateisystem 1:1 in 128-Bit-Blöcken mit konstantem Offset abgebildet wird. (Ansonsten wäre doch bei den gängigen Dateisystemen jede Menge "Plaintext" aufgrund der bekannten Dateisystemstruktur bekannt?). Kann ich überprüfen, ob sich der Inhalt in Truecrypt-Containern geändert hat, ohne die kompletten Dateien zu vergleichen?
:
Bearbeitet durch User
Was würde es wohl für die Sicherheit der Daten bedeuten, wenn zwei zum verschiedenen Zeitpunkt mit gleichen Daten befüllte Container die exakt gleichen Binärdaten aufweisen würden? Schon die alte Enigma hat an verschiedenen Tagen verschiedene Chiffre erzeugt, selbt mit den gleichen Walzeneinstellungen[1]. Denk noch mal kurz über dein Ansinnen nach. Roland [1]Wie bei der Enigma das Steckbrett mit dem Tagescode, hat auch TC/VC Pseudozufallkomponenten, welche die Chiffre variieren.
Roland E. schrieb: > Was würde es wohl für die Sicherheit der Daten bedeuten, wenn zwei zum > verschiedenen Zeitpunkt mit gleichen Daten befüllte Container die exakt > gleichen Binärdaten aufweisen würden? Es handelt sich natürlich um die selben Container, innerhalb deren Lebensdauer sich die Nutzdaten geändert haben oder auch nicht. (Also Kopien des selben Containers zu unterschiedlichen Zeitpunkten. Leider unsortiert.)
:
Bearbeitet durch User
Walter T. schrieb: > ich hangele mich gerade durch alte Backups, die ich deduplizieren will. > In diesen Backups finden sich unter anderem TrueCrypt- oder > VeraCrypt-Container, deren Inhalt sich anscheinend nur selten geändert > hat. Hinein schauen kann ich nicht, will ich auch nicht. > > Das Problem ist: Die Container sind recht groß, es sind viele, und > entsprechend lange dauert es, den Hash über die komplette Datei zu > berechnen. Es würde sehr viel Zeit sparen, wenn man sich z.B. auf einen > Block bestimmter Größe beschränken könnte, um festzustellen, ob sich der > Inhalt geändert hat, z.B. die jeweils ersten 100 MB. Wenn du nicht genau weißt, welches Filesystem in dem Container ist, dann gibt es keine Abkürzung. Um sicher zu gehen, daß das Image unverändert ist (vulgo: ein Duplikat) mußt du schon das gesamte Image hashen. Eine Abkürzung gibt es aber für den umgekehrten Fall. Wenn du das Image in Stücke teilst und den Hash über jedes Stück einzeln berechnest, reicht ein Mismatch aus. Wenn die IO-Bandbreite reicht, kannst du so auch die Partitionen parallel hashen und die Vorteile mehrerer CPU-Kerne nutzen. StoreBackup macht das z.B. so. > An welchen Stellen ändern sich die Daten in der > Containerdatei, wenn in einer Datei auf dem Gast-Dateisystem sich etwas > ändert? Wahrscheinlich ja nicht überall, ansonsten wären die > verschlüsselten Volumes ja unglaublich langsam. Normalerweise werden immer komplette Blöcke, also standardmäßig 512 Bytes auf einmal ver- bzw. entschlüsselt. > Ich gehe aber auch nicht davon aus, dass das Dateisystem 1:1 in > 128-Bit-Blöcken mit konstantem Offset abgebildet wird. (Ansonsten wäre > doch bei den gängigen Dateisystemen jede Menge "Plaintext" aufgrund der > bekannten Dateisystemstruktur bekannt?). Das Problem mit dem "known plaintext" wird umgangen, indem ein geeigneter Blockmode (meist CBC) und ein nicht ratbarer IV gewählt wird. Für LUKS (das ist das einzige das ich näher kenne) ist z.B. ESSIV wählbar. Ein anderer Modus ist XTS. In beiden Fällen führen identische Klartextblöcke zu verschiedenen Kryptoblöcken.
Hallo Walter T., Walter T. schrieb: > Dateisysteme. An welchen Stellen ändern sich die Daten in der > Containerdatei, wenn in einer Datei auf dem Gast-Dateisystem sich etwas > ändert? Wahrscheinlich ja nicht überall, ansonsten wären die > verschlüsselten Volumes ja unglaublich langsam. > > Ich gehe aber auch nicht davon aus, dass das Dateisystem 1:1 in > 128-Bit-Blöcken mit konstantem Offset abgebildet wird. (Ansonsten wäre Nein, auf Sektorebene. > doch bei den gängigen Dateisystemen jede Menge "Plaintext" aufgrund der > bekannten Dateisystemstruktur bekannt?). Nein, es wird alles verschlüsselt. Wenn wir von Dateicontainern sprechen, handelt es sich um eine Reihe von aufeinanderfolgenden Sektoren, also die Nutzdaten, die um den notwendigen Verwaltungswasserkopf ergänzt werden. Diese Nutzdaten inklusive Wasserkopf, werden durchgängig verschlüsselt, unabhängig davon, ob diese Daten den Bootsektor, bei NTFS die MFT, die Frei-Bitmap oder Verzeichnisse oder Journals darstellen. Dieser Block von Sektoren wird von Truecrypt/Veracrypt als Partition gemounted und unter Windows mit Laufwerksbuchstaben versehen. Truecrypt/Veracrypt weiß nicht, was es da verschlüsselt und behandelt alles gleich, weil eben auf Partitionsebene sektorweise verschlüsselt wird und nicht etwas auf Dateiebene. > Kann ich überprüfen, ob sich der Inhalt in Truecrypt-Containern geändert > hat, ohne die kompletten Dateien zu vergleichen? Nein, kannst Du nicht. Ich habe Deinen Beitrag abgewertet und begründe gerne auch, warum. Dein Anliegen ist sehr unsinnig! Der Inhalt von Truecrypt-Containern, die beispielsweise mit dem NTFS formatiert worden sind, kann sich auch ändern, ohne dass Nutzdaten verändert worden sind. Ein Metadatum jeder Datei ist das "Access Date", das diese Änderung verursacht. Im NTFS befinden sich diese Änderungen in der MFT ("Master File Table"). Deren Länge ist variabel, insbesondere kann die Datei sich verlängern und fragmentieren. Bei Defragmentierung kann sich die Position der MFT innerhalb des Containers ändern. Zwar haben Windows-Betriebssysteme bestimmte Angewohnheiten, wie sie NTFS-Dateisystem formatieren, aber der Speicherort der MFT ist nicht statisch sondern durch den Bootsektor festgelegt. Aber selbst wenn der Bootsektor sich nicht ändert, kann sich die Länge der MFT und ihre Bestandteile, abgelegt in sogenannten "Clustern", verändern. NTFS enthält keine Hashs über die Nutzdaten. Wenn Du auf Dateiebene hashen willst, musst Du auch einen Zugang auf Dateiebene haben. Für Dich gibt es nur ein "Friss (hash den Container) oder stirb!". Aufgrund der oben beschriebenen Problematik kannst Du die Container gar nicht deduplizieren. Wenn Deine Präferenz aber auf Erledigung der von Dir beschriebenen Aufgabe liegst, brauchst Du eher ein Dateisystem, das standardmäßig Nutzdaten hasht und die Daten abspeichert. Ob die Hashs dann auf den verschlüsselten Daten oder den Nutzdaten gerechnet werden, weiß ich nicht. Auf jeden Fall dürfte der oder die Benutzer keine *crypt-Container verwenden. Dein Fehler besteht darin, dass Du versuchst, auf eine andere Ebene im Storage-System zuzugreifen, über die Du nichts wissen kannst. Und selbst wenn Du etwas wüsstest, könnten sich diese Informationen bis zum nächsten Deduplikationsversuch ändern. Im Sinne des "Schuster, bleib bei Deinen Leisten!" ist für Dich ein Container nur eine Datei, über deren Inhalt Du nichts weißt und keine Annahmen treffen darfst.
Axel S. schrieb: > Eine Abkürzung gibt es aber für den umgekehrten Fall. Wenn du das Image > in Stücke teilst und den Hash über jedes Stück einzeln berechnest, > reicht ein Mismatch aus. Naja, das hilft ja wenig. Da hashen lineare Laufzeit hat, gewinne ich ja nichts durch partitionieren. Peter M. schrieb: > Dein Anliegen ist sehr unsinnig! Sicher. Jedes Anliegen in jeder Forenfrage war schon immer unsinnig. Ich habe mich daran gewöhnt. Peter M. schrieb: > Wenn Du auf Dateiebene hashen willst, .... Ich will nicht auf Dateiebene hashen. Mir reicht es aus zu wissen, wann ein Container unverändert ist. Stell' Dir einfach mal das folgende Szenario vor: Tante Erna hat auf ihrem PC vier Truecrypt-Container mit je 2 GB Größe. In einem sind ihre Bitcoins, in einem ihre Nackbilder vom Seniorenbingo, in einem ihre Arztbriefe und in einem ihre geheimen Kochrezepte. Dann hat sie brav seit 2014 jede Woche ein Backup ihrer gesamten Datenpartition gemacht, und leider hat das Backup-Script nie gemerkt, wenn die Container unverändert geblieben sind, weil sie sehr oft zwischen den Backups noch nicht einmal gemountet waren. So ähnlich sieht die aktuelle Datenhalde gerade aus.
:
Bearbeitet durch User
Peter M. schrieb: > Der Inhalt von Truecrypt-Containern, die beispielsweise mit dem NTFS > formatiert worden sind, kann sich auch ändern, ohne dass Nutzdaten > verändert worden sind. Ja, nur war das nicht die Frage. Das ist auch die Gegenrichtung. Es geht aber nicht darum, was in dem Container ist. Nur darum ob der Container sich verändert hat. Und zwar ohne ihn komplett zu lesen. Ich gehe auch davon aus, daß schon das reine Mounten des Filesystems im Container zu einer (Meta)Datenänderung führen wird. Aber wenn der Container gar nicht gemounted wurde zwischen zwei Backups (etwa weil das Filesystem zu einer VMware-Maschine gehört die gar nicht gelaufen ist) dann haben sich weder Container noch Inhalt verändert. Wenn man also bspw. wüßte, daß ein Timestamp mit dem letzten Mount-Zeitpunkt im Sektor X des Filesystems liegt, dann würde es reichen den (logischen) Sektor X des verschlüsselten Containers auf Änderung testen. Aber das erfordert mehr Wissen, als man normalerweise hat. Weder weiß man, was für ein Filesystem im Container ist. Noch weiß man mit welchen Tricks es gemounted wird. Es würde sich nur für die Gegenprobe eignen: Block verändert => Filesystem verändert. Aber für den anderen Fall wäre es mir zu heikel. Da würde ich den gesamten Container vergleichen (bzw. hashen).
Walter T. schrieb: > Naja, das hilft ja wenig. Da hashen lineare Laufzeit hat, gewinne ich ja > nichts durch partitionieren. Doch. Vorausgesetzt du hast mehrere CPU-Kerne und mehr IO-Bandbreite als ein Kern zum Hashen braucht.
Wenn die Volumes gemountet werden verändert Windows etwas, auch wenn logisch nichts geändert wird. D.h. - Binär identische Container sind ungeöffnet und können dedupliziert werden. - Binär ungleiche Container könnten logisch gleich sein (nur z.B. den Mülleimer geleert), aber auch neue Dateien enthalten. Für dich nicht nachvollziehbar. Du brauchst ein besseres Programm, das nicht hasht sondern beide Dateien liest und byteweise vergleicht. Beim ersten Unterschied muss es dann einfach abbrechen und du bist raus weil du nicht reinschauen kannst/willst. Wenn der User automatisch immer gemountet hat, hast du so dermaßen Pech...
Jens M. schrieb: > Du brauchst ein besseres Programm, das nicht hasht sondern beide Dateien > liest und byteweise vergleicht Das Programm müßte dann aber zwei Dateien lesen. Bzw für N Dateien müßte es pessimal N·(N-1) Vergleiche machen und dazu 2·N·(N-1) Dateien lesen. Hashbasiert läuft das ganze so, daß man nur N Dateien einliest und dabei N Hashes produziert. Und dann eine Datei, die einen Hash liefert den man schon mal gesehen hat, als Duplikat behandelt.
Hallo Walter T., Walter T. schrieb: > Ich will nicht auf Dateiebene hashen. Mir reicht es aus zu wissen, wann > ein Container unverändert ist. > > Stell' Dir einfach mal das folgende Szenario vor: Tante Erna hat auf > ihrem PC vier Truecrypt-Container mit je 2 GB Größe. In einem sind ihre > Bitcoins, in einem ihre Nackbilder vom Seniorenbingo, in einem ihre Was sind denn "Nackbilder"? Das muss etwas Perverses sein, das ich nicht verstehe! > Arztbriefe und in einem ihre geheimen Kochrezepte. Dann hat sie brav > seit 2014 jede Woche ein Backup ihrer gesamten Datenpartition gemacht, > und leider hat das Backup-Script nie gemerkt, wenn die Container > unverändert geblieben sind, weil sie sehr oft zwischen den Backups noch > nicht einmal gemountet waren. > > So ähnlich sieht die aktuelle Datenhalde gerade aus. Wunderbar! Entweder prüfst Du die binäre Identität des aktuellen Containers gegenüber dem Container aus dem letzten Backup-Lauf oder Du gibst Dich auch mit einem Hash zufrieden. Ein Unterschied im Hash bedeutet aber nicht notwendigerweise, dass sich der Dateiinhalt geändert hat, siehe oben. Axel S. schrieb: > weiß man, was für ein Filesystem im Container ist. Noch weiß man mit > welchen Tricks es gemounted wird. Es gibt keine "Tricks".
Axel S. schrieb: > Doch. Vorausgesetzt du hast mehrere CPU-Kerne und mehr IO-Bandbreite als > ein Kern zum Hashen braucht. Genau. Aber diese Voraussetzung ist nicht erfüllt. Der Flaschenhals ist eindeutig die Lesegeschwindigkeit der Festplatte(n). Die CPU langweilt sich regelrecht. Außerdem funktioniert das mit dem Hashen auch dann noch, wenn Tante Erna die Container im Dateisystem verschoben oder umbenannt hat. Wenn man sich vorstellt, dass 10 Jahre jede Woche 4 Dateien à 2 GB gesichert wurden, ist ja allein der Teil des Backups schon 4 TB. Bei allen anderen großen Dateien ist das aber kein Problem, weil die Metadaten üblicherweise vorn liegen und es reicht, die ersten ca. 50 MB zu vergleichen. Nur die TrueCrypt-Container bereiten mir Kopfzerbrechen. Aber wahrscheinlich geht wirklich kein Weg daran vorbei, auch die riesigen Container komplett zu hashen.
Walter T. schrieb: > die Lesegeschwindigkeit der Festplatte(n) Ein PC kennt keinen Feierabend. Du kannst ihn gerne über Nacht arbeiten lassen. :-) Es ist jedoch ein Geschwindigkeitsunterschied, ob ich alle Dateien auf einmal aufrufe oder nur einen Ordner aufrufe, in dem sie alle drin sind.
Axel S. schrieb: > Das Programm müßte dann aber zwei Dateien lesen. Bzw für N Dateien müßte > es pessimal N·(N-1) Vergleiche machen und dazu 2·N·(N-1) Dateien lesen. Ja, das ist korrekt. Der Unterschied ist aber: Die Hashlösung muss (!) jede Datei komplett lesen, merkt sich die Hashes und kann dann vergleichen. Der Bytevergleich kann und sollte nach einem Vergleichsfehler sofort abbrechen, weil wenn nur ein Byte nicht übereinstimmt die Datei nicht mehr gleich ist. Die Chancen stehen nicht schlecht, das das hier relativ häufig vorkommt und die Geschichte dadurch schneller wird. Zudem: Wenn man ein vernünftiges System hat, kann man von einer lokalen SSD durchaus mehrere GB/s ziehen, da geht das Vergleichen schon flott. Das vorherige umkopieren auf ein lokales Laufwerk kann dann massiv Zeit sparen.
Moin, Walter T. schrieb: > Peter M. schrieb: >> Dein Anliegen ist sehr unsinnig! > > Sicher. Jedes Anliegen in jeder Forenfrage war schon immer unsinnig. Ich > habe mich daran gewöhnt. Das nun vielleicht nicht. Aber ich wuerde mir schon Gedanken um die Qualitaet einer Verschluesselung machen, wenn jeder da mal locker flockig Annahmen ueber die Inhalte treffen koennte. Egal welche Annahmen. Und egal wie oft oder wann geaendert. Gruss WK
Jens M. schrieb: > Der Bytevergleich kann und sollte nach einem Vergleichsfehler sofort > abbrechen, weil wenn nur ein Byte nicht übereinstimmt die Datei nicht > mehr gleich ist. Die Chancen stehen nicht schlecht, das das hier relativ > häufig vorkommt und die Geschichte dadurch schneller wird. Das gilt allerdings nur, wenn gleiche Dateien in der Minderheit sind. Das ist hier definitiv nicht der Fall. Dergute W. schrieb: > Aber ich wuerde mir schon Gedanken um die > Qualitaet einer Verschluesselung machen, wenn jeder da mal locker > flockig Annahmen ueber die Inhalte treffen koennte. Jede Verschlüsselung ist ein Kompromiß. Idealerweise würden sich Änderungen in einem einzigen Zeichen in einem einzigen Datensatz auf den kompletten Cointainer auswirken. Real wäre das allerdings unbrauchbar langsam, also wird es wohl irgendeine Lokalität geben. Es gibt auch Artikel dazu, wie mehrere aufeinanderfolgende Versionsstände des gleichen Truecrypt-Containers mit leicht geänderten Inhalten die Verschlüsselung schwächen, weswegen sie für Cloud-Backups ungeeignet seien.
:
Bearbeitet durch User
Hallo Walter, Walter T. schrieb: > Jede Verschlüsselung ist ein Kompromiß. Idealerweise würden sich > Änderungen in einem einzigen Zeichen in einem einzigen Datensatz auf den > kompletten Cointainer auswirken. Real wäre das allerdings unbrauchbar > langsam, also wird es wohl irgendeine Lokalität geben. Du verwechselt da etwas. Ein Bitwechsel in einer Datei sollte etwa 50% der Bits im zugehörigen Hash verändern, wenn ich mich richtig erinnere, aber doch nicht den ganzen Container! Stell' Dir vor Du hast einen Terabyte großen Container und schreibst nun eine neue Datei namens HelloWorld.txt in den Container. Wie lange möchtest Du auf das Ergebnis warten? Ich kenne keine Verschlüsselungssoftware, die Deine Anforderung erfüllt. Der Container benimmt sich bei Zugriffen und Änderungen "lokal" wie eine ganz normale Windows-Partition mit dem Unterschied, dass Du den Inhalt nicht lesen kannst.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.