[gelöst] Backup-Tar verschlüsseln

Probleme mit Samba, NFS, FTP und Co.
breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: Backup-Tar verschlüsseln

Beitrag von breakthewall » 02.01.2018 08:50:43

wanne hat geschrieben: ↑ zum Beitrag ↑
05.12.2017 23:56:26
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.
Ich glaube ja persönlich, dass Quantencomputer eine Sackgasse sind. Zumindest können sie symmetrischen Verschlüsselungsverfahren nicht gefährlich werden, und selbst wenn ein Verschlüsselungsalgorithmus um eine Quadratwurzel gekürzt werden kann, dann ist das bei 256 Bit Schlüssellänge dennoch zu vernachlässigen. Seit vielen Jahren werden auch vielversprechende asymmetrische Verschlüsselungsverfahren evaluiert, die effektiv gegen Quantencomputer resistent sind. Lange wird es nicht mehr dauern bis zur Standardisierung. Ich denke nicht das es den einen Durchbruch geben, und plötzlich Panik ausbrechen wird.
wanne hat geschrieben: ↑ zum Beitrag ↑
05.12.2017 23:56:26
gpg2 -c --cipher-algo CAMELLIA256 --s2k-digest-algo SHA512
Hier hast schon zum zweiten Mal denselben Fehler drin. Die --cipher-algo bzw. --digest-algo Parameter, sind unwirksam bei symmetrischer Verschlüsselung. Es müssen immer die --s2k--cipher-algo bzw. --s2k-digest-algo Parameter genutzt werden, ansonsten nutzt gpg weiterhin die Standard-Parameter. Und das wären dann aes256 und sha256.

breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: Backup-Tar verschlüsseln

Beitrag von breakthewall » 02.01.2018 09:57:03

TomL hat geschrieben: ↑ zum Beitrag ↑
07.12.2017 19:50:58
Primär muss man sich entscheiden, ob man symmetrische oder asymmetrische Entschlüsselung bevorzugt.
Es gibt hier keine Entscheidung. Zumal symmetrische Verschlüsselungsverfahren für die Verschlüsselung von vielen Daten geeignet sind, asymmetrische Verschlüsselungsverfahren dagegen überhaupt nicht. Nicht umsonst werden asymmetrische Verschlüsselungsverfahren meist nur zum Schlüsselaustausch genutzt. Nimmt man nun einmal RSA als Beispiel, dann nutzt dieses Verschlüsselungsverfahren lediglich 8 byte Blöcke mit begrenzter Nachrichtenlänge. Wird diese Grenze nun überschritten anhand der Datenmenge, dann hat das kritische Folgen hinsichtlich der Sicherheit der Daten. Und je mehr dieser Daten erzeugt werden, desto mehr Teile des ursprünglichen Schlüssels werden sozusagen unfreiwillig veröffentlicht. Daher sollte das zwingend vermieden werden, auch wenn es auf den ersten Blick wirkt, als würde das problemlos funktionieren.
TomL hat geschrieben: ↑ zum Beitrag ↑
07.12.2017 19:50:58
Ein Vorteil der asymmetrischen Verschlüsselung mit RSA2048 ist, dass der Key zur Verschlüsselung nicht auch zur Entschlüsselung genutzt werden kann.
Sicher ist das praktisch, aber dennoch ungeeignet um große Datenmengen zu verschlüsseln. Wenn dann nimmt man eine Hybridverschlüsselung, indem die Daten stets symmetrisch verschlüsselt werden, und dann verschlüsselt man den symmetrischen Schlüssel mit einem asymmetrischen Verschlüsselungsverfahren. Das wäre dann eine saubere Sache.
TomL hat geschrieben: ↑ zum Beitrag ↑
07.12.2017 19:50:58
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.
Genau genommen ist RSA-2048 ohnehin die letzte logische Option, bevor es schmerzhaft wird in Sachen Leistung mit größeren Schlüssellängen. Hier ist ECC eben deutlich schneller und effektiver, und heute schon experimentell in gpg nutzbar, mit dem --expert Parameter.
TomL hat geschrieben: ↑ zum Beitrag ↑
07.12.2017 19:50:58
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.
Wie gesagt man kann auch eine Hybridverschlüsselung umsetzen. Dann liesst man den symmetrischen Schlüssel eben mit dem Private-Key aus, und entschlüsselt dann die symmetrisch verschlüsselten Daten. Eine weitere Option wäre auch noch Twofish, zu dem es seit 1998, keine vollständige Kryptoanalyse gibt, um den Verschlüsselungsalgorithmus überhaupt brechen zu können. Und nimmt man nun die Verschlüsselungsalgorithmen mit 256 Bit Schlüssellänge, dann hat man es mit einem 32 stelligen Schlüssel zutun, den man berechnen muss, oder man ermittelt das Nutzerpasswort was diesen Schlüssel frei gibt. Zumindest ist das selbst für Supercomputer eine Mammutaufgabe, und technisch noch nicht möglich.

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 02.01.2018 10:56:20

Moin breakthewall & ein frohes neues Jahr

Du hattest auf Wannes Post geantwortet...
breakthewall hat geschrieben: ↑ zum Beitrag ↑
02.01.2018 08:50:43
Die --cipher-algo bzw. --digest-algo Parameter, sind unwirksam bei symmetrischer Verschlüsselung. Es müssen immer die --s2k--cipher-algo bzw. --s2k-digest-algo Parameter genutzt werden, ansonsten nutzt gpg weiterhin die Standard-Parameter. Und das wären dann aes256 und sha256.
... und jetzt hoffe ich, Du hilfst mir kurz bei der Interpretation der Man-Page und meines Versuchsergebnisses. Ich bring das alles nicht übereinander mit Deiner Aussage... und weil ich das ja tatsächlich "produktiv" nutze, liegt mir natürlich an Eindeutigkeit.

Ich kann daraus jetzt gar nicht entnehmen, dass für meine Anwendung nur das eine funktioniert und das andere nicht:

Code: Alles auswählen

--s2k-cipher-algo name
      Use name as the cipher algorithm for symmetric encryption with a
      passphrase if  --personal-cipher-preferences  and  --cipher-algo
      are not given.  The default is AES-128.

--cipher-algo name
      Use name as cipher algorithm. Running the program with the  com‐
      mand --version yields a list of supported algorithms. If this is
      not used the cipher algorithm is selected from  the  preferences
      stored  with  the  key.  In general, you do not want to use this
      option as it allows you to violate the OpenPGP standard.  --per‐
      sonal-cipher-preferences  is the safe way to accomplish the same
      thing.
Wenn ich diese Jobs nacheinander laufen lasse...

Code: Alles auswählen

gpg --verbose --symmetric --cipher-algo AES256 --yes --output "$SourceFile".1enc "$SourceFile"
gpg --verbose --symmetric --cipher-algo TWOFISH --yes --output "$SourceFile".2enc "$SourceFile"
gpg --verbose --symmetric --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --yes --output "$SourceFile".3enc "$SourceFile"
gpg --verbose --symmetric --s2k-cipher-algo TWOFISH --s2k-digest-algo SHA512 --yes --output "$SourceFile".4enc "$SourceFile"
...kommt das dabei raus... und es wird gemäß meiner Anweisung jeweils die gewählt Cipher verwendet :

Code: Alles auswählen

gpg: pinentry launched (2200 gnome3:curses 1.0.0 ? ? ?)
gpg: pinentry launched (2202 gnome3:curses 1.0.0 ? ? ?)
gpg: using cipher AES256
gpg: writing to 'selnic.1enc'

gpg: pinentry launched (2206 gnome3:curses 1.0.0 ? ? ?)
gpg: pinentry launched (208 gnome3:curses 1.0.0 ? ? ?)
gpg: using cipher TWOFISH
gpg: writing to 'selnic.2enc'

gpg: pinentry launched (2212 gnome3:curses 1.0.0 ? ? ?)
gpg: pinentry launched (2214 gnome3:curses 1.0.0 ? ? ?)
gpg: using cipher AES256
gpg: writing to 'selnic.3enc'

gpg: pinentry launched (2218 gnome3:curses 1.0.0 ? ? ?)
gpg: pinentry launched (2220 gnome3:curses 1.0.0 ? ? ?)
gpg: using cipher TWOFISH
gpg: writing to 'selnic.4enc'
Ich sehe hier also keinen Unterschied, ob mit oder ohne --s2k. Wo liegt hier mein Verständnisproblem oder was mache ich falsch?

breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: Backup-Tar verschlüsseln

Beitrag von breakthewall » 02.01.2018 11:32:11

TomL hat geschrieben: ↑ zum Beitrag ↑
02.01.2018 10:56:20
Moi... und jetzt hoffe ich, Du hilfst mir kurz bei der Interpretation der Man-Page und meines Versuchsergebnisses. Ich bring das alles nicht übereinander mit Deiner Aussage... und weil ich das ja tatsächlich "produktiv" nutze, liegt mir natürlich an Eindeutigkeit.

...kommt das dabei raus... und es wird gemäß meiner Anweisung jeweils die gewählt Cipher verwendet :

Code: Alles auswählen

gpg: pinentry launched (2200 gnome3:curses 1.0.0 ? ? ?)
gpg: pinentry launched (2202 gnome3:curses 1.0.0 ? ? ?)
gpg: using cipher AES256
gpg: writing to 'selnic.1enc'
Frohes Neues.

Also wie die Manpage ja schon aussagt, manipulieren die --s2k-* Parameter, die rein symmetrische Verschlüsselung über den -c bzw. --symmetric Parameter. Dagegen sorgen die Parameter darunter dafür, dass der OpenPGP-Standard manipuliert werden kann, wenn man bspw. mit asymmetrischen Verschlüsselungsverfahren arbeitet, wahlweise bezüglich der Signierung oder Verschlüsselung von Nachrichten. Auch im realen Einsatz verhielt sich das so.

Dein Output ist recht seltsam.

Was sagt denn jene Kommandozeile?

Code: Alles auswählen

file selnic.*
Normalerweise sollte hier die Differenz zu sehen sein.
Zuletzt geändert von breakthewall am 02.01.2018 11:35:43, insgesamt 1-mal geändert.

TomL

Re: [gelöst] Backup-Tar verschlüsseln

Beitrag von TomL » 02.01.2018 11:35:39

Ha ..... klasse ... :THX: ... wieder was dazugelernt :D

Code: Alles auswählen

file selnic*
selnic:      Bourne-Again shell script, UTF-8 Unicode text executable
selnic.1enc: GPG symmetrically encrypted data (AES256 cipher)
selnic.2enc: GPG symmetrically encrypted data (TWOFISH cipher)
selnic.3enc: PGP symmetric key encrypted data - AES with 256-bit key salted & iterated - SHA512 .
selnic.4enc: PGP symmetric key encrypted data - Twofish with 256-bit key salted & iterated - SHA512 .
Wobei mir der Unterschied auf die Sicherheit des verschlüsselten Files jetzt nicht so recht klar ist.... also zwischen den beiden AES256-Versionen und zwischen den beiden TWOFISH-Varianten.

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

Re: Backup-Tar verschlüsseln

Beitrag von wanne » 03.01.2018 15:52:59

breakthewall hat geschrieben: ↑ zum Beitrag ↑
02.01.2018 08:50:43
Ich denke nicht das es den einen Durchbruch geben, und plötzlich Panik ausbrechen wird.
Sehe ich auch nicht so. Plötzlich kommt das auf keinen Fall. Aber wenn man seine Daten asymmetrisch verschlüsselt kann es halt sein, dass die in 50 Jahren vergleichsweise einfach entschlüsselt werden können. Das ist halt ein Grund für symmetrische Verfahren.
breakthewall hat geschrieben: ↑ zum Beitrag ↑
02.01.2018 08:50:43
wanne hat geschrieben: ↑ zum Beitrag ↑
05.12.2017 23:56:26
gpg2 -c --cipher-algo CAMELLIA256 --s2k-digest-algo SHA512
Hier hast schon zum zweiten Mal denselben Fehler drin. Die --cipher-algo bzw. --digest-algo Parameter, sind unwirksam bei symmetrischer Verschlüsselung. Es müssen immer die --s2k--cipher-algo bzw. --s2k-digest-algo Parameter genutzt werden, ansonsten nutzt gpg weiterhin die Standard-Parameter. Und das wären dann aes256 und sha256.
Nein.
Das ist der relevante Teil im Sourcecode:

Code: Alles auswählen

              algo = opt.def_cipher_algo;
              if (!algo)
                algo = opt.s2k_cipher_algo;
Kurz wenn du keinen cipher-algo angibst, wird s2k-cipher-algo verwendet. Du kannst das auch ausprobieren. Da ist dann wirklich Camellia drin. s2k-cipher-algo wird lediglich verwendet wenn kein cipher-algo angegeben wurde. cipher-algo ist das Totschalgargument und überschreibt alles. Das gilt sowohl für die PGP-Standards wie auch für die s2k-cipher-algo Option.
rot: Moderator wanne spricht, default: User wanne spricht.

breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: Backup-Tar verschlüsseln

Beitrag von breakthewall » 03.01.2018 16:32:49

wanne hat geschrieben: ↑ zum Beitrag ↑
03.01.2018 15:52:59
Nein.
Das ist der relevante Teil im Sourcecode:

Code: Alles auswählen

              algo = opt.def_cipher_algo;
              if (!algo)
                algo = opt.s2k_cipher_algo;
Kurz wenn du keinen cipher-algo angibst, wird s2k-cipher-algo verwendet. Du kannst das auch ausprobieren. Da ist dann wirklich Camellia drin. s2k-cipher-algo wird lediglich verwendet wenn kein cipher-algo angegeben wurde. cipher-algo ist das Totschalgargument und überschreibt alles. Das gilt sowohl für die PGP-Standards wie auch für die s2k-cipher-algo Option.
Also meinen Erfahrungen nach war das nicht so. Hatte das vor gut zwei bis drei Jahren exzessiv getestet, wo die standardmäßigen Verschlüsselungsverfahren nur mit den --s2k-* Optionen überschrieben werden konnten. Sprich mit den anderen Parametern, wurde immer mit AES und damals noch SHA1 verschlüsselt, egal ob man Twofish oder sonstiges gewählt hat. Hatte diesbezüglich den Werner Koch in der Mailingliste angeschrieben, und da kam der Rat die --s2k-* Optionen zu nutzen.

Sieht ganz danach aus als hätte sich das geändert, gemäß dem Quellcode. Gibts dazu irgendwelche zeitlichen Daten?

Ansonsten müsste ich das nochmals austesten.
Zuletzt geändert von breakthewall am 03.01.2018 16:34:43, insgesamt 1-mal geändert.

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 03.01.2018 16:34:07

wanne hat geschrieben: ↑ zum Beitrag ↑
03.01.2018 15:52:59
Kurz wenn du keinen cipher-algo angibst, wird s2k-cipher-algo verwendet. Du kannst das auch ausprobieren. Da ist dann wirklich Camellia drin. s2k-cipher-algo wird lediglich verwendet wenn kein cipher-algo angegeben wurde. cipher-algo ist das Totschalgargument und überschreibt alles. Das gilt sowohl für die PGP-Standards wie auch für die s2k-cipher-algo Option.
Was bedeutet dieser Unterschied, wo ich bei den ersten beiden "cipher-algo" angegeben habe und bei letzten zwei "s2k-cipher-algo"? Hat dieser Unterschied überhaupt eine Bedeutung?

Code: Alles auswählen

file selnic*
selnic:      Bourne-Again shell script, UTF-8 Unicode text executable
selnic.1enc: GPG symmetrically encrypted data (AES256 cipher)
selnic.2enc: GPG symmetrically encrypted data (TWOFISH cipher)
selnic.3enc: PGP symmetric key encrypted data - AES with 256-bit key salted & iterated - SHA512 .
selnic.4enc: PGP symmetric key encrypted data - Twofish with 256-bit key salted & iterated - SHA512 .

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

Re: [gelöst] Backup-Tar verschlüsseln

Beitrag von wanne » 04.01.2018 10:57:31

Wobei mir der Unterschied auf die Sicherheit des verschlüsselten Files jetzt nicht so recht klar ist.... also zwischen den beiden AES256-Versionen und zwischen den beiden TWOFISH-Varianten.
Für AES-128 vs. AES-256 hat man sich vor allem gedacht mehr hilft mehr. Mehr Runden längere Schlüssel... Ob sich das dann wirklich hilfreich oder gar kontraproduktiv herausstellt wird man sehen. (Oder hoffentlich nicht sehen.)

AES vs. Twofish: Wer eher Bruce Schneier vertraut nimmt Twofish wer eher dem NIST vertraut nimmt eher AES. Beides anerkannte Methoden. Daneben ist Twofish ein sehr konservativer Ansatz. Funktioniert als Feistelchiffre wie die meisten besseren Verschlüsslungen der zweiten Hälfte des letzten Jahrhunderts. AES ist dagegen sehr elegant. Unterscheidet sich auch nicht stark von einem Feistelchiffre kann aber Mathematisch elegant dargestellt und damit leicht analysiert werden. Die Hoffnung: Etwaige Schwachstellen oder Backdoors wären längst erkannt.
rot: Moderator wanne spricht, default: User wanne spricht.

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

Re: Backup-Tar verschlüsseln

Beitrag von wanne » 04.01.2018 11:57:58

TomL hat geschrieben: ↑ zum Beitrag ↑
03.01.2018 16:34:07
Das gilt sowohl für die PGP-Standards wie auch für die s2k-cipher-algo Option.
Das ist vor allem für Skript bzw. konfigurationsdateien interessant:
Du kannst einen alias definieren der s2k-cipher-algo für Symmetrische Verschlüsselung personal-cipher-preferences für OpenPGP Verschlüsslung verwendet.
Da kannst du dann für beide Varianten unterschiedliche defaults setzen.
Z.B. ist es wohl weitestgehend Sinnlos die 256Bit Varianten für die Kombination mit asymmetrischen Verfahren (OpenPGP) zu verwenden. Während man für Symmetrisch auch ungewöhnlichere Ciphers nehmen kann, weil das eh nur gpg auf machen kann.
Man muss dann nicht darauf achten, was man da vor sich hat und die Option einfach immer anhängen.

Danach kann man das für einen Spezialfall mit cipher-algo nochmal anders entscheiden.
rot: Moderator wanne spricht, default: User wanne spricht.

Trollkirsche
Beiträge: 497
Registriert: 08.08.2015 15:03:09
Wohnort: Schweiz Zürich

Re: Backup-Tar verschlüsseln

Beitrag von Trollkirsche » 01.02.2018 00:33:07

TomL hat geschrieben: ↑ zum Beitrag ↑
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:
Alles braucht seine Zeit. Ich kenne das Thema Algorithmen auch noch nicht wirklich, bin aber froh, dass wir hier solche Experten wie wanne haben, die uns helfen können. Da ich gerade ebenfalls an einer verschlüsselten Backup Lösung arbeite, ein hochinteressantes Thema. Ich hatte vor, mit luks die komplette USB Platte zu verschlüsseln und dort die Dateien hineinzupacken. Könnte man mit decrypted derived script das passwort vom ursprünglichen pw nicht auch ableiten und somit für die Entschlüsselung der USB Backup Platte nutzbar machen?

TomL

Re: Backup-Tar verschlüsseln

Beitrag von TomL » 01.02.2018 15:30:58

Gibt es einen besonderen Grund für das vorherige Full-Quoting?
Trollkirsche hat geschrieben: ↑ zum Beitrag ↑
01.02.2018 00:33:07
Da ich gerade ebenfalls an einer verschlüsselten Backup Lösung arbeite, ein hochinteressantes Thema. Ich hatte vor, mit luks die komplette USB Platte zu verschlüsseln und dort die Dateien hineinzupacken.
Ist die Backup-Platte permanent angeschlossen und verbunden oder soll sie passend zum Backup-Job manuell angeschlossen werden?

Antworten