Band/Tape verschlüsseln

Morfio

Well-Known Member
Hallo,

derzeit schreibe ich via "tar" nächtlich ein Backup auf Band (DLT). Jetzt steht die Anforderung an, das Backup zu verschlüsseln. Ich habe im Internet gesucht und nicht wirklich was gefunden (außer, dass LTO eine Hardwareverschlüsselung mit AES besitzen sollen, ich habe aber DLT).

Hat vielleicht jemand eine Idee, wie man das auf einfach Art machen könnte?

Viele Grüße, Morfio
 
Je nachdem, wie auf das Band geschrieben wird, ist evtl. auch die Verschlüsslung per geli direkt auf device-Ebene möglich (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html")

Ein Backup/Schreiben ginge dann per dlt0.eli (verschlüsselt) statt per dlt0 (direkt). Ein DAT-Laufwerk hier macht das zumindest mit, keine Ahnung wie es auf einem DLT-Laufwerk aussieht...
 
Mit geli scheint's nicht zu gehen:

[root@ernie /server]# geli init -s 4096 -K /root/sa0.key /dev/sa0
geli: Cannot get informations about /dev/sa0: Inappropriate ioctl for device.

Wie würde denn der Aufruf mit aespipe aussehen? Kann ich das einfach auf /dev/sa0 umleiten, also bsplw. so?:

tar -vch /server | aespipe -p3 -eAES256 -C128 3< passwdfile.pwd > /dev/sa0
 
Morfio: wie wäre es damit die Date durch durch tar, gzip und openssl zu pipen? OpenSSL bietet alles was du brauchst inkl. sauberer Betriebsmodi und du benutzt nur Inhalte des Basissystems.
 
Es funktioniert zwar, ist aber elend langsam. Ca. 800MB dauert mit des3 bzw. aes-128 und base64 ca. 4 Minuten. Ohne Verschlüsselung um die 50 Sekunden. Gibt es vielleicht eine Möglichkeit, das zu beschleunigen?
 
Zu Hardwareverschlüsselung kann ich nichts sagen. Ansonsten:

Wenn es nur darum geht, den eigentlichen Prozess der Bandaufzeichnung zu beschleunigen, könntest Du je nach Plattenplatz die Verschlüsselung zunächst temporär auf der Festplatte vornehmen und dann die verschlüsselten Dateien anschließend aufs Band sichern. Die Gesamtzeit des Backups wird dadurch aber natürlich noch erhöht, das ist klar.
 
Hoi,

die oifachste Lösung ist das vorher auf nem HW Raid z.B. mittels Openssl und Crypto Hardware Beschleuniger zu verschlüsseln und erst danach verschlüsselt die Daten ganz normal auf die Tape Library zu übertragen. Das geht um Welten schneller als das direkt zu pipen oder sonst irgendwelche Scherze dazwischen zu jagen. Den Datenspeicher nach erfolgreichem Verify sicher zu löschen stellt ja heut zu Tage dank secure wipe und sonstiger Techniken kein wirkliches Problem dar.

Beste Grüße,
Bummibär
 
Also ich würde erwarte, das Pipes kein Bottleneck sind. Ich pipe häufiger dd in gzip o.ä. da ist fast nie ein Prozess in pipe read blockiert. Pipes sollten doch auch nicht mehr 2 - 3 Kopien anfertigen wie früher. Damit dürfte ein Problem die unnötig kleine Größe der Buffer by read/write sein. Mal sehen ob ich zeit finde dem auf den Grund zu gehen.
 
Pipes sind ausreichend schnell. Sie sind unter FreeBSD (mal wieder eine meiner sinnlosen Zahlen) deutlich schneller als unter Linux [1] und mir wäre nicht bekannt, dass sich unter Linux jemals jemand drüber beschwert hätte. Um auf das Problem zurückzukommen, ich würde einmal misc/buffer [2]ausprobieren. Kann bei einigen Medientypen wie Tapes im Zusammenspiel mit eher langsamen Hauptprozessoren wahre Wunder wirken. :)

1: http://jeffr-tech.livejournal.com/19210.html
2: http://www.freshports.org/misc/buffer/
 
Mit misc/buffer ist es schon eine Nummer schneller. Via:

time tar -zcf - "${BACKUP_DIR}" | buffer | openssl des3 -salt -k "password" | buffer > /dev/sa0

dauert das statt 4 Minuten nur noch 1 Minute und 10 Sekunden. Allerdings um damit ein TB weg zu sichern dauert das schon recht lange alles.

Kann man noch was "pimpen"?
 
Mit misc/buffer ist es schon eine Nummer schneller. Via:

time tar -zcf - "${BACKUP_DIR}" | buffer | openssl des3 -salt -k "password" | buffer > /dev/sa0

dauert das statt 4 Minuten nur noch 1 Minute und 10 Sekunden. Allerdings um damit ein TB weg zu sichern dauert das schon recht lange alles.

Kann man noch was "pimpen"?

Hm, probier vielleicht mal blowfish, also "openssl bf". Interessiert mich, ob das schneller ist :)

Ach ja, und bei buffer mal den genutzten Speicher erhöhen mit "-m". Standard ist wohl "one megabyte".
 
Nimm besser für diese Datenmengen kein Cipher mit 64 Bit Blockgröße. Wenn OpenSSL daraus nur einen Strom macht wird sich bei 1TB der Angreifer freuen.
 
Wie Olodin sagt, mehr Buffer. RAM ist billig, niemand schlägt dich, wenn du da 256 Megabyte nimmst :)
 
@Olodin: mit bf dauert's 1 Minute 35 für die selben Daten.

Wenn ich -m 100 oder 256 oder 512 mache, kommt: max_shmem <zahl> too low.
 
Oh, da muss noch ein m an die Zahl.

[Edit] Nein, doch nicht: Cannot handle that many blocks, aborting!
 
Back
Top