V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Eventuell sind zwei Dinge in der Anleitung nicht mehr aktuell:
|
franco_bez
Anmeldungsdatum: 1. Mai 2007
Beiträge: 688
|
V for Vortex schrieb: Wie kann ich prüfen, ob meine Root-Partition mit Data Journaling eingehängt ist? Ich könnte das dann nämlich an meinem frischen Test-14.04(edit:13.10) exemplarisch prüfen.
findmnt in der Konsole eingegeben sollte alles auflisten
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Danke. Und das müsste data=journal oder writeback anzeigen, nicht ordered richtig? Dann ist der Absatz noch gültig – und ich muss die grub.cfg meines neu installierten System anpassen. 😕
|
franco_bez
Anmeldungsdatum: 1. Mai 2007
Beiträge: 688
|
V for Vortex schrieb: Danke. Und das müsste data=journal oder writeback anzeigen, nicht ordered richtig? Dann ist der Absatz noch gültig – und ich muss die grub.cfg meines neu installierten System anpassen. 😕
Da bin ich überfragt. So wie ich man mount verstehe ist das journal auch bei data=ordered aktiv, es scheint da nur die Reihenfolge der Schreibzugriffe eine andere zu sein. Wie sich das genau auf die Performance und die Datensicherheit bei Stromausfall auswirkt müßte man nachforschen.
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
franco_bez schrieb: So wie ich man mount verstehe ist das journal auch bei data=ordered aktiv, es scheint da nur die Reihenfolge der Schreibzugriffe eine andere zu sein.
Was uns zur Frage zurück bringt, ob der Abschnitt im Wiki (so) (noch) stimmt. Bei mir hat die dort genannte Kerneloption nichts an data=ordered geändert.
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Nachtrag: data=ordered betrifft in der Tat nur die Reihenfolge des Schreibens von Daten und Journal, zeigt also somit ein aktives Journaling an. Außerdem soll es in Ubuntu die Standardeinstellung sein, welche Datensicherheit der höheren Geschwindigkeit von data=journal vorzieht.
Da bei meinem nach der Wiki-Anleitung verschlüsseltem Kubuntu 13.10 sowohl mit und ohne die Kerneloption kopt=root=/dev/mapper/vgubuntu-root das /-Dateisystem mit data=ordered gemountet wird, scheint der Tipp im Artikel überholt zu sein.
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Zufällig gefunden: Tuning: Journal-Modus aendern 🤓 Dort sind die drei Modi kurz erläutert. Ich bin dafür, den (m.E. auch völlig falsch betitelten) Abschnitt System_verschlüsseln#GRUB-Konfiguration-aktualisieren-ueberpruefen nach unten zu den anderen Problemlösungen zu schieben und um eine vorangehende Prüfung des Journalings per findmnt (data=journal , ordered oder writeback ) zu erweitern, um zu sehen, ob der Kerneleintrag wirklich nötig ist – bei mir wie gesagt nicht. Bei der Gelegenheit würde ich die doch schon recht zahlreichen Problemlösungen eine zusammenfassende Überschrift geben. Alternativ könnte der o.g. Abschnitt in einen Hinweiskasten, da optional, aber nicht direkt ein Problem behandelnd. Allerdings ist er mit dem findmnt-Zusatz erst nach und nicht während der Installation sinnvoll. Meinungen? Und zuletzt: Kann der Abschnitt über das nicht mehr unterstützte 10.04 weg?
|
franco_bez
Anmeldungsdatum: 1. Mai 2007
Beiträge: 688
|
V for Vortex schrieb: Ich bin dafür, den (m.E. auch völlig falsch betitelten) Abschnitt System_verschlüsseln#GRUB-Konfiguration-aktualisieren-ueberpruefen nach unten zu den anderen Problemlösungen zu schieben und um eine vorangehende Prüfung des Journalings per findmnt (data=journal , ordered oder writeback ) zu erweitern, um zu sehen, ob der Kerneleintrag wirklich nötig ist – bei mir wie gesagt nicht. Bei der Gelegenheit würde ich die doch schon recht zahlreichen Problemlösungen eine zusammenfassende Überschrift geben. Alternativ könnte der o.g. Abschnitt in einen Hinweiskasten, da optional, aber nicht direkt ein Problem behandelnd. Allerdings ist er mit dem findmnt-Zusatz erst nach und nicht während der Installation sinnvoll. Meinungen? Und zuletzt: Kann der Abschnitt über das nicht mehr unterstützte 10.04 weg?
Wenn Du Zeit hast, dann mach das. Für mich hört sich das gut an.
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Danke, ich legs mir auf die Wochen-Todo-Liste. ☺
|
at46n
Anmeldungsdatum: 5. Januar 2013
Beiträge: Zähle...
|
Unter "Software und Kernelmodule laden" steht "Dann werden bis einschließlich Jaunty in einem Terminal durch Eingabe von modprobe dm-crypt die benötigten Kernelmodule geladen." Jaunty wird nun schon länger nicht mehr Unterstützt. Ist der Befehl in Lucid oder neueren Ubuntuversionen noch nötig oder ist der ganze Absatz hinfällig?
|
stfischr
Anmeldungsdatum: 1. März 2007
Beiträge: 19197
|
at46n schrieb: oder ist der ganze Absatz hinfällig?
So ist es. Wenn du möchtest kannst du das gerne entfernen.
|
user32847
Anmeldungsdatum: 29. Januar 2014
Beiträge: 332
|
Am 19. Juni gab es folgende Änderung:
cryptsetup -c aes-xts-plain64 -s 512 -h sha512 luksFormat /dev/sdX2 Ich kenne mich mit Kryptographie nicht aus, in den Cryptsetup-FAQ steht aber folgendes SHA-1 is (academically) broken for finding collisions, but not for using it in a key-derivation function. And that collision vulnerability is for non-iterated use only. And you need the hash-value in verbatim. This basically means that if you already have a slot-key, and you have set the PBKDF2 iteration count to 1 (it is > 10'000 normally), you could (maybe) derive a different passphrase that gives you the the same slot-key. But if you have the slot-key, you can already unlock the key-slot and get the master key, breaking everything. So basically, this SHA-1 vulnerability allows you to open a LUKS container with high effort when you already have it open. The real problem here is people that do not understand crypto and claim things are broken just because some mechanism is used that has been broken for a specific different use. The way the mechanism is used matters very much. A hash that is broken for one use can be completely secure for other uses and here it is.
Was empfehlt ihr so? Muss man dann evtl. --iter-time auch ändern?
|
at46n
Anmeldungsdatum: 5. Januar 2013
Beiträge: 6
|
Ich muss zugeben, dass ich die Sicherheitslücke von SHA-1 nicht verstanden und deshalb die Änderung vorgenommen habe. So wie ich die von dir zitierten FAQ (https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions Punkt 5.20) jetzt allerdings verstehe, war dies nicht wirklich nötig. Allerdings ist mir auch kein Nachteil bekannt, wenn man SHA512 statt SHA-1 einsetzt. Die Option --iter-time bzw. -i ändert die Zeit die der Rechner für die Iterationen verwendet wenn ein Schlüssel hinzugefügt bzw. ein neues Crypt-Device erstellt wird. Standard ist dabei 1000 ms also eine Sekunde. Dabei werden wie in der FAQ bereits erwähnt in der Regel mehr als 10000 Iterationen durchgeführt. Wenn du nun eine längere Zeit wählst, werden natürlich mehr Iterationen durchgeführt, allerdings dauert dann das Entschlüsseln mit diesem Schlüssel auch jedes mal entsprechend länger. Dies ist aber von der verwendeten Hardware abhängig. Man sollte aber davon ausgehen, dass ein Angreifer in der Lage ist die Iterationen in einem Bruchteil der Zeit durchzuführen, weshalb meiner Meinung nach ein gutes Passwort viel wichtiger ist als eine längere Iterationszeit. Aber vielleicht kann da nochmal jemand mit mehr Verständnis von Kryptographie etwas dazu sagen.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
Die SHA-1 Attacke wurde m.W. immer noch nicht in der Praxis umgesetzt. Das ist alles sehr theoretischer Natur und bei Iterierung wie sie LUKS durchführt ehwieso hinfällig, da man die Attacke dann hunderttausendfach wiederholt zur Anwendung bringen müsste. Hashkollisionen sind eher für andere Anwendungen interessant, z.B. wenn man dir ein modifiziertes Ubuntu-ISO unterjubeln will, das dir bei der Prüfung mit sha1sum trotzdem das richtige Ergebnis liefert. Da gibts auch keine Iteration, sondern nur ein Hash und fertig. Aber selbst da verlassen sich die meisten immer noch auf md5... Der Hauptzweck der Hashfunktion bei LUKS ist eigentlich, Rechenzeit zu verbraten und zwar so, daß keine Abkürzung möglich ist. D.h. wer Passwörter bruteforcen will kommt nicht drum herum, für jeden Versuch erneut hunderttausend mal die Hashfunktion zu durchlaufen.
Man sollte aber davon ausgehen, dass ein Angreifer in der Lage ist die Iterationen in einem Bruchteil der Zeit durchzuführen, weshalb meiner Meinung nach ein gutes Passwort viel wichtiger ist als eine längere Iterationszeit.
Beides ist wichtig. Was bei dir auf deinem aktuellen Rechner eine ganze Sekunde Zeit zur Berechnung braucht, wird auch auf anderer/schnellerer Hardware etwas kosten. Und egal wie gut dein Passwort ist, es macht einen Unterschied ob du pro Sekunde nur tausend Passwörter probieren kannst oder 100 Millionen. Aber LUKS macht die Iteration ja sowieso automatisch, insofern braucht man sich da keinen Kopf drum machen. Wenn man jetzt den LUKS Container vor vielen Jahren auf entsprechend langsamerer Hardware angelegt hat, kann man das vielleicht mal erneuern (luksAddKey usw.), aber sonst... den genauen Itercount den cryptsetup verwendet hat, kann man sich mit cryptsetup luksDump anschauen. Wir haben hier im Forum schon mal ein LUKS Bruteforce geschafft. ( http://forum.ubuntuusers.de/topic/luks-passwort-vergessen/ ). Aber das war großes Glück. Der Container wurde auf alter Hardware angelegt und hatte somit einen geringen Itercount, entsprechend mehr Versuche konnten pro Sekunde durchgeführt werden. Zudem lag eine gute Idee vor wie das Passwort aufgebaut gewesen war. Wenn du die möglichen Passwörter nicht auf wenige tausend einschränken kannst hast du da einfach keine Chance.
|
stfischr
Anmeldungsdatum: 1. März 2007
Beiträge: 19197
|
Hey, bin gerade im Forum drauf aufmerksam geworden. Unter Boot-Partition steht: Größe: mindestens 120 MB (mehr ist im Regelfall aber nicht nötig ggf. müssen nur nach einigen Updates alte Kernelpakete deinstalliert werden)
Anhand der vielen "/boot ist voll"-Threads im Forum halte ich die Empfehlung für gefährlich. Ich selber nutze immer 1GB für /boot, dann muss ich nur 2 Mal im Jahr aufräumen ☺ jug meinte, dass man da mehr etwas allgemeines und keine konkrete Größenempfehlung schreiben sollte. Wobei die min 120MB natürlich bleiben sollen (bzw bei Bedarf auf kommende riesen-Kernels angepasst werden) Mir schwebt da eine Formulierung wie: Größe: mindestens 120 MB. Je kleiner man /boot wählt, desto häufiger muss man sich um die Entfernung alter Kernels kümmern. Bei 1GB braucht man nur 1 bis 2 Mal im Jahr aufräumen, wer genügend Platz hat, sollte sich den Komfort gönnen.
|