unbuntuS12
Anmeldungsdatum: 2. Juni 2010
Beiträge: 1816
|
@itoss:
[...] jedem der Linux mit Hirn nutzt und schaut was im System passiert erklären sich die Zusammenhänge von selbst ...
Ja, ja. Selber nix Substantielles zum Thema beizutragen zu haben als irgendwelche unbegründeten Mutmaßungen über Verschlüsselung, aber Leute diskreditieren, die Diskussionen anstoßen, Dinge im Kopf bewegen und sich informieren und davon profitieren, wenn Menschen Dinge anders und in ihren Worten formulieren.
Naja ich bin raus, zum Manuals zitieren ist mir meine zeit zu schade ...
Ich bitte darum! Die Zeit, die du bis hier verwendest hast, war in keiner Weise sinnvoll investiert.
|
Toehah3u
Anmeldungsdatum: 27. April 2015
Beiträge: 817
|
(A-) itoss schrieb: Soziales Ausspionieren ist immer noch am einfachsten, da die Menschen in der Regal immer noch gutgläubig und hilfbereit sind und den Feind nicht als solchen sehen.
Tja, der gutgläubige und hilfsbereite Bürger wird mal eben vom BKA unter Generalverdacht gestellt: Im Kampf gegen Terroristen und deren Nutzung verschlüsselter Kommunikation fordert das Bundeskriminalamt Wieso eigentlich BKA? Ich dachte immer wir haben einen Verfassungsschutz und den MAD? 😕
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Von itoss habe ich bessere wie schlechtere Beiträge gesehen - bei ihm steckt schon mehr dahinter als man manchmal meinen könnte. 😉 Ich denke, lubuntu-lulu ist sehr wissbegierig und wir mussten uns die Denkweisen auch erst aneignen. Ein Link zu lost+found hätte es jetzt auch nicht kürzer gemacht und das Verschachtelungsdenken dauert bei manchen eben etwas oder sie sind sich noch unsicher. Wird schon irgendwann ankommen und Klick machen. Sah ja auch auf einem ganz guten Weg aus. Für mehr Fragen gibt es ja auch Links, aber vieles hier sind eher grundsätzliche Denkweisen - die kann man aber schon noch mal in einem Forum durchkauen (müssen ja nicht immer fünf Seiten werden). Jemand, der fragt, ist mir allemal lieber als jemand, der keinen Bock hat und so rüberkommt wie "hier, mach mal". Das mit dem selber Doku lesen kommt dann schon, wenn man mit Links anfüttert - oder man lässt es eben bleiben. Abpinseln muss die Links keiner - ergeben sich Detailfragen oder auch Grundsatz-Verständnisprobleme, kann man sie klären. Muss auch nicht jeder alles so im Detail verstehen. Vielleicht sollte man es mal irgendwie aufmalen:
Hier sieht man schön, wo was ist und wo die Grenzen verlaufen. Die Grenzen sind hart: Dateien wissen nur, dass sie in ext4 geschachtelt sind, aber nix von LUKS. ext4 weiß nur, dass es in LUKS liegt, aber nix von der Partition. LUKS weiß, in welcher Partition es liegt und welches Dateisystem drin ist. Aber das Wichtigste: ext4 ist es egal, ob es in LUKS oder direkt in Partition liegt, wenn nicht verschlüsselt wird. Bei ecryptfs sieht das anders aus: Da entfällt die Zwischenschicht wie LUKS, stattdessen sieht man die Dateien alle mit verschlüsselten Namen. Bei LUKS sieht man gar nichts. Nach dem Entschlüsseln sieht es bei beiden Verschlüsselungsmethoden so aus, als seien da nur normale Dateien drin. Bei LUKS kann man nicht mal erahnen, dass die Dateien irgendwie verschlüsselt sind - man sieht ihnen absolut nichts an. Die Daten selber wissen es auch nicht. Das wird alles voreinander versteckt. Also gibt es auch keinerlei Unterschiede für die Dateien, ob nun LUKS vorhanden ist oder nicht. Beispielsweise findet sich bei beiden Varianten immer der Ordner lost+found. Erst wenn man tiefer bohrt, sieht man, dass die Dateien verschlüsselt sind, z.B. wenn man hier guckt:
$ mount
...
/dev/mapper/luksdisk on /geheim type ext4 (rw)
...
Normalerweise sieht man hier im Dateimanager nur, dass seine Daten in /geheim sind - allenfalls der Name ist verräterisch, könnte aber auch /videos oder sonst wie heißen. Aber in der Ausgabe sieht man auch den mapper als Gerät, sprich den Teil, der oben mit LUKS aufgemalt wurde. Er hat auch einen frei wählbaren Namen, hier im Beispiel luksdisk. Ohne LUKS würde dort statt dessen /dev/sda1 oder sowas stehen bzw. neuerdings ja eine ID: UUID=*****. Könnte man hier auch so machen, aber der Name luksdisk ist hier auch eindeutig genug, das System speichert die UUID dazu woanders. Wenn ich aber jetzt noch mehr erkläre, macht es das eher komplizierter - wahrscheinlich bin ich mit dem letzten Absatz auch schon etwas über dieses Stadium hinaus. Grüße, Benno
|
lubuntu-lulu
(Themenstarter)
Anmeldungsdatum: 7. September 2014
Beiträge: 542
|
Benno-007 unbuntuS12 Herzlichen Dank für euer Verständnis und eure Geduld! itoss schrieb: Das sind alles Grundlagen um die es hier geht und jedem der Linux mit Hirn nutzt und schaut was im System passiert erklären sich die Zusammenhänge von selbst ...
Diesen Standpunkt verstehe ich ehrlich gesagt nicht ganz. Ich nutze (L)Ubuntu jetzt seit rund zwei Jahren und bevor ich mich hier für die Verschlüsselung und LUKS interessierte, musste ich mich noch nie mit ext4 oder Partitionen beschäftigen. Vielleicht war ich ja zu dumm oder blind? Ich nutzte meine USB-Sticks und Festplatten die letzten zwei Jahren ja immer noch mit FAT-32/NTFS. Mir war gar nicht so klar, dass es (wenn ich die Datenträger nur für Linux benutzen werde) auch Sinn machen würde sie mit ext4 zu formatieren.
Ja, vielleicht hätte ich mir mal den Wiki-Artikel über Dateisysteme/Formatierung durchlesen müssen.
Immerhin war mir von Anfang an klar, dass die Festplatte auf der mein Lubuntu läuft anders formatiert ist als bei einem Windows-System. Aber wie gesagt, in meinem Alltag musste ich mich nie mit ext4 und Partitionen beschäftigen, und ich nutzte wohl weiterhin FAT-32/NTFS, weil ich mir nicht sicher war, ob ich einen der Datenträger nicht doch mal an ein Windows-Gerät anschließen werde. Mittlerweile kenne auch ich den Wiki-Artikel zu ext4 und LUKS/Verschlüsselung. Ich verstehe ehrlich gesagt nicht, warum du einem so nahe treten musst. Ich habe mehrfach gesagt, dass ich eben etwas langsamer im Denken bin oder öfters zwei-dreimal nachfragen muss damit ich es wirklich verstanden habe.
Wenn ich deine Geduld oder dein Fachwissen damit zu sehr strapaziere, dann kannst du dich ja tatsächlich einfach aus der Diskussion verabschieden. Es ist schon faszinierend: Im Vergleich zu den meisten Bekannten von mir verstehe ich und weiß ich mehr über Linux und Computertechnik, aber im Vergleich zu vielen hier im Forum bin ich eben doch noch ein totaler Schüler und Anfänger mit unglaublich vielen Wissenslücken. Zusammenfassend kann ich nur sagen, dass ich in den letzten zwei Jahren unglaublich viel über Linux gelernt habe. Ich hätte mir nie erträumt, dass ich mal so viel über die Kommandozeile bedienen werde oder kleinste Parameter in Konfigurationsdateien ändern werde, damit etwas nach meinen Wünschen funktioniert. Oder, dass ich über ein Bash-Script und das Firefox AddOn "OpenWith" Bilder direkt an Imgur.com zum Upload schicken werde. Ich bin im Vergleich zu meinem einstigen Windows-Nutzen viel bewusster in meiner Computernutzung geworden und verstehe (in vielen Fällen) die Zusammenhänge viel mehr. Trotzdem muss ich auch zugeben, dass ich mich nicht jeden Tag mit Linux,Datenträgern oder Programmieren beschäftige.
In meinem Alltag läuft auf meinem fast alles so wie ich es haben möchte und wenn mal ein Problem auftritt, dann habe ich es bisher immer mit Hilfe der tollen und geduldigen Forenmitglieder hier gelöst bekommen. Und jedes Mal habe ich was dazu gelernt, so dass ich es beim nächsten Mal hoffentlich auch alleine lösen kann. Ich bin auch stolz darauf, es jetzt geschafft zu haben einen meiner Datenträger zu verschlüsseln - auch wenn es "nur" ein paar Terminalbefehle waren! Ich beschäftige mich ja gerade mal eine gute Woche mit dem Thema Verschlüsselung und auf den ersten Blick kann das ein kleines Hirn wie meines schon etwas durcheinander bringen.
Ich werde immer Verständnis dafür haben, wenn jemand sagt, dass seine Geduld mit mir am Ende ist - aber dann bitte einfach in einem freundlichen Ton ☺ Ein schönes und erholsames Wochenende! LG,
Leo
|
romensch2
Anmeldungsdatum: 8. Juni 2012
Beiträge: 170
|
Hallo Leute, ähnlich wie lubuntu-lulu würde ich im Vgl. zum "Forumstandard" nicht als Linux-Experten bezeichnen, jedoch hab ich in den vier Jahren Ubuntu einiges dazu gelernt. Seit 14.04 verschlüssele ich meine Ubuntu-Installation. Hauptgrund ist, dass ich den Laptop oft herumschleppe (Uni, Reisen in der Bahn) und man nie ausschließen kann, dass der geklaut wird. Der Täter hätte dann nicht nur mein Gerät sondern auch meine ganzen Daten, das ist ein großer Teil "Persönlichkeit". Da ich konsequent Google, Facebook etc. meiden will ist es dann nur logisch gegen so einen Fall vorzubeugen. Standard-Kriminelle, die mir den Rechner klauen würden, wird so eine encfs/LUKS Verschlüsselung schon effektiv abschrecken. Aufwand die Daten zu holen zu hoch, formatieren, neues Windoof drauf und Gerät auf dem Hehlermarkt verkaufen. Ohne Verschlüsselung liegen die Daten jedoch auf dem Präsentierteller und können einfach abgeschöpft werden.
Staatsfeind Nr. 1 bin ich nicht, daher gehe ich jetzt nicht auf Szenarien ein was der Verfassungsschutz oder gar die NSA alles anstellen würden/können. 😉 Seit 16.04 hab ich LUKS eingesetzt als Verschlüsselung. War auch etwas stolz, dass ich das hinbekommen habe, auch wenn es nur ein paar Terminalbefehle sind. Aber man muss dann doch mal einen Nachmittag Zeit investieren und im Wiki lesen, um die Idee und Funktionsweise des ganzen zu verstehen und dann auch die Terminalbefehle einigermaßen umsetzen zu können. Hatte auch bisher einen Fall, als ich von Live Ubuntu auf die Platte zugreifen wollte und das ging dann auch mit dem manuellen Mounten. Bauchschmerzen hätte ich nur falls mal die Partitionen neu aufgeteilt werden müssten. Aber ich denke bis 18.04 werde ich mit den jetzigen Partitionen auskommen. 😉 Für externe Datenträger ist mir ext4 oder gar LUKS allerdings ehrlichgesagt zu unkomfortabel. Oft trägt man damit ja Daten zu anderen Leuten und die haben dann Windows (oder Bluerayplayer etc lesen nur FAT32/NTFS) und selbst ein einfaches ext4 nervt mich dann schon, wenn man zwar Dateien lesen kann aber dann nur als root schreiben kann, weil man kein chown gemacht hat etc. Da bin ich dann zu wenig vertraut mit Dateisystemrechten, um mich dann bei externen Datenträgern auf jedem Gerät mit auseinanderzusetzen. 😀 Soviel meine Meinung dazu. ☺ Aber auf jeden Fall ein super Wiki und eine super Community hier. Man bekommt echt sehr viel Hilfe, das ist einer der Hauptgründe, wieso ich Ubuntu nicht mehr gegen MS Windows tauchen wollen würde. 👍
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Da reicht setzen von ext (Tipp ganz unten) auf Gruppe plugdev, so dass quasi jedes Ubuntu/ Linux drauf zugreifen kann, nachdem man es ansteckte. Der Gruppe natürlich ggf. alle Rechte geben. Problem ist wohl die Rechtevererbung - da steht aber hier was zu ACL: http://unix.stackexchange.com/questions/67105/is-it-possible-to-disable-file-permissions-on-a-ext3-or-ext4-file-system Im Prinzip gibt man entgegen dem Beispiel unten dann mit setfacl statt für Gruppe sudo für plugdev alle Rechte. Und Luks ist ein Klick im Dateimanager und schon kommt die PW-Abfrage. Auf vernünftigen Rechnern mit vorinstalliertem LUKS.
|
lubuntu-lulu
(Themenstarter)
Anmeldungsdatum: 7. September 2014
Beiträge: 542
|
AES gilt doch immer noch als nicht geknackt, oder? Gibt es noch sicherere/stärke Verschlüsselungsmethoden für mich als Normalanwender? Weil ich verstehe nicht ganz die im deutsch und englischen Wikipedia aufgelisteten Attacken/Schwachstellen. Bei manchen Attacken auf AES und bei manchen Schwachstellen wird dann erwähnt, dass dieses oder jenes Vorgehen aber in der Praxis keine Anwendung finde würde/könnte (und nur ein mathematisches Rechenspiel ist?). Englisches Wikipedia:
Attacks have been published that are computationally faster than a full brute force attack, though none as of 2013 are computationally feasible. For AES-128, the key can be recovered with a computational complexity of 2126.1 using the biclique attack. For biclique attacks on AES-192 and AES-256, the computational complexities of 2189.7 and 2254.4 respectively apply. Related-key attacks can break AES-192 and AES-256 with complexities 2176 and 299.5, respectively. The key space to be searched by brute force increases by a factor of 2 for each additional bit of key length (assuming, importantly, random choice of keys) which alone increases the degree of difficulty for a brute force search very rapidly. Mere key length is not, however, regarded as sufficient for security against attack, for there are ciphers with very long keys which have been found vulnerable. However, related-key attacks are not of concern in any properly designed cryptographic protocol, as a properly designed protocol (i.e., implementational software) will take care not to allow related-keys, forcing key choice to be as random as possible. The first key-recovery attacks on full AES were due to Andrey Bogdanov, Dmitry Khovratovich, and Christian Rechberger, and were published in 2011.[28] The attack is a biclique attack and is faster than brute force by a factor of about four. It requires 2126.2 operations to recover an AES-128 key. For AES-192 and AES-256, 2190.2 and 2254.6 operations are needed, respectively. This result has been further improved to 2126.0 for AES-128, 2189.9 for AES-192 and 2254.3 for AES-256,[29] which are the current best results in key recovery attack against AES. This is a very small gain, as a 126-bit key (instead of 128-bits) would still take billions of years to brute force on current and foreseeable hardware. Also, the authors calculate the best attack using their technique on AES with a 128 bit key requires storing 288 bits of data (though this has later been improved to 256,[29] which is 9 petabytes). That works out to about 38 trillion terabytes of data, which is more than all the data stored on all the computers on the planet in 2016. As such this is a seriously impractical attack which has no practical implication on AES security.
At present, there are no known practical attacks that would allow anyone to read correctly implemented AES encrypted data.
Diese Aussage verstärkt meinen Eindruck, dass all diese auf Wikipedia zitierten Attacken auf AES zur Zeit fast "nur" mathematische oder kryptografische Rechenspiele/Konzepte/Ideen sind, aber in der Praxis noch keinerlei Anwendung finden können.
Allgemein ist natürlich zu sagen, dass es eine ganz andere Geschichte ist, was die Geheimdienste möglicherweise bereits geknackt habe ohne es publik zu machen 😀 Stimmt es weiterhin (wie im Wiki angedeutet), dass das Backup eines LUKS-Headers Angreifern kein Bißchen weiterhelfen kann?
Vlt. ist das ja ein anderer Kontext und mein Englisch ist wieder zu schlecht, aber spricht dieser Blog nicht über ein Risiko mit dem Header? Kann man den Backup-Header also ungeschützt auf einem anderen Datenträger rumliegen haben?
Wird dieses Backup entwendet, ist ein Zugriff auf den verschlüsselten Container trotzdem nur mit Schlüsselinformationen möglich
Wiping the RAID superblock just leaves the disk with encrypted data from dm-crypt. Since no other headers are present in an unencrypted format, it is impossible for an attacker to make sense of the encrypted data (partition boundaries, or filesystem superblocks for example).
PS: Über was macht diese luksDump Ausgabe eine Aussage? In mehreren Versuchsbeispielen stand da bei mir rmal 8 und mal 512.
Allgemein, gibt es eine (deutsch?) Erkläörung für die luksDump Ausgabe? Verstehe nämlich auch die ganzen anderen Bezeichnungen nicht (vielleicht bis auf cipher name/mode, uuid) Key material offset
Salt
Iterations
Version:
Cipher name:
Cipher mode:
Hash spec:
Payload offset:
MK bits:
MK digest:
MK salt:
MK iterations:
UUID: Ich weiß, das sind wieder viele Fragen und Quergedanken auf einmal. Ein wenig frage ich mich in diesem Zusammenhang natürlich schon wie die Datenschutz und Privacy-Kämpfer es je erreichen möchten, dass Hinz und Kunz auf einfachste Weise Verschlüsselung benutzen kann, denn mein Eindruck ist schon, dass es sich wie bei fast allem verhält: Wenn man wirkliche Sicherheit möchte, dann muss man sich schon etwas mehr mit der Materie beschäftigen und sie verstehen (oder es wie ich trotz geringer Intelligenz versuchen). ☺ Immerhin bekomme ich die Verschlüsselung mit LUKS bereits selbstständig hin 😛 aber ich möchte natürlich das Ganze etwas besser verstehen und mögliche Benutzerfehler vermeiden (gleiches galt glaube ich nämlich für die Nutzung von Tor; es waren keine technischen Fehler von Seiten des Tor-Netzwerkes die zur Identifizierung von Zielpersonen führten, sondern menschliche Benutzerfehler wie das Verwenden von selben Emailadressen oder Nicknames auf unterschiedlichen Sites). Danke für jegliche Hilfe, Erklärungen und eure Geduld mit mir.
Schade, dass ich niemanden habe der mir komplexere Zusammenhänge mal in Person erkläre kann 😛 Muss mal ein paar Mathematik-Freunde anrufen, vlt. können die mir das mit der Entropie und den Passwörtern nochmal verständlich erklären.
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Kopie vom LUKS-Header + PW = du bist drin. So hat er schon mal eine Komponente von zwei. Auf der anderen Seite hat er die ja sowieso. Allerdings ist die Gefahr, dass du mal das PW änderst, weil es z.B. im Bus von einer ÖPNV-Cam gefilmt wurde. Backup + ALTES PW = du bist drin, obwohl du ein neues gesetzt hast - aber nur im neuen Header - der alte geht ja weiterhin mit dem alten, um den Safe aufzusperren... Für viele Fragen muss man mal wenig, mal sehr viel googlen. Zu sehr ins technische sollte es gar nicht gehn, Hinweise wie oben sind für sichere Bedienung wichtig.
|
unbuntuS12
Anmeldungsdatum: 2. Juni 2010
Beiträge: 1816
|
romensch2 schrieb: Staatsfeind Nr. 1 bin ich nicht, daher gehe ich jetzt nicht auf Szenarien ein was der Verfassungsschutz oder gar die NSA alles anstellen würden/können. 😉
Na ja, die können ja nix. Also nicht nur die. Auch alle anderen. Lubuntu-Lulu hat das ja sehr schön zitiert: Eine Attacke, die Brute-Force auf einem 128-Bit-Suche um den Faktor 4 beschleunigt, verkleinert ebendiesen doch nur auf 126 Bit. Es ist zwar nicht auszuschließen, dass die Geheimdienste erfolgreiche Attacken gegen AES kennen, aber wenn auch nicht ausgeschlossen, so ist es schlicht unwahrscheinlich. Der Algorithmus liegt offen und viele, viele Kryptologen doktern dran rum. Möglich, dass man nur bei der NSA was gefunden hat, aber dann würde man auch irgendwann sehen, dass die selbst auf andere Algorithmen umsteigen. Vielmehr ist AES immer noch für Dokumente mit höchster Geheimhaltungsstufe zugelassen - allerdings erst ab 192 Bit Schlüssellänge. Das ist auch nachvollziehbar. Bruce Schneier schätzt, dass in einem lesenswerten Artikel, dass die NSA max. 80 Bit knacken kann. Konsequenterweise schreibt er
Honestly, I'm skeptical. Whatever the NSA has up its top-secret sleeves, the mathematics of cryptography will still be the most secure part of any encryption system. I worry a lot more about poorly designed cryptographic products, software bugs, bad passwords, companies that collaborate with the NSA to leak all or part of the keys, and insecure computers and networks. Those are where the real vulnerabilities are, and where the NSA spends the bulk of its efforts.
Oder, um es auf die Spitze zu treiben: xkcd. Mehr oder weniger in diese Richtung ging ja auch die Festnahme des Silkroad-Gründers:
To prevent Ulbricht from encrypting or deleting data on the laptop he was using to run the site as he was arrested, two agents pretended to be quarreling lovers. When they had sufficiently distracted him, one of the agents took his computer away and inserted a USB flash drive that cloned all the data on the hard drive.
Bleibt noch die Frage, wieso AES-128 nicht für TOP-Secret-Dokumente zugelassen ist, wenn die doch keiner knacken kann. Schneier schreibt in dem oben zitierten Artikel:
One last blue-sky possibility: a quantum computer. Quantum computers are still toys in the academic world, but have the theoretical ability to quickly break common public-key algorithms – regardless of key length – and to effectively halve the key length of any symmetric algorithm. I think it extraordinarily unlikely that the NSA has built a quantum computer capable of performing the magnitude of calculation necessary to do this, but it's possible. The defense is easy, if annoying: stick with symmetric cryptography based on shared secrets, and use 256-bit keys.
Quantencomputer reduzieren die Komplexität auf die Quadratwurzel bei symmetrischen Chiffren. Das bedeutet, mit AES-192 wäre man weiterhin safe (96 Bit zu knacken würde immerhin 2^16 = 65536(!) Mal die angenommene NSA-Leistung benötigen) und für die Extra-Portion Sicherheit nimmt man halt 256 Bit. Ich vermute auch, dass bevor symmetrische Chiffren fallen Quantencomputer die Primzahlzerlegung mit dem Shor-Algorithmus nicht nur für kleine Zahlen hinkriegen. Dann sind nämlich die asymmetrischen Chiffren kaputt. Das würde erstmal jegliche verschlüsselte Kommunikation übers Internet mit Leute verunmöglichen, mit denen man zuvor keinen symmetrischen Schlüssel ausgetauscht hat. Aber auch da gibt es Ansätze, die Funktionalität asymmetrischer Chiffren über Hashbäume zu realisieren (mir fällt gerade der Name nicht ein). Insofern: Happy Crypto! ☺ edit:
Stimmt es weiterhin (wie im Wiki angedeutet), dass das Backup eines LUKS-Headers Angreifern kein Bißchen weiterhelfen kann? Vlt. ist das ja ein anderer Kontext und mein Englisch ist wieder zu schlecht, aber spricht dieser Blog nicht über ein Risiko mit dem Header? Kann man den Backup-Header also ungeschützt auf einem anderen Datenträger rumliegen haben?
Es ist halt ein möglicher, anderer Ansatzpunkt. Vielleicht dir der Unterschied zwischen Passwort und Schlüssel noch nicht so ganz klar. AES (und DES, Blowfish, Twofish, ...) sind Blockchiffren. Es sind also Algorithmen, die als Eingabe einen Bitstring und einen Schlüssel nehmen und daraus Chiffretext produzieren. Es wird also für jeden Block ein Schlüssel benötigt. Bei AES ist ein Block immer 128 Bit groß, der Schlüssel entweder 128, 192 oder 256 Bit. Und idealerweise muss jetzt für jeden Block ein neuer Schlüssel verwendet werden. Wenn man nämlich immer denselben 128-Bit-Schlüssel verwendet, dann passiert das, was man hier sehr schön sehen kann: Der Pinguin ist verschlüsselt, aber sichtbar. Das aber nur am Rande. Wichtig ist: Auch wenn ein Blockmodus wie CBC verwendet wird, dann braucht es einen 128-Bit-Schlüssel. Du gibst aber zum Entschlüsseln keinen 128-Bit-Schlüssel, sondern ein Passwort ein. Das kann z.B. "Test" sein. Daraus wird dann über ein Schlüsselableitungsverfahren der ersten (Blockchiffren-)Schlüssel generiert. Und in welchen Fällen kann der LUKS-Header jetzt helfen? Wenn ein Passwort wirklich "Test" ist und ich weiß vielleicht nicht, dass es "Test" ist, aber ich habe Grund zur Annahme, dass du ein einfaches Passwort hast, dann brute-force ich lieber ein schwaches Passwort anstatt einen 128-Bit-Schlüssel. Wenn dein Passwort stark ist (mathematisch: Eine Entropie von mind. 128 Bit aufweist), dann schenke ich mir das und versuche direkt den Schlüssel zu erraten. Insofern: Wenn dein Passwort hinreichend komplex ist, dann hilft der Header nix. Wenn dein Passwort schwach ist, dann schon.
|
Happy_Penguin
Anmeldungsdatum: 23. Januar 2011
Beiträge: 583
|
Interessante Diskussion, die ich bisher komplett übersehen habe, weil sie sich hier versteckt, statt im Unterforum "Sicherheit". Da soll nochmal einer sagen, security by obscurity wäre nicht auch machbar ... 😉 Wenn wir hier schon beim Thema Verschlüsselung sind und weil der Threadtitel die Methode nicht einschränkt:
Hat schon jemand Erfahrung mit der EXT4-eigenen Verschlüsselung gesammelt, die ab Kernel 4.1 verfügbar sein soll? Ist die entsprechende Option in die aktuellen Ubuntu-Kernel kompiliert? Seht Ihr Vorteile gegenüber der Verwendung von LVM/LUKS zur Vollverschlüsselung, bzw. Nachteile? Swap müsste man separat ver-LUKS-en, weil es ja kein ext4-FS ist, oder?
Unverschlüsselte Grüße. 😀
|
senden9
Anmeldungsdatum: 8. Februar 2010
Beiträge: 965
Wohnort: Österreich
|
Happy_Penguin schrieb: Nein. Das kannst du auf deinem System selber nachsehen:
| zgrep EXT4_FS_ENCRYPTION /proc/config.gz
zgrep CONFIG_EXT4_ENCRYPTION /proc/config.gz
|
Wenn dort …=y steht dann schon ☺ Ja, den Swap muss man dann separat verschlüsseln wenn man das möchte. Muss man ja je nach usecase nicht. Z.B. wenn das Gesamtsystem eh unverschlüsselt ist (z.B. der Standrechner Zuhause) und man nur einen USB-Stick verschlüsselt. Ich hab mir die EXT4 Verschlüsselung noch nicht genau angesehen. Allerdings gibt es einen LWN Artikel und das EXT4 Encryption Design Document in dem das Verfahren aus technischer Sicht beschrieben wird.
|