From bernhard at intevation.de Mon Feb 1 09:38:50 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 1 Feb 2016 09:38:50 +0100 Subject: Frage zur Option --no-for-your-eyes-only In-Reply-To: <56ABF614.9060404@arcor.de> References: <56A9F288.3030803@arcor.de> <56ABF614.9060404@arcor.de> Message-ID: <201602010938.51355.bernhard@intevation.de> On Saturday 30 January 2016 at 00:30:28, Gc3bcnter Thaler wrote: > Das wirkt dem versehentlichen Speichern der entschlüsselten Datei [..] > entgegegen Genau, es ist ein unverbindlicher Hinweis and die OpenPGP Software des Empfängers. Unverbindlich deshalb, weil sich der Kommunikationspartner das ja entschlüsseln kann und dann halt entscheiden kann, was er damit macht. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 473 bytes Beschreibung: This is a digitally signed message part. URL : From c.kremsmayr at gmx.net Sat Feb 6 15:36:05 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Sat, 6 Feb 2016 15:36:05 +0100 Subject: =?UTF-8?Q?Angabe_alternativer_Schl=c3=bcsselb=c3=bcnde_funktioniert?= =?UTF-8?Q?_nicht?= Message-ID: <56B604D5.1050206@gmx.net> Hallo GnuPG-Freunde, ich habe soeben unter Windows 7 mit den Optionen --keyring --secret-keyring --no-default-keyring experimentiert und komme nicht zum gewünschten Ergebnis. Mein GnuPG-Heimatverzeichnis ist unverändert seit der Installation (Standardverzeichnis nach der Installation unter Windows 7). Nun habe ich folgendes Verzeichnis angelegt: E:/abc/def/ghi/ angelegt. Das Kommando gpg2 --no-default-keyring --keyring E:/abc/def/ghi/pubring.gpg --secret-keyring E:/abc/def/ghi/secring.gpg --gen-key müsste nun ja die beiden neuen Schlüssel in die beiden soeben erstellten Schlüsselbünde in E:/abc/def/ghi/ ablegen. Tut es aber nicht. Beim Erzeugen des Schlüsselpaares erhalte ich keine Meldung: gpg: kein schreibbarer öffentlicher Schlüsselbund gefunden: Unbekannter Systemfehler Schlüsselerzeugung fehlgeschlagen: Unbekannter Systemfehler Offensichtlich müssen die beiden Schlüsselbünde bereits existiueren. Also habe ich pubring.gpg und secring.gpg aus dem GnuPG-Heimatverzeichnis nach E:/abc/def/ghi/ kopiert. Nun erhalte ich dei dem oben erwähnten Kommando dieselbe Fehlermeldung. -- Was übersehe ich? Christine From c.kremsmayr at gmx.net Sat Feb 6 15:39:14 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Sat, 6 Feb 2016 15:39:14 +0100 Subject: Option -- enable-large-rsa Message-ID: <56B60592.2050309@gmx.net> Hallo, Wenn ich die Option -- enable-large-rsa in meine Konfigurationsdatei geschrieben und wollte aus Interesse einen sehr langen Schlüssel erzeugen. Bereits beim Start von gpg2 erhalte ich die Meldung: gpg: C:/Users/win/AppData/Roaming/gnupg/gpg.conf:3: WARNING: gpg not built with large secure memory buffer. Ignoring en able-large-rsa Wenn ich die Meldung richtig interpretiere, dann kann man die Option nicht ohne Weiteres nach der Installation von Gpg4win verwenden. Ich möchte einen Hinweis im Manual (Beschreibung der Option) von GnuPG 2.0.29 anregen, dass die Option nur dann zur Verfügung steht, wenn GnuPG mit large secure memory buffer kompiliert wurde. ---- Im Manual für GnuPG 2.0.29 heißt es: With –gen-key and –batch, enable the creation of larger RSA secret keys than is generally recommended (up to 8192 bits). These large keys are more expensive to use, and their signatures and certifications are also larger. Christine From malte.gell at gmx.de Sat Feb 6 16:47:36 2016 From: malte.gell at gmx.de (Malte Gell) Date: Sat, 6 Feb 2016 16:47:36 +0100 Subject: Option -- enable-large-rsa In-Reply-To: <56B60592.2050309@gmx.net> References: <56B60592.2050309@gmx.net> Message-ID: <56B61598.50507@malte.gell.gmx.de> Am 06.02.2016 um 15:39 schrieb Christine Kremsmayr: > Hallo, > > Wenn ich die Option -- enable-large-rsa in meine Konfigurationsdatei > geschrieben und wollte aus Interesse einen sehr langen Schlüssel erzeugen. > Bereits beim Start von gpg2 erhalte ich die Meldung: Cool, seit wann gibt es diese Option denn? gpg 2.0.24 erkennt sie scheinbar nicht über gpg --gen-key --enable-large-rsa. gpg: Ungültige Option "--enable-large-rsa" Ist auch egal, ich denke, für Schlüssel über 2048 Bit gibt es ohnehin nur ganz wenige Gründe für ganz wenige Leute... Gruß Malte From malte.gell at gmx.de Sat Feb 6 16:54:51 2016 From: malte.gell at gmx.de (Malte Gell) Date: Sat, 6 Feb 2016 16:54:51 +0100 Subject: =?UTF-8?Q?Re:_Angabe_alternativer_Schl=c3=bcsselb=c3=bcnde_funktion?= =?UTF-8?Q?iert_nicht?= In-Reply-To: <56B604D5.1050206@gmx.net> References: <56B604D5.1050206@gmx.net> Message-ID: <56B6174B.1080904@malte.gell.gmx.de> Am 06.02.2016 um 15:36 schrieb Christine Kremsmayr: > Das Kommando > > gpg2 --no-default-keyring --keyring E:/abc/def/ghi/pubring.gpg > --secret-keyring E:/abc/def/ghi/secring.gpg --gen-key > > müsste nun ja die beiden neuen Schlüssel in die beiden soeben erstellten > Schlüsselbünde in E:/abc/def/ghi/ ablegen. Tut es aber nicht. Und wenn du bei o.g. Befehl einfach mal das --no-default-keyring weglässt? Du hast in deinem Befehl den Slash / benutzt, muss man unter Windows bei Pfaden nicht den Backslash \ verwenden? Gruß From c.kremsmayr at gmx.net Sat Feb 6 17:31:06 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Sat, 6 Feb 2016 17:31:06 +0100 Subject: Probleme beim Anzeigen von Foto-IDs Message-ID: <56B61FCA.6080403@gmx.net> Hallo, Ziel: Ich will erreichen, dass GnuPG unter Windows 7 zur Anzeige des Fotos in der Foto-ID eines Schlüssels das Programm Irfan View gestertet wird und nicht das Standardprogramm zur Anzeige von Bildern (Windows-Fotoanzeige). Dazu habe ich mit der Option --photo-viewer experimentiert, komme aber nicht zum gewünschten Ergebnis. Fall 1: Ich verwende die beiden Optionen -- exec-path und --photo-viewer weder in der Konfigurationsdatei noch in der Kommandozeile. Ergebnis: Es wird beim Ausführen von gpg2 --list-keys automatisch das Standard-Anzeigeprogramm von Windows gestartet, aber kein Foto angezeigt. Fall 2: In der Konfigurationsdatei steht: exec-path "C:/Program Files/IrfanView/i_view32.exe" Ergebnis: Gleich wie in Fall 1. Fall 3: In der Konfigurationsdatei steht: photo-viewer "C:/Program Files/IrfanView/i_view32.exe" Ergebnis: Es wird beim Ausführen von gpg2 --list-keys gar kein Anzeigeprogramm gestartet. Woran bitte liegt es? CHristine From c.kremsmayr at gmx.net Sat Feb 6 17:57:28 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Sat, 6 Feb 2016 17:57:28 +0100 Subject: =?UTF-8?Q?Re:_Angabe_alternativer_Schl=c3=bcsselb=c3=bcnde_funktion?= =?UTF-8?Q?iert_nicht?= In-Reply-To: <56B6174B.1080904@malte.gell.gmx.de> References: <56B604D5.1050206@gmx.net> <56B6174B.1080904@malte.gell.gmx.de> Message-ID: <56B625F8.8050008@gmx.net> Hi, danke für deine Antwort. Am 06.02.2016 um 16:54 schrieb Malte Gell: > hlüsselbünde in E:/abc/def/ghi/ ablegen. Tut es aber nicht. > Und wenn du bei o.g. Befehl einfach mal das --no-default-keyring weglässt? > Du hast in deinem Befehl den Slash / benutzt, muss man unter Windows bei > Pfaden nicht den Backslash \ verwenden? > Habe soeben Folgendes versucht: gpg2 --keyring E:/abc/def/ghi/pubring.gpg --secret-keyring E:/abc/def/ghi/secring.gpg --gen-key gpg: Schlüsselblockhilfsmittel`C:/Users/win/AppData/Roaming/gnupg/E:/abc/def/ghi/secring.gpg': No such file or directory gpg: Schlüsselblockhilfsmittel`C:/Users/win/AppData/Roaming/gnupg/E:/abc/def/ghi/pubring.gpg': No such file or directory D.h., GPG legt die beiden Schlüsseldateien nicht an, gut zu wissen. Schlüsselerstellung war erfolgreich, natürlich wurden sie in die beiden Standard-Schlüsselbünde abgelegt (GnuPG-Heimatverzeichnis, pubring.gpg und secring.gpg). Zur anderen Frage: Nein, man muss in GnuPG immer Slashes angeben, keine Backslashes, auch unter Win. Christine From c.kremsmayr at gmx.net Sat Feb 6 17:46:43 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Sat, 6 Feb 2016 17:46:43 +0100 Subject: Weitere Fragen zu --photo-viewer und --exec-path Message-ID: <56B62373.6010100@gmx.net> Darf ich zur Frage von oben bitte gleich zwei weitere hängen? Option --photo-viewer: Ich verstehe ehrlich gesagt die Beschreibung nicht: This is the command line that should be run to view a photo ID. "%i" will be expanded to a filename containing the photo. Was ist "%i"? Ein Platzhalter, für den dann zur Laufzeit ein Dateiname eingesetzt wird? Wie teile ich GnuPG mit, was für "%i" eingesetzt werden soll? Ist diese Option vielleicht nur für Programmierer gedacht, nicht für Anwender? Aus der Option --exec-path string werde ich auch nicht schlau: Sets a list of directories to search for photo viewers and keyserver helpers. If not provided, keyserver helpers use the compiled-in default directory, and photo viewers use the $PATH environment variable. Note, that on W32 system this value is ignored when searching for keyserver helpers. Könnte mir bitte jemand erklären, wie ich diese Option verwenden muss? Noch eine Frage: Was ein ein Keyserver-Helper? Christine From carnap at gmx.at Sat Feb 6 22:17:16 2016 From: carnap at gmx.at (Josef Carnap) Date: Sat, 6 Feb 2016 22:17:16 +0100 Subject: =?UTF-8?Q?Eigenartiges_Verhalten_beim_=c3=9cberpr=c3=bcfen_von_Klar?= =?UTF-8?Q?textsignaturen?= Message-ID: <56B662DC.90105@gmx.at> Hallo GnuPG-Liste, ich kann ja mit --clearsign eine KLartextsignatur über z.B. eine Tetxtdatei erstellen. Wenn ich sie mit --verify überprüfe, meckert GnuPG, dass es sich nicht um eine abgetrennte Signatur handle und dass daher die Signatur nicht überprüft würde: gpg: WARNING: Dies ist keine abgetrennte Signatur; die Datei 'E:/GnuPG/Wichtige Textdatei 8.txt' wurde NICHT geprüft! Ich glaube, ich habe irgendwas vergessen, weiß aber nicht was. Gruß Carnap From telegraph at gmx.net Sun Feb 7 00:46:51 2016 From: telegraph at gmx.net (Gregor Zattler) Date: Sun, 7 Feb 2016 00:46:51 +0100 Subject: Eigenartiges =?iso-8859-1?Q?Verhalten_?= =?iso-8859-1?Q?beim_=DCberpr=FCfen?= von Klartextsignaturen In-Reply-To: <56B662DC.90105@gmx.at> References: <56B662DC.90105@gmx.at> Message-ID: <20160206234651.GA3252@len.workgroup> Hi Josef, * Josef Carnap [06. Feb. 2016]: > ich kann ja mit --clearsign eine KLartextsignatur über z.B. eine > Tetxtdatei erstellen. > Wenn ich sie mit --verify überprüfe, meckert GnuPG, dass es sich nicht > um eine abgetrennte Signatur handle und dass daher die Signatur nicht > überprüft würde: > > gpg: WARNING: Dies ist keine abgetrennte Signatur; die Datei > 'E:/GnuPG/Wichtige Textdatei 8.txt' wurde NICHT geprüft! Aus dem gedächtnis: Du musst die Prüfung auf die Datei mit der Signatur machen, wenn Du also von der Datei Muh.txt eine abgetrennten Signatur in Sig.txt hast, dann: gpg --verify Sig.txt Muh.txt Ciao; Gregor From carnap at gmx.at Sun Feb 7 10:01:45 2016 From: carnap at gmx.at (Josef Carnap) Date: Sun, 7 Feb 2016 10:01:45 +0100 Subject: =?UTF-8?Q?Re:_Eigenartiges_Verhalten_beim_=c3=9cberpr=c3=bcfen_von_?= =?UTF-8?Q?Klartextsignaturen?= In-Reply-To: <20160206234651.GA3252@len.workgroup> References: <56B662DC.90105@gmx.at> <20160206234651.GA3252@len.workgroup> Message-ID: <56B707F9.2040302@gmx.at> Hallo Gregor, Am 07.02.2016 um 00:46 schrieb Gregor Zattler: > Aus dem gedächtnis: Du musst die Prüfung auf die Datei mit der > Signatur machen, wenn Du also von der Datei Muh.txt eine > abgetrennten Signatur in Sig.txt hast, dann: > > gpg --verify Sig.txt Muh.txt Ich habe durchaus die Signatur geprüft, nicht die ursprüngliche Datei. Übrigens habe ich eine integrierte Klartextsignatur gemacht, keine abgetrennte. Soeben nochmals getestet. Ursache vermutlich gefunden: GnuPG nimmt an, dass sich in dem Verzeichnis, in dem sich die integrierte Signatur dateiname.txt.asc befindet, NICHT noch die ursrpüngliche Datei dateiname.txt befindet. Das war der Grund. Ich habe nun NUR die Signaturdatei dateiname.txt.asc in ein weiteres Verzeichnis verschoben, die Überprüfung noch einmal gemacht, und es hat geklappt. -- Vielleicht interessiert das jemanden ... Danke dennoch für den Tipp. Gruß Josef From telegraph at gmx.net Sun Feb 7 13:56:55 2016 From: telegraph at gmx.net (Gregor Zattler) Date: Sun, 7 Feb 2016 13:56:55 +0100 Subject: Weitere Fragen zu --photo-viewer und --exec-path In-Reply-To: <56B62373.6010100@gmx.net> References: <56B62373.6010100@gmx.net> Message-ID: <20160207125655.GA7012@len.workgroup> Hi Christine, * Christine Kremsmayr [06. Feb. 2016]: > Darf ich zur Frage von oben bitte gleich zwei weitere hängen? > > Option --photo-viewer: > Ich verstehe ehrlich gesagt die Beschreibung nicht: > > This is the command line that should be run to view a photo ID. > "%i" will be expanded to a filename containing the photo. > > Was ist "%i"? Ein Platzhalter, für den dann zur Laufzeit ein Dateiname > eingesetzt wird? Wie teile ich GnuPG mit, was für "%i" eingesetzt werden > soll? > Ist diese Option vielleicht nur für Programmierer gedacht, nicht für > Anwender? Manche Keys haben ein Photo (sinnvollerweise: der Person, die über den key verfügt, d. h. in der Regel die Person, die den Key erstellt hat) integriert. Mit --photo-viewer kann man das Kommando angeben, mit dem diese Photos angezeigt werden sollen. Beispiel: --photo-viewer "qiv %I" ruft das Programm "quiv" mit dem temporären Dateinamen des Fotos auf, qiv zeigt dann das Foto an. Als NutzerIn schreibt man das in die Konfigurationsdatei photo-viewer "qiv %I" und benutz das künftig, z. B. beim überprüfen von Unterschriften. Wenn der photo-viewer nicht gefunden wird (weil er nicht an einem Standardplatz installiert ist), kann man mit --exec-path angeben, wo nach dem photo-viewer gesucht werden soll -- also eine eher seltene Situation. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- From c.kremsmayr at gmx.net Sun Feb 7 15:44:25 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Sun, 7 Feb 2016 15:44:25 +0100 Subject: Weitere Fragen zu --photo-viewer und --exec-path In-Reply-To: <20160207125655.GA7012@len.workgroup> References: <56B62373.6010100@gmx.net> <20160207125655.GA7012@len.workgroup> Message-ID: <56B75849.7090405@gmx.net> Hallo Gregor, Am 07.02.2016 um 13:56 schrieb Gregor Zattler: > Hi Christine, > * Christine Kremsmayr [06. Feb. 2016]: > Mit --photo-viewer kann man das > Kommando angeben, mit dem diese Photos angezeigt werden sollen. > > Beispiel: > > --photo-viewer "qiv %I" Hurrah!!! Danke! Ich habe in meine Konfigurationsdatei geschrieben: exec-path "C:/Program Files/IrfanView" photo-viewer "i_view32.exe %I" Auch die Option, so verwendet: photo-viewer "i_view32.exe %I" Und es funktioniert nun. Besten Dank, Gregor. Christine From ml.throttle at xoxy.net Mon Feb 8 02:19:30 2016 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Mon, 08 Feb 2016 02:19:30 +0100 Subject: Weitere Fragen zu --photo-viewer und --exec-path In-Reply-To: <56B62373.6010100@gmx.net> (Christine Kremsmayr's message of "Sat, 6 Feb 2016 17:46:43 +0100") References: <56B62373.6010100@gmx.net> Message-ID: <874mdknglf.fsf@helmutwaitzmann.news.arcor.de> Christine Kremsmayr : > Option --photo-viewer: > Ich verstehe ehrlich gesagt die Beschreibung nicht: > > This is the command line that should be run to view a photo ID. > "%i" will be expanded to a filename containing the photo. > > Was ist "%i"? Ein Platzhalter, für den dann zur Laufzeit ein Dateiname > eingesetzt wird? Genau. > Wie teile ich GnuPG mit, was für "%i" eingesetzt werden soll? Garnicht. GnuPG sucht sich einen Dateinamen selbst aus, schreibt dort das Photo hinein und übergebt den Dateinamen an der Stelle der Kommandozeile, wo %i steht, an den Bildbetrachter. > Aus der Option --exec-path string werde ich auch nicht schlau: > Sets a list of directories to search for photo viewers and keyserver > helpers. If not provided, keyserver helpers use the compiled-in default > directory, and photo viewers use the $PATH environment variable. Note, > that on W32 system this value is ignored when searching for keyserver > helpers. > Könnte mir bitte jemand erklären, wie ich diese Option verwenden muss? Wenn Dein Bildbetrachter an einer Stelle im System abgelegt ist, wo er auch sonst (d. h. außerhalb von GnuPG) als Programm gefunden wird, musst Du diese Option vermutlich überhaupt nicht verwenden. > Noch eine Frage: Was ein ein Keyserver-Helper? Keine Ahnung. Ich gehe aber davon aus, dass in der Standardinstallation das „compiled‐in default directory“ schon das richtige sein wird. From c.kremsmayr at gmx.net Mon Feb 8 19:13:10 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Mon, 8 Feb 2016 19:13:10 +0100 Subject: Weitere Fragen zu --photo-viewer und --exec-path In-Reply-To: <874mdknglf.fsf@helmutwaitzmann.news.arcor.de> References: <56B62373.6010100@gmx.net> <874mdknglf.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <56B8DAB6.90205@gmx.net> Am 08.02.2016 um 02:19 schrieb Helmut Waitzmann: >> Wie teile ich GnuPG mit, was für "%i" eingesetzt werden soll? > Garnicht. GnuPG sucht sich einen Dateinamen selbst aus, schreibt > dort das Photo hinein und übergebt den Dateinamen an der Stelle der > Kommandozeile, wo %i steht, an den Bildbetrachter. Darf ich jetzt gleich unverschämt weiterfragen? Ich habe ins Blaue gerate bezüglich einiger Werte. "%I" does the same [wie "%i], except the file will not be deleted once the viewer exits.--> Ich nehme an, das Foto wird nicht aus dem Speicher gelöscht, auch wenn das Fotoanzeigeprogramm geschlossen wird, korrekt? "%k" for the key ID --> Ich nehme an: Wenn ich die Option --photo-viewer "0x123E45 %k" verwende, dann wird nur die Foto-ID angezeigt, die im Schlüssel 0x123E45 gespeichert ist? "%f" for the key fingerprint --> Ich nehme an, Wenn ich die Option --photo-viewer "7F65 A380 B5FE B685 E8F6 7820 6F52 3CA7 DDED 9124 %k" verwende, dann werden nur die Foto-IDs angezeigt, die im Schlüssel 7F65 A380 B5FE B685 E8F6 7820 6F52 3CA7 DDED 9124 gespeichert sind? "%t" for the extension of the image type (e.g. "jpg") --> Wozu ist dieser Wert da? ich verwende grundsätzlich nur Fotos im Format JPEG. Ist dieser Wert für Fälle gedacht, in denen das Format abweicht, zB. GIF? Wenn ich ein Foto als GIF-Datei habe, muss ich dann die Optioon so verwenden: --photo-viewer "gif %t"? "%T" for the MIME type of the image (e.g. "image/jpeg") --> das verstehe ich leider nicht. "%v" for the single-character calculated validity of the image being viewed (e.g. "f") --> dito. "%V" for the calculated validity as a string (e.g. "full") --> dito. "%U" for a base32 encoded hash of the user ID --> dito. "%%" for an actual percent sign --> Diesen Wert verstehe ich leider überhaupt nicht. The default viewer is "xloadimage -fork -quiet -title ’KeyID 0x%k’ STDIN". Note that if your image viewer program is not secure, then executing it from GnuPG does not make it secure. Unter Windows 8.1 funktioniert die Anzeige eines Fotos übrigens nicht ohne Verwendung der Option. Vielleicht interessiert das jemanden. Vielleicht weißt du einige Antworten, wenn nicht -- kein Beinbruch, die gestrige Antwort war die wichtigere. Gruß Christine From ml.throttle at xoxy.net Tue Feb 9 09:08:50 2016 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Tue, 09 Feb 2016 09:08:50 +0100 Subject: Weitere Fragen zu --photo-viewer und --exec-path In-Reply-To: <56B8DAB6.90205@gmx.net> (Christine Kremsmayr's message of "Mon, 8 Feb 2016 19:13:10 +0100") References: <56B62373.6010100@gmx.net> <874mdknglf.fsf@helmutwaitzmann.news.arcor.de> <56B8DAB6.90205@gmx.net> Message-ID: <87k2mei9ub.fsf@helmutwaitzmann.news.arcor.de> Christine Kremsmayr : > Am 08.02.2016 um 02:19 schrieb Helmut Waitzmann: >>> Wie teile ich GnuPG mit, was für "%i" eingesetzt werden soll? >> Garnicht. GnuPG sucht sich einen Dateinamen selbst aus, schreibt >> dort das Photo hinein und übergebt den Dateinamen an der Stelle der >> Kommandozeile, wo %i steht, an den Bildbetrachter. > Darf ich jetzt gleich unverschämt weiterfragen? Ich habe ins Blaue > gerate bezüglich einiger Werte. > > "%I" does the same [wie "%i], except the file will not be deleted once > the viewer exits.--> Ich nehme an, das Foto wird nicht aus dem Speicher > gelöscht, auch wenn das Fotoanzeigeprogramm geschlossen wird, korrekt? Ich bin mir nicht sicher, ob ich Dich richtig verstehe. Gemeint ist vermutlich folgendes: Mit %i legt GnuPG eine Bilddatei an und übergibt deren Namen an den Bildbetrachter. Und dann wartet GnuPG, bis Du den Bildbetrachter beendest. Sobald Du ihn beendet hast, löscht GnuPG die Bilddatei. Das ist ja auch ganz sinnvoll, denn die braucht ja jetzt niemand mehr. Nun gibt es aber auch Bildbetrachter, die im Hintergrund bereits laufen, und für die es ein Bildübergabeprogramm gibt, das man starten kann, damit der bereits laufende Bildbetrachter ein neues Fenster auf dem Bildschirm aufmacht und das Bild anzeigt. Wenn man jetzt das Bildübergabeprogramm startet, wendet es sich an den laufenden Bildbetrachter und übergibt ihm den Dateinamen des anzuzeigenden Bildes. Dann beendet es sich. Der Bildbetrachter öffnet die Bilddatei und zeigt sie an. Wenn Du jetzt in die Konfigurationsdatei photo-viewer "mein_Bildübergabeprogramm %i" reinschreibst, löscht GnuPG die Bilddatei, sobald das Bildübergabeprogramm sich beendet hat. Möglicherweise ist aber der Bildbetrachter noch gar nicht dazu gekommen, die Bilddatei zu öffnen und zu lesen. D.h., GnuPG raubt ihm das Bild, ehe er es anzeigen kann. Um das zu vermeiden, kann man statt %i %I nehmen. Dann sollte sich allerdings der Bildbetrachter darum kümmern, die Bilddatei nach Gebrauch zu löschen: GnuPG löscht sie nicht. > "%k" for the key ID --> Ich nehme an: Wenn ich die Option > --photo-viewer "0x123E45 %k" verwende, dann wird nur die Foto-ID > angezeigt, die im Schlüssel 0x123E45 gespeichert ist? Nein. Da steckt viel weniger dahinter: --photo-viewer "0x123E45 %k" würde bedeuten, ein Bildprogramm namens „0x123E45“ zu starten und ihm als Parameter das kurze Schlüssel‐Id des Schlüssels zu übergeben, eher nicht das, was Du wolltest. Vergiss nicht: Die Option --photo-viewer (oder das entsprechende in der Konfigurationsdatei) muss eine ganze Kommandozeile für den Bildbetrachter enthalten. %k könntest Du beispielsweise verwenden – wenn der Bildbetrachter das unterstützt –, um ihm einen Titel mitzuteilen, den er am Bildfenster anzeigen soll. Auf diese Weise kannst Du am Fenstertitel sehen, welches Schlüssel‐Id der Schlüssel hat, zu dem das Bild gehört. Ein Beispiel dazu hast Du weiter unten mit dem Bildbetrachter „xloadimage“ zitiert, wo genau das gemacht wird. > "%f" for the key fingerprint --> Ich nehme an, Wenn ich die > Option --photo-viewer "7F65 A380 B5FE B685 E8F6 7820 6F52 3CA7 > DDED 9124 %k" verwende, dann werden nur die Foto-IDs angezeigt, > die im Schlüssel 7F65 A380 B5FE B685 E8F6 7820 6F52 3CA7 DDED > 9124 gespeichert sind? Ähnlich verhält es sich mit %K und %f: Man kann sie verwenden, um den Bildbetrachter zu veranlassen, das lange Schlüssel‐Id oder den Fingerabdruck des Schlüssels im Bildtitel zu verwenden. > "%t" for the extension of the image type (e.g. "jpg") --> Wozu > ist dieser Wert da? ich verwende grundsätzlich nur Fotos im > Format JPEG. Ich vermute, die Entscheidung, welchen Bildtyp ein Photo hat, liegt beim Schlüsselersteller, also Deinem Kommunikationspartner, nicht bei Dir. > Ist dieser Wert für Fälle gedacht, in denen das Format abweicht, > zB. GIF? Wenn ich ein Foto als GIF-Datei habe, muss ich dann > die Optioon so verwenden: --photo-viewer "gif %t"? Das kommt auf den Bildbetrachter an. Manche Bildbetrachter raten nicht selbst, in was für einem Bildformat die Daten (oder die Datei) sind, die GnuPG ihnen übergibt, sondern wollen den Bildtyp in der Kommandozeile genannt bekommen. Nimm an, Du hättest einen Bildbetrachter, der immer zwei Parameter haben will: als ersten Parameter den Bildtyp (z.B. "jpg" oder "gif") und als zweiten die Bilddatei. Dann müsstest Du photo-viewer "mein_Bildbetrachter %t %i" schreiben, damit GnuPG ihm mitteilt, von welchem Bildtyp die Datei ist. > "%T" for the MIME type of the image (e.g. "image/jpeg") --> das > verstehe ich leider nicht. Das ist ähnlich wie bei %t und wäre für Bildbetrachter, die als Bildtyp z.B. image/jpeg oder image/gif gesagt bekommen wollen. Die folgenden vier sind in meinem GnuPG noch nicht enthalten. Aber ich versuche mal, zu raten: > "%v" for the single-character calculated validity of the image > being viewed (e.g. "f") --> dito. > > "%V" for the calculated validity as a string (e.g. "full") --> > dito. Zu jedem User‐Id eines jeden Schlüssels (Deinem eigenen und fremden öffentlichen Schlüsseln) in Deinem Schlüsselring kennt GnuPG eine Gültigkeit, wie z.B. „ultimately trusted“, „fully trusted“, „marginally trusted“ (weiß nicht, wie die deutschen Begriffe dazu heißen, vielleicht „uneingeschränkt gütlig“, "voll gültig“, „kaum gültig“). %V in der Kommandozeile ersetzt GnuPG durch ultimate, full, marginal, …. Entsprechend ersetzt GnuPG %v in der Kommandozeile durch die Anfangsbuchstaben u, f, m, …. Auch die können dazu verwendet werden, dem Bildbetrachter einen Bildtitel mitzugeben, den er anzeigen soll. > "%U" for a base32 encoded hash of the user ID --> dito. Hier berechnet GnuPG aus dem user ID einen base32‐kodierten Hashwert und schreibt ihn dort in die Kommandozeile des Bildbetrachters, wo %U steht. Auch da kann ich mir nur vorstellen, dass man das dazu verwenden kann, um den Bildtitel entsprechend festzulegen. Der Bildbetrachter bekommt ja keinen Schlüssel übergeben sondern nur das im Schlüssel enthaltene Bild. Daher nehme ich an, er kann damit nichts weiteres anfangen, außer, einen Bildtitel anzuzeigen. > "%%" for an actual percent sign --> Diesen Wert verstehe ich > leider überhaupt nicht. %% ist dafür gedacht, wenn Du ein %‐Zeichen in die Kommandozeile stellen willst, z.B., weil darin Umgebungsvariablen vorkommen, etwa photo-viewer "%%PROGRAMFILES%%/mein_Bildbetrachter %i" GnuPG macht aus %% dann %. Dann wird also der Bildbetrachter %PROGRAMFILES%/mein_Bildbetrachter mit dem Namen der von GnuPG erzeugten Bilddatei als Parameter aufgerufen. > The default viewer is "xloadimage -fork -quiet -title ’KeyID > 0x%k’ STDIN". Note that if your image viewer program is not > secure, then executing it from GnuPG does not make it secure. Das ist ein Beispiel eines Bildbetrachters, dem man mittels -title 'ein Bildtitel' sagen kann, welchen Titel er beim Bild anzeigen soll. Im angeführten Beispiel würde GnuPG beim Anzeigen eines Bildes, das im Schlüssel, der das kurze Schlüssel‐Id 0x123E45 hat, enthalten ist, dann xloadimage -fork -quiet -title 'KeyID 0x123E45' STDIN starten. From k.hofmann81 at web.de Tue Feb 16 17:32:37 2016 From: k.hofmann81 at web.de (Klara Hofmann) Date: Tue, 16 Feb 2016 17:32:37 +0100 Subject: =?UTF-8?Q?Pr=c3=a4ferenzlisten_f=c3=bcr_Algorithmen?= Message-ID: <56C34F25.8080808@web.de> Hallo, ich spiele gerade mit Präfernzlisten herum (--edit-key --> setpref, --personal-cipher-preferences, --personal-digest-preferences, --personal-compress-preferences) und würde meine Vermutungen gerne testen. Ganz einfach lässt sich die Option --personal-digest-preferences testen: in die Konfigurationsdatei eintragen, Datei signieren und in der Signatur nachsehen, welcher Hashalgorithmus verwendet wurde. Aber wie prüfe ich nach, welchen symmetrischen Algorithmus und welches Kompressionsverfahren GnuPG bei --encrypt tatsächlich verwendet hat? Ist eine Prüfung ohne Weiteres möglich? Klara From malte.gell at gmx.de Wed Feb 17 04:20:07 2016 From: malte.gell at gmx.de (Malte Gell) Date: Wed, 17 Feb 2016 04:20:07 +0100 Subject: =?UTF-8?Q?Re:_Pr=c3=a4ferenzlisten_f=c3=bcr_Algorithmen?= In-Reply-To: <56C34F25.8080808@web.de> References: <56C34F25.8080808@web.de> Message-ID: <56C3E6E7.50109@malte.gell.gmx.de> Am 16.02.2016 um 17:32 schrieb Klara Hofmann: > Aber wie prüfe ich nach, welchen symmetrischen Algorithmus und welches Kompressionsverfahren GnuPG bei --encrypt tatsächlich verwendet hat? Ist eine Prüfung ohne Weiteres möglich? Einfach -v an den Befehl dranhängen: gpg -v -d test.asc gpg: enabled debug flags: memstat gpg: TWOFISH verschlüsselte Daten gpg: Verschlüsselt mit einer Passphrase gpg: Ursprünglicher Dateiname='test' Wie man sieht, benutze ich Twofish. From bernhard at intevation.de Wed Feb 17 09:39:40 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 17 Feb 2016 09:39:40 +0100 Subject: Public tender "EasyGpg", BSI Germany In-Reply-To: <201509230948.46858.bernhard@intevation.de> References: <201509230948.46858.bernhard@intevation.de> Message-ID: <201602170939.45829.bernhard@intevation.de> Moin Moin, On Wednesday 23 September 2015 at 09:48:40, Bernhard Reiter wrote: > the Federal Agency of IT-Security of Germany > has published a public tender about improving the usability > of end-to-end email encryption by improving GnuPG, Thunderbird, Kontact > Mail and certificate exchange. It seems to be inspired by STEED. the BSI has awarded the contract to g10 Code and Intevation! More details at https://wiki.gnupg.org/EasyGpg2016 Best Regards, Bernhard ps: "Moin Moin" is an round-the-clock usable greeting in the north of Germany. Roughly see https://en.wikipedia.org/wiki/Moin -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 473 bytes Beschreibung: This is a digitally signed message part. URL : From k.hofmann81 at web.de Wed Feb 17 09:47:50 2016 From: k.hofmann81 at web.de (Klara Hofmann) Date: Wed, 17 Feb 2016 09:47:50 +0100 Subject: =?UTF-8?Q?Re:_Pr=c3=a4ferenzlisten_f=c3=bcr_Algorithmen?= In-Reply-To: <56C3E6E7.50109@malte.gell.gmx.de> References: <56C34F25.8080808@web.de> <56C3E6E7.50109@malte.gell.gmx.de> Message-ID: <56C433B5.8030508@web.de> Am 17.02.2016 um 04:20 schrieb Malte Gell: > Einfach -v an den Befehl dranhängen: > > gpg -v -d test.asc > > gpg: enabled debug flags: memstat > gpg: TWOFISH verschlüsselte Daten > gpg: Verschlüsselt mit einer Passphrase > gpg: Ursprünglicher Dateiname='test' > > Wie man sieht, benutze ich Twofish. > Besten Dank! Jetzt kann ich die Fälle durchtesten. Klara From carnap at gmx.at Wed Feb 17 18:23:04 2016 From: carnap at gmx.at (Josef Carnap) Date: Wed, 17 Feb 2016 18:23:04 +0100 Subject: Optionen --sig-notation und --cert-notation Message-ID: <56C4AC78.1060808@gmx.at> Hallo Liste, die beiden Optionen --sig-notation und --cert-notation sind mir nicht ganz klar. --cert-notation (in der Konfigurationsdatei) kann ich reproduzieren. Beim Auflisten der Schlüssel mit --check-sigs und --list-sigs wird der erfasste Text angezeigt. Nur: Weshalb wurde diese Option implementiert? Was ist ein möglicher Anwendungsfall? Dass man im ersten Teil standardmäßig ein @ eingeben muss, deutet darauf hin, dass man da irgend eine E-Mail-Adresse eingibt. Aber welche? --sig-notation kann ich nicht reproduzieren. Wenn ich eine ASCII-Signatur über eine Datei erstelle, wird der erfasste Text nicht in die Signatur eingeschrieben. Auch beim --verify der Signatur wird der Text nicht angezeigt. Weiß vielleicht bitte jemand, wo der Text angezeigt wird? Gruß Josef From carnap at gmx.at Wed Feb 17 18:47:50 2016 From: carnap at gmx.at (Josef Carnap) Date: Wed, 17 Feb 2016 18:47:50 +0100 Subject: Optionen --sig-notation und --cert-notation In-Reply-To: <56C4AC78.1060808@gmx.at> References: <56C4AC78.1060808@gmx.at> Message-ID: <56C4B246.8090207@gmx.at> Am 17.02.2016 um 18:23 schrieb Josef Carnap: > Hallo Liste, > > die beiden Optionen --sig-notation und --cert-notation sind mir nicht > ganz klar. > Nun konnte ich auch die Option --sig-notation reproduzieren. Sry, zu früh gefragt und zu wenig selbst nachgesehen ... Man muss bei --list-sigs auch die Option --list-options show-notations verwenden, und beim --verify von Signaturen auch die Option --verify-options show-notations verwenden. (Letzteres hatte ich vergessen.) Die Signatur-Notation wird also beim Überprüfen der Signatur angezeigt. Die anderen Fragen aber ziehe ich nicht zurück ;-) Josef From carnap at gmx.at Thu Feb 18 10:40:32 2016 From: carnap at gmx.at (Josef Carnap) Date: Thu, 18 Feb 2016 10:40:32 +0100 Subject: Fragen zur Option --group Message-ID: <56C59190.1010709@gmx.at> Hallo, Ich wollte soeben die Option --group verwenden, komme aber nicht zurecht. Ich erhalte stets die Meldung: C:\Users\win>gpg2 --recipient Vertrieb --armor --encrypt E:/GnuPG/"Vertrag mit ABC.txt" gpg: "16525F43: übersprungen: Kein ÷ffentlicher Schl³ssel gpg: E:/GnuPG/Vertrag mit ABC.txt: encryption failed: Kein ÷ffentlicher Schl³ssel Die in der Option angegebenen Schlüssel sind alles öffentliche Fremdschlüssel. In der Konfigurationsdatei habe ich die Option --group nacheinander auf folgende Art verwendet: goup "Vertrieb=C537BCF7 Vertrieb=0FB4393 Vertrieb=65354C1 Vertrieb=EC68571D" group Vertrieb="16525F43 A072CBE3 65FAF513 EC68571D" group Vertrieb=16525F43 Vertrieb=A072CBE3 Vertrieb=65FAF513 Vertrieb=EC68571D group Vertrieb = "16525F43 A072CBE3 65FAF513 EC68571D" Ich glaube, dass ich auf dem Schlauch sitze, ich finde ih aber nicht ;-) Josef From c.kremsmayr at gmx.net Thu Feb 18 19:11:06 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Thu, 18 Feb 2016 19:11:06 +0100 Subject: =?UTF-8?Q?Verst=c3=a4ndnisfrage_zum_Archivieren_verschl=c3=bcsselte?= =?UTF-8?Q?r_Daten?= Message-ID: <56C6093A.4080904@gmx.net> Hallo Liste, Mir ist eigentlich gar nicht klar, wann ich ein altes Schlüsselpaar (öffentlicher und privater Schlüssel) ohne unangenehme Konsequenzen löschen darf. Angenommen ich habe ein Schlüsselpaar K1 (= öffentlicher Hauptschlüssel) und K2 (privater Hauptschlüssel), das ich eine Zeit lang benutzt habe. Die mit K1 verschlüsselten Dateien und E-Mails möchte ich in alle Zukunft archivieren. Nun ist der private Sxchlüssel kompromittiert. Ich ersetze das Schlüsselpaar durch ein neues. Ich nehme an, ich muss den alten Schlüssel zwar wiuderrufen und den Widerruf-Schlüssel (Sperrzertifikat) auf den Keyserver laden; aber löschen darf ich zumindest den privaten Hauptschlüssel nicht. Anderenfalls sind die archivierten Daten auf ewig nicht mehr entschlüsselbar. Ist das korrekt? Oder gibt es die Möglichkeit, das Schlüsselpaar zu löschen und dennoch die Daten entschlüsseln zu können? Gruß Christine From martin at linux-ip.net Fri Feb 19 07:40:56 2016 From: martin at linux-ip.net (Martin A. Brown) Date: Thu, 18 Feb 2016 22:40:56 -0800 Subject: =?ISO-8859-15?Q?Re=3A_Verst=E4ndnisfrage_zum_Archivieren_verschl=FCsselter_Daten?= In-Reply-To: <56C6093A.4080904@gmx.net> References: <56C6093A.4080904@gmx.net> Message-ID: Guten Abend Christine, Hoffentlich kann ich hier eine passende Antwort anbieten. >Mir ist eigentlich gar nicht klar, wann ich ein altes Schlüsselpaar >(öffentlicher und privater Schlüssel) ohne unangenehme Konsequenzen >löschen darf. Zuerst...Hauptfrage: was sind die befürchtete Konsequenzen? Oder erwartete? Wenn es nur um die Schlüssel geht, dann, ist es nichts schlimmes. Wenn es um die Verschlüsselte Daten geht, dann kommt man in Risikobereich ein. >Angenommen ich habe ein Schlüsselpaar K1 (= öffentlicher >Hauptschlüssel) und K2 (privater Hauptschlüssel), das ich eine Zeit >lang benutzt habe. Die mit K1 verschlüsselten Dateien und E-Mails >möchte ich in alle Zukunft archivieren. Verstanden. >Nun ist der private Sxchlüssel kompromittiert. Ich ersetze das >Schlüsselpaar durch ein neues. Gut: Natürlich soll ein kompromittierter Schlüssel nicht mehr benutzt werden. Auch gut: Ein neues Paar einzuführen. >Ich nehme an, ich muss den alten Schlüssel zwar wiuderrufen und den >Widerruf-Schlüssel (Sperrzertifikat) auf den Keyserver laden; Ja, im Prinzip soll man den Widerruf-Schlüssel verbreiten. >aber löschen darf ich zumindest den privaten Hauptschlüssel nicht. >Anderenfalls sind die archivierten Daten auf ewig nicht mehr >entschlüsselbar. Ist das korrekt? Ja, das ist absolut korrekt. Mathematisch ist der private Hauptschlüssel nötig um diese älteren Daten zu entschlüsseln. Daher, z.B., behalte ich alte Schlüssel auf meinem eigenen Keyring (und diese Schlüssel benutze ich nie mehr für Verschlüsseln). >Oder gibt es die Möglichkeit, das Schlüsselpaar zu löschen und >dennoch die Daten entschlüsseln zu können? Nein, leider nicht möglich. Um diese Daten noch entschlüsseln zu können ist der Hauptschlüssel immer noch notwendig. Aber wenn der private Schlüssel kopromittiert ist, denkt man an die Folgen. Unter welchen Umständen war der private Hauptschlüssel kompromittiert? Hier sind wir im Bereich der Risikoabschätzung. * Alle alte Daten löschen? (OK, nein, nicht in diesem Fall...) * Entschlüsseln und nochmal Verschlüsseln mit neuem Paar? * Risiko der Aufdeckung des Inhalts übernehmen? Diese Fragen muß persönlich, oder im Konzert mit den Dateneigentümern, entschieden werden. Abstrakt kann man nur sagen, daß die Daten theoretisch greifbar sind. Die genaue Kosten kommen auf dem Wert der Daten an. Hoffentlich sind diese Antworten hilfreich, -Martin P.S. Entschuldigung wenn ich unbeholfen auf Deutsch schreibe. Ich bin weder Muttersprachler noch völlig fließend. -- Martin A. Brown http://linux-ip.net/ From c.kremsmayr at gmx.net Fri Feb 19 09:18:33 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Fri, 19 Feb 2016 09:18:33 +0100 Subject: =?UTF-8?Q?Re:_Verst=c3=a4ndnisfrage_zum_Archivieren_verschl=c3=bcss?= =?UTF-8?Q?elter_Daten?= In-Reply-To: References: <56C6093A.4080904@gmx.net> Message-ID: <56C6CFD9.7020407@gmx.net> Hallo Martin, Am 19.02.2016 um 07:40 schrieb Martin A. Brown: > Guten Abend Christine, > > Hoffentlich kann ich hier eine passende Antwort anbieten. Oh, deine Antwort ist ausgesprochen hilfreich. - Herzlichen Dank! > >> Mir ist eigentlich gar nicht klar, wann ich ein altes Schlüsselpaar >> (öffentlicher und privater Schlüssel) ohne unangenehme Konsequenzen >> löschen darf. > Zuerst...Hauptfrage: was sind die befürchtete Konsequenzen? Oder > erwartete? Datenverlust; kein Zugriff auf von mir versendete und von anderen erhaltene E-Mails und generell kein ZUgriff auf verschlüsselte Daten. > Ja, das ist absolut korrekt. Mathematisch ist der private > Hauptschlüssel nötig um diese älteren Daten zu entschlüsseln. > Daher, z.B., behalte ich alte Schlüssel auf meinem eigenen Keyring > (und diese Schlüssel benutze ich nie mehr für Verschlüsseln). OK, das dachte ich mir. > Aber wenn der private Schlüssel kopromittiert ist, denkt man an die > Folgen. Unter welchen Umständen war der private Hauptschlüssel > kompromittiert? Hier sind wir im Bereich der Risikoabschätzung. > > * Alle alte Daten löschen? (OK, nein, nicht in diesem Fall...) > * Entschlüsseln und nochmal Verschlüsseln mit neuem Paar? > * Risiko der Aufdeckung des Inhalts übernehmen? > > Diese Fragen muß persönlich, oder im Konzert mit den > Dateneigentümern, entschieden werden. Abstrakt kann man nur sagen, > daß die Daten theoretisch greifbar sind. Die genaue Kosten kommen > auf dem Wert der Daten an. Ja, ich denke auch, da muss der konkrete Schaden zuerst ermittelt werden, um dann adäquat darauf reagieren zu können. > > Hoffentlich sind diese Antworten hilfreich, Sehr sogar! > P.S. Entschuldigung wenn ich unbeholfen auf Deutsch schreibe. Ich > bin weder Muttersprachler noch völlig fließend. Dein Deutsch hier ist nahezu perfekt, ich habe nichts Unbeholfenes bemerkt. Warte nur, wenn ich auf gnupg-users in Englisch poste! ;-) Danke nochmals Christine From k.hofmann81 at web.de Fri Feb 19 09:27:42 2016 From: k.hofmann81 at web.de (Klara Hofmann) Date: Fri, 19 Feb 2016 09:27:42 +0100 Subject: =?UTF-8?Q?Regelwerk_f=c3=bcr_Ermittluing_der_Algorithmen?= In-Reply-To: References: Message-ID: <56C6D1FE.2000001@web.de> Hallo, (Ich habe diese Frasge bereits gestern an die Liste geschikt, dabei dürfte aber ein Fehler passiert sein.) Mich interessiert das Regelwerk, nach dem GnuPG den Algorithmus ermittelt, mit dem verschlüsselt bzw. signiert wird, wenn ein Benutzer A mit dem Schlüssel von Benutzer B Dateien/Daten verschlüsselt. Wenn A für den Schlüssel von B verschlüsselt, so können A und B ihre bevorzugten Algorithmen ja in Präferenzlisten schreiben: A schreibt z.B. in seine Konfigurationsdatei rein (ohne die --): --personal-cipher-preferences --personal-digest-preferences --personal-compress-preferences B wiederum kann mit --edit-key --> setpref ebenfalls Präferenzenlisten für sein Eigenzertifikat erstellen. Auch diese wird ja von GnuPG ausgewertet, wenn A für B verschlüsselt und/oder signiert. Nach meinen Beobachtungen habe ich bisher folgendes Regelwerk rekonstruieren können: 1. Wenn die Präferenzlisten As und Bs exakt dieselben Algorithmen in derselben Reihenfolge enthalten --> jeweils der erste angeführte Algo gewinnt (trivialer Fall: vollkommene Gleichheit: dieselben Algorithmen, dieselbe Reihenfolge in den Listen). 2. Wenn die drei Schnittmengen nicht leer sind, es aber Unterschiede in der Reihenfolge der Algos gibt --> der erstgenannte geeignete Algo des Absenders gewinnt (geeignet = er kommt auch in der Präferenzliste Bs vor). 3. Wenn eine Schnittmenge leer ist, dann wird weder A noch B bevorzugt, sondern es wird der in im OpenPGP-Standard empfohlene oder vorgeschriebene Algorithmus verwendet (3DES, SHA1, kleinster gemeinsamer Nenner). 4. Wenn man mehrere Empfänger-Schlüssel angibt (--encrypt-to, --recipient mehrmals verwenden), dann werden auch die Präferenzlisten dieser Schlüssel ausgewertet. Bisher hat sich dieses Regelwerk bewährt. Nicht aber im folgenden Fall: A (der Absender) verwendet z.B. in seiner Konfigurationsdatei folgende Optionen: --personal-cipher-preferences TWOFISH BLOWFISH AES --personal-digest-preferences RIPEMD160 SHA384 --personal-compress-preferences ZIP B hat im Eigenzertifikat seines Schlüssels folgende Präferenzliste festlegt: CAST5 CAMELLIA128 AES192 SHA512 MD5BZIP2 ZLIB. Die Schnittmengen für die Algorithmen sind leer. GnuPG müsste daher jeweils den kleinsten gemeinsamen Nenner verwenden: 3DES, SHA1 und ZIP. Wenn ich diesen Fall durchspiele, erweist sich meine Hypothese aber als falsch. GnuPG wählt CAST5 und SHA512. Weshalb ist das so? Kennt jemand vielleicht das tatsächliche Regelwerk? In meiner gpg.conf werden keine Algorithmen ausgeschlossen. Klara From ml.throttle at xoxy.net Fri Feb 19 09:33:34 2016 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Fri, 19 Feb 2016 09:33:34 +0100 Subject: =?utf-8?Q?Verst=C3=A4ndnisfrage?= zum Archivieren =?utf-8?Q?v?= =?utf-8?Q?erschl=C3=BCsselter?= Daten In-Reply-To: <56C6093A.4080904@gmx.net> (Christine Kremsmayr's message of "Thu, 18 Feb 2016 19:11:06 +0100") References: <56C6093A.4080904@gmx.net> Message-ID: <87lh6hhzev.fsf@helmutwaitzmann.news.arcor.de> Christine Kremsmayr : > Mir ist eigentlich gar nicht klar, wann ich ein altes Schlüsselpaar > (öffentlicher und privater Schlüssel) ohne unangenehme Konsequenzen > löschen darf. > > Angenommen ich habe ein Schlüsselpaar K1 (= öffentlicher Hauptschlüssel) > und K2 (privater Hauptschlüssel), das ich eine Zeit lang benutzt habe. > Die mit K1 verschlüsselten Dateien und E-Mails möchte ich in alle > Zukunft archivieren. Nun ist der private Sxchlüssel kompromittiert. Ich > ersetze das Schlüsselpaar durch ein neues. > > Ich nehme an, ich muss den alten Schlüssel zwar wiuderrufen und den > Widerruf-Schlüssel (Sperrzertifikat) auf den Keyserver laden; Ja, genau. Damit Alle sehen, dass sie den alten öffentlichen Schlüssel nicht mehr verwenden sollen, wenn sie Dir verschlüsselte Nachrichten schicken wollen. > aber löschen darf ich zumindest den privaten Hauptschlüssel > nicht. Anderenfalls sind die archivierten Daten auf ewig nicht > mehr entschlüsselbar. Da ist mir noch nicht ganz klar: Hast Du zum Entschlüsseln einen Unterschlüssel oder verwendest Du den Hauptschlüssel dazu? > Ist das korrekt? Deswegen sage ich zunächst: Das kommt darauf an: Es ist üblich – und GnuPG tut das normalerweise auch –, zum Verschlüsseln und Entschlüsseln nicht das Hauptschlüsselpaar sondern ein Extraschlüsselpaar zu verwenden, das als Unterschlüsselpaar an das Hauptschlüsselpaar gehängt wird. Prüfe nach, ob das bei Dir der Fall ist, mit dem Kommando gpg2 --edit-key -- 'Dein_Schlüssel-Id' quit Da sollten in der Ausgabe eine oder mehrere Zeilen, die mit „pub “ oder „sub “ beginnen, auftauchen: „pub“ steht für den öffentlichen Hauptschlüssel, „sub“ für einen öffentlichen Unterschlüssel. Am Ende einer jeden solchen Zeile steht „usage: “ und dahinter folgt einer oder mehrere Buchstaben: C steht dabei für certify: andere Schlüssel unterschreiben S steht dabei für sign: Daten signieren E steht dabei für encrypt: Daten verschlüsseln A steht dabei für authorize: sich ausweisen Damit kannst Du herausfinden, welcher Schlüssel zum Verschlüsseln (E) genutzt wird. Bei mir sieht es beispielsweise so aus (Zeilen leicht gekürzt): pub 2048R/1BB50F01 created: 2015-11-10 expires: 2016-11-09 usage: C trust: ultimate validity: ultimate sub 2048R/EE36C617 created: 2015-11-10 expires: 2016-11-09 usage: S sub 2048R/EF126582 created: 2015-11-10 expires: 2016-11-09 usage: E Und nun kommt es darauf an, ob der private Hauptschlüssel oder der private Unterschlüssel kompromittiert ist: Ist der private Hauptschlüssel kompromittiert, musst Du das Hauptschlüsselpaar widerrufen. Theoretisch könntest Du alle Unterschlüsselpaare weiterverwenden. Man müsste sie allerdings so, wie sie zuvor am alten Hauptschlüsselpaar hingen, jetzt an das neue Hauptschlüsselpaar hängen. Ob das machbar ist und – wenn ja – mit welchem Aufwand, ist mir nicht bekannt. Ist der private Unterschlüssel kompromittiert, aber der alte Hauptschlüssel unversehrt, genügt es, dem Hauptschlüsselpaar ein neues Unterschlüsselpaar hinzuzufügen und das alte Unterschlüsselpaar zu widerrufen. Das Web of Trust, das am Hauptschlüsselpaar hängt, bleibt in diesem Fall unversehrt. > Oder gibt es die Möglichkeit, das Schlüsselpaar zu löschen und dennoch > die Daten entschlüsseln zu können? Hoffentlich nicht: In dem Moment, in dem Du den privaten Entschlüsselungsschlüssel nicht mehr hast, unterscheidest Du Dich nicht mehr von allen anderen Menschen in Bezug auf die Frage, ob Du die alten für Dich verschlüsselten Nachrichten lesen kannst: Du kannst sie ebensowenig lesen wie die Anderen auch. Du kannst die alten Daten aber mit dem alten privaten Schlüssel entschlüsseln (solange Du ihn noch hast), und zwar auch, wenn Du den öffentlichen widerrufen hast, und sie mit einem neuen Schlüssel verschlüsseln. Wenn Du das mit allen alten Daten getan hast, kannst Du die mit dem alten Schlüssel verschlüsselten Daten und den alten privaten Schlüssel tatsächlich wegwerfen. Aber ich würde Dir empfehlen, zumindest den alten widerrufenen öffentlichen Schlüssel unbedingt aufzubewahren, damit Du jederzeit jedem Kommunikationspartner, der Deinen alten öffentlichen Schlüssel noch in unwiderrufener Form hat, den widerrufenen zukommen lassen kannst, damit er nicht auf die Idee kommt, ihn zu verwenden. -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-signature Dateigröße : 489 bytes Beschreibung: nicht verfügbar URL : From c.kremsmayr at gmx.net Fri Feb 19 09:38:56 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Fri, 19 Feb 2016 09:38:56 +0100 Subject: Weitere Fragen zu --photo-viewer und --exec-path In-Reply-To: <87k2mei9ub.fsf@helmutwaitzmann.news.arcor.de> References: <56B62373.6010100@gmx.net> <874mdknglf.fsf@helmutwaitzmann.news.arcor.de> <56B8DAB6.90205@gmx.net> <87k2mei9ub.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <56C6D4A0.3060009@gmx.net> Besten Dank für deine sehr engagierten Erklärungen, Helmut! Jetzt kann ich ir das alles im Detail ansehen (habe mir eigens ein Liinux aufgesetzt, damit ich das Ganze auch unter Linux testen kann)! Christine From ml.throttle at xoxy.net Fri Feb 19 09:40:07 2016 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Fri, 19 Feb 2016 09:40:07 +0100 Subject: =?utf-8?Q?Verst=C3=A4ndnisfrage?= zum Archivieren =?utf-8?Q?v?= =?utf-8?Q?erschl=C3=BCsselter?= Daten In-Reply-To: <56C6093A.4080904@gmx.net> (Christine Kremsmayr's message of "Thu, 18 Feb 2016 19:11:06 +0100") References: <56C6093A.4080904@gmx.net> Message-ID: <87k2m1hz3y.fsf@helmutwaitzmann.news.arcor.de> Christine Kremsmayr : > Mir ist eigentlich gar nicht klar, wann ich ein altes Schlüsselpaar > (öffentlicher und privater Schlüssel) ohne unangenehme Konsequenzen > löschen darf. > > Angenommen ich habe ein Schlüsselpaar K1 (= öffentlicher Hauptschlüssel) > und K2 (privater Hauptschlüssel), das ich eine Zeit lang benutzt habe. > Die mit K1 verschlüsselten Dateien und E-Mails möchte ich in alle > Zukunft archivieren. Nun ist der private Sxchlüssel kompromittiert. Ich > ersetze das Schlüsselpaar durch ein neues. > > Ich nehme an, ich muss den alten Schlüssel zwar wiuderrufen und den > Widerruf-Schlüssel (Sperrzertifikat) auf den Keyserver laden; Ja, genau. Damit Alle sehen, dass sie den alten öffentlichen Schlüssel nicht mehr verwenden sollen, wenn sie Dir verschlüsselte Nachrichten schicken wollen. > aber löschen darf ich zumindest den privaten Hauptschlüssel > nicht. Anderenfalls sind die archivierten Daten auf ewig nicht > mehr entschlüsselbar. Da ist mir noch nicht ganz klar: Hast Du zum Entschlüsseln einen Unterschlüssel oder verwendest Du den Hauptschlüssel dazu? > Ist das korrekt? Deswegen sage ich zunächst: Das kommt darauf an: Es ist üblich – und GnuPG tut das normalerweise auch –, zum Verschlüsseln und Entschlüsseln nicht das Hauptschlüsselpaar sondern ein Extraschlüsselpaar zu verwenden, das als Unterschlüsselpaar an das Hauptschlüsselpaar gehängt wird. Prüfe nach, ob das bei Dir der Fall ist, mit dem Kommando gpg2 --edit-key -- 'Dein_Schlüssel-Id' quit Da sollten in der Ausgabe eine oder mehrere Zeilen, die mit „pub “ oder „sub “ beginnen, auftauchen: „pub“ steht für den öffentlichen Hauptschlüssel, „sub“ für einen öffentlichen Unterschlüssel. Am Ende einer jeden solchen Zeile steht „usage: “ und dahinter folgt einer oder mehrere Buchstaben: C steht dabei für certify: andere Schlüssel unterschreiben S steht dabei für sign: Daten signieren E steht dabei für encrypt: Daten verschlüsseln A steht dabei für authorize: sich ausweisen Damit kannst Du herausfinden, welcher Schlüssel zum Verschlüsseln (E) genutzt wird. Bei mir sieht es beispielsweise so aus (Zeilen leicht gekürzt): pub 2048R/1BB50F01 created: 2015-11-10 expires: 2016-11-09 usage: C trust: ultimate validity: ultimate sub 2048R/EE36C617 created: 2015-11-10 expires: 2016-11-09 usage: S sub 2048R/EF126582 created: 2015-11-10 expires: 2016-11-09 usage: E Und nun kommt es darauf an, ob der private Hauptschlüssel oder der private Unterschlüssel kompromittiert ist: Ist der private Hauptschlüssel kompromittiert, musst Du das Hauptschlüsselpaar widerrufen. Theoretisch könntest Du alle Unterschlüsselpaare weiterverwenden. Man müsste sie allerdings so, wie sie zuvor am alten Hauptschlüsselpaar hingen, jetzt an das neue Hauptschlüsselpaar hängen. Ob das machbar ist und – wenn ja – mit welchem Aufwand, ist mir nicht bekannt. Ist der private Unterschlüssel kompromittiert, aber der alte Hauptschlüssel unversehrt, genügt es, dem Hauptschlüsselpaar ein neues Unterschlüsselpaar hinzuzufügen und das alte Unterschlüsselpaar zu widerrufen. Das Web of Trust, das am Hauptschlüsselpaar hängt, bleibt in diesem Fall unversehrt. > Oder gibt es die Möglichkeit, das Schlüsselpaar zu löschen und dennoch > die Daten entschlüsseln zu können? Hoffentlich nicht: In dem Moment, in dem Du den privaten Entschlüsselungsschlüssel nicht mehr hast, unterscheidest Du Dich nicht mehr von allen anderen Menschen in Bezug auf die Frage, ob Du die alten für Dich verschlüsselten Nachrichten lesen kannst: Du kannst sie ebensowenig lesen wie die Anderen auch. Du kannst die alten Daten aber mit dem alten privaten Schlüssel entschlüsseln (solange Du ihn noch hast), und zwar auch, wenn Du den öffentlichen widerrufen hast, und sie mit einem neuen Schlüssel verschlüsseln. Wenn Du das mit allen alten Daten getan hast, kannst Du die mit dem alten Schlüssel verschlüsselten Daten und den alten privaten Schlüssel tatsächlich wegwerfen. Aber ich würde Dir empfehlen, zumindest den alten widerrufenen öffentlichen Schlüssel unbedingt aufzubewahren, damit Du jederzeit jedem Kommunikationspartner, der Deinen alten öffentlichen Schlüssel noch in unwiderrufener Form hat, den widerrufenen zukommen lassen kannst, damit er nicht auf die Idee kommt, ihn zu verwenden. -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-signature Dateigröße : 489 bytes Beschreibung: nicht verfügbar URL : From c.kremsmayr at gmx.net Fri Feb 19 10:00:55 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Fri, 19 Feb 2016 10:00:55 +0100 Subject: =?UTF-8?Q?Re:_Verst=c3=a4ndnisfrage_zum_Archivieren_verschl=c3=bcss?= =?UTF-8?Q?elter_Daten?= In-Reply-To: <87k2m1hz3y.fsf@helmutwaitzmann.news.arcor.de> References: <56C6093A.4080904@gmx.net> <87k2m1hz3y.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <56C6D9C7.8060407@gmx.net> Am 19.02.2016 um 09:40 schrieb Helmut Waitzmann: > > Da ist mir noch nicht ganz klar: Hast Du zum Entschlüsseln einen > Unterschlüssel oder verwendest Du den Hauptschlüssel dazu? Nein, keine UNterschlüssel. Meine Frage bezieht sich auf den einfachen Fall, dass es nur ein Haupt-Schlüsselpaar gibt, keine Unterschlüssel. Übrigenbs ist mir das nicht passiert, ich spiele derzeit nur mit meheren E-Mail-Accounts und GnuPG-INstallationen auf Windows und Linux herum, um das Ganze kennenzulernen. > >> Ist das korrekt? > Deswegen sage ich zunächst: Das kommt darauf an: > > Es ist üblich – und GnuPG tut das normalerweise auch –, zum > Verschlüsseln und Entschlüsseln nicht das Hauptschlüsselpaar > sondern ein Extraschlüsselpaar zu verwenden, das als > Unterschlüsselpaar an das Hauptschlüsselpaar gehängt wird. Sofern ich das das Konzept der Unterschlüssel verstanden habe, ist das ja einer der Gründe, weshalb UNterschlüssel eingeführt wurden: Wenn der private Unterschlüssel (aber nicht der private Hauptschlüssel) kompromittiert ist, macht man einfach ein neues Unter-Schlüsselpaar. > Ist der private Hauptschlüssel kompromittiert, musst Du das > Hauptschlüsselpaar widerrufen. Theoretisch könntest Du alle > Unterschlüsselpaare weiterverwenden. Man müsste sie allerdings > so, wie sie zuvor am alten Hauptschlüsselpaar hingen, jetzt an das > neue Hauptschlüsselpaar hängen. Ob das machbar ist und – wenn > ja – mit welchem Aufwand, ist mir nicht bekannt. Ich habe bisher auch noch keine Hinweise gefunden, ob das geht. > > Ist der private Unterschlüssel kompromittiert, aber der alte > Hauptschlüssel unversehrt, genügt es, dem Hauptschlüsselpaar ein > neues Unterschlüsselpaar hinzuzufügen und das alte > Unterschlüsselpaar zu widerrufen. Das Web of Trust, das am > Hauptschlüsselpaar hängt, bleibt in diesem Fall unversehrt. Blöde Frage, weil wir gerade über Unterschlüssel sprechen: Auch wenn ich X Unter-Schlüsselpaare habe -- ich verteile (per Mail, per Upload auf Keyserver) immer den öffentlichen Hauptschlüssel, korrekt? Dieser sammelt die Zertifikate (Schlüsselsignaturen) der anderen Benutzer, korrekt? Und dennoch kann ich Inhalte, die mit meinem öffentlichen Hautpschlüssel verschlüsselt wurden, mit meinem privaten Unterschlüssel (der einen ganz anderen Fingerabdruck hat, entschlüsseln. Das ist dch der Witz an den Unterschlüsseln, verstehe ich das richtig? > >> Oder gibt es die Möglichkeit, das Schlüsselpaar zu löschen und dennoch >> die Daten entschlüsseln zu können? > Hoffentlich nicht: OK, verstanden. > In dem Moment, in dem Du den privaten > Entschlüsselungsschlüssel nicht mehr hast, unterscheidest Du Dich > nicht mehr von allen anderen Menschen in Bezug auf die Frage, ob > Du die alten für Dich verschlüsselten Nachrichten lesen kannst: > Du kannst sie ebensowenig lesen wie die Anderen auch. OK > > Du kannst die alten Daten aber mit dem alten privaten Schlüssel > entschlüsseln (solange Du ihn noch hast), und zwar auch, wenn Du > den öffentlichen widerrufen hast, und sie mit einem neuen > Schlüssel verschlüsseln. OK. Das Widerruf-Zertifikat ändert nichts daran, dass ich mit dem widerrufenen Schlüssel weiterhin entschlüsseln kann. > Aber ich würde Dir empfehlen, zumindest den alten widerrufenen > öffentlichen Schlüssel unbedingt aufzubewahren, damit Du jederzeit > jedem Kommunikationspartner, der Deinen alten öffentlichen > Schlüssel noch in unwiderrufener Form hat, den widerrufenen > zukommen lassen kannst, damit er nicht auf die Idee kommt, ihn zu > verwenden. Aha, daran dachte ich gar nicht, das ist wichtig. Besten Dank!! Christine From malte.gell at gmx.de Fri Feb 19 09:54:42 2016 From: malte.gell at gmx.de (Malte Gell) Date: Fri, 19 Feb 2016 09:54:42 +0100 Subject: =?UTF-8?Q?Re:_Regelwerk_f=c3=bcr_Ermittluing_der_Algorithmen?= In-Reply-To: <56C6D1FE.2000001@web.de> References: <56C6D1FE.2000001@web.de> Message-ID: <56C6D852.5030601@malte.gell.gmx.de> Am 19.02.2016 um 09:27 schrieb Klara Hofmann: > (...) > Wenn ich diesen Fall durchspiele, erweist sich meine Hypothese aber als > falsch. GnuPG wählt CAST5 und SHA512. > Weshalb ist das so? Kennt jemand vielleicht das tatsächliche Regelwerk? CAST5 ist der voreingestellte Algo für symmetrische Verschlüsselung. Dein Experiment hat nun ergeben, dass CAST5 auch benutzt wird, wenn kein anderer Alg ermittelt werden kann. CAST5 wird auch von älteren PGP Versionen unterstützt. From k.hofmann81 at web.de Fri Feb 19 10:53:24 2016 From: k.hofmann81 at web.de (Klara Hofmann) Date: Fri, 19 Feb 2016 10:53:24 +0100 Subject: =?UTF-8?Q?Re:_Regelwerk_f=c3=bcr_Ermittluing_der_Algorithmen?= In-Reply-To: <56C6D852.5030601@malte.gell.gmx.de> References: <56C6D1FE.2000001@web.de> <56C6D852.5030601@malte.gell.gmx.de> Message-ID: <56C6E614.3080507@web.de> Am 19.02.2016 um 09:54 schrieb Malte Gell: > Am 19.02.2016 um 09:27 schrieb Klara Hofmann: >> (...) >> Wenn ich diesen Fall durchspiele, erweist sich meine Hypothese aber als >> falsch. GnuPG wählt CAST5 und SHA512. >> Weshalb ist das so? Kennt jemand vielleicht das tatsächliche Regelwerk? > CAST5 ist der voreingestellte Algo für symmetrische Verschlüsselung. Aha, daran hat es gelegen. Ich dachte, 3DES sei der kleinste gemeinsame Nenner für symmetrisches Verschlüsseln. Dann scheine ich gar nicht so falsch zu liegen ... Danke! From k.hofmann81 at web.de Fri Feb 19 11:17:42 2016 From: k.hofmann81 at web.de (Klara Hofmann) Date: Fri, 19 Feb 2016 11:17:42 +0100 Subject: =?UTF-8?Q?Re:_Regelwerk_f=c3=bcr_Ermittluing_der_Algorithmen?= In-Reply-To: <56C6D852.5030601@malte.gell.gmx.de> References: <56C6D1FE.2000001@web.de> <56C6D852.5030601@malte.gell.gmx.de> Message-ID: <56C6EBC6.1050407@web.de> Am 19.02.2016 um 09:54 schrieb Malte Gell: > Am 19.02.2016 um 09:27 schrieb Klara Hofmann: >> (...) >> Wenn ich diesen Fall durchspiele, erweist sich meine Hypothese aber als >> falsch. GnuPG wählt CAST5 und SHA512. >> Weshalb ist das so? Kennt jemand vielleicht das tatsächliche Regelwerk? > CAST5 ist der voreingestellte Algo für symmetrische Verschlüsselung. Weißt du bitte vielleicht auch, weshalb GnuPG in diesem Fall als Hash-Algorithmus SHA512 nimmt? SHA512 ist ja nicht der voreingestellt Algorithmus? Hm. Der ist doch SHA1, oder? Klara From malte.gell at gmx.de Sat Feb 20 09:53:31 2016 From: malte.gell at gmx.de (Malte Gell) Date: Sat, 20 Feb 2016 09:53:31 +0100 Subject: =?UTF-8?Q?Re:_Regelwerk_f=c3=bcr_Ermittluing_der_Algorithmen?= In-Reply-To: <56C6EBC6.1050407@web.de> References: <56C6D1FE.2000001@web.de> <56C6D852.5030601@malte.gell.gmx.de> <56C6EBC6.1050407@web.de> Message-ID: <56C8298B.9000203@malte.gell.gmx.de> Am 19.02.2016 um 11:17 schrieb Klara Hofmann: > Am 19.02.2016 um 09:54 schrieb Malte Gell: >> Am 19.02.2016 um 09:27 schrieb Klara Hofmann: >>> (...) >>> Wenn ich diesen Fall durchspiele, erweist sich meine Hypothese aber als >>> falsch. GnuPG wählt CAST5 und SHA512. >>> Weshalb ist das so? Kennt jemand vielleicht das tatsächliche Regelwerk? >> CAST5 ist der voreingestellte Algo für symmetrische Verschlüsselung. > Weißt du bitte vielleicht auch, weshalb GnuPG in diesem Fall als > Hash-Algorithmus SHA512 nimmt? > SHA512 ist ja nicht der voreingestellt Algorithmus? Hm. Der ist doch > SHA1, oder? SHA1 ist da der kleinste gemeinsame Nenner. SHA1 gilt aber als nicht mehr zeitgemäß, vermutlich wird deshalb SHA512 genommen. SHA1 ist auf dem absteigenden Ast. Ob das auch für RIPEMD160 gilt, weiß ich aber nicht. Ich benutze RIPEMD160. From telegraph at gmx.net Sat Feb 20 15:03:13 2016 From: telegraph at gmx.net (Gregor Zattler) Date: Sat, 20 Feb 2016 15:03:13 +0100 Subject: Fragen zur Option --group In-Reply-To: <56C59190.1010709@gmx.at> References: <56C59190.1010709@gmx.at> Message-ID: <20160220140313.GA17031@len.workgroup> Hi Josef, * Josef Carnap [18. Feb. 2016]: > Ich wollte soeben die Option --group verwenden, komme aber nicht zurecht. > Ich erhalte stets die Meldung: > > C:\Users\win>gpg2 --recipient Vertrieb --armor --encrypt > E:/GnuPG/"Vertrag mit ABC.txt" > gpg: "16525F43: übersprungen: Kein ÷ffentlicher Schl³ssel > gpg: E:/GnuPG/Vertrag mit ABC.txt: encryption failed: Kein ÷ffentlicher > Schl³ssel > > Die in der Option angegebenen Schlüssel sind alles öffentliche > Fremdschlüssel. > > In der Konfigurationsdatei habe ich die Option --group nacheinander auf > folgende Art verwendet: > > goup "Vertrieb=C537BCF7 Vertrieb=0FB4393 Vertrieb=65354C1 Vertrieb=EC68571D" Ich bin mir nicht sicher, ob man das so angeben kann. Was geht ist: group Vertrieb 16525F43 group Vertrieb A072CBE3 group Vertrieb 65FAF513 group Vertrieb EC68571D etc. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- From carnap at gmx.at Sat Feb 20 17:31:04 2016 From: carnap at gmx.at (Josef Carnap) Date: Sat, 20 Feb 2016 17:31:04 +0100 Subject: Fragen zur Option --group In-Reply-To: <20160220140313.GA17031@len.workgroup> References: <56C59190.1010709@gmx.at> <20160220140313.GA17031@len.workgroup> Message-ID: <56C894C8.8090102@gmx.at> Am 20.02.2016 um 15:03 schrieb Gregor Zattler: > Hi Josef, > * Josef Carnap [18. Feb. 2016]: >> Ich bin mir nicht sicher, ob man das so angeben kann. Was geht >> ist: >> >> group Vertrieb 16525F43 >> group Vertrieb A072CBE3 >> group Vertrieb 65FAF513 >> group Vertrieb EC68571D >> Das funktioniert bei mir einfach nicht. Entweder (wenn ich irgendwo ein "=" einbaue) sagt GPG: gpg: C:/Users/win/AppData/Roaming/gnupg/gpg.conf:77: Ungültige Option oder es sagt: gpg: Kein '='-Zeichen in der Gruppendefinition gefunden `Vertrieb 245A2676' gpg: Kein '='-Zeichen in der Gruppendefinition gefunden `Vertrieb DA0D42EF' gpg: Kein '='-Zeichen in der Gruppendefinition gefunden `Vertrieb 20FB4393' gpg: Kein '='-Zeichen in der Gruppendefinition gefunden `Vertrieb 304081B6' :-( Josef From telegraph at gmx.net Sat Feb 20 21:16:55 2016 From: telegraph at gmx.net (Gregor Zattler) Date: Sat, 20 Feb 2016 21:16:55 +0100 Subject: Fragen zur Option --group In-Reply-To: <56C894C8.8090102@gmx.at> References: <56C59190.1010709@gmx.at> <20160220140313.GA17031@len.workgroup> <56C894C8.8090102@gmx.at> Message-ID: <20160220201655.GA23370@len.workgroup> Hi Josef, * Josef Carnap [20. Feb. 2016]: > Am 20.02.2016 um 15:03 schrieb Gregor Zattler: >> * Josef Carnap [18. Feb. 2016]: >>> Ich bin mir nicht sicher, ob man das so angeben kann. Was geht >>> ist: >>> >>> group Vertrieb 16525F43 >>> group Vertrieb A072CBE3 >>> group Vertrieb 65FAF513 >>> group Vertrieb EC68571D Mein fehler: Da gehört ein "=" Zeichen ein. Ich nutz(t)e das mit GnuPG 1.4. Meine Keyids fangen aber mit "0x" an. Besonders eindeutig würde es mit Fingerprints. > Das funktioniert bei mir einfach nicht. Entweder (wenn ich irgendwo ein > "=" einbaue) sagt GPG: > > gpg: C:/Users/win/AppData/Roaming/gnupg/gpg.conf:77: Ungültige Option Probier's doch mal mit einer gpg.conf, die nur aus einer Zeile besteht, dann weißt Du sicher, welche gemeint ist (ich bin mir immer unsicher, ob solche Angaben mit oder ohne Kommentarzeilen gezählt werden). Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- From ml.throttle at xoxy.net Sun Feb 21 01:19:25 2016 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Sun, 21 Feb 2016 01:19:25 +0100 Subject: =?utf-8?Q?Verst=C3=A4ndnisfrage?= zum Archivieren =?utf-8?Q?v?= =?utf-8?Q?erschl=C3=BCsselter?= Daten In-Reply-To: <56C6D9C7.8060407@gmx.net> (Christine Kremsmayr's message of "Fri, 19 Feb 2016 10:00:55 +0100") References: <56C6093A.4080904@gmx.net> <87k2m1hz3y.fsf@helmutwaitzmann.news.arcor.de> <56C6D9C7.8060407@gmx.net> Message-ID: <87h9h2hq3c.fsf@helmutwaitzmann.news.arcor.de> Christine Kremsmayr : > Am 19.02.2016 um 09:40 schrieb Helmut Waitzmann: >> >> Da ist mir noch nicht ganz klar: Hast Du zum Entschlüsseln einen >> Unterschlüssel oder verwendest Du den Hauptschlüssel dazu? > > Nein, keine UNterschlüssel. Meine Frage bezieht sich auf den einfachen > Fall, dass es nur ein Haupt-Schlüsselpaar gibt, keine Unterschlüssel. > Übrigenbs ist mir das nicht passiert, ich spiele derzeit nur mit meheren > E-Mail-Accounts und GnuPG-INstallationen auf Windows und Linux herum, um > das Ganze kennenzulernen. Gute Idee. >>> Ist das korrekt? >> Deswegen sage ich zunächst: Das kommt darauf an: >> >> Es ist üblich – und GnuPG tut das normalerweise auch –, zum >> Verschlüsseln und Entschlüsseln nicht das Hauptschlüsselpaar >> sondern ein Extraschlüsselpaar zu verwenden, das als >> Unterschlüsselpaar an das Hauptschlüsselpaar gehängt wird. > Sofern ich das das Konzept der Unterschlüssel verstanden habe, ist das > ja einer der Gründe, weshalb UNterschlüssel eingeführt wurden: Wenn der > private Unterschlüssel (aber nicht der private Hauptschlüssel) > kompromittiert ist, macht man einfach ein neues Unter-Schlüsselpaar. Ja. Ein weiterer war technischer Natur: Als RSA noch patentgeschützt war, verwendete GnuPG ein DSA‐ und ein ElGamal‐Schlüsselpaar. (Das kann man auch jetzt noch bei der Schlüsselerzeugung auswählen, wenn man möchte.) Jedenfalls einen von beiden Schlüsseltypen konnte man nicht zum Signieren und Verschlüsseln verwenden (ich weiß nicht mehr, ob das nun beim DSA‐ oder beim ElGamal‐Schlüsselpaar der Fall war). Daher brauchte man zwei Paare. Ein weiterer Grund ist, dass es in Bezug auf Kryptanalyse (also Schlüsselknacken) besser ist, wenn man denselben privaten Schlüssel nicht sowohl zum Entschlüsseln als auch zum Signieren verwendet. Beim Signieren wählst Du als Schlüsseleigentümer aus, welche Daten mit dem geheimen Schlüssel verarbeitet werden. Beim Entschlüsseln wählt derjenige die Daten aus, der sie verschlüsselt: Er schickt Dir eine verschlüsselte Nachricht, und Du kannst sie entweder entschlüsseln oder es bleiben lassen. Aber Du hast keine Kontrolle darüber, wie sie aussehen. Auch aus diesem Grund empfiehlt es sich, zwei Schlüsselpaare zu verwenden. Damit man aber nur 1 Paar in das Web of Trust einbinden muss, macht man das andere Paar zum Unterschlüsselpaar. Es nimmt über das Hauptschlüsselpaar am Web of Trust teil. Um das Web of Trust aufzubauen, braucht man ein Schlüsselpaar, mit dem man anderer Leute Schlüssel beglaubigen (zertifizieren) kann. Das kommt aber dem Signieren sehr nahe. Damit ist klar: Das Signier‐ und Zertifizier‐Schlüsselpaar ist das Hauptschlüsselpaar, und das Verschlüsselungs‐Schlüsselpaar ist das Unterschlüsselpaar. >> Ist der private Hauptschlüssel kompromittiert, musst Du das >> Hauptschlüsselpaar widerrufen. Theoretisch könntest Du alle >> Unterschlüsselpaare weiterverwenden. Man müsste sie allerdings >> so, wie sie zuvor am alten Hauptschlüsselpaar hingen, jetzt an das >> neue Hauptschlüsselpaar hängen. Ob das machbar ist und – wenn >> ja – mit welchem Aufwand, ist mir nicht bekannt. > > Ich habe bisher auch noch keine Hinweise gefunden, ob das geht. Im englischsprachigen Mailinglist war einmal zu lesen, dass Unterschlüssel, technisch gesehen, auch nichts anderes als Hauptschlüssel sind. Sie unterscheiden sich nur an der Stelle, an der steht, ob sie eine Haupt‐ oder eine Unterschlüsselrolle spielen sollen. Mit „gpssplit“, einem Werkzeug zum Auseinandernehmen von Schlüsseln, kommt man an die einzelnen Schlüssel und an den Schlüsselrollen‐Anzeiger ran, kann ihn umstellen und dann die Schlüssel wieder zusammenpacken. > Blöde Frage, weil wir gerade über Unterschlüssel sprechen: Auch wenn ich > X Unter-Schlüsselpaare habe -- ich verteile (per Mail, per Upload auf > Keyserver) immer den öffentlichen Hauptschlüssel, korrekt? Die öffentlichen Unterschlüssel werden auch mit verteilt. Will Dir jemand eine verschlüsselte Nachricht schicken, braucht er den öffentlichen Schlüssel des Schlüsselpaars, das zum Ver‐ und Entschlüsseln verwendet wird. Das ist meistens (siehe oben) ein Unterschlüsselpaar. Um es aber Dir zuzuordnen (mithilfe des Webs of Trust), schaut er sich den Hauptschlüssel an, an dem der öffentliche Verschlüsselungsschlüssel hängt. Deswegen braucht er beide: Deinen öffentlichen Hauptschlüssel und Deinen öffentlichen Verschlüsselungsunterschlüssel. [Der öffentliche Hauptschlüssel] > Dieser sammelt die Zertifikate (Schlüsselsignaturen) der anderen > Benutzer, korrekt? Ja. > Und dennoch kann ich Inhalte, die mit meinem öffentlichen Hautpschlüssel > verschlüsselt wurden, mit meinem privaten Unterschlüssel (der einen ganz > anderen Fingerabdruck hat, entschlüsseln. Nein, das geht nicht. Zum Entschlüsseln braucht man den privaten Schlüssel desselben Schlüsselpaars, mit dessen öffentlichem Schlüssel verschlüsselt wurde. > Das ist dch der Witz an den Unterschlüsseln, verstehe ich das > richtig? Nicht ganz. Der Witz ist, dass man zwar einerseits zwei Schlüsselpaare (eines zum Signieren und Zertifizieren und Signaturprüfen, ein anderes zum Ent‐ und Verschlüsseln, siehe oben) verwendet. Dadurch, dass man aber andererseits das Ent‐ und Verschlüsselungs‐Schlüsselpaar zum Unterschlüsselpaar des Zertifizierschlüsselpaars macht, braucht es kein extra Web of Trust. From ml.throttle at xoxy.net Sun Feb 21 03:08:02 2016 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Sun, 21 Feb 2016 03:08:02 +0100 Subject: =?utf-8?Q?Verst=C3=A4ndnisfrage?= zum Archivieren =?utf-8?Q?v?= =?utf-8?Q?erschl=C3=BCsselter?= Daten In-Reply-To: <87h9h2hq3c.fsf@helmutwaitzmann.news.arcor.de> (Helmut Waitzmann's message of "Sun, 21 Feb 2016 01:19:25 +0100") References: <56C6093A.4080904@gmx.net> <87k2m1hz3y.fsf@helmutwaitzmann.news.arcor.de> <56C6D9C7.8060407@gmx.net> <87h9h2hq3c.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <87d1rqhl2b.fsf@helmutwaitzmann.news.arcor.de> Helmut Waitzmann : > „gpssplit“ Das muss „gpgsplit“ heißen. From c.kremsmayr at gmx.net Mon Feb 22 11:18:00 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Mon, 22 Feb 2016 11:18:00 +0100 Subject: FRage zu Widerruf-Zertifikaten In-Reply-To: <20160220201655.GA23370@len.workgroup> References: <56C59190.1010709@gmx.at> <20160220140313.GA17031@len.workgroup> <56C894C8.8090102@gmx.at> <20160220201655.GA23370@len.workgroup> Message-ID: <56CAE058.60901@gmx.net> 1. So wie ich die Sache verstehe, ist das Erstellen eines Widerruf-Zertifikates eigentlich nur dann zweckmäßig, wenn der zu widerrufende Schlüssel auf einem Keyserver liegt. Wenn ich verschlüsselte Kommunikation in einem geschlossenen Benutzergruppe betreibe, bringt mir ein Widerruf-Zertifikat nicht -- ist das korrekt so? Ich muss dann halt alle meine Kommunikationspartner anschreiben und sie bitten, den alten öffentlichen Schlüssel nicht mehr zu benutzen und stattdessen einen neuen öffentlichen Schlüssel verteilen und die Komm.partner bitten, den neuen öffentlichen Schlüssel zu importieren und zu nutzen. Richtig? 2. Noch eine Frage: Mit dem Erstellen des Widerruf-Zertifikates (--gen-revoke) passiert vorerst einmal gar nichts, solange ich das W-Zertifikat nicht auf déinen Schlüsselserver hochlade -- ist das korrekt? 3. Wie ändert man den Widerruf-Grund eines W-Zertifikates? Einfach ein neues mit dem passenden Grund erstellen oder kann man ein vorhandenes wirklich bearbeiten (ich habe dazu nichts gefunden)? Christine From carnap at gmx.at Mon Feb 22 12:16:31 2016 From: carnap at gmx.at (Josef Carnap) Date: Mon, 22 Feb 2016 12:16:31 +0100 Subject: Fragen zur Option --group In-Reply-To: <20160220201655.GA23370@len.workgroup> References: <56C59190.1010709@gmx.at> <20160220140313.GA17031@len.workgroup> <56C894C8.8090102@gmx.at> <20160220201655.GA23370@len.workgroup> Message-ID: <56CAEE0F.1030305@gmx.at> Darf ich noch einmal lästig sein? Am 20.02.2016 um 21:16 schrieb Gregor Zattler: > Hi Josef, > * Josef Carnap [20. Feb. 2016]: >> Am 20.02.2016 um 15:03 schrieb Gregor Zattler: >>> * Josef Carnap [18. Feb. 2016]: >>>> Ich bin mir nicht sicher, ob man das so angeben kann. Was geht >>>> ist: >>>> >>>> group Vertrieb 16525F43 >>>> group Vertrieb A072CBE3 >>>> group Vertrieb 65FAF513 >>>> group Vertrieb EC68571D > Mein fehler: Da gehört ein "=" Zeichen ein. OK, danke, habe ich nun reingegeben. Ich habe folgende Zeilen in der gpg.conf probiert (die Option in jeweils einer Zeile verwendet, kein Zeilenumbruch): group Vertrieb=FF456430841793627794A925FF89857E25B4F1D4 group Vertrieb=356EE781EE3C34C00D605BD075B39FCADA0D42EF group Vertrieb=FACB7B6434FAED3327AB3FD2E65CBADE80A035C7 group Vertrieb=1BCCC50730E8A1D3924AD0975D2509ED304081B6 group Vertrieb = FF456430841793627794A925FF89857E25B4F1D4 group Vertrieb = 356EE781EE3C34C00D605BD075B39FCADA0D42EF group Vertrieb = FACB7B6434FAED3327AB3FD2E65CBADE80A035C7 group Vertrieb = 1BCCC50730E8A1D3924AD0975D2509ED304081B6 Beide Male ergibt das Kommando gpg2 --recipient Vertrieb --armor --output E:/GnuPG/neu5/"Wichtige Textdatei 19.txt.asc" --encrypt E:/GnuPG/"Wichtige Textdatei 19.txt" folgende Fehlermeldung: gpg: group: übersprungen: Kein ÷ffentlicher Schl³ssel gpg: E:/GnuPG/Wichtige Textdatei 19.txt: encryption failed: Kein ÷ffentlicher Schl³ssel Mich irritiert Folgendes: Folgende Kommandos funktionieren einwandfrei: gpg2 --recipient 25B4F1D4 --armor --output E:/GnuPG/neu5/"Wichtige Textdatei 19.txt.asc" --encrypt E:/GnuPG/"Wichtige Textdatei 19.txt" gpg2 --recipient DA0D42EF --armor --output E:/GnuPG/neu5/"Wichtige Textdatei 19.txt.asc" --encrypt E:/GnuPG/"Wichtige Textdatei 19.txt" gpg2 --recipient 80A035C7 --armor --output E:/GnuPG/neu5/"Wichtige Textdatei 19.txt.asc" --encrypt E:/GnuPG/"Wichtige Textdatei 19.txt" gpg2 --recipient 304081B6 --armor --output E:/GnuPG/neu5/"Wichtige Textdatei 19.txt.asc" --encrypt E:/GnuPG/"Wichtige Textdatei 19.txt" ---- Gruß Josef Vielleicht interessiert es: Meine gpg.conf # Tests der group-Option: #======================== #Vertrieb=0FB4393 Vertrieb=65354C1 Vertrieb=EC68571D" --> geht nicht #goup name="Vertrieb=C537BCF7 Vertrieb=0FB4393 Vertrieb=65354C1 Vertrieb=EC68571D" --> geht nicht #group Vertrieb="16525F43 A072CBE3 65FAF513 EC68571D" --> geht nicht #group Vertrieb=16525F43 Vertrieb=A072CBE3 Vertrieb=65FAF513 Vertrieb=EC68571D --> geht nicht #group Vertrieb = "16525F43 A072CBE3 65FAF513 EC68571D" #group Vertrieb=245A2676 #group Vertrieb=DA0D42EF #group Vertrieb=20FB4393 #group Vertrieb=304081B6 #group Vertrieb=25B4F1D4 group Vertrieb=DA0D42EF group Vertrieb=80A035C7 group Vertrieb=304081B6 --> geht nicht #group Vertrieb = 25B4F1D4 group Vertrieb = DA0D42EF group Vertrieb = 80A035C7 group Vertrieb = 304081B6 --> geht nicht #group Vertrieb=FF456430841793627794A925FF89857E25B4F1D4 group Vertrieb=356EE781EE3C34C00D605BD075B39FCADA0D42EF group Vertrieb=FACB7B6434FAED3327AB3FD2E65CBADE80A035C7 group Vertrieb=1BCCC50730E8A1D3924AD0975D2509ED304081B6 group Vertrieb = FF456430841793627794A925FF89857E25B4F1D4 group Vertrieb = 356EE781EE3C34C00D605BD075B39FCADA0D42EF group Vertrieb = FACB7B6434FAED3327AB3FD2E65CBADE80A035C7 group Vertrieb = 1BCCC50730E8A1D3924AD0975D2509ED304081B6 From telegraph at gmx.net Mon Feb 22 13:06:36 2016 From: telegraph at gmx.net (Gregor Zattler) Date: Mon, 22 Feb 2016 13:06:36 +0100 Subject: Fragen zur Option --group In-Reply-To: <56CAEE0F.1030305@gmx.at> References: <56C59190.1010709@gmx.at> <20160220140313.GA17031@len.workgroup> <56C894C8.8090102@gmx.at> <20160220201655.GA23370@len.workgroup> <56CAEE0F.1030305@gmx.at> Message-ID: <20160222120636.GA17674@len.workgroup> Hi Josef, * Josef Carnap [22. Feb. 2016]: > Am 20.02.2016 um 21:16 schrieb Gregor Zattler: >> * Josef Carnap [20. Feb. 2016]: >>> Am 20.02.2016 um 15:03 schrieb Gregor Zattler: >>>> * Josef Carnap [18. Feb. 2016]: >>>>> Ich bin mir nicht sicher, ob man das so angeben kann. Was geht >>>>> ist: >>>>> >>>>> group Vertrieb 16525F43 >>>>> group Vertrieb A072CBE3 >>>>> group Vertrieb 65FAF513 >>>>> group Vertrieb EC68571D >> Mein fehler: Da gehört ein "=" Zeichen ein. > OK, danke, habe ich nun reingegeben. > > Ich habe folgende Zeilen in der gpg.conf probiert (die Option in jeweils > einer Zeile verwendet, kein Zeilenumbruch): Tja, probier's doch mal mit Zeilenumbruch. Die Option ist dazu da, einen Gruppennamen mit einem Schlüssel zu verbinden. Ich habe noch nie gesehen, dass man solche Optionen einfach mehrfach hintereinander in eine Zeile schreibt. Meistens sind die Formate von Konfigurationsdateien zeilenorientiert. [...] > Mich irritiert Folgendes: Folgende Kommandos funktionieren einwandfrei: > > gpg2 --recipient 25B4F1D4 --armor --output E:/GnuPG/neu5/"Wichtige > Textdatei 19.txt.asc" --encrypt E:/GnuPG/"Wichtige Textdatei 19.txt" Naja, der Key ist da, die group funktioniert nicht. [...] > # Tests der group-Option: > #======================== > #Vertrieb=0FB4393 Vertrieb=65354C1 Vertrieb=EC68571D" --> geht nicht > #goup name="Vertrieb=C537BCF7 Vertrieb=0FB4393 Vertrieb=65354C1 > Vertrieb=EC68571D" --> geht nicht > #group Vertrieb="16525F43 A072CBE3 65FAF513 EC68571D" --> geht nicht > #group Vertrieb=16525F43 Vertrieb=A072CBE3 Vertrieb=65FAF513 > Vertrieb=EC68571D --> geht nicht Versuch's dochj mal minimalistisch mit einer Datei mit zwei Zeilen: group Vertrieb=245A2676 group Vertrieb=DA0D42EF und sonst nichts, auch keine Kommentare. Dann kannst Du die Fehlermeldung klarer den angegebenen Zeilen zurodnen. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- From carnap at gmx.at Mon Feb 22 17:26:37 2016 From: carnap at gmx.at (Josef Carnap) Date: Mon, 22 Feb 2016 17:26:37 +0100 Subject: Fragen zur Option --group Message-ID: <56CB36BD.3030501@gmx.at> Besten Dank Gregor! Ich hatte leider einen Fehler in meiner Konfigurationsdatei. Für alle, die es interessiert: Folgende Einträge in der Konfigurationsdatei definieren eine Gruppe namens "Vertrieb": group Vertrieb=25B4F1D4 group Vertrieb=DA0D42EF group Vertrieb=80A035C7 group Vertrieb=304081B6 --- group Vertrieb=0x25B4F1D4 group Vertrieb=0xDA0D42EF group Vertrieb=0x80A035C7 group Vertrieb=0x304081B6 --- group Vertrieb=FF456430841793627794A925FF89857E25B4F1D4 group Vertrieb=356EE781EE3C34C00D605BD075B39FCADA0D42EF group Vertrieb=FACB7B6434FAED3327AB3FD2E65CBADE80A035C7 group Vertrieb=1BCCC50730E8A1D3924AD0975D2509ED304081B6 Alle Einträge funktionieren: Die mit Short-, mit Long-ID und die mit Fingerabdruck. Jeweils mit und ohne 0x-Präfix. Wichtig: Weder vor noch nach dem "=" darf sich ein Leerzeichen befinden. Danke nochmals für die Geduld. Josef From c.kremsmayr at gmx.net Mon Feb 22 17:53:41 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Mon, 22 Feb 2016 17:53:41 +0100 Subject: =?UTF-8?Q?Frage_zum_L=c3=b6schen/Widerrufen_von_Unterschl=c3=bcssel?= =?UTF-8?Q?n=3f?= Message-ID: <56CB3D15.5080703@gmx.net> Die Sache mit dem Widerrufen ist mir noch nicht klar: Angenommen, mein Unterschlüssel zum Signieren (Daten) und Ver- und Entschlüsseln ist kompromittiert. Lösche ich da den kompromittierten Schlüssel oder widerrufe ich ihn nur? Ich nehme an: nur widerrufen, damit ich ihn weiterhin zum Entschlüsseln von Nachrichten verwenden kann, korrekt? Und löschen tu ich ihn, wenn ich ganz sicher bin, dass ich ihn nie mehr benötigen werde? Was ist eigentlich, wenn der Unterschlüssel bereits auf einen Keyserver hochgeladen wurde? Nützt da das Löschen überhaupt etwas? Wenn ich den US lösche und dann den ganzen Key erneut hochlade --> ist dann der US auch auf dem Keysrrver gelöscht oder ergibt das Löschen nur dann einen Sinn, wenn man keine Keyserver benutzt? Ich will das nicht testen, weil ich derzeit noch nicht mit Keyservern arbeite und ich die Server nicht mit Testschlüsseln vollmüllen will. Christine From telegraph at gmx.net Mon Feb 22 18:04:20 2016 From: telegraph at gmx.net (Gregor Zattler) Date: Mon, 22 Feb 2016 18:04:20 +0100 Subject: FRage zu Widerruf-Zertifikaten In-Reply-To: <56CAE058.60901@gmx.net> References: <56CAE058.60901@gmx.net> Message-ID: <20160222170420.GB17674@len.workgroup> Hi Christine, * Christine Kremsmayr [22. Feb. 2016]: > 1. So wie ich die Sache verstehe, ist das Erstellen eines > Widerruf-Zertifikates eigentlich nur dann zweckmäßig, wenn der zu > widerrufende Schlüssel auf einem Keyserver liegt. Wenn ich > verschlüsselte Kommunikation in einem geschlossenen Benutzergruppe > betreibe, bringt mir ein Widerruf-Zertifikat nicht -- ist das korrekt so? Nicht ganz, denn: > Ich muss dann halt alle meine Kommunikationspartner anschreiben und sie > bitten, den alten öffentlichen Schlüssel nicht mehr zu benutzen und > stattdessen einen neuen öffentlichen Schlüssel verteilen und die > Komm.partner bitten, den neuen öffentlichen Schlüssel zu importieren und > zu nutzen. Richtig? Es ist richtig, dass Deine Kommunikationspartner den neuen Schlüssel importieren müssen, sie müssen aber auch den alten künftig ignorieren. Sie sollten ihn nicht löschen, weil sie damit alte Signaturen prüfen können. Sie könnten ihn auch selbst disablen, aber wer weiß schon wie das geht? Wenn sie hingegen das Widerrufzertifikat importieren (wie einen Schlüssel), dann wird der Key disabled und bei der Auswahl eines Verschlüsselungskeys künftig nicht angezeigt. > 2. Noch eine Frage: Mit dem Erstellen des Widerruf-Zertifikates > (--gen-revoke) passiert vorerst einmal gar nichts, solange ich das > W-Zertifikat nicht auf déinen Schlüsselserver hochlade -- ist das korrekt? Genau, solange niemand das Widerrufzertifikat kriegt, passiert nichts. > 3. Wie ändert man den Widerruf-Grund eines W-Zertifikates? Einfach ein > neues mit dem passenden Grund erstellen oder kann man ein vorhandenes > wirklich bearbeiten (ich habe dazu nichts gefunden)? Keine Ahnung. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- From telegraph at gmx.net Mon Feb 22 18:12:46 2016 From: telegraph at gmx.net (Gregor Zattler) Date: Mon, 22 Feb 2016 18:12:46 +0100 Subject: Frage zum =?iso-8859-1?B?TPZzY2hlbi9X?= =?iso-8859-1?Q?iderrufen_von_Unterschl=FCsseln=3F?= In-Reply-To: <56CB3D15.5080703@gmx.net> References: <56CB3D15.5080703@gmx.net> Message-ID: <20160222171246.GC17674@len.workgroup> Hi Christine, * Christine Kremsmayr [22. Feb. 2016]: > Die Sache mit dem Widerrufen ist mir noch nicht klar: Angenommen, mein > Unterschlüssel zum Signieren (Daten) und Ver- und Entschlüsseln ist > kompromittiert. > Lösche ich da den kompromittierten Schlüssel oder widerrufe ich ihn nur? Widerrufen. Du brauchst ihn noch, um alte Daten aus Deinem Archiv zu entschlüsseln. > Ich nehme an: nur widerrufen, damit ich ihn weiterhin zum Entschlüsseln > von Nachrichten verwenden kann, korrekt? Genau. > Und löschen tu ich ihn, wenn ich ganz sicher bin, dass ich ihn nie mehr > benötigen werde? Ja, was Du nie wirklich sein kannst, wenn Du den öffentlichen Schlüssel mal rausgegeben hast. > Was ist eigentlich, wenn der Unterschlüssel bereits auf einen Keyserver > hochgeladen wurde? Nützt da das Löschen überhaupt etwas? Wenn ich den US > lösche und dann den ganzen Key erneut hochlade --> ist dann der US auch > auf dem Keysrrver gelöscht Nein. Keyserver arbeiten immer nur additiv, weil es gegenüber den Keyservern keine Authentifizierung gibt, kannst Du Dich nicht als diejenige ausweisen, die berechtigt ist, den Schlüssel (oder Teile) zu löschen. . > oder ergibt das Löschen nur dann einen Sinn, wenn man keine > Keyserver benutzt? Wenn der "Sinn" darin bestehen soll, dass der Key nicht mehr verwandt werden kann, dann gilt: Wenn Du -- egal wie -- den Schlüssel verbreitet hast, musst Du um sicher zu gehen, alle Kopien des Schlüssels löschen. Das klappt selbst dann nicht, wenn Du ihn mir direkt gegeben hast, weil Du mich nicht zwingen kannst ihn zu löschen oder nicht sicher sein kannst, dass ich ihn nicht bereits weitergegeben habe. Wenn ein Key erst mal rausgegeben ist, muss man damit rechnen, dass er auch benutzt wird. Ciao; Gregor From c.kremsmayr at gmx.net Mon Feb 22 18:29:37 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Mon, 22 Feb 2016 18:29:37 +0100 Subject: Frage zu Widerruf-Zertifikaten In-Reply-To: <20160222170420.GB17674@len.workgroup> References: <56CAE058.60901@gmx.net> <20160222170420.GB17674@len.workgroup> Message-ID: <56CB4581.7060403@gmx.net> Hi Gregor, Am 22.02.2016 um 18:04 schrieb Gregor Zattler: > Hi Christine, > * Christine Kremsmayr [22. Feb. 2016]: > > Es ist richtig, dass Deine Kommunikationspartner den neuen > Schlüssel importieren müssen, sie müssen aber auch den alten > künftig ignorieren. Sie sollten ihn nicht löschen, weil sie > damit alte Signaturen prüfen können. OK, das hätte ich aber wissen müssen, immer wieder übersehe ich was ganz Wichtiges. Danke für den HInweis! > Sie könnten ihn auch selbst > disablen, aber wer weiß schon wie das geht? gpg2 --edit-key --> disable Ich habs aber bisher nur bei eigenen Schlüsseln versucht, ich weiß nicht, ob ich dazu einen priv. Schlüssel benötige; muss ich mir auch noch ansehen ... > Wenn sie hingegen > das Widerrufzertifikat importieren (wie einen Schlüssel), dann > wird der Key disabled und bei der Auswahl eines > Verschlüsselungskeys künftig nicht angezeigt. Aha, dieses Info-Stück hat mir gefehlt. Ich dachte immer, das funktioniert nur dann, wenn man das Widerruf-Zertifikat auf den Keyserver hochlädt. Wieder was gelernt :-) > >> 2. Noch eine Frage: Mit dem Erstellen des Widerruf-Zertifikates >> (--gen-revoke) passiert vorerst einmal gar nichts, solange ich das >> W-Zertifikat nicht auf déinen Schlüsselserver hochlade -- ist das korrekt? > Genau, solange niemand das Widerrufzertifikat kriegt, passiert > nichts. > > Danke! Große Klarheit deine Antworten! Christine From c.kremsmayr at gmx.net Mon Feb 22 18:35:49 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Mon, 22 Feb 2016 18:35:49 +0100 Subject: Frage zu Widerruf-Zertifikaten In-Reply-To: <56CB4581.7060403@gmx.net> References: <56CAE058.60901@gmx.net> <20160222170420.GB17674@len.workgroup> <56CB4581.7060403@gmx.net> Message-ID: <56CB46F5.2040501@gmx.net> Am 22.02.2016 um 18:29 schrieb Christine Kremsmayr: > gpg2 --edit-key --> disable > > Ich habs aber bisher nur bei eigenen Schlüsseln versucht, ich weiß > nicht, ob ich dazu einen priv. Schlüssel benötige; muss ich mir auch > noch ansehen ... Ja, es geht auch bei Fremdschlüsseln, soeben versucht. Christine From telegraph at gmx.net Mon Feb 22 18:42:42 2016 From: telegraph at gmx.net (Gregor Zattler) Date: Mon, 22 Feb 2016 18:42:42 +0100 Subject: Frage zu Widerruf-Zertifikaten In-Reply-To: <56CB4581.7060403@gmx.net> References: <56CAE058.60901@gmx.net> <20160222170420.GB17674@len.workgroup> <56CB4581.7060403@gmx.net> Message-ID: <20160222174242.GD17674@len.workgroup> Hi Christine, * Christine Kremsmayr [22. Feb. 2016]: > Am 22.02.2016 um 18:04 schrieb Gregor Zattler: >> Sie könnten ihn auch selbst >> disablen, aber wer weiß schon wie das geht? > gpg2 --edit-key --> disable Ich hatte gar nicht in Zweifel gezogen, dass Du das nicht weßt oder rauskriegst, nachdem Du Dich ja gerade intensiv mit den command line Kommandos und Optionen von GnuPG beschäftigst. Es ging mir vielmehr um die praktische Handhabung: Die allermeisten Leute, die ich kenne, die gpg benutzen tun das durch enigmail (und kennen auch das nicht wirklich gründlich) und wüssten nicht, wie sie einen Kommandozeilenaufruf machen sollten. Ich schloss von mir auf Dich und nahm an, dass Deine KorrespondenzpartnerInnen auch nicht alle HelInnen der Kommandozeile sind. Ciao; Gregor From ml.throttle at xoxy.net Mon Feb 22 21:10:43 2016 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Mon, 22 Feb 2016 21:10:43 +0100 Subject: FRage zu Widerruf-Zertifikaten In-Reply-To: <56CAE058.60901@gmx.net> (Christine Kremsmayr's message of "Mon, 22 Feb 2016 11:18:00 +0100") References: <56C59190.1010709@gmx.at> <20160220140313.GA17031@len.workgroup> <56C894C8.8090102@gmx.at> <20160220201655.GA23370@len.workgroup> <56CAE058.60901@gmx.net> Message-ID: <87twl0a4ki.fsf@helmutwaitzmann.news.arcor.de> Christine Kremsmayr : > 1. So wie ich die Sache verstehe, ist das Erstellen eines > Widerruf-Zertifikates eigentlich nur dann zweckmäßig, wenn der zu > widerrufende Schlüssel auf einem Keyserver liegt. Wenn ich > verschlüsselte Kommunikation in einem geschlossenen Benutzergruppe > betreibe, bringt mir ein Widerruf-Zertifikat nicht -- ist das korrekt so? Es kann bereits dann etwas bringen, wenn Du einen geschlossenen Benutzerkreis hast. Du schreibst ja: > Ich muss dann halt alle meine Kommunikationspartner anschreiben und sie > bitten, den alten öffentlichen Schlüssel nicht mehr zu benutzen und > stattdessen einen neuen öffentlichen Schlüssel verteilen und die > Komm.partner bitten, den neuen öffentlichen Schlüssel zu importieren und > zu nutzen. Richtig? Solange Du zu dem öffentlichen Schlüssel, den Du widerrufen möchtest, den privaten hast, kannst Du jederzeit an alle Deine Kommunikationspartner eine signierte Nachricht schicken, in der genau das drinsteht, was Du oben schreibst; und Du brauchst dazu kein Widerrufzertifikat. Anders sieht es aus, wenn Du Deinen Schlüssel widerrufen willst, weil Dir der private abhanden gekommen ist (Festplatte kaputt und kein Backup vorhanden, Passphrase vergessen). Dann ist guter Rat teuer: Damit Deine Kommunikationspartner Dir glauben, müsstest Du die oben ganannte Nachricht unterschreiben – und das kannst Du ohne den privaten Schlüssel nicht! Die Nachricht einfach unsigniert zu verschicken, ist nicht sehr sinnvoll: Da könnte ja jeder kommen und in Deinem Namen eine unsignierte Nachricht an Deine Kommunikationspartner schicken. Wenn Deine Partner der unsignierten Nachricht nun glaubten, wäre Dein Web of Trust zerrissen. Deshalb sind sie gut beraten, einer unsignierten Nachricht von Dir nicht zu glauben. Alles, was Du dann noch tun könntest, wäre, Deine Partner zu besuchen und es ihnen direkt zu sagen. Also: Ein Widerrufzertifikat ist so gut wie eine „vorbeugend“ geschriebene signierte Nachricht, in der Du mitteilst, dass man Deinen Schlüssel nicht mehr verwenden soll. Deswegen empfiehlt es sich, es geheim zu halten: Denn, wer es hat, kann Deinen Schlüssel zwar nicht kompromittieren (d. h. sich als Dich ausgeben), aber widerrufen, also Dein Web of Trust zerreißen. Helmut From k.hofmann81 at web.de Wed Feb 24 15:16:16 2016 From: k.hofmann81 at web.de (Klara Hofmann) Date: Wed, 24 Feb 2016 15:16:16 +0100 Subject: Fragen zur Option --import-options Message-ID: <56CDBB30.2090202@web.de> Hallo, In der Beschreibung zur Option --import-options import-local-sigs Ist von einem Schlüsselbund-Schema die Rede. Was ist damit gemeint? In der Beschreibung zum Wert repair-pks-subkey-bug ist von einem Bug der Keyserver-Software die Rede. Existiert dieser Bug eigentlich noch? Oder ist dieser Options-Wert vielleicht schon obsolet? Meinem (recht neuen) Verständnis nach beziehen sich die Import-Optionen alle auf den Import von öffentlichen Schlüssel, ist das korrekt (bin mir nicht ganz sicher). Liebe Grüße From k.hofmann81 at web.de Wed Feb 24 15:23:38 2016 From: k.hofmann81 at web.de (Klara Hofmann) Date: Wed, 24 Feb 2016 15:23:38 +0100 Subject: Option --trust-model auto und direct Message-ID: <56CDBCEA.4010309@web.de> Hallo, Eine Frage zur Option --trust-model, Wert "auto": In der Beschreibung ist die Rede von einer internen Trust-DB. Was ist das für eine interne Trust-DB? Wo kann man darüber mehr erfahren? Oder sind vielleicht selbst programmierte Vertrauensdatenbanken mit eigenem Regelwerk für die Ermittlung der Gültigkeit der Schlüssel gemeint? Wert "direct": angenommen, ich möchte GnuPG ausschließlich in abgeschlossenen Benutzergruppen verwenden und auf das Web of Trust verzichten. Jeder Kommunikationspartner kennt jeden recht gut, und alle zertifizieren gegenseitig ihre Schlüssel . Ich nehme an, da verwenden die User am besten die Option so: --trust-model direct --> korrekt? Wenn ich die Doku richtig verstanden habe, errechnet sich dann die Gültigkeit eines importierten Fremdschlüssels nur noch daraus, dass er ein Zertifikat (Schlüssel-Signatur) von meinem Schlüssel besitzt, der seinerseits den Owenertrust-Wert ultimate besitzt. Die Vertrauensbeziehungen sind dann alle direct trust. IHabe ich daas verstanden? (Boah, das Web of Trust ist nicht einfach ...). Liebe Grüße From k.hofmann81 at web.de Wed Feb 24 15:26:15 2016 From: k.hofmann81 at web.de (Klara Hofmann) Date: Wed, 24 Feb 2016 15:26:15 +0100 Subject: Option --default-recipient-self Message-ID: <56CDBD87.6030501@web.de> Hallo, Eine Frage zur Option --default-recipient-self: Irgendwie verstehe ich die Beschreibung der Option, andererseits werde ich aus der Option immer noch nicht schlau. Mit --recipient lege ich ja den/die Fremdschlüssel fest, mit denen verschlüsselt wird. Mit --encrypt-to bzw. --hidden-encrypt-to lege ich meinen eigenen Schlüssel fest, mit dem zusätzlich verschlüsselt wird, damit ich die verschlüsselten Daten, die ich verschicke, jederzeit entschlüsseln kann. Wozu ist dann --default-recipient-self da? Falls ich --recipient auf der Kommandozeile vergesse? Weiß jemand vielleicht einen griffigen Anwendungsfall für diese Option? Beschreibung im Manual: --default-recipient-self Use the default key as default recipient if option --recipient is not used and don’t ask if this is a valid one. The default key is the first one from the secret keyring or the one set with --default-key. Liebe Grüße From malte at wk3.org Wed Feb 24 16:57:22 2016 From: malte at wk3.org (Malte) Date: Wed, 24 Feb 2016 16:57:22 +0100 Subject: Option --default-recipient-self In-Reply-To: <56CDBD87.6030501@web.de> References: <56CDBD87.6030501@web.de> Message-ID: <1872407.kKeJcbPUv3@localhost> Hi, wenn ich es richtig verstehe, ist der einzige Unterschied, dass du bei -- encrypt-to noch explizit die Schlüssel-ID mit angeben musst (bzw. auch eine völlig beliebige angeben kannst), und --default-recipient-self den Default-Key (in der Regel dein einer eigener) nimmt. Liebe Grüße, Malte -- 1BEA 8159 A070 2E53 0152 A59F 0CC5 76E9 703E 1DDC From ml.throttle at xoxy.net Thu Feb 25 20:40:13 2016 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Thu, 25 Feb 2016 20:40:13 +0100 Subject: Option --default-recipient-self In-Reply-To: <56CDBD87.6030501@web.de> (Klara Hofmann's message of "Wed, 24 Feb 2016 15:26:15 +0100") References: <56CDBD87.6030501@web.de> Message-ID: <87k2ls7f48.fsf@helmutwaitzmann.news.arcor.de> Klara Hofmann : > Eine Frage zur Option --default-recipient-self: Irgendwie verstehe ich > die Beschreibung der Option, andererseits werde ich aus der > Option immer noch nicht schlau. > > Mit --recipient lege ich ja den/die Fremdschlüssel fest, mit denen > verschlüsselt wird. ja, die Schlüssel der Empfänger, die die Daten lesen können sollen. Wenn man „--(hidden-)recipient“ nicht angibt, fragt Gnupg danach, sofern man nicht „--default-recipient“ oder „--default-recipient-self“ verwendet. Das Mailerprogramm, beispielsweise Thunderbird, hat also zwei Möglichkeiten, Gnupg mitzuteilen, für welche Empfänger verschlüsselt werden soll: Entweder nutzt es „--(hidden-)recipient“ oder beantwortet Gnupgs Frage. Welche Möglichkeit es nutzt, weiß ich nicht. > Mit --encrypt-to bzw. --hidden-encrypt-to lege ich meinen > eigenen Schlüssel fest, mit dem zusätzlich verschlüsselt wird, > damit ich die verschlüsselten Daten, die ich verschicke, > jederzeit entschlüsseln kann. Genau. Und das Geschickte daran: Ich schreibe hidden-encrypt-to mein_User‐Id oder encrypt-to mein_User‐Id in die Gnupg‐Konfigurationsdatei hinein. Dann muss Thunderbird nicht einmal wissen, welcher mein Schlüssel ist. Gnupg sorgt auf diese Weise ganz von selbst dafür, dass ich verschickte Nachrichten auch selber lesen kann. Gnupg ist (zumindest in der UNIX‐Welt, ich vermute aber auch, unter MS‐Windows) direkt als interaktives Programm, gestartet von der Kommandozeile, verwendbar: Ich kann es also pur, ohne Thunderbird, verwenden, um Dateien zu verschlüsseln. Auch da muss ich dann „--(hidden-)recipient“ verwenden oder Gnupgs Fragen beantworten, wie Thunderbird auch. Wenn ich beispielsweise eine Datei so verschlüsseln wollte, dass nur ich sie lesen kann, müsste ich in der Kommandozeile gpg --recipient mein_User‐Id --encrypt -- zu_verschlüsselnde_Datei starten. Jedes Mal hier mein_User‐Id eintippen zu müssen, ist umständlich. Dass ich es schon längst in der Gnupg‐Konfigurationsdatei mit „--(hidden-)encrypt-to“ angegeben habe, nützt mir da nichts. Aus dem Manual: `--encrypt-to `name'' Same as `--recipient' but this one is intended for use in the options file and may be used with your own user-id as an "encrypt-to-self". These keys are only used when there are other recipients given either by use of `--recipient' or by the asked user id. No trust checking is performed for these user ids and even disabled keys can be used. `--hidden-encrypt-to `name'' Same as `--hidden-recipient' but this one is intended for use in the options file and may be used with your own user-id as a hidden "encrypt-to-self". These keys are only used when there are other recipients given either by use of `--recipient' or by the asked user id. No trust checking is performed for these user ids and even disabled keys can be used. Die werden von Gnupg also nur beachtet, wenn ich „--(hidden-)recipient“ angegeben habe, oder Gnupgs Frage nach User‐Ids beantworte. > Wozu ist dann --default-recipient-self da? Genau für diesen Fall. Ich hole ein bisschen aus. Aus dem Manual: `--default-recipient NAME' Use NAME as default recipient if option `--recipient' is not used Ich könnte also default-recipient mein_User‐Id in die Gnupg‐Konfigurationsdatei hineinschreiben. Dann fragt Gnupg nicht nach, wenn keine weiteren User‐Ids mit „--(hidden-)recipient“ angegeben werden, sondern verwendet einfach dieses. Allerdings hat das dann den Nachteil, dass Gnupg dann mich (oder auch Thunderbird) nie nach User‐Ids fragt, selbst wenn ich es wollte. Daher ist es vielleicht besser, das nicht in die Konfigurationsdatei reinzuschreiben, sondern nur als Option beim Gnupg‐Start zu verwenden. Allerdings ist das dann auch nicht weniger umständlich, als --(hidden-)recipient mein_User‐Id zu verwenden. Aber es gibt noch eine andere Möglichkeit, um viel Umstand in der Kommandozeile herumzukommen. Dazu muss ich nochmal ausholen: Im Manual steht: `--default-key NAME' Use NAME as the default key to sign with. If this option is not used, the default key is the first key found in the secret keyring. Note that `-u' or `--local-user' overrides this option. Mit default-key mein_User‐Id in der Gnupg‐Konfigurationsdatei gebe ich Gnupg meinen (Signier‐)schlüssel bekannt. Und es ist auch geeignet für „--default-recipient-self“: > Beschreibung im Manual: > --default-recipient-self > Use the default key as default recipient if option --recipient is not > used and don’t ask if this is a > valid one. The default key is the first one from the secret keyring or > the one set with --default-key. Im Zusammenspiel mit „--default-key mein_User‐Id“ ist „--default-recipient-self“ dasselbe wie „--default-recipient mein_User‐Id“ und ist für den Fall geeignet, dass dieser Schlüssel, den man bei „--default-recipient“ angeben will, der eigene ist: Ich gebe Gnupg in der Konfigurationsdatei mit „default-key“ meinen Schlüssel bekannt. Jetzt kann ich mit „--default-recipient-self“ Daten für mich verschlüsseln, ohne nochmals mit „--default-recipient“ irgend einen Empfängerschlüssel angeben zu müssen: gpg --default-recipient-self --encrypt -- zu_verschlüsselnde_Datei Nochmal zusammengefasst: Beim Verschlüsseln fragt mich Gnupg nach Empfänger‐User‐Ids, wenn ich weder „--(hidden-)recipient“ noch „--default-recipient NAME“ oder „--default-recipient-self“ angebe. „--hidden-encrypt-to NAME“ und „--encrypt-to NAME“ werden von Gnupg nur beachtet, wenn ich andere Empfänger mit „--recipient“ oder „--hidden-recipient“ angebe. „--default-recipient NAME“ und „--default-recipient-self“ ändern daran nichts. „--default-recipient NAME“ und „--default-recipient-self“ werden von Gnupg nur beachtet, wenn ich keine anderen Empfänger mit „--recipient“ oder „--hidden-recipient“ angebe. „--hidden-encrypt-to NAME“ und „--encrypt-to NAME“ ändern daran nichts. Also gehe ich so vor: In die Gnupg‐Konfigurationsdatei schreibe ich die Zeilen „encrypt-to “ oder „hidden-encrypt-to “ und die Zeile „default-key “ , wobei ich für „“ das Fingerprint meines Hauptschlüssels hinschreibe. Wenn ich jetzt Gnupg in der Kommandozeile verwenden will, um Daten für mich zu verschlüsseln, muss ich nur gpg --default-recipient-self --encrypt -- zu_verschlüsselnde_Datei schreiben. Ich muss weder mein User‐Id in die Kommandozeile stellen, noch Gnupg Fragen beantworten. From ml.throttle at xoxy.net Thu Feb 25 22:16:52 2016 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Thu, 25 Feb 2016 22:16:52 +0100 Subject: Fragen zur Option --import-options In-Reply-To: <56CDBB30.2090202@web.de> (Klara Hofmann's message of "Wed, 24 Feb 2016 15:16:16 +0100") References: <56CDBB30.2090202@web.de> Message-ID: <87fuwg7an5.fsf@helmutwaitzmann.news.arcor.de> Klara Hofmann : > In der Beschreibung zur Option --import-options import-local-sigs Ist > von einem Schlüsselbund-Schema > die Rede. Was ist damit gemeint? Ja, von einem „shared keyring scheme“ ist die Rede. Ich vermute, auf Deutsch nicht „verteiltes Schlüsselringschema“ sondern „Schema mit verteiltem Schlüsselring“, also eine Art, einen Schlüsselring zu verwenden, bei der mehrere Personen einen Schlüsselring gemeinsam benutzen. Eine nicht‐lokale sondern „normale“ Signatur (eigentlich eher ein Zertifikat, denn es geht hier um das Unterschreiben anderer Leute Schlüssel) ist eine Beglaubigung, die jemand an einem öffentlichen Schlüssel einer anderen Person anbringt, um seinem GnuPG und der ganzen Welt mitzuteilen: Ich weiß, dass derjenige, dessen User‐Id ich unterschrieben habe, wirklich so heißt, und, dass die E‐Mail‐Adresse, die er angegeben hat, wirklich seine ist. Außerdem weiß ich, dass der Schlüssel, an dem das User‐Id hängt, sein Schlüssel ist. Beispiel: Anne möchte Bernds Schlüssel beglaubigen. Dazu trifft sie sich mit ihm. Bernd bringt ausgedruckt das User‐Id „Bernd Mustermann “ und das Fingerprint seines Schlüssels und außerdem seinen Personalausweis mit. Dann lässt sich Anne den Personalausweis zeigen und nimmt das User‐Id und das Fingerprint in Empfang. Zuhause lädt sie sich Bernds Schlüssel anhand des Fingerprints von einem Schlüsselserver herunter und unterschreibt das User‐Id „Bernd Mustermann “ an Bernds Schlüssel, das den Namen, der auf dem Personalausweis stand, und die E‐Mail‐Adresse, die Bernd ihr gegeben hat, enthält. Dann schickt sie Bernd den so zertifizierten Schlüssel zurück, damit er ihn auf den Schlüsselserver hochlädt (oder sie lädt ihn selber auf den Schlüsselserver hoch). So teilt sie ihrem GnuPG und der ganzen Welt mit: Ich bestätige, dass Bernd Mustermann, dessen User‐Id ich unterschrieben habe, wirklich so heißt, und, dass die E‐Mail‐Adresse „“ wirklich seine ist. Außerdem bestätige ich, dass dieser Schlüssel sein Schlüssel ist. Nun könnte es sein, dass Anne, da sie sich mit Personalausweisen nicht auskennt, nicht entscheiden kann, ob der Personalausweis, den Bernd ihr gezeigt hat, gefälscht oder echt ist. Deshalb möchte sie auch nicht vor der ganzen Welt dafür geradestehen, dass sie Bernds Personalausweis geprüft hat und für echt hält. Das bedeutet: Sie darf Bernds Schlüssel nicht zertifizieren. Trotzdem möchte sie Bernds Schlüssel mit ihrem GnuPG verwenden. Damit Annes GnuPG Bernds Schlüssel anerkennt, braucht es aber Annes Zertifikat an Bernds Schlüssel. Was kann Anne tun? Sie beglaubigt Bernds Schlüssel mit einem lokalem Zertifikat. Dann ist ihr GnuPG zufrieden. Wenn sie Bernds Schlüssel exportiert, wird das lokale Zertifikat nicht mit exportiert, es sei denn, sie würde an ihrem GnuPG `--export-options `parameters'' This is a space or comma delimited string that gives options for exporting keys. Options can be prepended with a `no-' to give the opposite meaning. The options are: export-local-sigs Allow exporting key signatures marked as "local". This is not generally useful unless a shared keyring scheme is being used. Defaults to no. einstellen. Jetzt zur Anfangsfrage zurück: > In der Beschreibung zur Option --import-options > import-local-sigs Ist von einem Schlüsselbund-Schema die > Rede. Was ist damit gemeint? import-local-sigs Allow importing key signatures marked as "local". This is not generally useful unless a shared keyring scheme is being used. Defaults to no. Ich vermute, damit ist einfach gemeint: Wie verwendet Anne ihren Schlüsselring? Exportiert sie ihn auf einen anderen Rechner? Teilt sie ihn mit anderen Personen in ihrem engsten Umfeld? Je nachdem, wie sie export-local-sigs und import-local-sigs einstellt, wird dabei die lokale Signatur mit übertragen oder nicht. > In der Beschreibung zum Wert repair-pks-subkey-bug ist von einem Bug der > Keyserver-Software die Rede. Existiert dieser Bug eigentlich noch? Oder > ist dieser Options-Wert vielleicht schon obsolet? Soweit ich gelesen habe, gibt es längst Patches für die Software. Aber ich habe es nicht in der Hand, ob wirklich alle Schlüsselserverbetreiber ihren Server auf Vordermann gebracht haben. From ml.throttle at xoxy.net Fri Feb 26 01:41:01 2016 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Fri, 26 Feb 2016 01:41:01 +0100 Subject: Option --trust-model auto und direct In-Reply-To: <56CDBCEA.4010309@web.de> (Klara Hofmann's message of "Wed, 24 Feb 2016 15:23:38 +0100") References: <56CDBCEA.4010309@web.de> Message-ID: <87r3g05mmg.fsf@helmutwaitzmann.news.arcor.de> Klara Hofmann : > Eine Frage zur Option --trust-model, Wert "auto": > In der Beschreibung ist die Rede von einer internen Trust-DB. Was ist > das für eine interne Trust-DB? Sie ist in GnuPG eingebaut. GnuPG speichert darin das Maß an Sorgfalt, das ich Anderen beim Zertifizieren zutraue. Mit dem GnuPG‐Kommando „--edit-key“ „trust“ füttere ich die Datenbank. Im Beispiel nebenan (<87fuwg7an5.fsf at helmutwaitzmann.news.arcor.de>): Wenn ich Anne gut kenne und weiß, dass sie anderer Leute User‐Ids, beispielsweise Bernd Mustermanns, mit einem nicht‐lokalen Zertifikat nur dann versieht, wenn sie wirklich für alle Daten im User‐Id unter Eid geradestehen will, dann kann ich GnuPG mitteilen, dass es Annes Schlüssel vollständig vertrauen soll. > Wo kann man darüber mehr erfahren? Das frage ich mich auch. Vielleicht hilft weiter? > Wert "direct": angenommen, ich möchte GnuPG ausschließlich in > abgeschlossenen Benutzergruppen verwenden und auf das Web of Trust > verzichten. Jeder Kommunikationspartner kennt jeden recht gut, und alle > zertifizieren gegenseitig ihre Schlüssel . Ich nehme an, da verwenden > die User am besten die Option so: --trust-model direct --> korrekt? So verstehe ich das auch. > Wenn ich die Doku richtig verstanden habe, errechnet sich dann die > Gültigkeit eines importierten Fremdschlüssels nur noch daraus, dass er > ein Zertifikat (Schlüssel-Signatur) von meinem Schlüssel besitzt, der > seinerseits den Owenertrust-Wert ultimate besitzt. > Die Vertrauensbeziehungen sind dann alle direct trust. So verstehe ich das auch. Helmut From k.hofmann81 at web.de Fri Feb 26 09:40:57 2016 From: k.hofmann81 at web.de (Klara Hofmann) Date: Fri, 26 Feb 2016 09:40:57 +0100 Subject: Option --trust-model auto und direct In-Reply-To: <87r3g05mmg.fsf@helmutwaitzmann.news.arcor.de> References: <56CDBCEA.4010309@web.de> <87r3g05mmg.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <56D00F99.8020405@web.de> Am 26.02.2016 um 01:41 schrieb Helmut Waitzmann: > Klara Hofmann : > >> Eine Frage zur Option --trust-model, Wert "auto": >> In der Beschreibung ist die Rede von einer internen Trust-DB. Was ist >> das für eine interne Trust-DB? > Sie ist in GnuPG eingebaut. LOL, da habe ich zu kompliziert gedacht, es ist die "normale" Vertrauensdatenbank (trustdb.gpg) :-) Sry, mein Fehler. >> Wo kann man darüber mehr erfahren? > Das frage ich mich auch. Vielleicht hilft > weiter? Hauke Lagings Website ist da auch sehr explizit, finde ich. >> Wert "direct": angenommen, ich möchte GnuPG ausschließlich in >> abgeschlossenen Benutzergruppen verwenden und auf das Web of Trust >> verzichten. Jeder Kommunikationspartner kennt jeden recht gut, und alle >> zertifizieren gegenseitig ihre Schlüssel . Ich nehme an, da verwenden >> die User am besten die Option so: --trust-model direct --> korrekt? > So verstehe ich das auch. > >> Wenn ich die Doku richtig verstanden habe, errechnet sich dann die >> Gültigkeit eines importierten Fremdschlüssels nur noch daraus, dass er >> ein Zertifikat (Schlüssel-Signatur) von meinem Schlüssel besitzt, der >> seinerseits den Owenertrust-Wert ultimate besitzt. >> Die Vertrauensbeziehungen sind dann alle direct trust. > So verstehe ich das auch. > > Besten Dank für deine wie immer hilfreichen Antworten! Gruß Klara From k.hofmann81 at web.de Fri Feb 26 11:06:44 2016 From: k.hofmann81 at web.de (Klara Hofmann) Date: Fri, 26 Feb 2016 11:06:44 +0100 Subject: Option --default-recipient-self In-Reply-To: <87k2ls7f48.fsf@helmutwaitzmann.news.arcor.de> References: <56CDBD87.6030501@web.de> <87k2ls7f48.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <56D023B4.9010106@web.de> Hallo Helmut, wow, danke für die ausführliche Antwort! Ich muss jetzt denken ... und ausprobieren ... Gruß Klara From k.hofmann81 at web.de Fri Feb 26 11:16:35 2016 From: k.hofmann81 at web.de (Klara Hofmann) Date: Fri, 26 Feb 2016 11:16:35 +0100 Subject: Fragen zur Option --import-options In-Reply-To: <87fuwg7an5.fsf@helmutwaitzmann.news.arcor.de> References: <56CDBB30.2090202@web.de> <87fuwg7an5.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <56D02603.70809@web.de> Am 25.02.2016 um 22:16 schrieb Helmut Waitzmann: > Klara Hofmann : > >> In der Beschreibung zur Option --import-options import-local-sigs Ist >> von einem Schlüsselbund-Schema >> die Rede. Was ist damit gemeint? > Ja, von einem „shared keyring scheme“ ist die Rede. Ich vermute, > auf Deutsch nicht „verteiltes Schlüsselringschema“ sondern „Schema > mit verteiltem Schlüsselring“, also eine Art, einen Schlüsselring > zu verwenden, bei der mehrere Personen einen Schlüsselring > gemeinsam benutzen. Super, ich glaube, das ist die Antwort, nach der ich gesucht habe. > > Eine nicht‐lokale sondern „normale“ Signatur (eigentlich eher ein > Zertifikat, denn es geht hier um das Unterschreiben anderer Leute > Schlüssel) ist eine Beglaubigung, die jemand an einem öffentlichen > Schlüssel einer anderen Person anbringt, um seinem GnuPG und der > ganzen Welt mitzuteilen: Ich weiß, dass derjenige, dessen User‐Id > ich unterschrieben habe, wirklich so heißt, und, dass die > E‐Mail‐Adresse, die er angegeben hat, wirklich seine ist. > Außerdem weiß ich, dass der Schlüssel, an dem das User‐Id hängt, > sein Schlüssel ist. > > Beispiel: > > Anne möchte Bernds Schlüssel beglaubigen. Dazu trifft sie sich mit > ihm. Bernd bringt ausgedruckt das User‐Id > > „Bernd Mustermann “ > > und das Fingerprint seines Schlüssels und außerdem seinen > Personalausweis mit. > > Dann lässt sich Anne den Personalausweis zeigen und nimmt das > User‐Id und das Fingerprint in Empfang. > > Zuhause lädt sie sich Bernds Schlüssel anhand des Fingerprints von > einem Schlüsselserver herunter und unterschreibt das User‐Id > > „Bernd Mustermann “ > > an Bernds Schlüssel, das den Namen, der auf dem Personalausweis > stand, und die E‐Mail‐Adresse, die Bernd ihr gegeben hat, enthält. > > Dann schickt sie Bernd den so zertifizierten Schlüssel zurück, > damit er ihn auf den Schlüsselserver hochlädt (oder sie lädt ihn > selber auf den Schlüsselserver hoch). Ich hab einmal irgendwo gelesen, dass das einige Schlüsselbesitzer gar nicht wollen. Die laden lieber selbr hoch .. (angeblich; mich würde es derzeit nicht so stören ...) > > Nun könnte es sein, dass Anne, da sie sich mit Personalausweisen > nicht auskennt, nicht entscheiden kann, ob der Personalausweis, > den Bernd ihr gezeigt hat, gefälscht oder echt ist. Deshalb > möchte sie auch nicht vor der ganzen Welt dafür geradestehen, dass > sie Bernds Personalausweis geprüft hat und für echt hält. Das > bedeutet: Sie darf Bernds Schlüssel nicht zertifizieren. OK, das ist ein interessanter Anwendungsfall von lokalen Zertifikaten. Ich habe immer geschlossene Benutzergruppen im Sinn: Die treffen sich einmal und tauschen die Daten aus (Fingerprints, Benutzer-Kennungen, Ausweise etc.). Dann zertifizieren sie sich gegenseitig und verwenden vielleicht nicht einmal Keyserver. > Trotzdem möchte sie Bernds Schlüssel mit ihrem GnuPG verwenden. > > Damit Annes GnuPG Bernds Schlüssel anerkennt, braucht es aber > Annes Zertifikat an Bernds Schlüssel. Was kann Anne tun? Sie > beglaubigt Bernds Schlüssel mit einem lokalem Zertifikat. > Dann ist ihr GnuPG zufrieden. Wenn sie Bernds Schlüssel > exportiert, wird das lokale Zertifikat nicht > mit exportiert, es sei denn, sie würde an ihrem GnuPG > > `--export-options `parameters'' > This is a space or comma delimited string that gives > options for exporting keys. Options can be prepended with a > `no-' to give the opposite meaning. The options are: > > export-local-sigs > Allow exporting key signatures marked as "local". This > is not generally useful unless a shared keyring scheme > is being used. Defaults to no. > > einstellen. Soweit klar. > Jetzt zur Anfangsfrage zurück: > >> In der Beschreibung zur Option --import-options >> import-local-sigs Ist von einem Schlüsselbund-Schema die >> Rede. Was ist damit gemeint? > Ich vermute, damit ist einfach gemeint: Wie verwendet Anne ihren > Schlüsselring? Exportiert sie ihn auf einen anderen Rechner? > Teilt sie ihn mit anderen Personen in ihrem engsten Umfeld? > > Je nachdem, wie sie export-local-sigs und import-local-sigs > einstellt, wird dabei die lokale Signatur mit übertragen oder > nicht. OK. Ich stell mir das einmal wie einen zentralen Schlüsselbund für eine Support-Abteilung (z.B.) vor. Die Mitarbeiter zertifizieren alle lokal (nicht-exportierbar) oder sie tun das nur teilweise, exportieren und importieren dann aber trotzdem die lokalen Zertifikate. > >> In der Beschreibung zum Wert repair-pks-subkey-bug ist von einem Bug der >> Keyserver-Software die Rede. Existiert dieser Bug eigentlich noch? Oder >> ist dieser Options-Wert vielleicht schon obsolet? > Soweit ich gelesen habe, gibt es längst Patches für die Software. > Aber ich habe es nicht in der Hand, ob wirklich alle > Schlüsselserverbetreiber ihren Server auf Vordermann gebracht > haben. OK, danke; so was habe ich vermutet (aber nicht gewusst ;-) Liebe Grüße und danke nochmal. Klara From c.kremsmayr at gmx.net Sun Feb 28 13:25:43 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Sun, 28 Feb 2016 13:25:43 +0100 Subject: =?UTF-8?Q?Verst=c3=a4ndnisfrage_zum_Passwort-Mangling?= Message-ID: <56D2E747.7060802@gmx.net> Halli Liste, Ich abe nur ein sehr vages und unsicheres Verständnis der beiden Optionen --s2k-digest-algo und --s2k-mode, weil ich das Konzept hinter dem Verschlüsseln von privaten GnuPG-Schlüsseln nicht wirklich verstehe. Nach der Lektüre einiger Suchmaschinen-Treffer würde ich dieses Konzept so formulieren: Private GnuPG-Schlüssel werden im Schlüsselbund immer verschlüsselt gespeichert. Wie bei jeder symmetrischen Verschlüsselung benötigt der symmetrische Algorithmus (einstellbar mit --s2k-digest-algo) einen Schlüssel zur Verschlüsselung. GnuPG könnte nun einfach das vom Benutzer eingegebene Passwort als Schlüssel verwenden. Das hätte aber einen Nachteil: Die Bits des Passworts hängen miteinander zusammen; es ist keine zufällige Bitfolge. (Das eingegebene Passwort direkt als Schlüssel zu verwenden, könnte aber durch die Option --s2k-mode = 0 erzwungen werden.) Daher ist die tatsächliche Erzeugung des Schlüssels komplexer: 1. Dem vom Benutzer eingegebenen Passwort werden zuerst ein paar zufällige Bits ("Salt") hinzugefügt. Diese Zufallsbits werden zusammen mit dem Passwort gespeichert. Grund: Wenn nun ein anderer Benutzer aus demselben Passwort ebenfalls einen Hashwert bildet, kommt ein anderer Hashwert heraus, weil in diesem Fall auch ein neuer Salt verwendet wird. 2. Nun wird aus der Kombination aus Passwort und Zufallsbits ein Hashwert gebildet. Der Algorithmus kann mit --s2k-digest-algo gesteuert werden. 3. Nun wird der gebildete Hashwert durcheinandergewürfelt. 4. Das Ergebnis dieses "mangling" ist der symmetrische Schlüssel. Mit diesem wird der private GnuPG-Schlüssel verschlüsselt. Schritte 1 bis 3 bilden eine Iteration. Gegen das Knacken der Passphrase kann man sich mit einer hohen Anzahl an Iterationen schützen. Diese Anzahl kann durch die Option --s2k-count festgelegt werden. Mit --s2k-mode kann festgelegt werden, ob und wie das Durcheinanderwürfeln stattfindet: 0: Es wird überhaupt nicht gewürfelt, sondern das eingegebene Passwort als Schlüssel verwendet. Nicht empfehlenswert. 1: Zum Passwort wird eine zufällige Bitfolge hinzugefügt. Ist schon besser, trotzdem nicht empfehlenswert. 3: Defaultwert. Verhalten wie oben beschrieben. Auswertung der Option --s2k-count. Empfehlenswert. Habe ich verstanden, was eine Iteration ist, oder liege ich völlig daneben? Kennt jemand Erklärungen dieses Themas für GnuPG-Benutzer, die keine Entwickler sind? Liebe Grüße Christine From c.kremsmayr at gmx.net Sun Feb 28 13:52:25 2016 From: c.kremsmayr at gmx.net (Christine Kremsmayr) Date: Sun, 28 Feb 2016 13:52:25 +0100 Subject: Interpretation des Ergebnisses von --export-ownertrust Message-ID: <56D2ED89.6040403@gmx.net> Mit gpg2 --export-ownertrust kann ich die Werte des Vertrauensstatus (sog. "Besitzervertrauen") der öffentlichen Schlüssel anzeigen lassen. Wie aber interpretiere ich die Ziffern rechts vom Fingerabdruck? In meinem Fall erhalte ich diese Ausgabe: ----- C:\Users\ckr>gpg2 --export-ownertrust gpg: verwende Vertrauensmodell PGP # Liste der zugewiesenen Trustwerte, erzeugt am 02/28/16 13:42:21 Mitteleuropõische Zeit # ("gpg --import-ownertrust" um sie zu restaurieren) 356EE781EE3C34C00D605BD075B39FCADA0D42EF:3: 87441C8D5FA9D2D46F3CFE8FBD17F2430CE312D4:6: B59D9B8DA5895CF837844F4EC440EB6B86F0B249:6: C4C3767EFE9BF995431824EF6AD043812A4BF322:6: 3C41B1B124266AF139B902F24DC129B8831622ED:5: ----- Was bedeutet bitte 3? Was 6? Welche möglichen Ziffern können da angezeigt werden? Mir fehlt das Mapping zwischen den Ownertrust-Werten und den Ziffern. Mir sind nur folgende Ownertrust-Werte bekannt: Unbekannt --> 0? Kein Vertrauen --> 1? Marginales Vertrauen Vollständiges Vertrauen Absolutes Vertrauen Da komme ich nicht auf 6 mögliche Statuswerte. Liebe Grüße Christine