VeraCrypt - Wovon hängt die Entschlüsselungsdauert ab?

[nonharderware]

Titel = Frage.

Von welchen CPU-Faktoren hängt die Dauer der Entschlüsselung eines Containers ab?

Kerne? Befehlssatz? GHz?

:confused:

[Geldmann3]

Das kommt ganz auf die verwendete Verschlüsselungsmethode an.
AES wird sogar in Hardware beschleunigt, sollte also signifikant schneller sein als alles andere.

Mehr Taktrate sollte auf derselben CPU generell für mehr Performance sorgen.

[nonharderware]

Verstehe.

Gibt es bei Twofish Serpent AES relevante Unterschiede bei den Voraussetzungen an CPUs von Intel und AMD?

[lumines]

Vergiss "Twofish Serpent AES" und nimm nur AES. Deine CPU kann sehr wahrscheinlich AES in Hardware beschleunigen, was nicht nur schnell, sondern auch sicherer als AES in Software ist, weil alle Operationen durch AES-NI in konstanter Zeit berechnet werden können.

Die einzige legitime Alternative zu AES ist heute üblicherweise ChaCha20. Alles andere kannst du getrost ignorieren.

Von welchen CPU-Faktoren hängt die Dauer der Entschlüsselung eines Containers ab?

Das kommt auf die Chipher an, die verwendet wird. AES kann wie gesagt in Hardware beschleunigt werden und kommt sehr schnell auf mehrere Gigabyte pro Sekunde. ChaCha20 kann nicht in Hardware beschleunigt werden, ist aber auch in Software vergleichsweise schnell und kann (im Gegensatz zu AES) auch in Software in konstanter Zeit berechnet werden. Praktisch kann man daher sagen, dass du immer AES nutzen willst, wenn deine CPU AES beschleunigen kann (sei es durch AES-NI oder vergleichbare Instruktionen von z.B. ARMv8) und in allen anderen Fällen ChaCha20.

[nonharderware]

Vergiss "Twofish Serpent AES" und nimm nur AES. Deine CPU kann sehr wahrscheinlich AES in Hardware beschleunigen, was nicht nur schnell, sondern auch sicherer als AES in Software ist, weil alle Operationen durch AES-NI in konstanter Zeit berechnet werden können.

Die einzige legitime Alternative zu AES ist heute üblicherweise ChaCha20. Alles andere kannst du getrost ignorieren.



Das kommt auf die Chipher an, die verwendet wird. AES kann wie gesagt in Hardware beschleunigt werden und kommt sehr schnell auf mehrere Gigabyte pro Sekunde. ChaCha20 kann nicht in Hardware beschleunigt werden, ist aber auch in Software vergleichsweise schnell und kann (im Gegensatz zu AES) auch in Software in konstanter Zeit berechnet werden. Praktisch kann man daher sagen, dass du immer AES nutzen willst, wenn deine CPU AES beschleunigen kann (sei es durch AES-NI oder vergleichbare Instruktionen von z.B. ARMv8) und in allen anderen Fällen ChaCha20.

:up:

Herzlichen Dank!

[Locutus2002]

Die einzige legitime Alternative zu AES ist heute üblicherweise ChaCha20. Alles andere kannst du getrost ignorieren.

Ich welcher Hinsicht legitim? Sicherheit oder nur Performance? Wo kann man sowas nachlesen? Mich würde mal ein Vergleich der verschiedenen Verschlüsselungsmethoden bzgl. Performance und Sicherheit interessieren.

[Badesalz]

Das kommt ganz auf die verwendete Verschlüsselungsmethode an.
AES wird sogar in Hardware beschleunigt, sollte also signifikant schneller sein als alles andere.
Ist Camellia wieder rausgeflogen?

Allgemein...
1. Bisher gibt es keinen - öffentlich bekannten - theoretisch sichereren Algo als Serpent. Das war damals so und ist heute noch genauso. Sein asm64 für x86 ist bereits voll ausgereift. Besser geht nicht.

2. Camellia, ist grob gesagt der AES wie er hätte sein müssen, wenn sein primärer Schwerpunkt Sicherheit wäre. Camellia kann daher ebenfalls AES-HW nutzen (!), wird aber nicht so stark beschleunigt wie AES. Ist damit aber quasi immer die zweitschnellste Lösung.

3. Es gibt keine Szenarios in dem die Crypto eines Privatmenschen (auch den egal wie zivilrechtlich kriminellen) angegriffen werden sollte. Entweder man hackt das laufende System, wodurch Crypto egal wird (weil dann hat man alles) oder man hackt die Software die Crypto macht, weil sie fehlerhaft bzw. nicht genug abgesichert ist. Sonst wir der klassischen Arbeit nachgegangen wie z.B. Mikrokamera im Feuermelder auf den Bildschirm, social engineering usw. usw.
In anderen Gegenden ist das Hacken des Passwortes in der Tat weiterhin durchgeführt, nicht aber am System, sondern an seinem Besitzer selbst...

Es macht wenig Sinn sich über Cryptoalgos viel Kopf zu machen. Systemsicherheit ist wie immer massiv wichtiger. Bei Crypto sind Hashing und Passworthandling allgemein, das notwendigere Thema.

[Corny]

Ich welcher Hinsicht legitim? Sicherheit oder nur Performance? Wo kann man sowas nachlesen? Mich würde mal ein Vergleich der verschiedenen Verschlüsselungsmethoden bzgl. Performance und Sicherheit interessieren.


Für die Performance der einzelnen Verschlüsselugnsverfahren hat Veracrypt einen integrierten Benchmark.

[nonharderware]

Für die Performance der einzelnen Verschlüsselugnsverfahren hat Veracrypt einen integrierten Benchmark.


Cool, dies war mir nicht bekannt!

[lumines]

Ich welcher Hinsicht legitim? Sicherheit oder nur Performance? Wo kann man sowas nachlesen? Mich würde mal ein Vergleich der verschiedenen Verschlüsselungsmethoden bzgl. Performance und Sicherheit interessieren.

In Software wie VeraCrypt findet man haufenweise exotische oder obskure Verschlüsselungsmethoden, von denen man als Nutzer besser die Finger lassen sollte, weil sie entweder zu langsam sind oder keinen klaren Sicherheitsgewinn gegenüber AES liefern.

Camellia, Serpent, Twofish etc. stammen z.B. aus einer Zeit, bevor AES standardisiert wurde. Es ist nicht so, dass sie pauschal schlecht sind, sondern dass sie heute neben AES einfach praktisch keine Relevanz mehr haben. Aus historischen Gründen sind das vielleicht interessante Ciphers, aber man sollte sich wirklich fragen, ob man Ciphers und Codepfade in einer Software wie VeraCrypt nutzen will, die das letzte Mal vor 20 Jahren aktiv begutachtet worden sind.

Davon abgesehen sind hier so Sachen wie der verwendete Blockmodus und die Key Derivation Function zum Strecken der verwendeten Passphrase sowieso wichtiger als der eigentliche Algorithmus für die symmetrische Verschlüsselung. AES-XTS mit einem Passworthash wie PBKDF2, bcrypt oder scrypt ist auch ziemlich genau das, was alle modernen Vollverschlüsselungen nutzen.

1. Bisher gibt es keinen - öffentlich bekannten - theoretisch sichereren Algo als Serpent. Das war damals so und ist heute noch genauso. Sein asm64 für x86 ist bereits voll ausgereift. Besser geht nicht.

Es ist wahrscheinlich tatsächlich so, dass Feistelchiffren aus akademischer Sicht länger analysiert worden sind als anderen Arten symmetrischer Verschlüsselung. Trotzdem würde heute vermutlich niemand ohne einen sehr guten Grund etwas anderes als AES oder eine der ChaCha-Varianten nutzen. Die Sicherheitsmargen sind hier einfach so hoch und die Performance zu gut, als dass Alternativen hier noch konkurrenzfähig wären. Signifikant schneller als AES in Hardware oder ChaCha20 in Software bei wenigstens gleichen oder besseren Sicherheitsmargen zu sein ist scheinbar schwierig.

Vor einigen Jahren wurde für Android eine weitere Blockchiffre zur Vollverschlüsselung von Low-End-Geräten vorgeschlagen, aber daraus ist z.B. nichts geworden: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da7a0ab5b4babbe5d7a46f852582be06a00a28f0

Das Problem hat sich auf eine gewisse Art und Weise sowieso von selbst gelöst. Auch Android-Low-End-Geräte haben mittlerweile mit ARMv8 vergleichbare Performance und Sicherheit wie x86-Hardware mit AES-NI. Die Diskussion ist damit noch einmal ein gutes Stück langweiliger geworden.

[Rooter]

weil alle Operationen durch AES-NI in konstanter Zeit berechnet werden können.
...
und kann (im Gegensatz zu AES) auch in Software in konstanter Zeit berechnet werden.Kannst du bitte erklären, was es mit diesem "in konstanter Zeit" auf sich hat. Geht es da um potentielle Seitenkanal-Angriffe?

MfG
Rooter

[lumines]

Geht es da um potentielle Seitenkanal-Angriffe?

Genau, man könnte theoretisch anhand der Rechenzeit bestimmter Operationen etwas über die verschlüsselten Daten lernen.

[nonharderware]

Genau, man könnte theoretisch anhand der Rechenzeit bestimmter Operationen etwas über die verschlüsselten Daten lernen.

Parallel verschlüsseln mit verschiedenen Algorithmen und nur einen nehmen?
Wäre ja bei MC-CPUs nicht so das Drama.

[lumines]

Parallel verschlüsseln mit verschiedenen Algorithmen und nur einen nehmen?
Wäre ja bei MC-CPUs nicht so das Drama.

Falsch implementiert kann es schlechter sein als nur AES zu nutzen. Auch richtig implementiert würde ich das eher unter Esoterik laufen lassen. AES-256 hält sogar hypothetischen Quantencomputern stand. Eher findet jemand Angriffsmöglichkeiten über den XTS-Modus oder in der Authentifizierung der Daten.

Viele Container- und Vollverschlüsselungen sind nur unter ganz bestimmten Sicherheitsmodellen sicher nutzbar. Wenn du z.B. einen per VeraCrypt-verschlüsselten Container auf ein Medium lädst (z.B. ein entferntes Speichermedium wie ein S3 Bucket, Dropbox etc.), auf das auch ein Angreifer Schreibrechte hat, dann kann er der Ciphertext oder den Header des Volumes modifizieren. Dadurch sind diverse Angriffe möglich, teilweise kann darüber auch lokal auf deinem Rechner Code ausgeführt werden.

Das sind leider Probleme, die sehr viele Kryptosysteme haben, die ihre Wurzeln in den 90ern haben. Die Authentifizierung der Daten war damals noch nicht so ein großes Thema, weil Daten eher lokal auf einem Rechner oder Ort lagen, auf den Angreifer keinen ständigen Zugriff hatten. Deshalb spielt die Wahl der symmetrischen Verschlüsselung generell eher eine nicht ganz so wichtige Rolle, wie man vielleicht meinen würde. Es ist eher wichtiger zu verstehen, unter welchen Annahmen so etwas wie eine Vollverschlüsselung sicher ist. Als Verschlüsselung von internen oder externen Speichermedien ist VeraCrypt vermutlich vollkommen in Ordnung, zum Lagern auf entfernten Speichermedien (Netzwerkshares, Cloudspeicher etc.) ist es aber nicht geeignet.

[Badesalz]

Ähmm... also wenn Crypto nur wirkich sicher sein sollte, wenn keiner die Daten in die Hände bekommt :confused: dann erkenne ich den Sinn darin nicht ;)

AES-XTS mit einem Passworthash wie PBKDF2, bcrypt oder scrypt ist auch ziemlich genau das, was alle modernen Vollverschlüsselungen nutzen
In meiner halbjährlichen Tradition möchte ich daran erinnern, daß "modern" nicht zu den Adjektiven gehört die eine Eigenschaft bezüglich der Qualität beschreiben können.
Es entstammt Latein, bedeutet im Original "neuartig" und für Leute die kleinwenig Lebenserfahrung in die Diskussionen bringen gibt es keine reale Grundlage um es um weitere Assoziationen zu erweitern.

https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Kleine Diskussion mit dem Autor
https://news.ycombinator.com/item?id=7675698

Eine erste reale Erkenntnis: Wenn ihr Daten nach draußen auslagert, lagert es nicht als Images von FDE, sondern als Container. Und natürlich macht ihr für euch selbst auch eine Checksum der Datei um es zu vergleichen, wenn ihr den Container holt.
(nein, nicht CRC ;))

Ich hab mit "Mounir" darüber schonmal kurz über Mail diskutiert. Und wir kamen sogar zum einen Konsens. Nämlich, daß wir uns in unserer jeweiligen Meinung ziemlich verunsichert haben :usweet: Das Thema ist leider selbst für Cryptoverhältnisse jenseits von trivial :usad:

Seitenkanäle... Da liefert bereits Wikipedia genug Stoff für die richtigen Gedanken. Es wird nicht der Algo, sondern die Implementierung (die Cryptosoft selbst also) "beobachtet". Klingelt es hier bei jemandem inwiefern und auf welche Weise genau, das Homeuser betrifft und was dann schon alles schiefgelaufen ist, bevor man sich so an eure Crypto ranmacht?
https://de.wikipedia.org/wiki/Seitenkanalattacke

Daher bleibt mein "3." imho immer der wichtigste Punkt.
Es gibt auch keinen besseren Schutz als die Daten die es zu schützen gibt, bei sich zu behalten :tongue:
Als ich das letzte Mal über Datensicherheit nachdachte, hab ich mir anschliessend eine "echte" HW-Firewall gebaut die nicht von den Clients aus bedient wird/werden muss und einen echten NAS mit ZFS.

p.s.:
Das sind leider Probleme, die sehr viele Kryptosysteme haben, die ihre Wurzeln in den 90ern haben. Die Authentifizierung der Daten war damals noch nicht so ein großes Thema, weil Daten eher lokal auf einem Rechner oder Ort lagen, auf den Angreifer keinen ständigen Zugriff hatten.Das liegt daran, daß man damals Sicherheit nach klaren Sicherheitsregeln definierte. Und ich sehe persönlich kaum Szenarios wo ein Privatmann das heute anders sehen sollte.

[lumines]

Ähmm... also wenn Crypto nur wirkich sicher sein sollte, wenn keiner die Daten in die Hände bekommt :confused: dann erkenne ich den Sinn darin nicht ;)

Das ist auch nicht das, was ich geschrieben habe. "In die Hand bekommen" wäre read-only. Ich habe bewusst von einem Angreifer geschrieben, der schreibenden Zugriff auf die Daten haben kann.

In meiner halbjährlichen Tradition möchte ich daran erinnern, daß "modern" nicht zu den Adjektiven gehört die eine Eigenschaft bezüglich der Qualität beschreiben können.
Es entstammt Latein, bedeutet im Original "neuartig" und für Leute die kleinwenig Lebenserfahrung in die Diskussionen bringen gibt es keine reale Grundlage um es um weitere Assoziationen zu erweitern.

Ich meine "modern" im Sinne von: Man hat aus den Fehlern der Vergangenheit gelernt. Der XTS-Modus ist eine Antwort auf die Unzulänglichkeiten der CBC / CTR-Modi für Vollverschlüsselungen.

Dein verlinkter Artikel geht übrigens auf genau das alles ein. Im Grunde gibst du hier den Inhalt von dort nur sehr undifferenziert und teilweise falsch wieder.

Eine erste reale Erkenntnis: Wenn ihr Daten nach draußen auslagert, lagert es nicht als Images von FDE, sondern als Container. Und natürlich macht ihr für euch selbst auch eine Checksum der Datei um es zu vergleichen, wenn ihr den Container holt.
(nein, nicht CRC ;))

Egal ob Images oder Container: Der XTS-Modus ist nicht sicher auf entfernten Medien nutzbar.

Du kannst eine Prüfsumme als Poor Man's Message Authentication Code nutzen, musst das dann aber bei jeder Änderung des Containers machen. Aber genau das fehlt eben: Ein MAC, der den Container / das Image authentifiziert.

Wegen genau dieser Probleme ist es auch so schwierig eine Vollverschlüsselung auf Blockdevice-Ebene zu designen. Es ist einfacher einzelne Dateien zu authentifizieren als ein Blockdevice. Du kannst problemlos eine Datei nehmen, sie verschlüsseln (das kann auch der alte CBC-Modus sein), einen MAC per z.B. HMAC bilden und vor dem Entschlüsseln diesen MAC checken. Fertig ist eine Verschlüsselung, die resistent gegen Manipulation durch einen Angreifer ist. Solche verschlüsselten Dateien kann man dann auch auf "unsicheren" Medien lagern. Heute würde man eher AES-GCM, ChaCha20-Poly1305 oder was auch immer nehmen, weil die schon von sich aus Dateien (oder auch zusätzlichen Plaintext, z.B. den Header eines Volumes) authentifizieren, aber das Prinzip ist letztendlich immer das gleiche.

Eine einfache Verbesserung bei VeraCrypt wäre, dass man wenigstens den Header des Volumes authentifizieren könnte. So könnte man gewisse Angriffe abmildern. Dessen sind sich die Autoren von VeraCrypt wahrscheinlich auch bewusst, ich liefere hier keine neuen Einblicke oder so. Es ist nur so, dass man damit ein neues Format bilden würde, das nicht mehr abwärtskompatibel mit dem alten Format wäre. Offenbar ist das nicht gewünscht, also wird es eben für immer ein paar Schwächen haben. Wenn man die Schwächen versteht und VeraCrypt nicht "falsch" benutzt, ist das auch vollkommen in Ordnung. Ich will hier nur die Limitierungen aufzeigen und dass es auch bessere Möglichkeiten gibt. Nur weil VeraCrypt keine Verbesserungen am Format vornimmt, bedeutet das nicht, dass es keine klaren Verbesserungen geben kann.

Ich hab mit "Mounir" darüber schonmal kurz über Mail diskutiert. Und wir kamen sogar zum einen Konsens. Nämlich, daß wir uns in unserer jeweiligen Meinung ziemlich verunsichert haben :usweet: Das Thema ist leider selbst für Cryptoverhältnisse jenseits von trivial :usad:

Irgendwie habe ich das Gefühl, dass bei der Konversation nur eine Person verunsichert worden ist.

p.s.:
Das liegt daran, daß man damals Sicherheit nach klaren Sicherheitsregeln definierte. Und ich sehe persönlich kaum Szenarios wo ein Privatmann das heute anders sehen sollte.

Genau das hat man damals leider nicht gemacht. VeraCrypt hat z.B. kein klares Threat Model. Das gilt übrigens auch für den XTS-Modus. Man kann nur rückwirkend sagen, dass es unter bestimmten Annahmen sicher ist.

[Badesalz]

Das ist auch nicht das, was ich geschrieben habe.Na dann :cool:

Ich meine "modern" im Sinne von: Man hat aus den Fehlern der Vergangenheit gelernt. Der XTS-Modus ist eine Antwort auf die Unzulänglichkeiten der CBC / CTR-Modi für Vollverschlüsselungen.Gabs da nicht schon was anderes dazwischen? :wink:

Dein verlinkter Artikel geht übrigens auf genau das alles ein. Im Grunde gibst du hier den Inhalt von dort nur sehr undifferenziert und teilweise falsch wieder.Und habs trotzdem soweit verstanden, daß ich genau den Artikel verlinkte der auf genau das eingeht. Das könnte man wohl gut nutzen, wenn man Leuten erklären will was ein Paradoxon ist ;)

Egal ob Images oder Container: Der XTS-Modus ist nicht sicher auf entfernten Medien nutzbar.Dafür ist er halt modern...

Du kannst eine Prüfsumme als Poor Man's Message Authentication Code nutzen, musst das dann aber bei jeder Änderung des Containers machen.Das schon, aber Privatvolk wirft Container imho fast nie in die Cloud um dann ständig damit zu arbeiten.

Aber genau das fehlt eben: Ein MAC, der den Container / das Image authentifiziert.Nun.. Nochmal ein undifferenzienter und teilweise falscher Link von mir...
https://github.com/veracrypt/VeraCrypt/issues/681

Es ist nur so, dass man damit ein neues Format bilden würde, das nicht mehr abwärtskompatibel mit dem alten Format wäre.[/quote]Es gab schonmal solche Veränderungen in der Geschichte des Projektes.

Irgendwie habe ich das Gefühl, dass bei der Konversation nur eine Person verunsichert worden ist.Schon ok. Ich will deine Gefühle keineswegs verletzen. Andererseits mich auch nicht mit dir über sie unterhalten. Ein ehrliches toi toi toi muss an der Stelle reichen.

Sonst hab ich deinen Ansatz leider nicht in Gänze durchgeblickt: Die Kategorie "unsichere Medien" ist mir bisher femd. Es gibt auch andere?
Das eigene Medium kann jedenfalls nicht das Gegenteil davon sein. Sobald jemand den Datenträger mitnimmt/klaut oder man es verliert, ist das ein genauso ein unsicheres (entferntes) Medium wie wenn man die Daten in der gleichen Form auf irgendeiner Cloud lagert. Ergo, es gibt keine sicheren Medien. Das ist auch zu allermeist der Antrieb dafür warum die Leute ihre Daten verschlüsseln.

p.s.:
An sich bin ich auch eher für "nur" Dateiverschlüsselung. Was in der Nutzung leider um Größenordnungen beschwerlicher ist. Der einzige annehmbare Ansatz den ich dazu kenne war/ist die v1 von AxCrypt unter Win.

[lumines]

Nun.. Nochmal ein undifferenzienter und teilweise falscher Link von mir...
https://github.com/veracrypt/VeraCrypt/issues/681

Ich sag ja, die Idee einen MAC zu integrieren ist nicht besonders originell und relativ naheliegend, nur eben technisch schwierig umzusetzen, wenn man das für Blockdevices umsetzen will. Deshalb ist in dem Issue natürlich auch wenig passiert.

Sonst hab ich deinen Ansatz leider nicht in Gänze durchgeblickt: Die Kategorie "unsichere Medien" ist mir bisher femd. Es gibt auch andere?
Das eigene Medium kann jedenfalls nicht das Gegenteil davon sein. Sobald jemand den Datenträger mitnimmt/klaut oder man es verliert, ist das ein genauso ein unsicheres (entferntes) Medium wie wenn man die Daten in der gleichen Form auf irgendeiner Cloud lagert. Ergo, es gibt keine sicheren Medien. Das ist auch zu allermeist der Antrieb dafür warum die Leute ihre Daten verschlüsseln.

Das kann man schon so sehen, aber dann wäre VeraCrypt für deine Anforderungen eigentlich nicht geeignet.

p.s.:
An sich bin ich auch eher für "nur" Dateiverschlüsselung. Was in der Nutzung leider um Größenordnungen beschwerlicher ist. Der einzige annehmbare Ansatz den ich dazu kenne war/ist die v1 von AxCrypt unter Win.

Es ist nicht wirklich schwieriger, es muss nur transparent über das jeweilige Dateisystem unterstützt werden. Normalerweise wird dann aber auch direkt über das Dateisystem verschlüsselt und so etwas wie VeraCrypt ist dann eigentlich obsolet.

[Badesalz]

Das kann man schon so sehen, aber dann wäre VeraCrypt für deine Anforderungen eigentlich nicht geeignet.Für meine? Wofür nochmal taugt das dann?

Es ist nicht wirklich schwieriger, es muss nur transparent über das jeweilige Dateisystem unterstützt werden. Normalerweise wird dann aber auch direkt über das Dateisystem verschlüsselt und so etwas wie VeraCrypt ist dann eigentlich obsolet.Irgendwie hab ich so ein Bauchgefühl, daß wenn alleine durch die Systemanmeldung ein Zugriff auf diese Daten/Dateien frei ist, das für ein gängiges privates System keine gute Idee ist und das einen kleinen Haufen zusätzlicher Angriffsverktoren bereitstellt...

Ich muss noch kurz darüber nachdenken :ucoffee:

Bis denne.

[lumines]

Für meine? Wofür nochmal taugt das dann?

Das ist bei unauthentifizierten Vollverschlüsselungen tatsächlich nicht so offensichtlich, gegen was sie überhaupt schützen können. Genau das war / ist auch der Grund, warum man überhaupt angefangen hat, transparente, authentifizierte Vollverschlüsselungen direkt über das Dateisystem zu machen.

Ich kann es nur immer wieder sagen: VeraCrypt und TrueCrypt hatten nie ein formales Threat Model. Man kann sich nur einzelne Angriffszenarien ausdenken und schauen, ob es diesen standhalten könnte. Alle Analysen von VeraCrypt / TrueCrypt gehen auch genau so vor, z.B. die vom BSI: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Veracrypt/Veracrypt.pdf?__blob=publicationFile&v=1

Das BSI kommt hier übrigens auch zum gleichen Schluss:

In conclusion, we did not find substantial security issues in VeraCrypt. VeraCrypt in its current version does seem to protect the confidentiality of data in an encrypted volume as long as the volume is not mounted. Authenticity and integrity, however, are not protected.

VeraCrypt ist vollkommen in Ordnung, wenn man die Vertraulichkeit von Daten auf z.B. einem verloren gegangenen Laptop oder Datenträger sicherstellen will. Alles darüber hinaus kann VeraCrypt nicht leisten.

Das Dokument vom BSI ist aber generell interessant. Man findet dort einen Abschnitt, dass dieses Mixen mehrerer Ciphers wenigstens nicht schlechter ist als nur AES zu nutzen. Es ist zwar relativ sinnlos, aber immerhin hat man damit keinen groben Fehler gemacht, wenn man es irgendwann einmal genutzt hat.

[Badesalz]

VeraCrypt ist vollkommen in Ordnung, wenn man die Vertraulichkeit von Daten auf z.B. einem verloren gegangenen Laptop oder Datenträger sicherstellen will. Alles darüber hinaus kann VeraCrypt nicht leisten.Wenn man mit "verloren gegangen" alle Arten von Entwendung meint, was gibt es da noch für weitere Szenarien bezüglich Verschlüsselung? (für die es eben weniger taugt)

[lumines]

Wenn man mit "verloren gegangen" alle Arten von Entwendung meint, was gibt es da noch für weitere Szenarien bezüglich Verschlüsselung? (für die es eben weniger taugt)

Verschlüsselte Offsite-Backups fallen mir spontan ein.

[Badesalz]

Offsite? Also der USB-Stick mit dem Container der bei Eltern lagert? ;)

https://www.computerweekly.com/de/feature/Was-Offsite-Backup-vom-Cloud-Backup-unterscheidet