staging.inyokaproject.org

Hallo zusammen,

woollte heute mal meine verschlüsselten LUKS1 volumes nach LUKS2 konvertieren und bin dabei auf das

Unable to move keyslot area. Not enough space.

Problem gestoßen. Da stellt sich mir nun die Frage, wie löse ich das 😀

Die Volumes sind so aufgebaut:

Vol1:
sda -> sda1 -> LUKS1 -> LVM PV -> LVM VG -> LVM LV -> ext4

Vol2:
sdb -> sdb1 -> LUKS1 -> LVM PV -> LVM VG -> LVM LV -> ext4

Vol3:
sdc -> sdc1 -> md raid1 --md0 -> LUKS1 -> ext4
sdd -> sdd1 -> md raid1 -|

Hat jemand eine Idee, wie ich den Keyslot space vergrößern kann? Resize der Partitions? Ich bin grade etwas planlos...

Danke!

Ist das noch ein sehr alter Header mit 2056 Sektoren oder sowas (luksDump, Payload offset)? Hast du sehr viele Keyslots in Gebrauch?

Du kannst cryptsetup mit --debug laufen lassen dann sollten die Größen angezeigt werden um die es hier geht.

Nein nur 1 Keyslot in gebraucht. --debug bei convert sagt:

# Converting LUKS device to type LUKS2
# Max size: 1052672, LUKS1 (full) header size 1052672 , required shift: 28672
Unable to move keyslot area. Not enough space.

Scheint als würde LUKS1 alles belegen.... ist die Frage wo der "space" liegt, in dem die Keyslot data liegt, das versuche ich gerade rauszufinden und damit, ob es sinnvoll sein könnte die ext4 partition im luks device zu verkleinern und damit ggf. platz zu befreien.....

PS: dump sagt übrigens 2056 Payload offset.

edit: OK, scheint hinter dem partition header und vor den verschlüsselten daten zu liegen.... Hat schon mal jemand probiert ext4 zu verkleinern, das crypto volume zu verkleinern und damit diesen header space zu vergrößern?

Der Header liegt vor den Daten, du müsstest ein Loch zwischen Header und Daten bekommen, was mit Sicherheit den Header nutzlos macht. Kurzfassung: Wird so nicht funktionieren.

Effektiv hilft nur Daten auf ein anderes Device kopieren, dann neu formatieren und zurück mit den Daten. Würde bei LVM ja alles im laufenden Betrieb gehen.

Alter LUKS 1 Header, und cryptsetup convert scheint das mit dem Offset einfach nicht zu unterstützen. Um das Offset zu ändern musst du alle Daten verschieben...

Du kannst mit luksDump --dump-master-key den Masterkey bekommen und mit diesem selber einen passenden LUKS 2 Header bauen. Das ist möglich denn generell erlaubt LUKS 2 auch kleinere Offsets. Nur stehen dir dann kaum Keyslots zur Verfügung.

Den Masterkey kannst du bei luksFormat mit --master-key-file übergeben und das 2056 Sektor Offset mit --offset 2056. Somit nutzt der neue LUKS 2 Header dann den gleichen Schlüssel wie der alte LUKS 1 Header und auch das gleiche Offset. Wenn alles andere auch stimmt (Sektorgröße, Cipher, ...) dann öffnen sich die gleichen Daten.

Da LUKS2 bei luksFormat gerne die ersten 16M überschreibt (neues Standardoffset) solltest du den neuen Header unbedingt als separate Datei anlegen (detached header) und erst wenn da alles stimmt und funktioniert, die 2056 Sektoren des alten Headers überschreiben.

Wenn du es falsch machst ist kompletter Datenverlust die Folge.

Im Zweifel lieber so lassen wie es ist. Wenn du meinst daß der LUKS 1 Keyslot zu unsicher ist, kannst du den auch einfach mit luksChangeKey neu setzen mit einem entsprechend höheren Itercount.

Beispiel für einen LUKS 2 Header mit Offset 2056 Sektoren:

# truncate -s 2M foobar.img
# cryptsetup luksFormat --offset=2056 --sector-size=512 foobar.img
WARNING: keyslots area (1019904 bytes) is very small, available LUKS2 keyslot count is very limited.
# cryptsetup luksDump foobar.img
LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	16384 [bytes]
Keyslots area: 	1019904 [bytes]
UUID:          	d29fa658-c491-4f81-9924-61b7e2311333
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 1052672 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 512 [bytes]

Also "zu Fuss" konvertieren wäre schon machbar aber... es muss wirklich alles stimmen sonst gibts nur Datensalat.

Das Vorgehen mit dem Header bauen mit Master Key hatte ich in einem anderen Zusammenhang mal hier: https://unix.stackexchange.com/a/178722/30851 (heute veraltet, da noch vor LUKS 2 geschrieben)

Naja, bei meinem Softraid1 könnte ich ja eine Platte rauswerfen und dort dann decrypted Data zwischenlagern. Das wäre wohl das Einfachste. Löst allerdings nicht mein Problem auf dem non-raid Volume. Hmmm. Hintergrund der Aktion war dieser Artikel: https://mjg59.dreamwidth.org/66429.html Man beachte den link zu dem Artikel auf indymedia. Wie "seriös" das wirklich ist, kann ich nicht beurteilen (indymedia....), aber wenn man das Prooblem vermeiden könnte, wieso nicht tun.

Kommentatoren verweisen auf ggf problematische OPSEC aber das kann ich nicht beurteilen. Mein Denkansatz war einfach, wenn das Problem vermeidbar ist, dann vermeide es.

Frage am Rande: Welche Iterations werden denn bei LUKS1 als sicher erachtet? Dump meint bei meinen Volumes wären überall >300k gesetzt....

LUKS setzt den Iteration Count dynamisch, hängt also von der Geschwindigkeit deines aktuellen PCs ab. Pi mal Daumen eine Sekunde Rechenzeit pro Keyslot. Du kannst die --iter-time beliebig hoch setzen, musst dann aber nach Passworteingabe auch entsprechend lange warten.

Du kannst eine leere Datei erstellen und diese mit luksFormat --type 1 zum LUKS Container machen und mit luksDump anschauen, dann kennst du deine aktuellen Standardwerte.

Wichtig sind die Iterations im Keyslot, und die ändern sich mit jedem luksChangeKey.

Noch wichtiger ist die Passphrase selbst. Eine gute Passphrase braucht im Prinzip gar keine Iterations. Aber 128 bit entropie eintippen (12 Zufallswörter frei nach XKCD) will halt auch nicht jeder.