Änderung in der Verwaltung der privaten Schlüssel?

[Werner Koch]

On Thu, 15 Nov 2018 19:17, dg8wnx at gmx.net said:

> Mir ist aufgefallen, das GPG wohl neuerdings die Datei SECRING.GPG nicht
> mehr verwendet. Zumindest bei mir.
> PUBRING.GPG aber schon.

Das ist seit 2.1 grundsätzlich so.  Wir benutzen dieses Format schoin
immer für gpgsm (gpg 2.0)

> Private Schlüssel werden nun offenbar in einem Unterverzeichnis in
> einzelnen Dateien abgelegt. Und pro Schlüssel werden offenbar 2 Dateien
> angelegt.

Richtig, für jeden Schlüssel wird eine Datei angelegt.  Dies Schlüssel
sind dann unabhängig vom Protokoll und so ist es auch möglich denselben
SChlüssel für S/MIME und OpenPGP und SSH zu benutzen.  Nicht das das
eine gute Idee is, aber gelegentlich kann das sinnvoll sein.

Unten habe ich nochmal den betreffenden Abschnitt aus der What's new in
2.1 kopiert.  Sorry, ich habe davon leider keine deutsche Übersetzung.

> Ist das so fix, oder kann man auch das "alte" System verwenden?
> Oder ist bei mir nur was verstellt?

Nein, geht nicht mehr.  Überhaupt ist alles im ~/.gnupg eine interne
Angelegenheit von GnuPG und andere Programme sollten darauf niemals
direkt zugreifen.  Immer schön gpg --export verwenden.  Sage ich schon
seit Jahren ;-)

Übrigens: Das Format dieser Schlüsseldateien ist in
<https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;f=agent/keyformat.txt>
beschrieben.


73 und Salam-Shalom,

   Werner


=====
Aus https://gnupg.org/faq/whats-new-in-2.1.html

** Removal of the secret keyring
:PROPERTIES:
:CUSTOM_ID: nosecring
:END:

gpg used to keep the public key pairs in two files: =pubring.gpg= and
=secring.gpg=.  The only difference is that secring stored in addition
to the public part also the private part of the key pair.  The secret
keyring thus contained only the keys for which a private key is
available, that is the user’s key.  It required a lot of code to keep
both versions of the key in sync and led to sometimes surprising
inconsistencies.

The design of GnuPG-2 demands that only the gpg-agent has control over
the private parts of the keys and the actual encryption engine (gpg or
gpgsm) does not know about the private key but care only about session
keys and keys for symmetric encryption.  This has been implemented
about 10 years ago for /gpgsm/ (the S/MIME part of GnuPG).  However,
/gpg/ (the OpenPGP part) used the gpg-agent only as passphrase entry
and cache device but handles the private key itself.

With GnuPG 2.1 this changed and /gpg/ now also delegates all private
key operations to the gpg-agent.  Thus there is no more code in the
/gpg/ binary for handling private keys.  En passant this allows the
long time requested “merging of secret keys” and several other
advanced key management techniques.

To ease the migration to the no-secring method, /gpg/ detects the
presence of a =secring.gpg= and converts the keys on-the-fly to the
the key store of /gpg-agent/ (this is the =private-keys-v1.d=
directory below the GnuPG home directory (=~/.gnupg=)).  This is done
only once and an existing =secring.gpg= is then not anymore touched by
/gpg/.  This allows co-existence of older GnuPG versions with GnuPG
2.1.  However, any change to the private keys using the new /gpg/ will
not show up when using pre-2.1 versions of GnuPG and vice versa.

Note that the command =--export-secret-keys= still creates an OpenPGP
compliant file with the secret keys.  This is achieved by asking
/gpg-agent/ to convert a key and return it in the OpenPGP protected
format.  The export operation requires that the passphrase for the key
is entered so that /gpg-agent/ is able to change the protection from
its internal format to the OpenPGP required format.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 227 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.gnupg.org/pipermail/gnupg-de/attachments/20181116/e6eb1c67/attachment-0001.sig>