[gelöst] Backup-Tar verschlüsseln

Probleme mit Samba, NFS, FTP und Co.
wanne
Moderator
Beiträge: 5409
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: 311
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
Beiträge: 3299
Registriert: 24.07.2014 10:56:59

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 .
vg, Thomas

wanne
Moderator
Beiträge: 5409
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: 5409
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.

Antworten