From mailinglist at doczkal.de  Mon Jan  4 19:30:22 2016
From: mailinglist at doczkal.de (Thomas Doczkal)
Date: Mon, 4 Jan 2016 19:30:22 +0100
Subject: =?UTF-8?Q?Re:_Signatur_=c3=bcber_mehrere_Dateien_erstellen?=
In-Reply-To: <56840005.40408@arcor.de>
References: <56840005.40408@arcor.de>
Message-ID: <568ABA3E.7040601@doczkal.de>

On 12/30/2015 05:02 PM, Günter Thaler wrote:
> gpg --detach-sign --output E:/GnuPG/neu/Gesamtsignatur.sig
> E:/GnuPG/neu/"Wichtige Textdatei 1.txt" "Wichtige Textdatei 2.txt"
> "Wichtige Textdatei 3.txt" "Wichtige Textdatei 4.txt"
Hallo Günter,

Ohne das ich mich mit Windows wirklich gut auskenne fällt mir auf, dass
du für die erste Datei den vollen Pfad angibst, die weiteren Dateien
aber relativ übergeben werden.
In welchem Ordner hast du dich befunden, als du die gpg-shell aufgemacht
hast?

Wenn du dich auf E:\ befindest, dann müsste dein Kommando in etwas so
aussehen.

gpg --detach-sign --output E:/GnuPG/neu/Gesamtsignatur.sig
E:/GnuPG/neu/"Wichtige Textdatei 1.txt" E:/GnuPG/neu/"Wichtige Textdatei 2.txt" E:/GnuPG/neu/"Wichtige Textdatei 3.txt" E:/GnuPG/neu/"Wichtige Textdatei 4.txt"

Hab leider gerade kein Windows zur Hand um meine Theorie zu bestätigen...

Viele Grüße
Thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20160104/16f20e52/attachment.sig>

From ml.throttle at xoxy.net  Tue Jan  5 07:00:19 2016
From: ml.throttle at xoxy.net (Helmut Waitzmann)
Date: Tue, 05 Jan 2016 07:00:19 +0100
Subject: Frage zu Mailinglisten
In-Reply-To: <201511241418.13984.bernhard@intevation.de> (Bernhard Reiter's
 message of "Tue, 24 Nov 2015 14:18:08 +0100")
References: <564DA08F.3040205@mtmedia.org>
 <21E88336-C772-45DF-937A-5F6F0C74CB22@freenet.de>
 <87wptdwa8h.fsf@helmutwaitzmann.news.arcor.de>
 <201511241418.13984.bernhard@intevation.de>
Message-ID: <87h9isr2eq.fsf@helmutwaitzmann.news.arcor.de>

Bernhard Reiter <bernhard at intevation.de> writes:
> On Friday 20 November 2015 at 05:44:04, Helmut Waitzmann 
> Anti-Spam-Ticket.a.pgab wrote:
>> Der Mailinglistenbetreiber einer privaten Mailingliste könnte auch
>> einen Schlüssel für die Mailingliste erstellen und bekanntgeben.
>
> Dann wäre es kein Ende-zu-Ende

Ob das gut oder schlecht wäre, hängt davon ab, ob dem
Listenbetreiber vertraut werden kann.

> und es ist das Problem zu lösen, wer auf der Liste zugelassen wird

Das hat der Listenbetreiber – wie bei allen unverschlüsselten
Mailinglisten auch – in der Hand, wenn er so vorgeht:  Er
akzeptiert nur Nachrichten, die mit Schlüsseln signiert sind,
deren öffentliches Gegenstück er in seiner
Teilnehmerschlüssel‐Datenbank findet; alle anderen Nachrichten
wirft er weg, ohne sie zu verteilen.

Wenn dem Listenbetreiber nicht vertraut werden kann, dass er die
Frage, wer zur Liste zugelassen ist, richtig beantwortet, muss die
Frage von jedem Listenteilnehmer selbst beantwortet werden, d. h.,
die Listenteilnehmer verwenden im Endeffekt keine Mailingliste,
sondern schicken die Nachrichten selber an alle gewünschten
Adressaten.  Frage:  Wie stimmen sich die Listenteilnehmer darüber
ab, wen sie als Teilnehmer zulassen wollen und wen nicht?

> und wie der geheime Schlüssel der Liste zu schützen ist.

Auch das ist Sache des Listenbetreibers.  Kein Listenteilnehmer
braucht den geheimen Schlüssel der Liste.  (Nur den öffentlichen
muss er kennen.)  Der Listenbetreiber kann den geheimen Schlüssel
der Liste so, wie jeden anderen geheimen Schlüssel auch, unter
Verschluss halten.

Oder zielt Deine Frage auf einen anderen Aspekt der
Schlüsselgeheimhaltung?

So, wie ich das verstehe, bleiben nur zwei Möglichkeiten:

* Die Liste wird zentral von einem Listenbetreiber verwaltet. Dann
  liegt es an ihm, zu entscheiden, wer an der Liste teilnehmen
  darf.  Das bedeutet, dass er auch entscheidet, mit welchen
  öffentlichen Listenteilnehmer‐Schlüsseln die Nachrichten, die
  von der Liste verteilt werden, verschlüsselt werden.

  Um das machen zu können, muss er jede Nachricht, die an die
  Liste geschickt wird, entschlüsseln und sie

  (1) entweder für jeden Listenteilnehmer einzeln mit dessen
      öffentlichem Schlüssel oder

  (2) für alle Listenteilnehmer gemeinsam mit den öffentlichen
      Schlüsseln aller Listenteilnehmer verschlüsseln.

  Im ersten Fall muss der Listenbetreiber jede Nachricht so oft
  verschicken, wie die Liste Teilnehmer hat.  Im zweiten Fall
  genügt es, wenn der Listenbetreiber jede Nachricht nur einmal an
  alle Teilnehmer gemeinsam verschickt.
  
  Die Signatur der Nachricht, die der Autor der Nachricht
  vorgenommen hat, kann in beiden Fällen erhalten bleiben.

  Damit der Listenbetreiber eine Nachricht, die an die Liste
  geschickt wird, entschlüsseln kann, muss sie (mindestens) auf
  den öffentlichen Schlüssel des Listenbetreibers verschlüsselt
  sein.

  Das ist natürlich keine Ende‐zu‐Ende‐Verschlüsselung, die direkt
  von jedem Listenteilnehmer zu jedem Listenteilnehmer reicht.
  
  Wenn man das nicht will (z. B. weil der Listenbetreiber nicht
  vertrauenswürdig ist), bleibt nur die dezentrale Form:

* Alle Teilnehmer verschlüsseln ihre Nachrichten für alle
  Teilnehmer der Liste.  Dann gibt es echte
  Ende‐zu‐Ende‐Verschlüsselung von jedem Teilnehmer zu jedem
  Teilnehmer.  Allerdings stellen sich dann weitere Fragen:

    Wie machen neue Listenteilnehmer den bisherigen Teilnehmern
    ihren öffentlichen Schlüssel bekannt?

    Woher erhalten neue Listenteilnehmer die öffentlichen
    Schlüssel der bisherigen Teilnehmer?

  Dieses Verfahren ist dann – was den Aspekt der Verschlüsselung
  angeht – nichts anderes, als das, was man hätte, wenn alle
  Listenteilnehmer ihre Nachrichten nicht an die Liste, sondern
  direkt an alle Listenteilnehmer addressieren würden, d. h., wenn
  keine Mailingliste verwendet würde.


From g.thaler at arcor.de  Tue Jan  5 17:35:32 2016
From: g.thaler at arcor.de (=?UTF-8?Q?G=c3=bcnter_Thaler?=)
Date: Tue, 5 Jan 2016 17:35:32 +0100
Subject: =?UTF-8?Q?Re:_Signatur_=c3=bcber_mehrere_Dateien_erstellen?=
In-Reply-To: <568ABA3E.7040601@doczkal.de>
References: <56840005.40408@arcor.de> <568ABA3E.7040601@doczkal.de>
Message-ID: <568BF0D4.8060209@arcor.de>

Hallo Thomas,

Am 04.01.2016 um 19:30 schrieb Thomas Doczkal:

> Ohne das ich mich mit Windows wirklich gut auskenne fällt mir auf, dass
> du für die erste Datei den vollen Pfad angibst, die weiteren Dateien
> aber relativ übergeben werden.

Genau das war der Fehler. Ich dachte, nach der ersten Datei braucht man
nur mehr die weiteren Dateinamen anzugeben, ein Fehlschluss.

Besten Dank!



From g.thaler at arcor.de  Mon Jan 18 10:22:10 2016
From: g.thaler at arcor.de (=?UTF-8?Q?G=c3=bcnter_Thaler?=)
Date: Mon, 18 Jan 2016 10:22:10 +0100
Subject: Frage zu --secret-keyring bzw. --keyring
Message-ID: <569CAEC2.7030108@arcor.de>

Hallo,

GnuPG-Version: GnuPG 2.0.29 (Gpg4win 2.3.0)

Frage zur option --secret-keyring: Aus dem GnuPG-Manual lese ich heraus, 
dass mit dieser Option und einem angegebenen Pfad mit Dateinamen ein 
neuer privater Schlüsselbund erstellt wird; analog mit --keyring ein 
öffentlicher Schlüsselbund.
Mir ist nur nicht klar, bei welchen Kommandos man diese Optionen 
sinnvollerweise nutzt.

Gruß Günter


From g.thaler at arcor.de  Mon Jan 18 10:31:39 2016
From: g.thaler at arcor.de (=?UTF-8?Q?G=c3=bcnter_Thaler?=)
Date: Mon, 18 Jan 2016 10:31:39 +0100
Subject: Frage zur Option --export-options export-attributes
Message-ID: <569CB0FB.6050409@arcor.de>

Hallo,

GnuPG 2.0.29

Option --export-options export-attributes: Das Manual sagt: Include 
attribute user IDs (photo IDs) while exporting. This is useful to export 
keys
if they are going to be used by an OpenPGP program that does not accept 
attribute user IDs. Defaults to yes.

Das verstehe ich nicht. Wenn das externe Zielprogramm Foto-IDs ohnedies 
nicht unterstzützt, weshalb ergibt es einen Sinn, beim Export des 
Schlüssels auch die Foto-IDs zu exportieren?
Ich nehme an, ich verstehe die Info nicht -- aber was genau verstehe ich 
nicht? Oder ist nur gemeint: Weil nur selten Schlüssel Foto-IDs 
besitzen, muss man die Option dann explizit verwenden, wenn man 
Foto-IDs  mitexportieren will?

Gruß Günter



From g.thaler at arcor.de  Mon Jan 18 19:05:58 2016
From: g.thaler at arcor.de (=?UTF-8?Q?G=c3=bcnter_Thaler?=)
Date: Mon, 18 Jan 2016 19:05:58 +0100
Subject: Benutzer-ID ohne E-Mail-Adresse
Message-ID: <569D2986.6050205@arcor.de>

Hallo,

mit der Option --allow-freeform-uids kann ich beim Erstellen eines
Schlüsselpaares oder beim Hinzufügen einer Benutzer-ID diese ohne
E-Mail-Adresse anlegen.

Ist zu befürchten, dass ich dann Probleme mit Kommunikationspartnern
habe, die ältere GnuPG-Versionen einsetzen?
Ist vielleicht5 bekannt, ob es Probleme mit Kommunikationspartnern gibt,
die PGP einsetzen?

Das Manual sagt: Disable all checks on the form of the user ID while
generating a new one. This option should only be used in very special
environments as it does not ensure the de-facto standard format of user IDs.

"All checks disabled": Bedeutet das: ich kann beliebige Zeichen in der
UID verwenden?

lg G


From telegraph at gmx.net  Tue Jan 19 00:51:19 2016
From: telegraph at gmx.net (Gregor Zattler)
Date: Tue, 19 Jan 2016 00:51:19 +0100
Subject: Frage zu --secret-keyring bzw. --keyring
In-Reply-To: <569CAEC2.7030108@arcor.de>
References: <569CAEC2.7030108@arcor.de>
Message-ID: <20160118235119.GC8738@len.workgroup>

Hi Günter,
* Günter Thaler <g.thaler at arcor.de> [18. Jan. 2016]:
> Frage zur option --secret-keyring: Aus dem GnuPG-Manual lese ich heraus,
> dass mit dieser Option und einem angegebenen Pfad mit Dateinamen ein neuer
> privater Schlüsselbund erstellt wird; analog mit --keyring ein öffentlicher
> Schlüsselbund.

Nicht notwendigerweise "erstellt", aber "benutzt".

> Mir ist nur nicht klar, bei welchen Kommandos man diese Optionen
> sinnvollerweise nutzt.

Normalerweise gar nicht.  Wenn Du z.B. was ausprobieren willst,
kann es sinnvoll sein zu diesem Zweck eigene Schlüsselringe
anzulegen, einen test zu machen und sie dann wieder zu löschen.
Otto Normalencryptor wird wahrscheinlich mit einem secring und
einem pubring auskommen.

Ich habe z. B. die von der Linux-Distribution Debian
ausgelieferten keyringe mit in meiner gnupg -Konfiguration
eingebunden (man kann die Optionen mehrmals anwenden), um deren
Web-of-Trust bei vertrauensbewertungen meiner Keys zu nutzen.

Ciao; Gregor 



From telegraph at gmx.net  Tue Jan 19 00:55:31 2016
From: telegraph at gmx.net (Gregor Zattler)
Date: Tue, 19 Jan 2016 00:55:31 +0100
Subject: Benutzer-ID ohne E-Mail-Adresse
In-Reply-To: <569D2986.6050205@arcor.de>
References: <569D2986.6050205@arcor.de>
Message-ID: <20160118235531.GD8738@len.workgroup>

Hi Günter,
* Günter Thaler <g.thaler at arcor.de> [18. Jan. 2016]:
> mit der Option --allow-freeform-uids kann ich beim Erstellen eines
> Schlüsselpaares oder beim Hinzufügen einer Benutzer-ID diese ohne
> E-Mail-Adresse anlegen.
> 
> Ist zu befürchten, dass ich dann Probleme mit Kommunikationspartnern
> habe, die ältere GnuPG-Versionen einsetzen?
> Ist vielleicht5 bekannt, ob es Probleme mit Kommunikationspartnern gibt,
> die PGP einsetzen?

Wenn Du den Schlüssel zur Kommunikation per E-Mail einsetzten
willst: Die GnupG-Integration im E-Mail-Programm Deine/r/s
KorrespondenzpartnerIn wird z. B. beim Verschlüsseln einer
Antwort auf eine E-Mail von Dir anhand der Empfängeradrresse der
E-Mail den richtigen Schlüssel auswählen wollen.  Wenn die dann
nicht am Schlüssel dran ist: Problem.

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




From g.thaler at arcor.de  Tue Jan 19 12:35:41 2016
From: g.thaler at arcor.de (=?UTF-8?Q?G=c3=bcnter_Thaler?=)
Date: Tue, 19 Jan 2016 12:35:41 +0100
Subject: Frage zu --secret-keyring bzw. --keyring
In-Reply-To: <20160118235119.GC8738@len.workgroup>
References: <569CAEC2.7030108@arcor.de> <20160118235119.GC8738@len.workgroup>
Message-ID: <569E1F8D.3060205@arcor.de>

Hi Gregor,

danke für die Antwort.

Am 19.01.2016 um 00:51 schrieb Gregor Zattler:
> Nicht notwendigerweise "erstellt", aber "benutzt". 
Aha, falls also bereits vorhanden, dann nur benutzt. Falls nicht 
vorhanden, zuerst erstellt + dann benutzt.
>> Mir ist nur nicht klar, bei welchen Kommandos man diese Optionen
>> sinnvollerweise nutzt.
> Normalerweise gar nicht.
[...]
OK, ich nehme an, die Option kann mit allen Kommandos benutzt werden, 
bei der ein Schlüssel ausgeweählt oder erstellt (wohin? --> in welchen 
Schlüsselbund?) wird.
> Ich habe z. B. die von der Linux-Distribution Debian
> ausgelieferten keyringe mit in meiner gnupg -Konfiguration
> eingebunden (man kann die Optionen mehrmals anwenden), um deren
> Web-of-Trust bei vertrauensbewertungen meiner Keys zu nutzen.
Gutes Anwendungsbeispiel, danke!

Gruß Günter


From g.thaler at arcor.de  Tue Jan 19 12:38:17 2016
From: g.thaler at arcor.de (=?UTF-8?Q?G=c3=bcnter_Thaler?=)
Date: Tue, 19 Jan 2016 12:38:17 +0100
Subject: Benutzer-ID ohne E-Mail-Adresse
In-Reply-To: <20160118235531.GD8738@len.workgroup>
References: <569D2986.6050205@arcor.de> <20160118235531.GD8738@len.workgroup>
Message-ID: <569E2029.6010602@arcor.de>

Am 19.01.2016 um 00:55 schrieb Gregor Zattler:
>
> Wenn Du den Schlüssel zur Kommunikation per E-Mail einsetzten
> willst: Die GnupG-Integration im E-Mail-Programm Deine/r/s
> KorrespondenzpartnerIn wird z. B. beim Verschlüsseln einer
> Antwort auf eine E-Mail von Dir anhand der Empfängeradrresse der
> E-Mail den richtigen Schlüssel auswählen wollen.  Wenn die dann
> nicht am Schlüssel dran ist: Problem.
Ui, das ist logisch, hätte ich wissen müssen. Da mich derzeit nur das 
Konsolenprogramm interessiert, habe ich daran gar nicht gedacht. Danke!

Gruß Günter


From telegraph at gmx.net  Tue Jan 19 12:56:57 2016
From: telegraph at gmx.net (Gregor Zattler)
Date: Tue, 19 Jan 2016 12:56:57 +0100
Subject: Frage zu --secret-keyring bzw. --keyring
In-Reply-To: <569E1F8D.3060205@arcor.de>
References: <569CAEC2.7030108@arcor.de> <20160118235119.GC8738@len.workgroup>
 <569E1F8D.3060205@arcor.de>
Message-ID: <20160119115657.GB17367@len.workgroup>

Hi Günter,
* Günter Thaler <g.thaler at arcor.de> [19. Jan. 2016]:
> Am 19.01.2016 um 00:51 schrieb Gregor Zattler:
>>Nicht notwendigerweise "erstellt", aber "benutzt".
> Aha, falls also bereits vorhanden, dann nur benutzt. Falls nicht vorhanden,
> zuerst erstellt + dann benutzt.
>>>Mir ist nur nicht klar, bei welchen Kommandos man diese Optionen
>>>sinnvollerweise nutzt.
>>Normalerweise gar nicht.
> [...]
> OK, ich nehme an, die Option kann mit allen Kommandos benutzt werden, bei
> der ein Schlüssel ausgeweählt oder erstellt (wohin? --> in welchen
> Schlüsselbund?) wird.

--primary-keyring bezeichnet den keyring, in den importierte keys
rein sollen.

Ciao; Gregor 



From ml.throttle at xoxy.net  Tue Jan 19 21:52:22 2016
From: ml.throttle at xoxy.net (Helmut Waitzmann)
Date: Tue, 19 Jan 2016 21:52:22 +0100
Subject: Frage zur Option --export-options export-attributes
In-Reply-To: <569CB0FB.6050409@arcor.de> (=?utf-8?Q?=22G=C3=BCnter?=
 Thaler"'s message of "Mon, 18 Jan 2016 10:31:39 +0100")
References: <569CB0FB.6050409@arcor.de>
Message-ID: <871t9d8f6n.fsf@helmutwaitzmann.news.arcor.de>

Günter Thaler <g.thaler at arcor.de> writes:
> GnuPG 2.0.29
>
> Option --export-options export-attributes: Das Manual sagt: Include
> attribute user IDs (photo IDs) while exporting. 

Ich nehme an, das Manual hat damit Recht (ohne es ausprobiert zu
haben).

> This is useful to export keys if they are going to be used by an
> OpenPGP program that does not accept attribute user
> IDs. 

Da stutze ich zunächst auch, vermute aber, das ist im Zusammenhang
mit dem einführenden Satz für alle bei »--export-options«
angebbaren Options zu sehen:

| Options can be prepended with a `no-' to give the opposite
| meaning.

> Defaults to yes.

Das bedeutet:  Gibt man weder »export-attributes« noch
»no-export-attributes« an, verhält es sich so, als hätte man
»export-attributes« angegeben.

> Das verstehe ich nicht. Wenn das externe Zielprogramm Foto-IDs
> ohnedies nicht unterstzützt, weshalb ergibt es einen Sinn, beim Export
> des Schlüssels auch die Foto-IDs zu exportieren?

Die Frage stelle ich mir auch.

> Ich nehme an, ich verstehe die Info nicht -- aber was genau verstehe
> ich nicht?

Ich vermute, es ist gemeint:  Man kann

--export-options no-export-attributes

verwenden, wenn man Schlüssel ohne Foto‐Ids exportieren will.
Ausprobiert habe ich es nicht.

> Oder ist nur gemeint: Weil nur selten Schlüssel Foto-IDs
> besitzen, muss man die Option dann explizit verwenden, wenn man
> Foto-IDs  mitexportieren will?

Das eher nicht, denn es heißt dort ja: »Defaults to yes.«


From bernhard at intevation.de  Mon Jan 25 11:53:20 2016
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 25 Jan 2016 11:53:20 +0100
Subject: Frage zur Option --export-options export-attributes
In-Reply-To: <871t9d8f6n.fsf@helmutwaitzmann.news.arcor.de>
References: <569CB0FB.6050409@arcor.de>
 <871t9d8f6n.fsf@helmutwaitzmann.news.arcor.de>
Message-ID: <201601251153.25840.bernhard@intevation.de>

On Tuesday 19 January 2016 at 21:52:22, Helmut Waitzmann wrote:
> > Das verstehe ich nicht. Wenn das externe Zielprogramm Foto-IDs
> > ohnedies nicht unterstzützt, weshalb ergibt es einen Sinn, beim Export
> > des Schlüssels auch die Foto-IDs zu exportieren?
>
> Die Frage stelle ich mir auch.

Meine Vermutung ist, dass es so gemeint ist, dass die anderen Anwendungen
sich dann verweigern, wenn sie eine Foto-ID vorgelegt bekämen.

In jedem Falle habt Ihr Recht, dass diese Option klarer beschrieben werden
könnte, ich habe dafür folgenden Fall angelegt:

https://bugs.gnupg.org/gnupg/issue2228

Danke,
Bernhard

-- 
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         : </pipermail/attachments/20160125/47e6b44a/attachment.sig>

From bernhard at intevation.de  Mon Jan 25 11:34:33 2016
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 25 Jan 2016 11:34:33 +0100
Subject: Frage zu Mailinglisten
In-Reply-To: <87h9isr2eq.fsf@helmutwaitzmann.news.arcor.de>
References: <564DA08F.3040205@mtmedia.org>
 <201511241418.13984.bernhard@intevation.de>
 <87h9isr2eq.fsf@helmutwaitzmann.news.arcor.de>
Message-ID: <201601251134.39482.bernhard@intevation.de>

On Tuesday 05 January 2016 at 07:00:19, Helmut Waitzmann wrote:
>   Wenn man das nicht will (z. B. weil der Listenbetreiber nicht
>   vertrauenswürdig ist), bleibt nur die dezentrale Form:
>
> * Alle Teilnehmer verschlüsseln ihre Nachrichten für alle
>   Teilnehmer der Liste.  Dann gibt es echte
>   Ende‐zu‐Ende‐Verschlüsselung von jedem Teilnehmer zu jedem
>   Teilnehmer.

Ja, ich wollte nur darauf aufmerksam machen, dass eine Mailinglisten
Software hier nicht so automatisiert funktionieren kann, wie in 
unverschlüsselten Zusammenhängen. 

Würden die Email Anwendungen und Mailtransportdienste der Teilnehmer
TLS nutzen, dann kann das auch ein sehr guter Fortschritt sein und eine
normale Mailinglisten-Software könnte zur Verwendung kommen.
Das ist für viele (nicht-end-zu-ende) Verschlüsslungsszenarien 
ein vielversprechender Weg.

Gruß,
Bernhard

-- 
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         : </pipermail/attachments/20160125/588f5804/attachment.sig>

From wk at gnupg.org  Wed Jan 27 17:28:23 2016
From: wk at gnupg.org (Werner Koch)
Date: Wed, 27 Jan 2016 17:28:23 +0100
Subject: Frage zur Option --export-options export-attributes
In-Reply-To: <201601251153.25840.bernhard@intevation.de> (Bernhard Reiter's
 message of "Mon, 25 Jan 2016 11:53:20 +0100")
References: <569CB0FB.6050409@arcor.de>
 <871t9d8f6n.fsf@helmutwaitzmann.news.arcor.de>
 <201601251153.25840.bernhard@intevation.de>
Message-ID: <874mdzrnq0.fsf@vigenere.g10code.de>

On Mon, 25 Jan 2016 11:53, bernhard at intevation.de said:

> Meine Vermutung ist, dass es so gemeint ist, dass die anderen Anwendungen
> sich dann verweigern, wenn sie eine Foto-ID vorgelegt bekämen.

Bug Kompatibilität.  Einige OpenPGP Implementierungen konnten irgendwann
mal nicht mit Attribut IDs umgehen.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From g.thaler at arcor.de  Thu Jan 28 11:50:48 2016
From: g.thaler at arcor.de (=?UTF-8?Q?G=c3=bcnter_Thaler?=)
Date: Thu, 28 Jan 2016 11:50:48 +0100
Subject: Frage zur Option --no-for-your-eyes-only
Message-ID: <56A9F288.3030803@arcor.de>

Wie muss ich mir das Wirken dieser Option vorstellen? Ich verschlüssle 
mit einem Fremdschlüssel eine Datei und verwende die Option. Der 
Empfänger entschlüsselt die erhaltene Datei und speichert die 
entschlüsselte Datei lokal im Dateisystem.

Unter Windows:
Fall 1: Er will die Datei abc.txt in einem Verzeichnis, z.B. 
U:/INTENSO/Daten speichern. Er muss er den Verzeichnispfad mit dem 
Dateinamen ohnedies angeben: U:/INTENSO/Daten/abc.txt. In diesem Fall 
also kein Unterschied zum Fall ohne Verwenduing der Option.

Fall 2: Er will die Datei in seinem Heimat-Verzeichnis speichern 
(C:/USERS/sepp). Er muss nun aber mit --output explizit sein 
Homeverzeichnis angeben, damit er speichern kann. C:/Users/sepp/abc.txt. 
Ist das der Unterschied zu Fall 1?

Aus dem GPG-Manual:
Set the ‘for your eyes only’ flag in the message. This causes GnuPG to 
refuse to save the file unless the --output option is given, and PGP to 
use a "secure viewer" with a claimed Tempest-resistant font to display 
the message.

Was ist mit "secure viewer" gemeint? Und was ist ein Tempest-resistant font?

Ist das etwas, mit dem der Benutzer, der nur verschlüsselt kommunizieren 
will, wissen muss, oder ist diese Information vielleicht nur für 
Entwickler relevant, die GnuPG in Skripts verwenden?

Fragen über Fragen ...

Gruß Günter


From g.thaler at arcor.de  Sat Jan 30 00:30:28 2016
From: g.thaler at arcor.de (=?UTF-8?Q?G=c3=bcnter_Thaler?=)
Date: Sat, 30 Jan 2016 00:30:28 +0100
Subject: Frage zur Option --no-for-your-eyes-only
In-Reply-To: <56A9F288.3030803@arcor.de>
References: <56A9F288.3030803@arcor.de>
Message-ID: <56ABF614.9060404@arcor.de>

Ich habe zwischenzeitlich mit der Option herumgespielt, und es hat gut
funktioniert.

Vielleicht interessiert es jemanden:

Die Option setzt beim asymmetrischen Verschlüsseln das
"For-your-Eyes-only"-Flag in die verschlüsselte Datei.
Der Benutzer, der die Datei entschlüsselt, muss in der Kommandozeile mit
dem --decrypt-Kommando die Option --output benutzen, damit er die
entschlüsselte Datei lokal speichern kann. Ohne die Option --output wird
der entschlüsselte Text nur in der Konsole angezeigt.

Das wirkt dem versehentlichen Speichern der entschlüsselten Datei in
Verzeichnissen entgegegen, in denen Unbefugte Zugriffsrechte besitzen;
die Datei bleibt so nicht versehentlich unverschlüsselt im Dateisystem
liegen, auf das Unbefugte Zugriff haben. (Wenn sich alle Benutzer an den
Hinweis halten).

Als Anwendungfall habe ich mir folgenden ausgedacht: Sensible Dateien
(z.B. Zugangsdaten) können verschlüsselt im Netzlaufwerk abgelegt
werden, und Berechtigte (die den passenden privaten Schlüssel besitzen)
können die Daten jederzeit einsehen, ohne diese durch das Entschlüsseln
zu kompromittieren.

Eigentlich eine interessante Option.

Gruß Günter