Einfachheit ist in der Kryptografie nichts Positives, und auch keine Garantie für höhere Sicherheit. Die Vergangenheit zeigte zur Genüge, welches Schicksal einfache Verschlüsselungsformen erwartet. Wieso werden nun AES und Dual_EC_DRBG in einen Topf geworfen? Das eine hat mit dem anderen nichts zu tun. Und wie kann man bei AES von mehr Sicherheit ausgehen, und komplexeren Verschlüsselungsalgorithmen potenzielle Backdoors anlasten, nur weil man sie selbst nicht versteht? Die mathematischen Operationen dahinter sind kein Geheimnis. Auch die Spezifikationen des LUKS-Header-Formats sind nebenbei einsehbar, wenn es schon um Magic Numbers geht.wanne hat geschrieben:Nein. Die Einfachheit ist vor allem eine Garantie gegen Backdoors. Man wollte eben nicht irgend welche magic numbers, von denen man im besten Fall nicht weiß, wozu die gut sind oder sogar zeigen kann, dass der Autor da backdoors drin verstecken kann. (Dual_EC_DRBG) Des weiteren machen eine solche einfachen Algorithmen wahrscheinlicher, dass angriffe entweder schnell oder nie gefunden werden.
https://de.wikipedia.org/wiki/Advanced_ ... ue-Angriffwanne hat geschrieben:Was meinst du damit?
Einfach ausgedrückt hängt die Sicherheit von AES nur noch von der Hardware ab, und ist theoretisch bereits gebrochen. Und wenn diese weiterhin derartige Leistungssprünge hinlegt, wird das in absehbarer Zeit in praktische Reichweite kommen. Das mag zwar geschätzt noch 30~ Jahre dauern, vielleicht auch mehr, aber danach ist Feierabend für AES. Denn dieser Verschlüsselungsalgorithmus hat keine weiteren Hürden aufzubieten, weil er mathematisch schlicht zu einfach designt ist.
Bei allem Verständnis, aber das ist einfach Nonsens. Woher kommt denn die Information, ich würde ohne Verstand editieren? Ziemlich anmaßend. Du editierst also einen pseudo-zufälligen Ciphertext, ohne Wissen um die dahinter stehenden Datensätze, und ohne anschließende Fehler? Fakt ist jedoch, dass hier überhaupt nichts editieren werden kann, und schon gar nicht ohne essentielles Wissen, was sich wann an einer bestimmten Stelle befindet. Vor allem wenn beabsichtigt ist, dass das hinterher noch funktionieren, oder gar noch eine vorbestimmte Aktion auslösen soll. Das basiert zu 100% auf dem Zufallsprinzip, ob so eine Manipulation Erfolg hätte. Und CRC ist auch keine Verschlüsselung.wanne hat geschrieben:Das ist halt der Unterschied zwischen breakthewall editiert ohne Verstand an seinem Volume oder jemand weiß was er macht. Ich kann dir wunderbar ext4-LUKS-Volumes editieren, ohne dass da irgend was meckert. Bei btrfs ist das dank CRCs etwas schwieriger. Aber auch die ersten Attacken gegen WEP wurde nicht, weil er RC4 verwendeten geknackt, sondern weil man gedacht hat, das CRC+Verschlüsselung so was ähnliches wie ein MAC sei. Wäre eigentlich ein ganz cooles featrure, wenn man btrfs auf SHA oder MD5 umstellen könnte. Dann wäre ich da einer meinung
Der CBC-Modus ist heute nicht mehr im Einsatz. Und unter dem XTS-Modus funktioniert das nicht in dieser Art und Weise, auch wenn Manipulationen prinzipiell möglich wären. Nur wären diese generell rein blinder Natur, da man niemals vorhersehen kann, wie betreffende Daten durch den Verschlüsselungsalgorithmus gespeichert werden. Und für eine entsprechende Datenintegrität, würde sich ggf. ZFS/BTRFS anbieten, oder man bindet effektiv Dm-verity in den Startprozess mit ein um Manipulationen festzustellen. Eine andere Option wäre mit GPG und somit mit Signaturen zu arbeiten, um sensible Bereiche des Dateisystems zu verifizieren, bspw. den Linux-Kernel selbst.wanne hat geschrieben:Sowohl das wie auch dass einfache Änderungen zu völlig unvorhersehbaren Änderungen am Klartext führen ist auch für CBC so. Trotzdem gibt es Skripte im Netz, die in so einem Verschlüsselten Ubuntu-Volume den SSH so abändern, dass er nach keinem Passwort mehr fragt.
Hilft ungemein wenn man nicht weiß was wann geschrieben wird.wanne hat geschrieben:So als kleiner Hint: Wo so ein ext hinschreibt ist ein bisschen abschätzbar. Da braucht man keine Glaskugle sondern nur mkfs.ext4 zum testen.