[gelöst] Backup-Tar verschlüsseln

Probleme mit Samba, NFS, FTP und Co.
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: 8782
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: 8782
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.

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: 7447
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: 7447
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: 7447
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