cryptsetup Fragen (ohne LUKS) [gelöst]

[DeletedUserReAsG]

Wenn du »if=/pfad/zum/file« weglässt, liest dd von stdin. Den Rest musst selbst schauen, mir wär’ das zu kompliziert: ich hätte den cryptsetup-Teil fertiggemacht und einfach da die Nullen reingeschrieben, bis es voll ist. Wäre dann »dd if=/dev/zero of=/dev/mapper/name« oder halt »pv /dev/zero > /dev/mapper/name«

[NAB]

Das dd ist dann eigentlich auch überflüssig. Das hier müsste funktionieren:

Code: Alles auswählen

openssl enc -aes-128-cbc -in /dev/zero -iv $(xxd -l 16 -p /dev/random) -K $(xxd -l 16 -p /dev/random) | pv -btr > /dev/sdc

wird aber vermutlich auch mit einer Fehlermeldung abbrechen - nur dass du dank pv jetzt die Anzahl der übertragenen Bytes sehen kannst.

Die Optionen "-btr" von pv hab ich mir gerade ungetestet aus der man-page rausgesucht ... probier das aus, und wenn du daraus nicht schlau wirst, dann brich es ab und schau, ob du selber bessere Optionen findest.

"pv" musste ich vorher installieren ... apt-get install pv

Edit: hab's grad ausprobiert, nach /dev/zero. Es tut sich anderthalb Minuten gar nichts, dann fängt er an, mit 600MB/s zu schreiben und zeigt dabei die Anzahl der übertragenen GB an.

[wanne]

Der befehl von NAB ist zwar deutlcih schöner, weil man Fortschritt sieht aber ich verstehe nicht wozu jetzt noch der Aufwand:
Wenn es mit no space left on device abgebrochen hat, ist ja offensichtlich alles überschrieben worden. In sofern ist ja jetzt alles gut.

[DeletedUserReAsG]

[…] ich verstehe nicht wozu jetzt noch der Aufwand: Wenn es mit no space left on device abgebrochen hat […]

Wenn du etwas hochscrollst, kannst du dort lesen, dass der ursprüngliche Ansatz mit „error writing output file“ endete, was nunmal auch was ganz anderes bedeuten kann – zumindest meine Vorschläge zielten darauf ab, genau das „no space left […]“ erst hervorzulocken. Gut, man hätte auch mit ’nem Hexeditor die letzten Blöcke des fraglichen Devices öffnen und nachschauen können, ob da pseudozufällige Bytefolgen oder nur Nullbytes zu finden sind – ist unterm Strich aber auch nicht weniger aufwändig.

[mclien]

Die Fortschrittanzeige ist recht nett, läuft aber nur während des Vorgangs.
Läßt man das ganze unbeobachtet, ist das ergebnis das erwähnte "no space left on device", was ja für diesen Vorgang voll aussreicht. Wahrscheinlich würde es mit dd dann noch die die records in und records out als Abschluss anzeigen, ist aber hierfür unnötig.
Danke euch.

[wanne]

Ob man cryptsetup so aufrufen kann, dass PBKDF2 genutzt wird entzieht sich meiner Kenntnis (trotz man page studierens).

PBKDF2 ist salted. Ohne Header kein platz zum speichern des Salt. => Es ist prinzipbedingt unmöglich, das in plain zu machen.

[wanne]

Auchso und zu pv: Das -r ist IMHO unnötig weil sowieso default.
Das -p bringt bei der Pipe erstmal nichts. Die ist ja unedlich. man müsste da mit -s 230G oder so angeben, wie groß die Platte ist.

[mclien]

So 20 Stunden später ist die Patte fertig. Leider habe ich das nächste Problem hierbai:

Code: Alles auswählen

$ cryptsetup --cipher aes-cbc-essiv:sha128 create backup /dev/sdxX
Enter passphrase: 
device-mapper: reload ioctl on  failed: No such file or directory
device-mapper: table ioctl on  failed: No such device or address

In dmesg findet sich:

Code: Alles auswählen

[ 2293.176973] device-mapper: table: 254:0: crypt: Error creating IV
[ 2293.177094] device-mapper: ioctl: error adding target to table

Woraufhin ich nach einigem suchen folgendes fand (gentoo forum):

"If you are using a plain device and you need a compatible mode, just specify cipher, key size and hash algorithm explicitly. For compatibility with cryptsetup 1.0.x defaults, simple use the following:
cryptsetup create -c aes-cbc-plain -s 256 -h ripemd160 <name> <dev>"

Ist mir auch soweit klar, alle Optionen einzeln angeben, allerdings it mir jetzt der Unterschied zwischen "essiv" und "plain" bei dem cipher nicht recht klar.

[NAB]

Code: Alles auswählen

$ cryptsetup --cipher aes-cbc-essiv:sha128 create backup /dev/sdxX

Was hältst du von der Idee, dass sdxX nicht existiert, da du die Partitionstabelle auf sdx mit Zufallszahlen überschrieben hast?

[mclien]

Oh, sorry, meine Fehler.
Die Part Tabelle habe ich vorher mit parted angelegt.

Code: Alles auswählen

Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End    Size   File system  Name     Flags
 1      1049kB  250GB  250GB               primary

Alte Platte als "Testgelände"

[NAB]

hmmm ... stimmt ... ich krieg da auch ne andere Fehlermeldung:

Code: Alles auswählen

# cryptsetup --cipher aes-cbc-essiv:sha128 create backup /dev/sdx
Device /dev/sdx doesn't exist or access denied.

Und

Code: Alles auswählen

# touch ./deleteme
# cryptsetup --cipher aes-cbc-essiv:sha128 create backup ./deleteme
Enter passphrase: 
Requested offset is beyond real size of device /dev/loop0.

erzeugt auch nicht deine Fehlermeldung. Am --cipher kann es also auch nicht liegen. Irgendein Gerät lässt sich bei dir aber nicht öffnen.

Existiert bei dir /dev/loop-control? Ist das loop-Modul bei dir geladen?

Code: Alles auswählen

# lsmod | grep loop
loop                   28672  0 

[mclien]

Code: Alles auswählen

~# lsmod | grep loop
loop                   22641  0

Sieht so aus. Aber ich denke ggf. ist es doch das was ich im gentoo forum fand ([s.o.):

If you are using a plain device and you need a compatible mode, just specify cipher, key size and hash algorithm explicitly. For compatibility with cryptsetup 1.0.x defaults, simple use the following:

Code: Alles auswählen

cryptsetup create -c aes-cbc-plain -s 256 -h ripemd160 <name> <dev>

Das würde ja "nur" bedeuten, dass meine Version von cryptsetup die Optionen nicht in der "kompakten Version" übernehmen kann.
Dabei leuchtet mir dann aber nicht ein warum ich "aes-cbc-essiv" durch "aes-cbc-plain" ersetzen soll..

[NAB]

Also mir leuchtet das auch nicht ein ...

Das dm_crypt-Modul ist auch geladen?

Code: Alles auswählen

# lsmod | grep dm
dm_crypt               24576  1 
dm_mod                106496  9 dm_crypt

Ist sonst irgendwas auffällig am System? Ungewöhnlicher Kernel oder andere Modifikationen?

Die Meldung aus dem Gentoo-Forum:
https://forums.gentoo.org/viewtopic-t-859682.html
ist erstens steinalt und bezieht sich zweitens darauf, dass er eine bereits erstellte Verschlüsselung nicht öffnen kann ("I can't access my encrypted partition"). Das klappt erst, nachdem er den alten, mittlerweile geänderten, Standard-Algorithmus angibt. Und der lautete bei der alten Version 1.0 wohl damals "aes-cbc-plain".

Und du willst doch einen neuen Container erstellen, oder?

Wobei mich das gerade wundert ... ich dachte, bei "plain" werden gar keine Informationen zum verwendeten Algorithmus in dem Container hinterlegt. Dann dürfte cryptsetup aber auch nicht wissen, dass der falsche Algorithmus angegeben worden ist *kopfkratz*

Kannst du mal versuchen, mit

Code: Alles auswählen

cryptsetup erase /dev/sdxX

eventuellen Datenmüll, den er für einen Header halten könnte, zu löschen? Das sollte eine Sekunde dauern ... wenn es länger dauert, brich es ab, dann macht er mehr als notwendig ist.

Und mir fällt gerade auf:

Code: Alles auswählen

cat /proc/crypto | grep 128

sha128 gibt es nicht ... da war meine Einschätzung, dass es nicht am Algorithmus liegen kann, wohl zu voreilig. Du solltest sha256 verwenden.

[mclien]

Code: Alles auswählen

~# lsmod | grep dm
dm_crypt               22586  0 
dm_mod                 63645  1 dm_crypt

Und sorry, dass ich den link zum Forum unterschlagen habe (habe auch gerade einen Schädel und Zahnschmerz).

Am System habe ich nix rumgeschraubt, alles wheezy aus den repros.
Kann aber sein, dass ich beim Platten rumgeschubse hier die Platte erwischt habe, die ich schonmal mit cryptsetup bearbeitet hatte.

Und mir fällt gerade auf:

Code: Alles auswählen

cat /proc/crypto | grep 128

sha128 gibt es nicht ... da war meine Einschätzung, dass es nicht am Algorithmus liegen kann, wohl zu voreilig. Du solltest sha256 verwenden.

Ah, jetzt:

Code: Alles auswählen

 cryptsetup --cipher aes-cbc-essiv:sha256 create ext /dev/sdc1
Enter passphrase: 

Blöd nur, dass ich das "mit Müll beschreiben" der grossen Platte jetzt mit 128bit gemacht habe... (nochmal mit 256 oder werde ich jetzt echt zu paranoid?
(zumal ich ja beim Backup dann gleich 1/3 bis 1/2 wieder beschreibe...

[NAB]

Also lag's jetzt wirklich am sha128? Man, diese dämliche Fehlermeldung hätten sie auch etwas aussagekräftiger gestalten können ...

Dass das noch Wheezy war, muss ich überlesen haben ... meine Beispiele stammen von Jessie.

Blöd nur, dass ich das "mit Müll beschreiben" der grossen Platte jetzt mit 128bit gemacht habe... (nochmal mit 256 oder werde ich jetzt echt zu paranoid?

Ach quatsch ... 128 Bit erzeugt genau so schöne Zufallszahlen wie 256 Bit. Es geht ja nicht darum, dass niemand deine Nullen entschlüsseln darf, sondern darum zu verschleiern, wo der freie Platz aufhört und die Nutzdaten anfangen. Unterschiedliche Hash-Größen könnten da sogar noch für Verwirrung sorgen ^^

[mclien]

Also lag's jetzt wirklich am sha128? Man, diese dämliche Fehlermeldung hätten sie auch etwas aussagekräftiger gestalten können ...
..
Dass das noch Wheezy war, muss ich überlesen haben ... meine Beispiele stammen von Jessie.

Oder ich habe es mal wieder bergessen zu erwähnen, sähe mir ähnlich...

Dann ists halt sha256, ich war halt zu dämlich die /proc/crypto zu interpretieren.

Danke jedenfalls. (Dann kannich ja im nächsten Thread gleich das "wie bekomme ich mein RAID -> LVM verschlüsset"- Faß aufmachen

[NAB]

Öhm ... so prinzipiell ... für Raid brauchst du ja mindestens zwei Platten ... und da macht es mehr Sinn, die erst zu einem Raid zusammenzuschalten, und dann darauf den verschlüsselten Container zu erstellen. Sonst muss er identische Daten mehrmals verschlüsseln, das nagt an der Performance.

Und eventuell willst du nach dem Vollschreiben dein 8TB-Monster noch mal mit "smartctl -a /dev/sdx" prüfen, ob es auch alles gut überstanden hat, ohne "reallocated sectors".

[wanne]

Öhm ... so prinzipiell ... für Raid brauchst du ja mindestens zwei Platten ... und da macht es mehr Sinn, die erst zu einem Raid zusammenzuschalten, und dann darauf den verschlüsselten Container zu erstellen. Sonst muss er identische Daten mehrmals verschlüsseln, das nagt an der Performance.

Nein. Umgekehrt ist (auf multicores) performanter. Steht auch ausdrücklich im Manual, dass man das so machen soll.
Du musst 2 mal die Hälfte verschlüsseln. Ist gleich groß, lässt sich aber besser parallelisieren.

Der Befehl müsste vermutlich so heißen:

Code: Alles auswählen

cryptsetup --cipher aes-cbc-essiv:sha128 create /dev/sdxX backup

[MSfree]

Du musst 2 mal die Hälfte verschlüsseln. Ist gleich groß, lässt sich aber besser parallelisieren

Es gibt schon noch ein paar RAID-Level mehr als Kamikaze-RAID, das zwar gerne als RAID-0 bezeichnet wird, mit RAID ansich aber nichts zu tun hat, weil eben nicht Redundant.

Bei einem Mirrorset, also RAID-1 muß 2 mal alles geschrieben werden, was durch Mehrfachverschlüsselung über mehrere Kerne zwar gut parallelisierbar ist, aber eben dann auch 2 Kerne auslastet.

[NAB]

Der Befehl müsste vermutlich so heißen:

Du solltest das Manual auch gelesen haben, bevor du dich darauf berufst.

[wanne]

Du solltest das Manual auch gelesen haben, bevor du dich darauf berufst.

Das manual schon. nur den Befehl nicht, den ich kopiert habe.
Habe da intuitiv ein open drin gelesen...
Soll eh kein create mehr verwenden..