cryptsetup Fragen (ohne LUKS) [gelöst]

[mclien]

Ich muss gerade meine Backupplatte neu machen. Nun will ich das gerne mit cryptsetup machen und zwar ohne LUKS.
Gefunden habe ich das hier:

Code: Alles auswählen

$ sudo cryptsetup create backup /dev/sdc2
$ sudo mkfs.ext4 /dev/mapper/backup  #nur beim ersten mal, danach gibts das Dateisystem ja schon
$ sudo mount /dev/mapper/backup /mnt

# Dinge mit der Platte tun wie backup drauf oder runter

$ sudo umount /mnt
$ sudo cryptsetup remove backup

Also habe ich das mal vorsorglich mit einer (kleinen) überzähligen Platte getestet. Funktioniert soweit auch wunderbar, allerdings gibt es noch ein paar Unklarheiten für mich:
- Beim Anlegen des verschlüsselten Volumens, geht das alles recht schnell. create, passwort, fertig. Mounten und los gehts. das kommt mir jetzt irgendwie etwas zu schnell vor. Wollte die Verschlüsselung nicht etwas dauern?
- Oder habe ich Optionen vergessen (VerschlüsselungAlgorithmus und so)?
- Oder geschieht die Verschlüsselung dann "on the fly" beim kopieren der Daten?

EDIT: (Kurzversion Zusammenfassung)( je nach bedarf anpassen: ext4, sha256, backup)
-neue Platte zum Verschleiern mit Zufallsdaten beschreiben:

Code: Alles auswählen

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

(kann laaaange dauern, pv gibt dann nach einer Weile Laufzeit Anhaltspunkt, wie lange es noch dauert)
-Platte nutzen:
(-vorher Partitionstabelle anlegen)

Code: Alles auswählen

$ cat /proc/crypto | grep 128 #prüfen, ob es den beabsichtigen sha Wert gibt
$ cryptsetup --cipher aes-cbc-essiv:sha256 create backup /dev/sdxX # verschlüsseln der Partition
$ mkfs.ext4 /dev/mapper/backup  # nur beim ersten mal, danach gibts das Dateisystem ja schon
$ mount /dev/mapper/backup /mnt

# Dinge mit der Platte tun wie backup drauf oder runter

$ umount /mnt
$ scryptsetup remove backup

[NAB]

open <device> <name> --type <device_type>

Opens (creates a mapping with) <name> backed by device <device>.

Device type can be plain, luks (default), loopaes or tcrypt.

For backward compatibility there are open command aliases:

create (argument-order <name> <device>): open --type plain
plainOpen: open --type plain
luksOpen: open --type luks
loopaesOpen: open --type loopaes
tcryptOpen: open --type tcrypt

<options> are type specific and are described below for individual device types. For cre‐
ate, the order of the <name> and <device> options is inverted for historical reasons, all
other aliases use the standard <device> <name> order.

--cipher, -c <cipher-spec>
Set the cipher specification string.

cryptsetup --help shows the compiled-in defaults. The current default in the distributed
sources is "aes-cbc-essiv:sha256" for plain dm-crypt and "aes-xts-plain64" for LUKS.

Du erzeugst also einen "plain"-Container (ohne LUKS-Header) mit aes-cbc-essiv:sha256.

Dabei wird eigentlich gar nichts gemacht, außer den Container mit einer verschlüsselnden Ebene dazwischen zu öffnen. Das geht sehr schnell.

Alles, was du nun in den Container schreibst, wird "on the fly" verschlüsselt, angefangen beim Dateisystem, das du angelegt hast. Und beim Lesen wieder "on the fly" entschlüsselt. Wenn deine CPU Hardware-Verschlüsselung kann, geht das auch sehr schnell. Sonst treibt es deine Prozessorlast nach oben.

Wenn du die Platte vorher noch sicherheitshalber mit Zufallszahlen füllen willst, musst du das selber machen. Das dauert sehr lange.

[mclien]

open <device> <name> --type <device_type>

Danke fürs man-page filtern, war ich irgendwie zu doof zu..

--cipher, -c <cipher-spec>
Set the cipher specification string.

cryptsetup --help shows the compiled-in defaults. The current default in the distributed
sources is "aes-cbc-essiv:sha256" for plain dm-crypt and "aes-xts-plain64" for LUKS.

Du erzeugst also einen "plain"-Container (ohne LUKS-Header) mit aes-cbc-essiv:sha256.[/quote]
Da muss ich mir jetzt also nur überlegen, ob mir das reicht. Keine Ahnung wie ich das entscheiden soll. Es gibt doch noch irgendeine "eliptic curve" Verschlüsselung, die sehr viel besser ist? Leider kenne ich da nicht mehr als das Wort..

Wenn du die Platte vorher noch sicherheitshalber mit Zufallszahlen füllen willst, musst du das selber machen. Das dauert sehr lange.

Bei einer neuen Platte dann eher unnötig, denke ich.
Vielen Dank in jedem Fall

[DeletedUserReAsG]

Bei einer neuen Platte dann eher unnötig, denke ich.

Gerade da wär’s sinnvoll. Cryptsetup ohne Luks hat den Vorteil, keine Header zu haben – theoretisch sind die Daten von außen nicht von Zufall zu unterscheiden. Ist die Platte weitgehend leer, ist’s entsprechend einfach, die verschlüsselten Daten aufzufinden → erster Punkt zum Knacken abgehakt.

256 Bit hört sich vielleicht nicht besonders viel an, benutzt man doch heutzutage 4096Bit RSA und so, aber so recht vergleichbar ist’s nicht: 256 Bit Schlüssellänge bei einem symmetrischen Verfahren entsprechen laut Doku von openssl einer Schlüssellänge von 15360 Bit eines asymmetrischen Verfahrens, und 512 Bit bei EC-Verfahren.

[mclien]

Bei einer neuen Platte dann eher unnötig, denke ich.

Gerade da wär’s sinnvoll. Cryptsetup ohne Luks hat den Vorteil, keine Header zu haben – theoretisch sind die Daten von außen nicht von Zufall zu unterscheiden. Ist die Platte weitgehend leer, ist’s entsprechend einfach, die verschlüsselten Daten aufzufinden → erster Punkt zum Knacken abgehakt.

Ah, das hatte ich natürlich übersehen... Das wird ein Spass 6TB...

256 Bit hört sich vielleicht nicht besonders viel an, benutzt man doch heutzutage 4096Bit RSA und so, aber so recht vergleichbar ist’s nicht: 256 Bit Schlüssellänge bei einem symmetrischen Verfahren entsprechen laut Doku von openssl einer Schlüssellänge von 15360 Bit eines asymmetrischen Verfahrens, und 512 Bit bei EC-Verfahren.

Ah, ok. Wenn ich das für eine backup Platte nutze, kann ich mir aber überlegen trotzdem 512bit zu nehmen. Performance ist da ja nicht Prio 1.

[DeletedUserReAsG]

Mit ’ner CPU, die AES unterstützt, ist’s vielleicht schneller, erst den Container zu erstellen und und einzuhängen, und den dann einmal mit Nullen aus /dev/zero zu befüllen → verschlüsselte Nullen sehen theoretisch auch wie Zufall aus.

[mclien]

Ansonsten so:

Code: Alles auswählen

dd if=/dev/random of=/dev/sd

richtig? Oder muss man noch "zufälligere" Daten nehmen?

[DeletedUserReAsG]

Du sprachst von 6TB? random liefert selbst mit haveged nicht mehr als ‘n MB/s, ohne ist‘s typischerweise ein zweistelliger kB/s-Wert. Wenn du also ein paar Wochen Zeit hast, warum nicht?

[mclien]

ups. Was ist/gibts eine alternative?

[DeletedUserReAsG]

viewtopic.php?p=1074563#p1074563

Alternativ urandom – ist schneller, aber so richtig glücklich wird’s dich wohl auch nicht machen.

[mclien]

Hier http://serverfault.com/questions/86914/ ... hard-drive
gibts noch ein paar diskussionsbeiträge zu Thema.
Wobei mir:

Code: Alles auswählen

dd if=/dev/zero | openssl des > /dev/sdXy

einigermassen sinnvoll vorkommt und in etwa dem Vorschlag von niemand entspricht erst den Container zu erstellen und dann nullen zu schreiben.

Das i.o. link erwähnte c-programm kann ich persönlich mangels c-Kenntnissen nicht beurteilen. Der Vorschlag nur zufällig gewählte Teile der Platte mit zufälligen Daten zu beschreiben, scheint mir aber auch irgendwie sinnig.

EDIT:
Wenn ich es richtig verstehe, ist das Problem die nötige "Menge Zufall" (Entrophie?) zu erzeugen, richtig? Soviel ich weiß idt Rauschen im Radio recht zufällig. Kann man nicht das Rauschen aus dem Radio an line-in Anschliessen und das als Quelle für den Zufall nutzen? Dann wäre man doch bei viel Zufall und schneller Schreibgeschwindigkeit.

[wanne]

AES gibt's nur in 128 192 und 256 Bit. Und die 128Bit Variante ist tatsächlich die, die nach derzeitigem Kenntnisstand am meisten Rechenzeit zum brechen bräuchte.
Prinzipiell weisen lange Schlüssellängen eher auf schlechte Algorithmen hin. 128Bit ist eigentlich ausreichend. RSA würde auch keiner mehr verwenden, wenn es was wirklich robuste alternativen gäbe. (Da kommt gerade einiges an ECC aber das zeug ist neu wenige verstehen wirklich was da passiert und eben allessamt eben noch anfälliger für Shor-Algorithmus (Quantencomputer)) Deswegen werden wird da mit jedem neuen angriff die Schlüssellänge noch mehr vergrößert. (Die frage ist halt, wann man an der Grenze ist dass das verschlüsseln zwar unerträglich lange dauert aber das brechen trotzdem noch locker geht. Schon heute kann RSA nciht mehr alleine eingesetzt werde. Verschlüsselt werden immer nur die paar Byte für den Schlüssel eines anderen Algorithmuses. Und schon das dauert mitunter ganzschön lange. – Zumindest auf meinem WLAN-Router warte ich da schon ganzschön lange.)

Und wo wir gerade bei Quantencomputern sind: Der Grover-Algorithmus würde die für AES die Komplexität Wurzeln (Die bitlänge halbieren.) Damit wäre es Möglicherweise wieder sinnvoll AES 256 zu nutzen.

Das ganze zeug hinter dem ersten Strich halte ich für weniger relevant. Solange da nicht ecb steht funktioniert das alles mehr oder weniger gut. Lediglich vor manipulationen kann das nicht schützen.
Vor sowas kann dich unter Debian aber eh keine Verschlüsslung schützen, da der Kernel immer unverschlüsselt vorliegt. (Und der dann nach dem entschlüsseln munter manipulieren kann.) Lediglich für externe Medien, die häufig den Rechner verlassen, könnte das relevant sein.

[wanne]

EDIT:
Wenn ich es richtig verstehe, ist das Problem die nötige "Menge Zufall" (Entrophie?) zu erzeugen, richtig? Soviel ich weiß idt Rauschen im Radio recht zufällig. Kann man nicht das Rauschen aus dem Radio an line-in Anschliessen und das als Quelle für den Zufall nutzen? Dann wäre man doch bei viel Zufall und schneller Schreibgeschwindigkeit.

Sicherheitstechnisch eine gaanz dumme Idee:
Das ist alles andere als Gelichverteilt. Du kannst da garantiert irgend welche Reste von benachbarten Radiosendern und schöne Eigenheiten der Hardware raushören: Da wird es garantiert schöne Schwingkreise geben, die schön regelmäßig schwingen wo das aufhört, hört offensichtlich der verschlüsselte Teil an.
Außerdem ist das Ding eh etwa 100 mal langsamer als /dev/urandom.
Wie man das richtig macht, sieht man hier:
viewtopic.php?f=15&p=977483
Kurz:

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) > /dev/sdxX

Das schöne: Wenn du eh AES-128 nutzt ist das genau gleich schwer zu knacken, wie deine Crypto.

[wanne]

Warum ich eigentlich geantwortet habe: Meines Wissens benutzt kein PBKDF2. Das führt auf der einen Seite dazu, dass das so viel schneller öffnet. Für gleiche Sicherheit brauchst du etwa 2-4Zeichen längere Passwörter. Nicht die Welt. Sollte man aber vielleicht wissen.

[mclien]

Also zusammen gefasst wäre dann so vorzugehen bei einer neuen Platte:
- partitionatabelle anlegen (parted)
- Platte "zufallisieren":

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) > /dev/sdxX

- Platte nutzen:

Code: Alles auswählen

$ cryptsetup --cypher aes-cbc-essiv:sha128 create backup /dev/sdxX
$ mkfs.ext4 /dev/mapper/backup  #nur beim ersten mal, danach gibts das Dateisystem ja schon
$mount /dev/mapper/backup /mnt

# Dinge mit der Platte tun wie backup drauf oder runter

$ umount /mnt
$ cryptsetup remove backup

Oder habe ich bei den cryptsetup optionen was vergessen/falsch verstanden?
Wenn beide keys die gleiche Länge haben sind die Daten von den leeren Stellen schwerer zu unterscheiden.
Nachteil ist, dass man sich alle Optionen für das nächste Mal richtig merken muss. Soweit korrekt?

[mclien]

.... Meines Wissens benutzt kein PBKDF2.

Ich gestehe volles nicht-Verständnis dieses Satzes...

[mclien]

Warum ich eigentlich geantwortet habe: Meines Wissens benutzt kein PBKDF2. Das führt auf der einen Seite dazu, dass das so viel schneller öffnet. Für gleiche Sicherheit brauchst du etwa 2-4Zeichen längere Passwörter. Nicht die Welt. Sollte man aber vielleicht wissen.

Nachdem ich PBKDF2 wikipediert habe verstehe ich noch weniger. Ist mein ganzer Aufwand fürs verschlüsseln jetzt so gut wie 2-4 Zeichen lange Passwörter? (also quasi nutzlos?).

[mclien]

test mit einer alten 250GB PLatte:

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) > /dev/sdc
error writing output file

nach ca.1:30 h . Somit konnte opensl dann wohl die Daten nicht (vollständig) auf die Platte schreiben. Oder taugt das ganze nur beim Schreiben auf Prtitionen und nicht auf die ganze Platte?

[DeletedUserReAsG]

Da wird schlicht die Platte voll gewesen sein. Also alles, wie’s sein sollte – du hast ja keine Größe mitgegeben und daher schreibt’s, bis nix mehr geht. Bei dd hätte es eine hübschere Meldung und eine Zusammenfassung über die Menge der geschriebenen Daten gegeben, das wäre weniger rätzelhaft gewesen. Möglicherweise hätte man pv noch so dazwischenhängen können, dass man einen gescheiten Fortschrittsbalken bekommt.

[wanne]

Ist mein ganzer Aufwand fürs verschlüsseln jetzt so gut wie 2-4 Zeichen lange Passwörter? (also quasi nutzlos?).

PBKDF2 macht das offenen des devices absichtlich Rechenaufwändig. (Bei luks genau so, dass es auf dem aktuellen Rechner eine Sekunde braucht.)
Die Hoffnung ist, dass das den Nutzer kaum stört, dass das öffnen eine Sekunde statt mehrer µs braucht. Auf der anderen Seite ist das für bruteforce Attacken relativ schmerzhaft, weil die die ganze Zeit nur öffnen. Außerdem verhindert es Vorberechnungen. (Bei plain ist es nicht Rechenaufwändiger Tausend Rechner zu Brutforcen wie einen. Das ist halt angenehem für Angreifer die sich zusammenschließen oder viele Rechner angreifen. Insbesondere kann man den Angriff auch im vorraus berechnen.)
Alles kein Problem, wenn man ausreichend sichere Passwörter hat. Aber das sollte man halt haben.

[mclien]

Eine der Ideen ist, dass im Falle eines Diebstahls die Partition bei "plain" aussieht wie eine leere Partition, im Falle von Luks allerdings sofort als verschlüsselte Partition erkennbar ist. Ob man cryptsetup so aufrufen kann, dass PBKDF2 genutzt wird entzieht sich meiner Kenntnis (trotz man page studierens).
Bei der Plattenverschlüsselung neige ich allerdings zu passwortlängen jenseits von 30 Zeichen, womit das passen sollte.

@niemand: Leider ist mir momentan auch nicht klar wie ic die "Zielgrösse" mitgeben kann.

[DeletedUserReAsG]

@niemand: Leider ist mir momentan auch nicht klar wie ic die "Zielgrösse" mitgeben kann.

Ist auch nicht erforderlich. Wenn’s abbricht weil Platte voll ist, ist’s fertig. Du wolltest sie schließlich ja einmal mit verschlüsselten Nullen (von außen gesehen also mit Zufall) füllen.

[mclien]

Ja schon, allerdings ist das doch eine etwas "unscharfe" Diagnose von

Code: Alles auswählen

error writing output file

als erfolgreichen Anschluss der Aktion auszugehen. Könnte ja auch ein anderer Grund sein.
Aber ich werde dann mal loslegen, denn:
250GB -> 8000Gb Faktor 32, macht bei 1,5h für 250GB für die "8TB" Platte
"Nur 48 Stunden"
Ich nenne die Platte dann mal Eddy...

[DeletedUserReAsG]

… deswegen hätte ich das, wie geschrieben, über z.B. ›dd‹ oder auch ›pv‹ laufen lassen. dd gibt am Ende ’ne Zusammenfassung samt aussagekräftiger Fehlermeldung aus, mit pv kann man gar ’nen hübschen Fortschrittsbalken mit aktuellem Durchsatz und so zaubern.

[mclien]

ok, dann hilf einem alten Pfuscher nochmal auf die Sprünge, so?:

Code: Alles auswählen

dd if="openssl enc -aes-128-cbc -in /dev/zero -iv $(xxd -l 16 -p /dev/random) -K $(xxd -l 16 -p /dev/random)" | pv |  dd of=/dev/sdx

Ich habe allerdings noch kein Beispiel gefunden, dass man einen Befehl als inputfile für dd nutzen kann und blamier mich gerade...