Re: Verschlüsseltes tgz mit "garbage after EOF"

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Tue, 30 Jun 2009 13:07:44 +0200 (CEST)

Timm Wimmers wrote:
> Vielleicht sind mir noch einige Fragen gestattet, denn verschlüsselte
> (Offsite-) Backups sind genau mein Ziel. :)
>
> Wie gehst du vor? Also womit verschüsselst du und welcher "Cipher"
> genießt dein Vertrauen? Würdest du deine verschlüsselten Backups auch
> außerhalb ("untrusted network") ablegen, z.B. auf einem FTP-Server oder
> Amazon S3?

Im Prinzip genießt gar nichts mein Vertrauen. :-)

Ich verwende bf (BlowFish) in erster Linie aus Performance-
Gründen, da es ein recht schneller Algorithmus ist. Wenn
ein Rechner, dessen Prozessor nicht allzu schnell ist,
regelmäßig etliche GByte komprimieren, verschlüsseln und
durchs Netz schieben soll, dann ist der Performance-Aspekt
nicht zu vernachlässigen.

Davon abgesehen ist mir nicht bekannt, dass BlowFish schon
"gebrochen" worden wäre (sonst würde ich ihn nicht nehmen).

Wenn Du paranoid bist, kannst Du natürlich auch zweimal
verschlüsseln, z.B. einmal mit BF und einmal mit AES.
Dann müsste jemand schon zwei verschiedene Algorithmen
brechen, um an Deine Daten zu kommen, was auf absehbare
Zeit äußerst unwahrscheinlich sein dürfte. Wenn Du zwei
Cores und/oder Prozessoren hast (oder mehr), fällt der
Mehraufwand nicht so stark ins Gewicht.

Natürlich gilt hier auch die Regel, dass die Verschlüsselung
nur so stark sein kann wie Dein Passwort bzw. Passphrase.
Die Passwortsicherheit ist vermutlich entscheidender als
die Frage nach dem Verschlüsselungsalgorithmus.

An dieser Stelle sollte man erwähnen, dass ein Publiuc-key-
Verfahren (d.h. ein asymmetrescher Algorithmus) möglicher-
weise von Vorteil sein kann: Auf dem Rechner, der die
Backups verschlüsselt, muss nur der Public-key vorhanden
sein. Damit kann man die Backups aber _nicht_ wieder
entschlüsseln, d.h. selbst wenn jemand irgendwie an den
Key herankommt (z.B. durch Abfangen der EM-Abstrahlung von
Bildschirm und/oder Tastatur), nützt es ihm gar nichts.

Den Private-key könntest Du dann z.B. in einem Bankschließ-
fach deponieren (und _nur_ dort), z.B. auf Diskette, CD und
sicherheitshalber zusätzlich ausgedruckt -- im äußersten
Notfall muss man sich dann halt die Mühe machen, ein paar
Zeilen Hex-Codes einzutippen. Das ist allemal besser, als
alles zu verlieren.

Dafür ist z.B. GPG besser geeignet als das openssl-CLI.
(Aufpassen: gpg unterstützt ebenfalls Kompression mit gzip
und bzip2. Das sollte man ausschalten, damit die Daten
nicht zwemal "komprimiert" werden, was nicht besonders
viel bringt.)

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
With Perl you can manipulate text, interact with programs, talk over
networks, drive Web pages, perform arbitrary precision arithmetic,
and write programs that look like Snoopy swearing.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 30 Jun 2009 - 13:08:11 CEST

search this site