Wie sicher ist eine Verschlüsselung mit LUKS?

me_ver_1.0

Lt. Junior Grade
Registriert
Sep. 2005
Beiträge
458
Wie sicher ist eine LUKS Verschlüsselung mit "Schlüsseldatei" und "getrenntem (extra aufbewahrtem) Header"?
Ist in einem solchem Fall der Datenträger/die Datei als luks Verschlüsselung zu erkennen?
 
Das sollte aus dem Sourcecode lesbar sein :D

Gegenfrage: Wer soll denn nicht erkennen, dass da ein verschlüsselter Datenträger vorliegt? Dass dort Daten gespeichert sind, sieht man immer, allerdings kann man sie nicht von Zufallsdaten unterscheiden. Je nachdem wer fragt, wirst du bei Folter eher schwächer sein als die theoretische Sicherheit von LUKS. Außerdem ist schwer zu erklären, warum man eine Menge Zufallsdaten mit sich herumschleppt. Bei LUKS weiß ich es nicht genau, bei VeraCrypt kann man die beiden Header nicht vom Rest unterscheiden. Denke das ist hier ähnlich.

Willst du den Header entfernen? Der wird eh nicht erkennbar sein.
 
  • Gefällt mir
Reaktionen: BeBur
ja erkennen tut man dass verschlüsselt wurde - der Luks-Header ist im Normalfall weiterhin auf dem Volume vorhanden.

Wenn Du das nicht willst denke ich müsstest Du sowas wie ein reine "Stream" Verschlüsselung auf ein loopback device nutzen.... das ist Luks meines Wissens nicht.
 
Zuletzt bearbeitet:
LUKS ist so sicher wie deine Passphrase / Key was ausreichend hohe Entropie aufweisen sollte (XKCD 936 erklärt Entropie anschaulich, du darfst gerne, mehr als 44bit verwenden). externer Header ist sehr unüblich. kann man natürlich machen (oder auf LUKS verzichten und mit Plain verschlüsselung arbeiten Wo es keinen Header gibt). aber es besteht garkeine Notwendigkeit dazu und hat auch Nachteile
Ergänzung ()

Linux hat keine feste Laufwerks Zuordnung bei jedem Reboot können sich die Gerätenamen zufällg ändern, in Reihenfolge ihrerer Erkennung.Daher wird jedes Laufwerk über Header (UUIDs) identifiziert wenn du den LUKS header also entfernst brauchst du einen anderen Identifizierungsweg (bei GPT Partition könnte man die PARTUUID nehmen)

Sonst hast du das problem das du ext. Header keine UUID für die LUKS Daten hast und gar nicht weisst welches Gerät damit geöffnet werden muss. Du kannst damit dann jedes beliebig. Gerät öffnen nur hast du dann Datensalat statt Daten dahinter.

LUKS Extern Header ist insgesamt umständlich und wird von den meisten distirbutionen nicht standardmäsig unterstützt daher lieber den normalen LUKS Header belassen. Sicherheit ist einerlei wichtig ist auch das es zuverlässig funktioniert. Sonst sind die Daten am Ende so sicher das du selber, nicht mehr daran kommst.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Pummeluff
Wie würde das ohne LUKS mit z.B. einer Streamverschlüsselung funktionieren?

Ziel soll sein eine "Datei" zu haben (in der ein Dateiensystem steckt) die im System eingehangen werden kann.
Die "Datei" soll von aussen nicht als verschlüsselter Kontainer erkennbar sein.
Bin von ausgegangen das LUKS mit getrenntem Header genau das ist.

Welche Alternativen gibt es dazu?
 
me_ver_1.0 schrieb:
Bin von ausgegangen das LUKS mit getrenntem Header genau das ist.
Ja ist dann auch so. In der Datei ohne Header stehen nur Zufallsdaten. Zur Kontrolle, hexdump oder sonst hexeditor bemühen

Muss man aber direkt so erzeugen (Datenoffset im Header = 0) sonst sind die ersten x MB der Datei Null (wo sonst der Header stünde) und erst danach gehts mit Zufallsdaten los

Offset hat allerdings auch den Vorteil das die Datei nicht falsch erkannt werden kann. Zufallsdaten können falsch erkannt werden als Com Exe oder sonstiges. Alte dateiformate haben nur wenig magic bytes die zufällig auftreten können

Plain kann man machen aber dann braucht man noch stärkere Pass (LUKS hat Bruteforceschutz Plain von sich aus nicht), man muss sich sämtliche Parameter merken und es gibt kein Feedback ob das eingegebene Pass richtig war oder nicht, wird dann halt falsch entschlüsselt
 
Zuletzt bearbeitet:
Dafür kommt man halt bei "plain" ohne verdächtige Header aus, der ja auch irgendwo sein muss.

Das Verschlüsselte ist halt nur eine Datei oder eine unformatierte Partition / SDD etc und es gibt (ausser man hat history an bei bash etc :o ) nirgendwo einen Hinweis, dass da was verschlüsselt ist.

Dass die Gefahr da ist dass man das nicht mehr entschlüsseln kann weil man vergessen hat wie man das gemacht ist halt dann Pech, da muss man halt dafür sorgen dass dem nicht so ist .

Und wenn doch HAHA :D :D
 
Bohnenhans schrieb:
weil man vergessen hat wie man das gemacht
Jaien man muss dazu auch sagen cryptsetup verwendet Defaults. Die sich, manchmal einfach so, ändern können.

Bei Arch Linux ist plain default per aes-xts-plain64 sha256 . Bei Ubuntu 22.04 LTS ist das immer noch aes-cbc-essiv:sha256 ripemd160 .

Da funktioniert dann, auf einmal, der gleiche Befehl zum Öffnen nicht . Man muss tatsöälcih selber wissen was man da in welchem Modus laufen hat.

Bei LUKS Ändern sich auch die Defaults aber es ist im LUKS Header steht drin was los ist. Das macht weniger Kopfschmerzen.

Der Nachteil, des LUKS Headers ist dafür umgekehrt. Du kennst den Masterkey nicht der steht nur im LUKS Header hat mit der Passphrase nicht zu tun. Ist der LUKS Header kaputt sind die Daten verloren . Bei Plain kommst du immer ran weil der Master Key, direkt dein Passwort ist.

Es ist nicht verkehrt vom LUKS Header, ein Backup zu haben. Und mehr als eine Passphrase zuzufügen damit auch Keymaterial im Header, doppelt drin ist

hat eben alles Vor Nachteile
 
me_ver_1.0 schrieb:
Ist in einem solchem Fall der Datenträger/die Datei als luks Verschlüsselung zu erkennen?
Die Entropie ist bei moderner Verschlüsselung nahezu maximal, d.h. die Daten lassen sich quasi nicht von zufälligen Werten unterscheiden.
Du solltest dich aber ernsthaft fragen, ob das ein realistisches Szenario ist vs. das du als Laie selber den Zugriff auf die Daten verlierst, weil du irgendwann einen Fehler mit einem letztendlich unnötig komplizierten Setup gemacht hast.
 
Dem User geht es aber doch vor allem darum dass man nicht sehen kann dass überhaupt eine Verschlüsseluing vorhanden ist - sonst würdne die Üebrlegeungen den Header zu trennen ja gar keinen Sinn machen.

Und für den Fall ist ein Header auch wenn er extern vorhanden sein muss halt sehr viel schlechter als kein Header - auch ein externer Header verrät nunmal da wurde irgendwo gecrypted.
 
Bohnenhans schrieb:
Dem User geht es aber doch vor allem daum dass man nicht sehen kann dass überhaupt eine Verschlüsseluing vorhanden ist,
Das geht schon los mit: Braucht man plausible deniability? Auf welcher Ebene? Auf einer "Ich werf dich jetzt hier aus dem Fenster, wenn ich glaube, dass du verschlüsselte Daten hast" oder auf einer "Ich will vor (einem deutschen? russischen? chinesischen?) Gericht freigesprochen werden" Ebene? Weil man möge sich fragen, wie plausibel ist ein offensichtlich oder auch nur möglicherweiser absichtlich getrennter Speicherbereich mit maximaler Entropie.
Reicht es, wenn da mal kurz jemand auf den Laptop schaut, ob da was verschlüsselt ist? Oder werden sich das Forensiker anschauen? etc.

Verschlüsselung ist dafür afaik nicht gemacht, dafür gibt es Steganographie. Wenn es für Steganographie zu viele Daten sind, dann empfehle ich, die Existenz des Datenträgers an sich schon zu verheimlichen.
 
Ist doch egal warum er das machen will? Er wollte doch nur die technischen Möglichkeiten dazu wissen.
 
@Bohnenhans Ne, eben nicht, weil ein reines "versteckt sein" eben nicht vernünftig definiert ist. "Sicherheit" ist immer nur für konkrete Szenarien definiert, es gibt keine "Sicherheit an sich".
Wenn er einfach nur den Header entfernt, dann hat er im besten Fall einen verdächtig aussehenden Speicherbereich mit maximaler Entropie, bei dem jemand mit etwas Kenntnissen auf dem Gebiet sofort vermutet, dass es sich um verschlüsselte Daten handelt.
Wenn es ihm nur darum geht, seine Pornosammlung vor Mutti oder Freundin zu verstecken, dann soll er das sagen, da gibt es auch weniger aufwendige Möglichkeiten.
 
Äh er wollte nur wissen wie es geht - ich denke erst mal er hat sich sicher genug Gedanken selber gemacht was er machen will.

Naja ich seh das halt so:

Das ist halt sonst wie wenn jemand fragt wo ist die Sicherung für die Innenbleuchtung in meinem 911er GT3 die leuchtet nicht mehr....

Und es dann auch ganz wichtig für die Frage ist, dass man ganz ausführlich über die Vorteile von ÖPNV gegenüber der Nutzung von Individualmobilität redet, am besten jeder schreibt eine 20 seitige Abhandlung über die Vor- und Nachteile verschiedener Mobilitätsformen von Sandalen bis zum Beamen - vielleicht weiss ja der Fragesteller einfach gar nicht ob das Nutzen eines Porsches um von A nach B zu kommen überhaupt sinnvoll ist... :D :D
 
Die Antwort lautet im engeren Sinne lautet wie schon angedeutet und wie auch jemand im ersten Beitrag schon direkt geschrieben hatte: "geht nicht". Es ist aufgrund der hohen Entropie zu erkennen, dass da vermutlich verschlüsselte Daten liegen.
 
Entropien lassen sich immer problemlos schlüssig erklären

Dazu macht man sich einfach ein Script in einen Benchmarkordner mit vielen anderen solchem Kram das aus /dev/urandom in die Datei schreibt und die Zeit misst.

Was soll denn daran dann auffällig sein?
 
Ganz einfach: Jemand, der nicht nach versteckten Daten sucht, der wird erst gar nicht darüber stolpern. Aber wer danach sucht, der sucht nach Stellen mit hoher Entropie und der wird dir so eine Parallelkonstruktion nicht abkaufen, schließlich impliziert die Suche nach etwas immer einen gewissen Grad an Vermutung über die Existenz von etwas.
Wie hoch ist der Grad an Vermutung? Da sind wir jetzt schon wieder tief drin in dem, was ich zuvor angesprochen habe.
 
Ja und diese Person wird auch hinter jedem Bild und Soundfile und Video das irgendwo auf dem Rechner ist Steganographie vermuten?

Für die Person ist es genauso verdächtig dass man mehr als 1-2 Hintergrundbilder für den Desktop hat aber nur eines anzeigt.

Dann soll sie das halt vermuten - aber ohne weiteres Indiz wie einen Header und Co ist das halt eine extrem schwache Vermutung.
 
Zurück
Oben