[gelöst] Backup-Tar verschlüsseln

Probleme mit Samba, NFS, FTP und Co.
TomL

[gelöst] Backup-Tar verschlüsseln

Beitrag von TomL » 02.12.2017 10:45:32

Moin @ all

Ich möchte gerne einen Automatismus auf meinem Server einrichten, mit dem ich zyklisch ein verschlüsseltes Backup-Tar-Archiv in den Web-Space meiner Homepage hochlade. Jetzt überlege ich, welche Verschlüsselung ich hier anwende und ob es für einen solchen Zweck möglicherweise relevante Unterschiede in den 3 u.g. Alternativen gibt. Als Verschlüsselungstechnik-Nixwisser sind das für mich eigentlich schwer begreifbare Sachverhalte, die bei mir eher für Unsicherheit sorgen. Mit diesen 3 folgenden Verfahren habe ich bisher Erfahrungen sammeln können und könnte auch alle 3 technisch problemlos für diesen Zweck einrichten:

1. Luks-Container - was vermutlich hinsichtlich der Sicherheit keine Zweifel hinterläßt, aber die aufwendigste Methode darstellt.
2. Das Tar-Archiv mit CCrypt und AES256 verschlüsseln - was sich sehr einfach implementieren lässt
3. Das Tar-Archiv mit Openssl verschlüsseln - was ebenso einfach ist wie ccrypt und sogar ohne weitere Software immer mit Boardmitteln möglich ist

Bezogen auf die einfache Umsetzung in den Scripten gefällt mir OpenSSL am besten. Aber bevor ich anfange, würde ich gerne ein paar Meinungen dazu hören, wie Leute mit mehr Hintergrundwissen diese 3 Verfahren für solch einen Zweck einschätzen.... und ob es überhaupt hinsichtlich einer Anti-Schnüffel-Sicherheit bedeutsame Unterschiede gibt. Wenn alles gleichermaßen sicher ist, würde ich OpenSSL nehmen. Äh... ja, das ich ein sicheres Password verwende ist klar.... das kann ja hier auch wirklich nervend-kompliziert sein, weil dieses Archiv ja nur in einem Notfall geöffnet werden muss.
Zuletzt geändert von TomL am 07.12.2017 20:20:36, insgesamt 1-mal geändert.

DeletedUserReAsG

Re: Backup-Tar verschlüsseln

Beitrag von DeletedUserReAsG » 02.12.2017 12:00:44

Du könntest auch gpg in Erwägung ziehen. Damit kannst du mit einem Schlüsselpaar arbeiten und den öffentlichen Key zum Verschlüsseln nehmen, so dass der private Schlüssel zum Entschlüsseln nicht auf dem Server landet und folglich auch nicht dort von einem Angreifer abgegriffen werden kann.

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 02.12.2017 15:19:29

niemand hat geschrieben: ↑ zum Beitrag ↑
02.12.2017 12:00:44
Du könntest auch gpg in Erwägung ziehen. Damit kannst du mit einem Schlüsselpaar arbeiten und den öffentlichen Key zum Verschlüsseln nehmen, so dass der private Schlüssel zum Entschlüsseln nicht auf dem Server landet und folglich auch nicht dort von einem Angreifer abgegriffen werden kann.
Ja, das wäre sicher eine gute Alternative, auf die ich unbedingt zurückgreifen würde, wenn meine 3 o.g. Alternativen von irgendwelchen (ich sag mal) "unbefriedigenden" Faktoren begleitet würden. Meine Nix-Wisser-Verständnislos-Frage war ja "Gibts solche Faktoren oder sind die alle gleichermaßen sicher?" Ich tue mich im Moment mangels Verständnis auch so ein bisschen schwer mit "öffentlicher Schlüssel". Mein Gefühl sagt nämlich "Eigentlich willst du doch lieber nur einen geheimen Schlüssel."

Ich habe also jetzt so ein Problem, wo ich eine Wahl treffen soll, aber gleichzeitig die getroffene Wahl im Moment gar nicht vernünftig begründen kann, so das mir das auch ein passables Gefühl was sicheres getan zu haben verschafft.

Wenn ich an eine Openssl-verschlüsselte Datei denke, mit irgend einem kryptischen Password, ist das denn unsicher? Um zu sehen, warum mir diese Lösung so gut gefällt, hier mal ein wirklich leicht zu implementierendes Beispiel:

Code: Alles auswählen

openssl enc -e -aes-256-cbc -md md5 -in "$infile" -out "$infile.enc" -k "Ein heavy password"

DeletedUserReAsG

Re: Backup-Tar verschlüsseln

Beitrag von DeletedUserReAsG » 02.12.2017 15:37:32

Die Sache ist halt, dass, wenn du nur einen Schlüssel zum Ver- und Entschlüsseln gleichermaßen hast, dieser von einem Bösling abgegriffen werden könnte (in deinem Beispiel würde er etwa in der ~/.bash_history stehen, sofern da nix anderes konfiguriert wurde, und wenn du’s automatisieren willst, muss der Schlüssel sowieso irgendwo gespeichert werden) und dieser dann deine ganzen Backups damit entschlüsseln kann.

Arbeitest du mit asymmetrischer Verschlüsselung, könnte der Bösling den öffentlichen Schlüssel, mit dem du dort verschlüsselst, zwar auch klauen – aber er kann damit nichts entschlüsseln. Das ginge mit deinem privaten Schlüssel, der aber nicht auf dem Server ist (und idealerweise auch nie war). Heißt: du kannst bequem den öffentlichen Schlüssel auf der Kiste speichern und den z.B. in einem Cronjob zur Verschlüsselung des Backups hernehmen.

ccrypt kenne ich nicht, aber die Tatsache, dass es seit fünf Jahren tot zu sein scheint, würde mich abhalten, darauf zurückzugreifen. LUKS ist aus verschiedenen Überlegungen heraus nicht sinnvoll: feste Größe, recht hohe Komplexität, etc.. openssl ist recht etabliert, ich denke, das wäre meine Wahl, wenn ich zwischen den genannten dreien wählen sollte.

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Backup-Tar verschlüsseln

Beitrag von wanne » 02.12.2017 16:11:59

Ein dickes Puls für gpg. Das macht eine Menge zeug richtig worüber du erstmal nicht nachdenkst. (Bleibt meine Verschlüsselung auch sicher, wenn ich das gleich Passwort mehrfach verwende, wie sieht es mit langen entropiearmen aus Passwörtern aus, wie mit eher kurzen (chinesisch), können andere Nutzer auf einem Multiusersystem Passwörter mitlesen, leakt das durch die VM, darf ich es in einem Netzwerkprotokoll nutzen, darf ich nicht selbstgenerierte Daten mitverschlüsseln können die für Angriffe missbraucht werden…)
Das mag alles für dich nicht der Fall sein. Aber vielleicht mal irgend wann doch.
gpg ist schlicht gegen alle möglichen Arten von Angriffen ausgelegt ohne dass der Nutzer da weiter nachdenken muss. So rundumsorglospakete halte ich bei crypto für extrem wünschenswert und mit openssl ist das eher nicht gegeben.

Ich möchte hier auch nochmal darauf hinweisen, dass gpg mit der Option -c die Möglichkeit hat, schlicht mit einem Passwort zu verschlüsseln.

Daneben ist die Stabilität eine wichtige Sache.
openssl hat in der Vergangenheit mehrfach Algorithmen entfernt. So ist aes-256-gcm in aktuellen Implementierungen nicht mehr vorhanden. -md md5 war früher default. Will man heute Dateien entschlüsseln muss man es manuell angeben. Du musst also wissen, wann die Datei verschlüsselt wurde, um sie korrekt entschlüsseln zu können. Bei TLS Variante sind Kompression und die Anonymus-Cipher rausgeflogen. Es ist halt auf Netzwerk ausgelegt. Wenn du Daten auch in ein paar Jahren noch entschlüsseln können willst, musst du defakto eine heutige Version und den passenden Befehl dazupacken. (Du musst dich genau erinnern welchen Algorithmus du verwendet hast.)
Mit gpg kannst du auch Dateien von vor 20 Jahren entschlüsseln und wirst es vermutlich auch in 20 Jahren noch können.
Neuerungen haben immer nur das verschlüsseln betroffen. Entschlüsselt werden kann immer weiterhin.

Edit:
Kurz: Das ist einfach einfach und in jedem Fall sicher

Code: Alles auswählen

gpg -c
rot: Moderator wanne spricht, default: User wanne spricht.

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 02.12.2017 16:26:07

Ok, danke Euch beiden... das waren jetzt ein paar überzeugende Argumente. Dann werde ich mich mal mit GPG befassen und versuchen zu verstehen, wie man damit umgeht und ob/wie man das leicht handhaben kann. Ich kannte das bisher nur vom Namen, aber mit Manpage und ein paar Online-Beispielen krieg ich das hoffentlich wohl hin. Ich berichte später ....

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Backup-Tar verschlüsseln

Beitrag von wanne » 02.12.2017 16:45:14

Will nochmal auf meinen Edit hinweisen.
Das ist das was du verwenden willst:

Code: Alles auswählen

gpg -c
oder vielleicht auch

Code: Alles auswählen

gpg --cipher-algo AES256 -c
wenn du unbedingt aes-256 nutzen willst. MD5 kann gpg nicht nur RIPEMD160 und die SHA-Familie
Siehe auch:

Code: Alles auswählen

gpg --version
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
jph
Beiträge: 1049
Registriert: 06.12.2015 15:06:07
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Greven/Westf.

Re: Backup-Tar verschlüsseln

Beitrag von jph » 02.12.2017 16:54:45

Ich schlage Duplicity vor: „Duplicity backs directories by producing encrypted tar-format volumes and uploading them to a remote or local file server. Because duplicity uses librsync, the incremental archives are space efficient and only record the parts of files that have changed since the last backup. Because duplicity uses GnuPG to encrypt and/or sign these archives, they will be safe from spying and/or modification by the server.“

http://duplicity.nongnu.org/

Das unter GNOME nicht unbekannte Deja-Dup ist nichts anderes als ein grafisches Frontend für Duplicity. Beide sind in Main.

uname
Beiträge: 12043
Registriert: 03.06.2008 09:33:02

Re: Backup-Tar verschlüsseln

Beitrag von uname » 02.12.2017 22:30:33

Vielleicht Datei einmal durch Debianaespipe durchpipen.

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 03.12.2017 11:37:30

Moin @ all

Das war jetzt doch ein wenig kompliziert, aber ich glaube, es war erfolgreich. Mit den folgenden Schritten hat es jetzt anscheinend geklappt. Aber weil 'glauben' und 'anscheinend' ja gerade bei dem Hintergrund noch nicht der wahre Jakob sind, würde ich mich freuen, wenn vielleicht jemand noch Macken in meiner Vorgehensweise entdeckt und kurz drauf hinweist.

Code: Alles auswählen

PC 1
gpg --full-generate-key                                             # Key-Paar erzeugen
gpg -a --output testkey.pub --export testkeyid                      # Pub-Key exportieren

PC 2
gpg --import testkey.pub                                            # Auf zweiter Maschine importieren
gpg --edit-key testkeyid                                            # Trust-Level setzen
    gpg> trust
        5 = I trust ultimately
        
gpg --encrypt -a --recipient testkeyid --output test.enc test.txt   # verschlüsseln

gpg --decrypt --output ~/test.txt2 ~/test.enc                       # entschlüsseln mit planmäßigen Fehler
gpg: encrypted with 2048-bit RSA key, ID ABCDEF, created 2017-12-03
      "testkeyid (Testlauf) <toml@toml.de>"
gpg: decryption failed: Kein geheimer Schlüssel


PC 1
gpg --decrypt --output ~/test.txt2 ~/test.enc                       # entschlüsseln erfolgreich
gpg: encrypted with 2048-bit RSA key, ID ABCDEF, created 2017-12-03
      "testkeyid (Testlauf) <toml@toml.de>"
Aber ich habe noch 2 abschließende Fragen: Erstens, wozu ist das Password beim Erstellen des Private-Keys und dann wieder beim Entschlüsseln eigentlich notwendig? Ist denn nicht der Schlüssel (Privatekey) schon selber ausreichend sicher...?... den hat doch niemand außer mir? Und zweitens, Wanne hat in seinem Beispiel für symmetrische Verschlüsselung "gpg --cipher-algo AES256 -c" vorgegeben. Muss ich bei asymmetrischer Verschlüsselung mit Private und Pubkey auch eine Cipher vorgeben oder reicht da die Default-Einstellung? Was ist denn hierbei default?

PS
Vielen Dank für die anderen Vorschläge, aber ich versuche zuerst immer Lösungen mit Nutzung sowieso vorhandener Boardmittel zu finden, also ohne weitere Software installieren zu müssen. Deswegen war anfangs auch OpenSSL mein heimlicher Favorit. Aber die Argumente für GPG waren absolut überzeugend und GPG (ich hab nachgesehen) ist bereits auf allen meinen Maschinen installiert. Insofern ist klar, dass ich dabei bleibe.

Benutzeravatar
Meillo
Moderator
Beiträge: 8781
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Backup-Tar verschlüsseln

Beitrag von Meillo » 03.12.2017 17:00:30

Wenn du kein fertiges Backupsystem verwenden willst, sondern nur deine fertigen Backup-Tarballs verschluesseln willst, dann wuerde ich auch zu gpg tendieren.

TomL hat geschrieben: ↑ zum Beitrag ↑
03.12.2017 11:37:30
Aber ich habe noch 2 abschließende Fragen: Erstens, wozu ist das Password beim Erstellen des Private-Keys und dann wieder beim Entschlüsseln eigentlich notwendig? Ist denn nicht der Schlüssel (Privatekey) schon selber ausreichend sicher...?... den hat doch niemand außer mir?
Das ist ein zweiter Faktor, der die Sache sicherer macht:
1. Faktor: Haben: Du brauchst den Private Key
2. Faktor: Wissen: Du musst die Key-Passphrase kennen

Und zweitens, Wanne hat in seinem Beispiel für symmetrische Verschlüsselung "gpg --cipher-algo AES256 -c" vorgegeben. Muss ich bei asymmetrischer Verschlüsselung mit Private und Pubkey auch eine Cipher vorgeben oder reicht da die Default-Einstellung? Was ist denn hierbei default?
Ich kann nur soviel sagen, dass bei der asymmetrischen Verschluesselung die Daten intern auch symmetrisch verschluesselt werden (weil das viel schneller geht), und dann nur der generierte symmetrische Schluessel anschliessend asymmetrisch verschluesselt wird. Das passiert alles automatisch und du bekommst nichts davon mit.
Use ed once in a while!

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 03.12.2017 17:13:47

Danke, das habe ich soweit verstanden. Jetzt fehlt nur noch eins, was ich nicht auf die Reihe kriege... CCrypt macht (soweit ich mich erinnere) nur AES256. Wenn ich Openssl nutze, muss ich die Block-Cipher angeben, ich nehme auch hier AES256. Wenn ich einen Luks-Container oder eine Luks-Partition erstelle, muss ich wieder vorgeben, was verwendet wird... und wieder gebe ich AES vor. Wanne schreibt in seinem Beispiel ebenfalls AES256 zur Verwendung vor.

Was mich nun verunsichert, ist die Tatsache, dass in meinem obigen Beispiel das so nicht vorkommt, ich habe also nicht explizit einen Verschlüsselungs-Algorhythmus vorgegeben. Und da frage ich mich, ob das Resultat (i.ü.S.) jetzt nur die Qualität eines Zipfiles hat, was man einfach im Vorbeigehen hacken kann, weils eben gar nicht ordnungsgemäß verschlüsselt ist. Ich weiss nicht, ob bei Private/Pubkey auch ohne ausdrückliche Vorgabe von AES eine sichere Verschlüsselung besteht. Und weil ich auf etlichen Web-Seiten und selbst im gnupg-Handbuch nicht so recht eine Antwort finde und meinen eigenen Interpretationen total misstraue, frag ich lieber hier noch mal nach.

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Backup-Tar verschlüsseln

Beitrag von wanne » 04.12.2017 09:03:14

TomL hat geschrieben: ↑ zum Beitrag ↑
03.12.2017 17:13:47
CCrypt macht (soweit ich mich erinnere) nur AES256.
Nein. Rijndael veröffentlichte 15 oder waren es 25? Cipher. 3 der schnelleren wurden AES. ccrypt basiert auf einem der anderen. Wobei die da immer "based on" stehen haben. Nicht ganz eindeutig ob die wirklich exakt den nehmen.
Wanne schreibt in seinem Beispiel ebenfalls AES256 zur Verwendung vor.
Nur um den Befehl möglichst ähnlich zu dem openssl-Befehl zu machen. Ich würde immer eher empfehlen bei defaults zu bleiben. Auch ansonsten würde ich AES-256 nicht als dass non-plus-ultra verstehen. Die Welt hat sich in den letzten 20 Jahren weitergedreht und z.B. CAMELLIA Wurde ausdrücklich als bessere Alternative zu AES entwickelt. Trotzdem bleibt natürlich auch AES rock-solid. Alter ist ja eher ein Vorteil bei ungebrochenen Ciphers.
Was mich nun verunsichert, ist die Tatsache, dass in meinem obigen Beispiel das so nicht vorkommt, […] jetzt nur die Qualität eines Zipfiles hat,
Dass der eigentliche Blockcipher bei einer bekannteren Software erfolgreich angegriffen wurde, ist in dem Jahrhundert defakto nicht mehr vorgekommen (Ich will jetzt mal von irgend welchen obskuritäten alla Flugzeugen absehen, die noch Cipher nutzen, die seit über 1000 Jahren geknackt sind. (Nein. Da ist keine Null zu viel)).
Aber ein AES-128 verschlüsselt halt 128Bit mit weiteren 128Bit. Das alleine könnte man mit XOR auch bewiesenermaßen sicherer haben.
Viel interessantere Teil sind operation-modes, IVs (und wie zufällig die sind) Hashing-Algorithmen, key-strengthin, salting, Sidechannels...
Und das füllt eben eher ein Buch als einen Forenbeitrag. Deswegen will man da einen Werner Koch haben, der sich bekannter maßen wirklich damit auskennt.
Ich weiss nicht, ob bei Private/Pubkey
Die Möglichkeit für Private/Pubkey ist natürlich das Hauptfeature von gpg. Das was es besonders macht. Für deinen Zweck finde ich das aber gar nicht sinnvoll. Viel zu kompliziert. Wenn due einen extra keyfile haben will verschlüssel ein langes Passwort, mit dem du den eigentlichen File öffnest.
Bei -c hast du aber ganz normale symmetrische Verschlüsselung. Ohne öffentliche schlüssel.
rot: Moderator wanne spricht, default: User wanne spricht.

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 04.12.2017 12:29:52

wanne hat geschrieben: ↑ zum Beitrag ↑
04.12.2017 09:03:14
Ich würde immer eher empfehlen bei defaults zu bleiben.
Durch weiteres mühsamens Suchen und Lesen habe ich jetzt diese Defaults herausgefunden.... zumindest glaub ich, dass sie das sind. Wenn ich meinen Schlüssel öffne

Code: Alles auswählen

gpg --edit-key <keyid>
zeigt mir

Code: Alles auswählen

showpref
     [ultimate] (1). <keyid> (FTP-Backup) <tom@toml.de>
     Cipher: AES256, AES192, AES, 3DES
     Digest: SHA256, SHA384, SHA512, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
das eine Quelldatei anscheinend mit AES unter Verwendung meines Keyfiles verschlüsselt würde. Ist das so richtig festgestellt?
wanne hat geschrieben: ↑ zum Beitrag ↑
04.12.2017 09:03:14
Für deinen Zweck finde ich das aber gar nicht sinnvoll. Viel zu kompliziert.
Der Hintergrund für die Lösung ist, dass derzeit auf meinem Server völlig mannlos automatisch Teil-Backups erstellt werden. Das läuft quasi fast ohne Arbeit für mich ab. Mit dem verschlüsselten File will ich zusätzlich ein Blitzschlag- oder Hochwasser-Backup erzeugen, welches einfach auf meinen Webspace hochgeladen wird. Idealerweise und wenn ich Glück habe, werde ich ein solches Backup nie verwenden oder brauchen. Und natürlich finde ich das jetzt klasse, dass der Server, der diese Datei erzeugt, sie selber nicht entschlüsseln kann und das auch dort kein beidseitig nutzbarer Schlüssel (zum verschlüsseln notwendig) vorliegt. Ich habe einmal den Pubkey importiert und nun funktioniert das ganz einfach im Script... ich empfinde das als total easy.

Wanne, was Du manchmal in aller Kürze versuchst zu erklären, ist meist technisch so anspruchsvoll und wie jetzt hier so weit von meinen Fähigkeiten zu verstehen entfernt, dass ich dem kaum noch folgen kann. Gerade die Verschlüsselungstechniken sind m.M. nach ein Thema, was vermutlich nur noch Insider verstehen können. Mir helfen bei diesem Thema wirklich nur einfache Aussagen, die nicht auch noch ein tieferes Verstehen verlangen. Also als Beispiel: ein GPG-Key-Pair mit Defaults erzeugt und dann mit gpg --encrypt -a --recipient <keyfile> angewandt, erzeugt ein absolut sichere Datei. Das verstehe ich und kanns dann anwenden. Aber den Zusammenhang von AES256 und gleichzeitig RSA2048, von Block-Ciphern und irgendwelchen Algorhythmen und was da wirklich passiert, begreife ich nicht.... sorry.... aber ich denke, als eigentlich nur nomaler Anwender muss man das auch nicht verstehen.

Bitte aber jetzt nicht zu dem Schluss kommen "Für Dummköpfe ist mir die Zeit zu schade".... das wäre nämlich echt blöde .... :wink:

Benutzeravatar
Meillo
Moderator
Beiträge: 8781
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Backup-Tar verschlüsseln

Beitrag von Meillo » 04.12.2017 13:10:45

wanne hat geschrieben: ↑ zum Beitrag ↑
04.12.2017 09:03:14
Ich würde immer eher empfehlen bei defaults zu bleiben.
Ich meine mich zu erinnern, das es mal auf planet.debian.org, jemanden gab, der hin und wieder Vorschlaege fuer bessere Defaults fuer gpg gepostet hat ... ist alles schon eine Weile her. Auf die Schnelle finde ich die Posts nicht mehr.

Anonsten zu diesem Thema noch: https://www.gnupg.org/faq/gnupg-faq.htm ... r_gpg_conf

TomL hat geschrieben: ↑ zum Beitrag ↑
04.12.2017 12:29:52
Wanne, was Du manchmal in aller Kürze versuchst zu erklären, ist meist technisch so anspruchsvoll und wie jetzt hier so weit von meinen Fähigkeiten zu verstehen entfernt, dass ich dem kaum noch folgen kann. Gerade die Verschlüsselungstechniken sind m.M. nach ein Thema, was vermutlich nur noch Insider verstehen können. Mir helfen bei diesem Thema wirklich nur einfache Aussagen, die nicht auch noch ein tieferes Verstehen verlangen. Also als Beispiel: ein GPG-Key-Pair mit Defaults erzeugt und dann mit gpg --encrypt -a --recipient <keyfile> angewandt, erzeugt ein absolut sichere Datei. Das verstehe ich und kanns dann anwenden. Aber den Zusammenhang von AES256 und gleichzeitig RSA2048, von Block-Ciphern und irgendwelchen Algorhythmen und was da wirklich passiert, begreife ich nicht.... sorry.... aber ich denke, als eigentlich nur nomaler Anwender muss man das auch nicht verstehen.
Das Problem ist, dass genau das nicht moeglich ist: ``[dies und das] erzeugt eine absolut sichere Datei''. Es gibt keine absolute Sicherheit. Man kann stets nur ein gewisses Mass an Sicherheit erreichen, das von einer Menge an Faktoren abhaengig ist, u.a. auch von der Zeit in dem man sich befindet. Folglich kann dir niemand so einfache und klare Aussagen machen, die auch zutreffend und korrekt sind.

Was du erreichen kannst, ist, dass dir jemand, dessen Wissen du vertraust, dir empfiehlt, dass du es so und so machen sollst und du es dann genau so machst, ohne weiter darueber nachzudenken.
Use ed once in a while!

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 04.12.2017 14:09:50

Meillo hat geschrieben: ↑ zum Beitrag ↑
04.12.2017 13:10:45
Das Problem ist, dass genau das nicht moeglich ist: ``[dies und das] erzeugt eine absolut sichere Datei''. Es gibt keine absolute Sicherheit. Man kann stets nur ein gewisses Mass an Sicherheit erreichen, das von einer Menge an Faktoren abhaengig ist, u.a. auch von der Zeit in dem man sich befindet. Folglich kann dir niemand so einfache und klare Aussagen machen, die auch zutreffend und korrekt sind.
Nicht das jetzt hier ein Missverständnis vorliegt. Mir geht es bei meiner Frage nicht um alle Aspekte, die (auch) die Sicherheit einer Datei tangieren, wie z.B. mein Umgang mit den Schlüsseln, die Aufbewahrung der Schlüssel, kompromittierte Browser, offene Ports, unsichere Software-Konfigurationen (ssh, mailserver, ngingx), usw. Das interessiert mich alles nicht, damit kann ich umgehen.

Mein Frage zielt allein auf die Tatsache ab, dass ich eine Datei auf einer fremden Maschine speichern möchte und ob es mit einer solchen Verschlüsselung sicher verhindert ist, dass jemand diese Datei mit vertretbaren Aufwand öffnen kann, wenn dieser Schnüffler ausser dieser Datei sonst nichts anderes von mir hat. Und vielleicht noch darum, dass ich die Grundfunktionen des Programmes richtig bedient habe. Es wäre ja tragisch, wenn ich glaube, die Datei wäre verschlüsselt, aber weil ich Fehler gemacht habe, liegt (i.ü.S.)nur ein Zip-File vor.
Meillo hat geschrieben: ↑ zum Beitrag ↑
04.12.2017 13:10:45
Was du erreichen kannst, ist, dass dir jemand, dessen Wissen du vertraust, dir empfiehlt, dass du es so und so machen sollst und du es dann genau so machst, ohne weiter darueber nachzudenken.
Wenn mir das jemand in einer Kneipe oder auf dem Weihnachtsmarkt sagen würde, würde ich das nicht ungeprüft glauben.Wenn das allerdings hier gesagt wird, von bekannten Forumsmitgliedern, dann schon.... weil ich denke, dass jemand, der es noch besser weiss, sofort widersprechen würde, wenn da Unsinn erzählt wird. Wenn Wanne also sagen würde, mit einer auf diese Art verschlüsselten Datei kann keiner was anfangen, wenn er ausser dieser Datei nichts anderes hat, dann ist meine Frage für mich zufriedenstellend beantwortet und ich hätte für meine Lösung ein gutes Gefühl.

Benutzeravatar
Meillo
Moderator
Beiträge: 8781
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Backup-Tar verschlüsseln

Beitrag von Meillo » 04.12.2017 14:35:05

Du schreibst jetzt ja selber von ``vertretbarem Aufwand''. Im Rahmen solcher Weichmacher sind die von die gewuenschten Empfehlungen moeglich ... und in diesem Thread bekommst du ja auch genau diese ... bloss nicht immer ganz so schoen auf dem Silbertablett, wie du sie dir wuenschen wuerdest ... was auch daran liegt, dass kaum einer von uns so tief drin steckt, dein Szenario vollumfaenglich kennt und den Aufwand betreiben will alle Aspekte doppelt zu durchdenken, dass er sich mit seinen Empfehlungen aus dem Fenster lehnen will. Es wird also immer eine Unsicherheit bleiben, die du tragen musst.

An sich stimme ich dir aber zu: Hier gibt's einige User, die wissen wovon sie schreiben und die Community funktioniert so gut, dass Fehleinschaetzungen meist von anderen entdeckt werden. Und wenn man lieb fragt, dann bekommt man sogar oft auch noch speziell auf einen zugeschnittene Antworten. :THX:
Use ed once in a while!

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 04.12.2017 15:37:54

Meillo hat geschrieben: ↑ zum Beitrag ↑
04.12.2017 14:35:05
bloss nicht immer ganz so schoen auf dem Silbertablett, wie du sie dir wuenschen wuerdest ...
Das ist aber jetzt ein großes Missverständnis und ich verstehe auch gar nicht so recht, wie man das aus dem Verlauf des Threads ableiten kann. Es ist eher das Gegenteil der Fall, und zwar würde ich einer rund-um-sorglos-und-mach-glücklich-Lösung eher misstrauisch gegenüberstehen. Tatsächlich ist es so, dass ich mir meine Lösung gerne selber erarbeiten möchte, was ich ja auch mit stundenlangen Lesen von Howtos, gnupg-Handbuch und bereits gestern der FAQ und etlichen Experimenten versuche.

Das Dilemma ist, Du sagst es selber, dass gerade dieses Thema elendig kompliziert und einem Laien kaum verständlich ist. Aber was für mich noch wichtiger ist, ich misstraue meinen Englischkenntnissen zu einer korrekten Übersetzung und und darüber hinaus meinen Fähigkeiten, schlecht übersetztes auch noch richtig zu interpretieren. Deshalb beschreibe ich immer, was ich glaube herausgefunden zu haben und wie ich das imlementieren würde. Ich möchte nicht, dass mir jemand eine Lösung auf dem Silbertablett überreicht, sondern das mir vielleicht jemand bei meinem Geschreibsel sagt "Das ist so falsch, so funktioniert das nicht".... oder andersrum, im Idealfall "Wen man alle weiteren und relevanten Rahmenbedingungen ignoriert und jemanden -egal wem- eine solche Datei in die Hand gibt, kann er allein mit dieser Datei gar nix machen". Im ersten Fall suche ich weiter nach einer Lösung, im zweiten freu ich mich und bin zufrieden.

Benutzeravatar
Meillo
Moderator
Beiträge: 8781
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Backup-Tar verschlüsseln

Beitrag von Meillo » 04.12.2017 16:11:08

TomL hat geschrieben: ↑ zum Beitrag ↑
04.12.2017 15:37:54
Meillo hat geschrieben: ↑ zum Beitrag ↑
04.12.2017 14:35:05
bloss nicht immer ganz so schoen auf dem Silbertablett, wie du sie dir wuenschen wuerdest ...
Das ist aber jetzt ein großes Missverständnis [...]
Ja. Mein Kommentar sollte nicht negativ klingen. Ich denke, ich verstehe was du meinst, habe aber scheinbar nicht die passenden Worte dafuer gefunden. Vielleicht sollten wir die Meta-Diskussion beenden und zum Thema zurueckkehren. Du hattest noch eine offene Frage an wanne und andere Experten, glaube ich.
Use ed once in a while!

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Backup-Tar verschlüsseln

Beitrag von wanne » 05.12.2017 23:56:26

Wenn Wanne also sagen würde, mit einer auf diese Art verschlüsselten Datei kann keiner was anfangen, wenn er ausser dieser Datei nichts anderes hat, dann ist meine Frage für mich zufriedenstellend beantwortet und ich hätte für meine Lösung ein gutes Gefühl.
Zuerstmal sollte das auf alle 3 Varianten zutreffen.
Aber natürlich kommt das immer auf den Grad deiner Paranoidität an:
ccrypt ist zwar Open Source und es sind garantiert auch schon ein paar Augen drüber gegangen aber am Ende nicht so bekannt wie gpg. Wer weiß, was da noch gefunden werden könnte.
Qantencomputer sind mittlerweile real. (2001 konnte erstmals 15 in 3*5 auf einem QUatencomputer zerlegt werden. Heute können wir schon 143=11*13 rechnen) Sollten die irgend wann in den Größenordnungen wie echte Computer funktionieren ist jede der im Moment genutzten asymetrischen (public/private-key) Varianten kaputt.
Zumindest die NSA scheint da im Moment wirklich angst zu bekommen, dass das im nächsten Jahrzehnt der Fall sein könnte.
Seit man in den 80ern angefangen hat, wieder an Fermats Faktorisierungsmethode weiter zu optimieren kommen alle paar Jahre schnellerer Faktorisierungsmethoden raus. Im Moment führt das nur zu empfehlungen für immer noch längere RSA-Schlüsseln. (Wobei die alten zumindest für das nächste Jahrzhnt immer ausreichend waren.) Vielleicht kommt ja doch irgend wann der Durchbruch.
Das selbe gilt für die elliptischen asymmetrischen Verfahren. Wenn da mal ein zweiter Fermat kommt, und das auf RSA runter bricht haben die ein Problem.
Defakto sind das alle Sachen die die Zukunft betreffen und über die man nur spekulieren kann.
Die kleinste Wahrscheinlichkeit, dass dir ein Mathematiker einen Strich durch die Rechnung macht hast du IMHO vermutlich das gpg2 -c --cipher-algo CAMELLIA256 --s2k-digest-algo SHA512
Aber vorhersagen sind schwierig, vor allem, wenn sie die Zukunft betreffen. Und es ist garantiert um größenordnungen wahrscheinlicher, dass irgend jemand auf anderem Weg an die Klartextdaten kommt als, das einer der genutzten Ciphers kaputt ist.

Sei vorsichtig mit dem sonst nichts: Die volle Möglichkeit ohne irgend welche weiteren Informationen zu entschlüsseln, ist bei offenen Formaten eigentlich schon lange nicht mehr passiert
Sonst nichts ist aber eher selten. So Sachen wie "Passwort besteht nur aus ASCII-Zeichen"; "Im verschlüsselten befindet sich eine tar."; "Ich habe eine zweite Datei mit dem gleichen Passwort."; "Ich habe die gleiche Datei mit einem anderen Passwort."; "Ich kenne die Uhrzeit und/oder Rechner wo verschlüsselt wurde." oder "Ich habe da eine eigene Datei drin, die mitverschlüsselt wurde". Sind alles Sachen, die schon Verschlüsselungen zum Verhängnis geworden sind und die sich erstaunlich selten wirklich ausschließen lassen. Sowas, willst du halt nicht in deiner Crypto haben.

Btw. ist das ein grundsätzliches Problem bei komprimierten Inhalten. Wer eigene Daten unterschieben kann, kann anhand der komprimierten Größe erkennen, wie ähnlich die Inhalte sind. Das klingt absurd kompliziert, ist aber wohl einer der häufigst genutzten angriffe auf crypto in den letzten Jahren gewesen. Nach massiver Ausnutzung ist das deswegen z.B. auch aus TLS rausgeflogen.
Sollte man immer im Hinterkopf behalten.
rot: Moderator wanne spricht, default: User wanne spricht.

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 07.12.2017 19:50:58

So ganz langsam bekomme ich eine Ahnung, warum zu solchen Fragen eher allgemeine Zurückhaltung besteht.... was mir bei meinen Recherchen auch an anderen Orten aufgefallen ist. Es ist wohl tatsächlich so, dass man sich nur blamieren kann, wenn man nicht bis zum Hals im Crypto-Wissens-Sumpf steckt und trotzdem im Brustton der Überzeugung eine Meinung raushaut... das kann nur daneben gehen. :D Ich glaube, dieses Thema, welches mich jetzt schon einige Tage intensiv beschäftigt, toppt alle anderen bei mir gewesenen um Längen hinsichtlich seiner fachlichen Anforderungen. Es ist für den Laien schwer, wenn nicht gar unmöglich, hier eine Entscheidung zu treffen, die er auch wirklich sachlich begründen kann. Weil das so kompliziert ist, scheint es tatsächlich die einzige Lösung zu sein, einfach darauf zu vertrauen, dass die eigene Integrität (resp. die der eigenen Daten) gewahrt bleibt.

Was findet man im Web? So grob geschätzt und zusammengefasst sind wohl 95% der gefundenen Werke einfache Abschriften irgendeiner anderen Quelle, meistens mit Phrasen als Erklärungen versehen, die aber auch wieder nur Umformulierungen aus einer anderen Quelle sind oder häufig (i.ü.S.) nur beschreiben, das Regen nass macht. Teilweise sind Aussagen sogar überaltet. *hmmm*. Ein paar weitere Prozente im Fundus sind zwar die ultimative Wahrheit, aber die sind dann so dermaßen anspruchsvoll beschrieben, dass mans wieder nicht versteht. Und nur ein ziemlich kleines Häufchen an gefundenen Infos empfand ich dann für mich als wirklich hilfreich beim (ansatzweisen) Verstehen der Zusammenhänge - um überhaupt eine Begründung für die späteren eigenen Entscheidungen zu finden. Unter anderen (bzw. als erstes zu nennen) war es die Gnupg-Projektseite, die mir gut geholfen hat.

Primär muss man sich entscheiden, ob man symmetrische oder asymmetrische Entschlüsselung bevorzugt. Ein Vorteil der asymmetrischen Verschlüsselung mit RSA2048 ist, dass der Key zur Verschlüsselung nicht auch zur Entschlüsselung genutzt werden kann. Nun ja, Fakt ist, bei mir gibt es aber keine Kommunikationskanäle, über die ein Schlüsselaustausch stattfindet. Ich verschlüssel und entschlüssel allein für mich selber; lediglich das verschlüsselte Paket soll ohne die Möglichkeit einer Kontrolle (durch mich) auf Fremdzugriffe außerhalb meines Einflussbereiches gespeichert werden. Das heisst, sowohl Pubkey als auch Privatekey und Passphrase verlassen nie das Haus. Insofern ist hier der Pubkey-Verschlüsselung schon eine Grundlage entzogen. Darüber hinaus gibt es unterschiedliche Prognosen, wann RSA2048 gebrochen ist. Einige sagen, nicht vor 2030, die Franzosen sehen eine Sicherheits-Garantie nur bis 2020. Ich orientiere mich hier an der schlechtesten Prognose "minus 25%". Darüber hinaus wird nicht von allen eine Schlüsselvergrößerung auf 3072 oder 4096 Bit als tatsächliche Verbesserung der Sicherheit eingeschätzt. Alles zusammengenommen hat jetzt zu der Entscheidung geführt, RSA2048 nicht mehr für meine Zwecke zu nutzen und auf die Implementierung von ECC zu warten, welche dann RSA-16384 entspricht.

Damit bleibt dann bis auf weiteres anscheinend nur die symmetrische Verschlüsselung als Lösung übrig. Zu den Cipher'n AES256 und Camelia gibts derzeit nicht solche nahen Prognosen, wann die gebrochen sind - sofern man eine "harte" Passphrase wählt. Das klingt also erst mal ganz gut. Ein scheinbarer Nachteil ist, dass zur Verschlüsselung im Batchmode die Passphrase lesbar (zumindest für root) auf der Maschine hinterlegt sein muss - ein Nachteil deshalb, weil man damit auch entschlüsseln kann. Und wer sich dieses einen Schlüssels bemächtigt, hat eben vollen Zugang zu den verschlüsselten Daten-Paketen. Aber wie gesagt, es gibt ja hier keine Kommunikationskanäle, keinen Schlüsseltransport. Also, das ganze Thema, ob sich jemand meines Schlüssels bemächtigt oder über meinen kompromittierten Rechner in den Prozess der Verschlüsselung oder Entschlüsselung einschalten kann, ignoriere ich ... weil ich unterstelle, dass mein System nicht kompromittiert ist. Punkt! Tatsache ist, wenn der Rechner tatsächlich gekapert ist, mache ich mir doch über den Zugriff auf verschlüsselte Daten überhaupt keinen Kopp mehr, weil der virtuelle Einbrecher ja einfach auf die unverschlüsselten Originaldaten zugreifen kann.

Eine weitere Tatsache ist, wenn sich echt mal die NSA (oder ein anderer Verein) für mich interessiert, weil ich z.B. behaupte (wie jetzt hier) Donald Trump ist ein Alien, für den wir Menschen Grundnahrungsmittel seiner Art sind, dann kümmern die sich wohl eher nicht um die Verschlüsselung, sondern gehen einfach direkt an meinen Rechner, wenn ich gerade nicht im Hause bin.... das werde ich wohl am allerwenigsten verhindern können. Also, was solls....? Momentan denke ich also, dass eine symmetrische Verschlüsselung mit AES256 oder Camelia die bessere Wahl ist... eine, die meine Pakete vor schnüffelnden ISP-RZ-Admins ausreichend gut schützt.
wanne hat geschrieben: ↑ zum Beitrag ↑
05.12.2017 23:56:26
Sonst nichts ist aber eher selten. So Sachen wie "Passwort besteht nur aus ASCII-Zeichen"; "Im verschlüsselten befindet sich eine tar."; "Ich habe eine zweite Datei mit dem gleichen Passwort."; "Ich habe die gleiche Datei mit einem anderen Passwort."; "Ich kenne die Uhrzeit und/oder Rechner wo verschlüsselt wurde." oder "Ich habe da eine eigene Datei drin, die mitverschlüsselt wurde". Sind alles Sachen, die schon Verschlüsselungen zum Verhängnis geworden sind und die sich erstaunlich selten wirklich ausschließen lassen. Sowas, willst du halt nicht in deiner Crypto haben.

Btw. ist das ein grundsätzliches Problem bei komprimierten Inhalten. Wer eigene Daten unterschieben kann, kann anhand der komprimierten Größe erkennen, wie ähnlich die Inhalte sind. Das klingt absurd kompliziert, ist aber wohl einer der häufigst genutzten angriffe auf crypto in den letzten Jahren gewesen.
Das setzt aber immer voraus, dass entwender der Rechner oder die Kommunikationskanäle kompromittiert sind, um sich erfolgreich in diesen Prozess einzuschalten. Aber, isser einmal drin (der Böse, im Rechner), isses eh Zeitverschwendung sich mit dem Crypto-Prozess zu befassen.

Abschließend noch mal mein Dank an wanne und niemand, gpg war ein guter Rat.... das scheint eine wirklich gute Lösung zu sein...

Benutzeravatar
jph
Beiträge: 1049
Registriert: 06.12.2015 15:06:07
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Greven/Westf.

Re: Backup-Tar verschlüsseln

Beitrag von jph » 30.12.2017 15:34:56

TomL hat geschrieben: ↑ zum Beitrag ↑
03.12.2017 11:37:30
Vielen Dank für die anderen Vorschläge, aber ich versuche zuerst immer Lösungen mit Nutzung sowieso vorhandener Boardmittel zu finden, also ohne weitere Software installieren zu müssen. Deswegen war anfangs auch OpenSSL mein heimlicher Favorit. Aber die Argumente für GPG waren absolut überzeugend und GPG (ich hab nachgesehen) ist bereits auf allen meinen Maschinen installiert. Insofern ist klar, dass ich dabei bleibe.
Ich hole diesen alten Thread noch mal raus, weil ich noch meinen Senf dazugeben möchte…

Dein Basteltrieb in allen Ehren, aber ich würde den nicht unbedingt beim Backup ausleben. Wenn deine selbstgebaute Backuplösung deine Backups frisst, bist du relativ allein auf weiter Flur, was Unterstützung angeht. Und wenn die Urlaubsfotos weg sind, wird dir deine Frau zeigen, was die Abkürzung „WAF“ bei einem Backupwerkzeug bedeutet. :P

Eine Lösung aus dem Debian-Repository ist zumeist entsprechend verbreitet und hat eine Entwicklungsgeschichte hinter sich. Und zwar nicht nur bei dir, sondern bei vielen Anwendern in unterschiedlichen Einsatzszenarien. Das bedeutet, dass du eher Hilfe finden wirst und dass viele Fehler (die du bei einer Eigenentwicklung möglicherweise selbst begehen musst, um sie zu erkennen) bereits behoben wurden.

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 30.12.2017 19:14:44

jph hat geschrieben: ↑ zum Beitrag ↑
30.12.2017 15:34:56
Dein Basteltrieb in allen Ehren, aber ich würde den nicht unbedingt beim Backup ausleben.
:::
Eine Lösung aus dem Debian-Repository ist zumeist entsprechend verbreitet und hat eine Entwicklungsgeschichte hinter sich.
Sorry... aber ich verstehe Dich nicht. Ich hatte geschrieben:
TomL hat geschrieben: ↑ zum Beitrag ↑
03.12.2017 11:37:30
...aber ich versuche zuerst immer Lösungen mit Nutzung sowieso vorhandener Boardmittel zu finden, also ohne weitere Software installieren zu müssen.
Wenn also tar und gpg nicht aus dem Debian-Repo kommen... wo kommt das dann her? Ich habe das nämlich nicht installiert... meiner Meinung waren die Pakete bereits im Grundsystem durch den Installer enthalten. Und wieso ist die Nutzung von tar und gpg überhaupt eine Bastellösung? Ist die Verwendung von Containern mit Cryptsetup und LUKS auch eine Bastellösung, von der ebenso wie von tar und gpg abzuraten ist?

Bin nun ein wenig irritiert.... :roll:

Benutzeravatar
jph
Beiträge: 1049
Registriert: 06.12.2015 15:06:07
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Greven/Westf.

Re: Backup-Tar verschlüsseln

Beitrag von jph » 31.12.2017 13:51:10

TomL hat geschrieben: ↑ zum Beitrag ↑
30.12.2017 19:14:44
Wenn also tar und gpg nicht aus dem Debian-Repo kommen... wo kommt das dann her? Ich habe das nämlich nicht installiert... meiner Meinung waren die Pakete bereits im Grundsystem durch den Installer enthalten. Und wieso ist die Nutzung von tar und gpg überhaupt eine Bastellösung? Ist die Verwendung von Containern mit Cryptsetup und LUKS auch eine Bastellösung, von der ebenso wie von tar und gpg abzuraten ist?

Bin nun ein wenig irritiert.... :roll:
Ich habe mit „Bastellösung“ den falschen Begriff gewählt, weil man den als herabwertend interpretieren kann, was von mir nicht beabsichtigt war.

Lass ihn uns positiv verstehen: viele gute Tools sind Bastellösungen, weil diese wiederum aus anderen, bereits vorhandenen Tools zusammengebaut werden. Aber auch beim Zusammenbau vorhandener Tools kann man entscheidende Fehler machen. Gegen tar und gpg an sich spricht nichts, aber wenn du diese beiden Werkzeuge falsch miteinander kombinierst, können die Daten weg sein. Oder unvollständig. Oder ungewollt so verschlüsselt, dass du sie nicht wieder entschlüsseln kannst. Für mich das Backup eine Sache, die keine Experimente verzeiht. Daher wollte ich dir die Risiken noch einmal vor Augen führen und im gleichen Atemzug davon abraten, das Rad ausgerechnet an dieser Stelle neu erfinden zu wollen. Falls du es doch tust: testen, testen, testen!

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 31.12.2017 14:12:22

jph hat geschrieben: ↑ zum Beitrag ↑
31.12.2017 13:51:10
...davon abraten, das Rad ausgerechnet an dieser Stelle neu erfinden zu wollen.
Ich bin nicht sicher, was Du mit "das Rad neu erfinden" meinst. Ich bin nämlich der Meinung, dass ich das überhaupt nicht tue. Ganz im Gegenteil, ich lege ungemein Wert darauf, auf erprobte Verfahren von Debian zu setzen. Und dazu zähle ich eben tar und gpg.

Ganz nebenbei bemerkt denke ich, Deine Kritik passt nicht im geringsten zu meinem Backupkonzept.... was ich Dir natürlich nicht vorwerfe, weil Du das nicht kennst. Du kannst sicher sein, dass es keine derartigen von Dir genannten Risiken gibt. Bei mir liegen permanent auf 2 Speichermedien automatisch erstellte unverschlüsselte Backups vor, eins wird täglich erstellt, für das zweite Medium vierfach rollierend im 7-Tage-Zyklus... und bis hierhin wie gesagt "unverschlüsselt". Von diesen 7-Tage-Backups wird jeweils eine verschlüsselte Kopie angelegt, die jedoch das Original nicht verändert, und zwar um die Crypt-Kopie anschließend auf meinen Web-Space zu übertragen. Und genau wegen dieser Fremdspeicherung ist die Verschlüsselung alternativlos und obligatorisch. Und das ich diese Backups wiederherstellen kann.... nun ja, das ist definitiv ausreichend abgesichert.

Antworten