it-swarm.com.de

Migrieren von GPG-Hauptschlüsseln als Unterschlüssel auf einen neuen Hauptschlüssel

Derzeit habe ich 3 private GPG-Paare, die alle Hauptschlüssel sind. Ich möchte diese Schlüssel in Unterschlüssel für ein neues Schlüsselpaar konvertieren (und das im Tresor behalten).

Ich habe den folgenden Thread gelesen http://atom.smasher.org/gpg/gpg-migrate.txt , der eine Art Hacking der Binärdatei beinhaltet, um einen Hauptschlüssel in einen Unterschlüssel zu konvertieren und ihn zu ersetzen mit einem anderen.

Ist es möglich, meine verschiedenen Schlüssel zu einem neuen Einzelschlüsselpaar zu kombinieren, damit sie weiterhin gültig sind, und ich kann Personen auf das Signieren meines Hauptschlüssels verweisen, sodass ich keine Angst haben muss, meinen geheimen Hauptschlüssel zu verlieren.

Was ich habe

Hier habe ich 3 verschiedene Schlüssel (der private Schlüssel ist verfügbar).

$ gpg2 -k                          
----------------------------------
pub   2048R/712A2BBD 2013-01-29
uid                  Test Key 1
sub   2048R/F0B63FDA 2013-01-29

pub   2048R/72838B89 2013-01-29
uid                  Test Key 2
sub   2048R/A19F06EC 2013-01-29

pub   2048D/AC349218 2013-03-21
uid                  Test Key 3
sub   2048g/179E9F47 2013-03-21

Was ich will

Ich mag es, diese Schlüssel in Unterschlüssel umzuwandeln und sie in einen neuen Hauptschlüssel zu verschieben. Es sollte stattdessen ungefähr so ​​aussehen:

pub   4096R/CB577A43 2013-03-21
uid                  Master Key
sub   2048R/712A2BBD 2013-01-29
sub   2048R/F0B63FDA 2013-01-29
sub   2048R/72838B89 2013-01-29
sub   2048R/A19F06EC 2013-01-29
sub   2048D/AC349218 2013-03-21
sub   2048g/179E9F47 2013-03-21

Ist das überhaupt möglich? Oder hoffe ich am besten, meine 3 Schlüssel zu widerrufen und von vorne zu beginnen und einen neuen Schlüssel zu erstellen, der zu meiner Verwendung passt.

Was ich bisher gemacht habe

Verwenden Sie die Anweisungen von http://atom.smasher.org/gpg/gpg-migrate.txt

Ich habe es geschafft, meine Schlüssel mit gpgsplit zu exportieren und zu extrahieren. Ich habe auch den secret_key in einen secret_subkey geändert, indem ich das erste Byte von 0x95 in 0x9d geändert habe

Damit pgpdump sagt, dass das Geheimnis ein geheimer Unterschlüssel ist

~/keytest/key1❯ pgpdump/pgpdump 000001-005.secret_subkey          
Old: Secret Subkey Packet(tag 7)(920 bytes)
        Ver 4 - new
        Public key creation time - Tue Jan 29 13:09:07 CET 2013
        Pub alg - RSA Encrypt or Sign(pub 1)
        ...

Ich habe dann alle Schlüssel zu einem neuen Schlüssel zusammengeführt, um die Dateien zu verketten.

$ gpg2 --export-secret-key CB577A43 > master.gpg
$ cat master.gpg key1/* key2/* key3/* > newkey.gpg
# Removed ~/.gnupg
$ gpg2 --import newkey.gpg
# Ended up with this:
$ gpg -k
----------------------------------
pub   4096R/CB577A43 2013-03-21
uid                  Master Key
sub   2048R/208FAE4C 2013-03-21

~/keytest❯ gpg -K
----------------------------------
sec   4096R/CB577A43 2013-03-21
uid                  Master Key
ssb   2048R/208FAE4C 2013-03-21
ssb   2048R/712A2BBD 2013-01-29
uid                  Test Key 1
ssb   2048R/F0B63FDA 2013-01-29
ssb   2048R/72838B89 2013-01-29
uid                  Test Key 2
ssb   2048R/A19F06EC 2013-01-29
ssb   2048D/AC349218 2013-03-21
uid                  Test Key 3
ssb   2048g/179E9F47 2013-03-21

Was nicht so schlecht aussieht. Aber wenn ich meine Schlüssel vom Keyserver importiere gpg2 --recv-keys 712A2BBD 72838B89 AC349218 um die Unterschriften zurückzubekommen. Daraus wird Folgendes:

$ gpg -k                          
----------------------------------
pub   4096R/CB577A43 2013-03-21
uid                  Master Key
sub   2048R/208FAE4C 2013-03-21

pub   2048R/712A2BBD 2013-01-29
uid                  Test Key 1
sub   2048R/F0B63FDA 2013-01-29

pub   2048R/72838B89 2013-01-29
uid                  Test Key 2
sub   2048R/A19F06EC 2013-01-29

pub   2048D/AC349218 2013-03-21
uid                  Test Key 3
sub   2048g/179E9F47 2013-03-21

Was bleibt

Danach habe ich 4 öffentliche Schlüssel in meinem Schlüsselbund. Ich wollte diese Schlüssel verschieben, damit sie vom Hauptschlüssel CB577A43 abhängen, wie oben unter Was ich will.

42
lz.

Es kann tatsächlich getan werden.

Die Anweisungen unter atom.smasher.org/gpg/gpg-migrate.txt sind jetzt veraltet.

Versuche dies. Machen Sie wie immer Backups, denn es ist wirklich einfach, es durcheinander zu bringen.


Das sind also deine 'alten' Schlüssel:

$ gpg -K                          
----------------------------------
sec   2048R/712A2BBD 2013-01-29
uid                  Test Key 1
ssb   2048R/F0B63FDA 2013-01-29

sec   2048R/72838B89 2013-01-29
uid                  Test Key 2
ssb   2048R/A19F06EC 2013-01-29

sec   2048D/AC349218 2013-03-21
uid                  Test Key 3
ssb   2048g/179E9F47 2013-03-21

Und Sie haben einen neuen "Hauptschlüssel" erstellt, der keine Unterschlüssel enthält:

sec   4096R/CB577A43 2013-03-21
uid                  Master Key

Der Einfachheit halber werde ich die Prozedur nur mit dem ersten Ihrer "alten" Schlüssel proben:

sec   2048R/712A2BBD 2013-01-29  
uid                  Test Key 1
ssb   2048R/F0B63FDA 2013-01-29  

Mit dem gleichen Verfahren können Sie alle hinzufügen. Ich empfehle, dass Sie alle gleichzeitig hinzufügen, da Sie jedes Mal, wenn Sie die Schlüssel brechen und dann wieder zusammensetzen, die Bindungssignaturen neu erstellen müssen, und das ist ein Schmerz.


1. Verwenden Sie gpgsplit, um den "alten" Schlüssel in seine Bestandteile aufzuteilen.

$ gpg --export-secret-keys 712A2BBD | gpgsplit -vp 712A2BBD_

Schauen Sie sich nun die erstellten Dateien an:

$ ls
----------------------------------
712A2BBD_000001-005.secret_key
712A2BBD_000002-013.user_id
712A2BBD_000003-002.sig
712A2BBD_000004-007.secret_subkey
712A2BBD_000005-002.sig

Die erste Datei "712A2BBD_000001-005.secret_key" enthält das Paket für den privaten Hauptschlüssel ( des Pakettyps Tag 5 , daher "005") Ihres "alten" Schlüssels. "712A2BBD". (Sie benötigen dies, müssen es jedoch in einen Unterschlüssel konvertieren, wenn Sie es in Ihren neuen "Hauptschlüssel" migrieren möchten. In Schlüsseln, die mit den Standardeinstellungen von GPG generiert wurden, hat der private Hauptschlüssel normalerweise die Verwendungsflags "S". für sign und "C" für certify und hat kein "E" für die Verschlüsselung, weshalb der Schlüssel normalerweise mit einem "E" -Unterschlüssel generiert wird. Aufgrund der von uns verwendeten Prozedur ist jedoch letztendlich der Hauptschlüssel In einen Unterschlüssel umgewandelt und auf Ihren neuen "Hauptschlüssel" migriert, sind alle Verwendungsflags ("SCEA") aktiviert. Dies macht ihn wahrscheinlich weniger sicher und ist wahrscheinlich ein zu vermeidendes Verhalten.)

Die zweite Datei "712A2BBD_000002-013.user_id" ist das Paket für die Benutzer-ID ( Pakettyp-Tag 13 ). (Das brauchst du nicht).

Die dritte Datei, "712A2BBD_000003-002.sig", ist eine verbindliche Signatur ( Pakettyp-Tag 2 ) für diese Pakete. (Sie haben gewonnen brauche das nicht).

Die vierte Datei ist das Paket für den geheimen Unterschlüssel (F0B63FDA) ( Pakettyp-Tag 7 ). (Sie benötigen dies. In der Regel hat ein Unterschlüssel wie dieser das Verwendungsflag "E", dh er dient ausschließlich der Verschlüsselung. Beim Importieren in Ihren neuen "Hauptschlüssel" werden jedoch alle Verwendungsflags erfasst , ("SCEA"), was wahrscheinlich keine gute Sache ist .)

Die fünfte Datei, "712A2BBD_000005-002.sig", ist die Bindungssignatur ( des Pakettyps tag 2 ) für den Unterschlüssel. Sie haben gewonnen. ' Ich brauche es nicht.

Speichern Sie die beiden benötigten Dateien und entfernen Sie die anderen.


2. Ändern Sie den Hauptschlüssel (712A2BBD) in einen Unterschlüssel.

Sie müssen nichts mit dem Unterschlüssel (F0B63FDA) tun, um ihn auf Ihren neuen "Hauptschlüssel" zu migrieren, aber der Hauptschlüssel (712A2BBD) Ihres alten Schlüssels muss geändert werden, damit er funktioniert.

Öffnen Sie den Hauptschlüssel "712A2BBD_000001-005.secret_key" in einem Editor, der hexadezimale oder binäre Änderungen vornehmen kann. Ich habe ghex verwendet:

$ ghex 712A2BBD_000001-005.secret_key

Wenn Sie einen Hex-Editor verwenden, lautet das erste Byte "95". Ändern Sie es in "9D".

Wenn Sie einen Binäreditor verwenden, lautet das erste Byte "10010101". Ändern Sie es in "10011101".

Speichern Sie es und verwenden Sie dann pgpdump, um festzustellen, ob es Ihnen gelungen ist, es in einen Unterschlüssel zu ändern. Wenn Sie erfolgreich waren, wird die folgende Ausgabe angezeigt:

$ pgpdump 712A2BBD_000001-005.secret_key | head -1
-----------------
Old: Secret Subkey Packet(tag 7)(1836 bytes)

3. Fügen Sie Ihrem neuen "Hauptschlüssel" einen "Dummy" -Unterschlüssel für jeweils der Unterschlüssel hinzu, die Sie hinzufügen möchten.

Genau wie im Tutorial unter atom.smasher.org müssen Sie neue "Dummy" -Unterschlüssel auf Ihrem "Hauptschlüssel" erstellen, um sicherzustellen, dass Sie Schlüsselbindungssignaturen haben der Hauptschlüssel, der (zumindest zuerst) die migrierenden Unterschlüssel aufnehmen kann.

Stellen Sie sich vor, Sie erstellen "Slots" für die alten Unterschlüssel. Sie benötigen so viele Steckplätze wie Schlüssel, die Sie hinzufügen möchten.

Im vorliegenden Beispiel werden zwei Dummy-Unterschlüssel erstellt. Wenn Sie jedoch alle Schlüssel hinzufügen möchten, die Sie in Ihrem ursprünglichen Beitrag aufgeführt haben, möchten Sie sechs erstellen.

$ gpg --expert --edit-key CB577A43
----------------------------------------
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4096R/CB577A43  created: 2013-03-21  expires: never       usage: SC  
                     trust: unknown      validity: unknown

gpg>addkey

Stellen Sie beim Durchlaufen des Assistenten zur Generierung von Unterschlüsseln (der sich dank der obigen Option --expert im Expertenmodus befindet) sicher, dass er beim Generieren Ihres neuen Unterschlüssels "Dummy" vom selben ...

  • schlüsselstärke (2048, 4096 usw.)
  • typ (DSA, RSA, Elgamal)
  • nutzung (verschlüsseln, unterschreiben)

... als Unterschlüssel, den Sie in diesen "Slot" einfügen möchten.

Da wir zwei Unterschlüssel hinzufügen, erhalten wir zwei neue "Dummy" -Unterschlüssel auf dem "Hauptschlüssel". Speichern und schließen:

pub  4096R/CB577A43  created: 2013-03-21  expires: never       usage: SC  
                         trust: unknown      validity: unknown
sub  2048R/AAAAAAAA  created: 2014-01-01  expires: never       usage: S
sub  2048R/BBBBBBBB  created: 2014-01-01  expires: never       usage: E

gpg> save

4. Teilen Sie Ihren neuen "Hauptschlüssel" - zusammen mit seinen neuen Unterschlüsseln - in seine Bestandteile auf.

$ gpg --export-secret-keys CB577A43 | gpgsplit -vp CB577A43_

Sie sollten am Ende Folgendes haben:

$ ls
----------------
CB577A43_000001-005.secret_key
CB577A43_000002-013.user_id
CB577A43_000003-002.sig
CB577A43_000004-007.secret_subkey
**CB577A43_000005-002.sig**
CB577A43_000006-007.secret_subkey
**CB577A43_000007-002.sig**

Die fünfte und siebte Datei (die, die ich in ** s eingegeben habe) sind die Unterschlüssel-Schlüsselbindungs-Signaturpakete, die beim Generieren der "Dummy-Unterschlüssel" generiert wurden. Du wirst diese brauchen.

Die vierte und sechste Datei sind die eigentlichen "Dummy-Unterschlüssel" -Pakete. Sie können jetzt sicher gelöscht werden (die einzigen Dateien, die Sie löschen sollten.)

$ rm CB577A43_000004-007.secret_subkey CB577A43_000006-007.secret_subkey

5. "Stecken" Sie Ihre migrierenden "Unterschlüssel" in den geteilten Hauptschlüssel.

Bei den Schritten eins und zwei blieben Ihnen zwei Dateien:

712A2BBD_000001-005.secret_key (the original main key of your "old key", now edited into a subkey)
712A2BBD_000004-007.secret_subkey (the original subkey of your "old key".)

Kopieren Sie diese nun in den Ordner mit den geteilten Bestandteilen des "Hauptschlüssels" und benennen Sie diese Dateien so um, dass sie die gerade gelöschten "Dummy-Unterschlüssel" -Dateien ersetzen.

$ mv 712A2BBD_000001-005.secret_key CB577A43_000004-007.secret_subkey
$ mv 712A2BBD_000004-007.secret_subkey CB577A43_000006-007.secret_subkey

Sie sollten wieder sieben (in diesem Beispiel) Dateien haben, aber die Dateien vier und sechs sind jetzt Ihre alten Schlüssel, alle festgelegt und bereit, Unterschlüssel Ihres neuen Hauptschlüssels zu werden.

$ ls
----------------
CB577A43_000001-005.secret_key
CB577A43_000002-013.user_id
CB577A43_000003-002.sig
**CB577A43_000004-007.secret_subkey**
CB577A43_000005-002.sig
**CB577A43_000006-007.secret_subkey**
CB577A43_000007-002.sig

6. Verketten Sie die Dateien zu Dateien mit privatem und öffentlichem Schlüssel, die zum Import bereit sind

Fügen Sie die Dateien so zusammen, dass sie nacheinander zu einzelnen Dateien verkettet werden, um den späteren Import zu vereinfachen.

$ cat CB577A43_000001-005.secret_key CB577A43_000002-013.user_id CB577A43_000003-002.sig CB577A43_000004-007.secret_subkey CB577A43_000005-002.sig CB577A43_000006-007.secret_subkey CB577A43_000007-002.sig > concatenated_CB577A43.secret

Verwenden Sie denselben Befehl, leiten Sie die Ausgabe jedoch an gpgsplit weiter, um öffentliche Gegenstücke zu erstellen, bevor Sie in eine neue Datei umleiten:

$ cat CB577A43_000001-005.secret_key CB577A43_000002-013.user_id CB577A43_000003-002.sig CB577A43_000004-007.secret_subkey CB577A43_000005-002.sig CB577A43_000006-007.secret_subkey CB577A43_000007-002.sig | gpgsplit --no-split --secret-to-public > concatenated_CB577A43.public

7. Sichern Sie Ihren Schlüsselbund und löschen Sie dann die öffentlichen und privaten "alten" UND "Hauptschlüssel" von Ihrem Schlüsselbund.

$ cp -R ~/.gnupg/ ~/.gnupg_backup
$ gpg --delete-secret-and-public-keys CB577A43 712A2BBD

8. Laden Sie gnupg-1.2.0 herunter und erstellen Sie es.

Wenn in letzter Zeit jemand versucht, dem Tutorial unter atom.smasher.org zu folgen, besteht das Problem darin, dass bei den neuesten Versionen von gpg der Schlüssel nach dem Zusammensetzen und Hinzufügen hinzugefügt wird Zu ihrem Schlüsselbund haben die hinzugefügten Unterschlüssel 1) keine Verwendungsflags und 2) sie können das Ablaufdatum nicht zurücksetzen, wie im Tutorial atom.smasher.org empfohlen, a notwendiger Schritt zum Erstellen neuer und gültiger Schlüsselbindungssignaturen. Das Ergebnis ist, dass nach einem Export-/Importzyklus die Schlüssel von GPG als ungültig eingestuft werden und aus dem privaten Schlüsselbund verschwinden.

Um die Schlüssel erfolgreich zu importieren, müssen Sie eine alte Version von gnupg herunterladen und erstellen: eine Version von 2002 nicht weniger. Sobald Sie es erstellt haben, können Sie die Ablaufdaten für die neuen Schlüssel zurücksetzen und gültige Tastenkombinationen für die Schlüssel erfolgreich neu erstellen.

Laden Sie das alte Gnupg herunter.

$ wget ftp://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org/gnupg/gnupg-1.2.0.tar.bz2
$ tar -xjf gnupg-1.2.0.tar.bz2
$ cd gnupg-1.2.0/
$ ./configure
$ make

Navigieren Sie in den Ordner g10, der Ihre neu erstellte GPG-Binärdatei enthält

$ cd g10

Um diese Binärdatei zu verwenden, müssen Sie anstelle des neueren systemweiten Builds von gpg den absoluten Pfad zur Binärdatei eingeben. Wenn Sie sich im selben Ordner befinden, verwenden Sie ./gpg, zum Beispiel:

$ ./gpg --list-keys

8. Hängen Sie die neu zusammengestellte "Hauptschlüssel" -Datei mit importierten Unterschlüsseln an Ihre öffentlichen und privaten Schlüsselringe an.

Importieren Sie die Schlüssel nicht auf die normale Weise, da die Schlüsselbindungssignaturen nicht ausgecheckt werden, sodass die importierten Unterschlüssel nicht auf die normale Weise importiert werden. Ordnen Sie die Dateien stattdessen dem Ende Ihrer öffentlichen und privaten Schlüsselringe zu.

$ cat concatenated_CB577A43.secret >> ~/.gnupg/secring.gpg
$ cat concatenated_CB577A43.public >> ~/.gnupg/pubring.gpg

Überprüfen Sie, ob sie dort angekommen sind, indem Sie gnupg-1.2.0 verwenden, um die Schlüssel aufzulisten:

$ ./gpg --list-keys
-----------------
pub   4096R/CB577A43 2013-03-21
uid                  Master Key
sub   2048R/712A2BBD 2013-01-29
sub   2048R/F0B63FDA 2013-01-29

9. Bearbeiten Sie die Schlüssel mit gnupg-1.2.0.

Stellen Sie sicher, dass Sie zum Erstellungsordner für gnupg-1.2.0/g10 zurückkehren und die erstellte Binärdatei aufrufen, um Ihren neu importierten, neu zusammengestellten Hauptschlüssel mit Ihren importierten alten Unterschlüsseln zu bearbeiten:

$ ./gpg --edit-keys CB577A43
-----------------
sec  4096R/CB577A43  created: 2013-03-21 expires: never     
ssb  2048R/712A2BBD  created: 2013-01-29 expires: never     
ssb  2048R/F0B63FDA  created: 2013-01-29 expires: never 

Setzen Sie zuerst die Passwörter zurück.

Command> passwd

Es ist wahrscheinlich, dass alle Ihre alten Schlüssel andere Passwörter hatten als Ihr neuer Hauptschlüssel. Wenn Sie das Kennwort jetzt zurücksetzen, werden Sie nacheinander (zusammen mit der Unterschlüssel-ID) zur Eingabe aller Kennwörter der alten Schlüssel aufgefordert. Wenn Sie alle Kennwörter richtig eingegeben haben, werden Sie nach einem neuen Schlüssel gefragt. Sobald dies erledigt ist, haben alle das gleiche Passwort, um später Verrücktheiten zu vermeiden.

Zweitens setzen Sie das Ablaufdatum für ALLE Schlüssel zurück. Beginnen Sie mit dem Hauptschlüssel:

Command> expiry

Arbeiten Sie sich dann durch die einzelnen Unterschlüssel und ändern Sie das Ablaufdatum für jeden einzelnen.

Command> key 1
Command> expiry
Command> key 1
Command> key 2
Command> expiry
Command> key 2
Command> key 3

Und so weiter

Stellen Sie sicher, dass Sie den Wert auf einen Wert ändern, der noch nicht aktiviert war. Andernfalls wird keine Änderung vorgenommen. Sie können es später wieder auf den ursprünglichen Wert zurücksetzen: Jetzt ist eine Änderung erforderlich, damit gpg-1.2.0 neue Unterschlüssel-Bindungssignaturen erstellen kann.

Sobald dies alles erledigt ist, speichern Sie.

Command> save

gnupg-1.2.0 wird beendet und speichert die neuen Schlüsselbindungssignaturen, wodurch die Migration Ihrer alten Schlüssel in Ihren neuen Hauptschlüssel überprüft wird.


10. Bearbeiten Sie nun die Schlüssel mit dem Standard-Gnupg (aktuell), um festzustellen, ob es funktioniert hat.

Öffnen Sie denselben Schlüssel zum Bearbeiten mit der systemweiten Standardversion von gpg, um festzustellen, ob er funktioniert hat. Wenn es funktioniert hat, werden Sie zwei Dinge sehen:

  1. Die Ablaufdaten sind die neuen Ablaufdaten, auf die Sie gerade in Schritt 9 geändert haben, und nicht die ursprünglichen.
  2. Die Verwendungsflags rechts neben den Unterschlüsseln zeigen "Nutzung: SCEA" an.

.

$ gpg --edit-key CB577A43
--------------------------
pub  4096R/CB577A43  created: 2013-03-21  expires: [newdate]     usage: SC  
                     trust: unknown      validity: unknown
sub  2048R/712A2BBD  created: 2013-01-29  expires: [newdate]     usage: SCEA
sub  2048R/F0B63FDA  created: 2013-01-29  expires: [newdate]     usage: SCEA

Wenn es nicht funktioniert hat, sind die Verwendungsflags leer und das Ablaufdatum zeigt jetzt die Änderung an, die Sie gerade in Schritt 9 vorgenommen haben.

$ gpg --edit-key CB577A43
--------------------------
pub  4096R/CB577A43  created: 2013-03-21  expires: **never**     usage: SC  
                     trust: unknown      validity: unknown
sub  2048R/712A2BBD  created: 2013-01-29  expires: **never**     usage: 
sub  2048R/F0B63FDA  created: 2013-01-29  expires: **never**     usage: 

Schließlich müssen Sie einen Export-/Importzyklus durchlaufen und die dazwischen liegenden Schlüssel löschen. Wenn es dies überlebt, hat das Verfahren funktioniert.

$ gpg --export-secret-keys CB577A43 > CB577A43_new.secret
$ gpg --export CB577A43 > CB577A43_new.public
$ gpg --delete-secret-and-public-keys CB577A43
$ gpg --import CB577A43_new.secret CB577A43_new.public
$ gpg --edit-key CB577A43
--------------------------
pub  4096R/CB577A43  created: 2013-03-21  expires: [newdate]     usage: SC  
                     trust: unknown      validity: unknown
sub  2048R/712A2BBD  created: 2013-01-29  expires: [newdate]     usage: SCEA
sub  2048R/F0B63FDA  created: 2013-01-29  expires: [newdate]     usage: SCEA

11. Letzte Aufgaben.

Angenommen, es hat funktioniert, müssen Sie jetzt Ihre Unterschlüssel kreuzzertifizieren , damit sie Signaturen erstellen und überprüfen können.

$ gpg --edit-key CB577A43

Und von der gpg edit Eingabeaufforderung:

gpg> cross-certify

Sie müssen auch das Vertrauen zurücksetzen:

gpg> trust

Testen Sie den Schlüssel abschließend gründlich, um sicherzustellen, dass er funktioniert, bevor Sie ihn verteilen. Ich verweise auf das Tutorial atom.smasher.org für diese letzten Schritte:

  • überprüfen Sie alle Ablaufdaten und Einstellungen. Einige dieser Vorgänge haben möglicherweise Ihre Ablaufdaten und Einstellungen geändert. bei Bedarf zurücksetzen.

  • testen Sie alle Schlüsselkomponenten zum Erstellen und Überprüfen von Signaturen sowie zum Ver- und Entschlüsseln. Verwenden Sie den Knall (!), um jeden (Unter-) Schlüssel zu erzwingen: Signaturen erstellen und überprüfen:

    $ date | gpg -u '712A2BBD!' --clearsign | gpg -v --verify
    $ date | gpg -u 'F0B63FDA!' --clearsign | gpg -v --verify
    

    verschlüsseln entschlüsseln:

    $ date | gpg -ear '712A2BBD!' | gpg -v --decrypt
    $ date | gpg -ear 'F0B63FDA!' | gpg -v --decrypt
    
  • senden Sie nach dem lokalen Testen der Schlüssel Ihren neuen öffentlichen Schlüssel an eine oder zwei Personen und testen Sie alle Schlüsselkomponenten (senden Sie signierte/verschlüsselte Nachrichten unter Verwendung aller Schlüsselkomponenten aneinander). Stellen Sie sicher, dass sie zuerst Ihren alten Schlüssel (aus ihren Schlüsselringen) löschen! und stellen Sie sicher, dass sie verstehen, dass der Schlüssel NICHT in Umlauf gebracht werden darf, bis überprüft wurde, ob alle Funktionen funktionieren!

  • wenn Sie den neuen Schlüssel in Umlauf bringen, ist es wahrscheinlich eine gute Idee, den alten Schlüssel abzulaufen/zu widerrufen. Fügen Sie einen Widerrufskommentar hinzu, der die neue Schlüssel-ID und Anweisungen zum Löschen des alten Schlüssels aus dem Schlüsselbund angibt.

  • hinweis zum Schlüsselentzug: Gemäß den OpenPGP-Standards wird ein von einem Unterschlüssel generierter Widerruf ignoriert, es sei denn, dieser Unterschlüssel wurde (durch den Primärschlüssel) als Widerrufsschlüssel festgelegt. GnuPG scheint sich korrekt zu verhalten, einige Versionen von PGP (tm) jedoch möglicherweise nicht. Wenn jemand behauptet, Ihr neuer Schlüssel sei widerrufen worden, müssen Sie alle alten und aktuellen Schlüssel aus dem Schlüsselbund entfernen. Importieren Sie dann Ihre aktuellen Schlüssel erneut.

36
breakingbits

Wenn ich mich nicht irre, gibt es eine einfache Möglichkeit, dies ab GnuPG 2.1 zu tun. Sie erstellen einfach Ihren neuen Primärschlüssel und fügen dann einen anderen vorhandenen Schlüssel als Unterschlüssel hinzu.

Hier habe ich einen alten Schlüssel:

$ gpg2 --with-keygrip -k
<...>
------------------------------------
pub   rsa2048 2017-05-31 [SC] [expires: 2019-05-31]
      3758BEEEA38377DC66708915C102DFD7B21740B0
      Keygrip = 42B4CE6092555D85F6BF93CEE13DC20A0B347048
uid           [ultimate] Mr Test
sub   rsa2048 2017-05-31 [E]
      Keygrip = A5CA49DB1EF812E278340BE6B8590D51F5EF9A2C

Ich erstelle zuerst einen völlig neuen Primärschlüssel:

$ gpg2 --quick-generate-key 'Mr Test New'
About to create a key for:
    "Mr Test New"

Continue? (Y/n) y
<...>

pub   rsa2048 2017-05-31 [SC] [expires: 2019-05-31]
      4B496C1EF14F63BBA2F7C566AEA5541400F78E93
      4B496C1EF14F63BBA2F7C566AEA5541400F78E93
uid                      Mr Test New
sub   rsa2048 2017-05-31 [E]

(Der Einfachheit halber habe ich --quick-generate-key Verwendet. Natürlich können Sie auch --generate-key Oder --full-generate-key Verwenden, wenn Sie dies wünschen.)

Als nächstes werde ich den neuen Schlüssel mit dem Flag --expert Bearbeiten:

$ gpg2 --expert --edit-key 4B496C1EF14F63BBA2F7C566AEA5541400F78E93
<...>
sec  rsa2048/AEA5541400F78E93
     created: 2017-05-31  expires: 2019-05-31  usage: SC
     trust: ultimate      validity: ultimate
ssb  rsa2048/7882EFF25C40792B
     created: 2017-05-31  expires: never       usage: E
[ultimate] (1). Mr Test New

gpg>

Ich verwende den Unterbefehl addkey und aufgrund des Flags --expert Kann ich einen vorhandenen Schlüssel mithilfe seines Schlüsselgriffs hinzufügen (in meinem Beispiel ist dies Option 13, aber die Zahlen können sich ändern.) Also habe ich mich für den stabilen Alias ​​keygrip) entschieden:

gpg> addkey
Please select what kind of key you want:
   <...>
  (13) Existing key
Your selection? keygrip
Enter the keygrip: 42B4CE6092555D85F6BF93CEE13DC20A0B347048

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? e

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? q
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 365
Key expires at Thu May 31 10:21:30 2018 MSK
Is this correct? (y/N) y
Really create? (y/N) y

sec  rsa2048/AEA5541400F78E93
     created: 2017-05-31  expires: 2019-05-31  usage: SC
     trust: ultimate      validity: ultimate
ssb  rsa2048/7882EFF25C40792B
     created: 2017-05-31  expires: never       usage: E
ssb  rsa2048/072D4F8908E1A926
     created: 2017-05-31  expires: 2018-05-31  usage: S
[ultimate] (1). Mr Test New

gpg>

(Wenn Sie nach zulässigen Aktionen gefragt werden, passen Sie die Schlüsselfunktionen richtig an, da sie standardmäßig immer signieren und verschlüsseln.)

Auf diese Weise können Sie Ihrem neuen Schlüssel alle alten Primärschlüssel und ihre Unterschlüssel hinzufügen. Und vergessen Sie nicht, ganz am Ende save zu verwenden.

Sie können überprüfen, ob dies tatsächlich derselbe Schlüssel ist, indem Sie die Schlüsselgriffe vergleichen:

$ gpg2 --with-keygrip -k
<...>
------------------------------------
pub   rsa2048 2017-05-31 [SC] [expires: 2019-05-31]
      3758BEEEA38377DC66708915C102DFD7B21740B0
      Keygrip = 42B4CE6092555D85F6BF93CEE13DC20A0B347048
uid           [ultimate] Mr Test
sub   rsa2048 2017-05-31 [E]
      Keygrip = A5CA49DB1EF812E278340BE6B8590D51F5EF9A2C

pub   rsa2048 2017-05-31 [SC] [expires: 2019-05-31]
      4B496C1EF14F63BBA2F7C566AEA5541400F78E93
      Keygrip = CB90DD9613FC321B2E609D8ECB219657A6AFCFDD
uid           [ultimate] Mr Test New
sub   rsa2048 2017-05-31 [E]
      Keygrip = D0E14A5E1CD161CF2F18F9EBA53AB2EF12705679
sub   rsa2048 2017-05-31 [S] [expires: 2018-05-31]
      Keygrip = 42B4CE6092555D85F6BF93CEE13DC20A0B347048
5
kirelagin

Leider besteht Ihre beste Option darin, die Schlüssel zu widerrufen, einen neuen mit den gewünschten Unterschlüsseln zu erstellen und diese auf den Schlüsselserver hochzuladen. Ich habe vor ein paar Jahren versucht, dieses Aufteilen und Zusammenführen durchzuführen, und bin auf ähnliche Probleme gestoßen wie Sie. Ich bin schließlich auf einen ausgezeichneten Artikel gestoßen, der zeigt, warum es nicht funktioniert, aber ich kann es nicht finden. Wenn ich das tue, werde ich den Link posten.

1
felixphew

Dies kann einfach eine Frage des Löschens der Unterschlüssel von Ihrem Schlüsselserver sein, da ich denke, wenn Sie versuchen, die Signaturen zu importieren, überschreiben Sie die Schlüsseltypen wieder auf ihren ursprünglichen Wert.

Wenn Ihre konsolidierten Schlüssel nicht die erwarteten Signaturen haben, müssen Sie möglicherweise überprüfen, ob sie in den Schlüsseln enthalten sind, die Sie teilen, und sie werden beim erneuten Zusammensetzen wieder korrekt hinzugefügt. Ist es vielleicht ein Bestellproblem, wenn Sie sie verketten? Oder fehlen Ihnen die Signaturen des Masters, der die Unterschlüssel signiert, wenn sie wieder zusammengesetzt werden (Sig-Typ 0x18: Sig für die Unterschlüsselbindung)?

Ich würde vorschlagen, einen neuen Hauptschlüssel mit drei Unterschlüsseln so zu erstellen, wie Ihr Endprodukt aussehen soll, es dann zu entleeren oder zu teilen, um zu sehen, wie es aufgebaut ist, und schließlich Ihren ursprünglichen Hauptschlüssel mit Unterschlüsseln in derselben Reihenfolge mit allen zusammenzusetzen die gleichen Stücke. Achten Sie auf die Signaturtypen in pgpdump, da Sie möglicherweise einige davon erstellen müssen. gpg --edit-key kann dabei helfen und überprüfen, welche Zeichen die Schlüssel haben.

Schieben Sie dann Ihre aktualisierten Schlüssel auf den Server, bevor Sie versuchen, sie erneut herunterzuladen.

bearbeiten: Ich sollte hinzufügen, wenn eine der Unterschlüsselsignaturen, die Sie wiederherstellen möchten, von einem der anderen Unterschlüssel stammt, sollten sie wahrscheinlich weggelassen werden, da sie in ihrem neuen Kontext keinen Sinn ergeben. Tatsächlich würde ich überprüfen, ob Unterschlüssel normalerweise überhaupt signiert sind oder ob nur der Hauptschlüssel normalerweise signiert ist.

1
petiepooo

Vielen Dank an Breakingbits für die gründliche Anleitung. Die verlorenen/defekten Nutzungsflags können mit einem neuen Selbstsig korrigiert werden. Meine Forschung ergab mehrere Beiträge in gnupg-Benutzern zu diesem Thema, die alle im Wesentlichen sagten "nicht unterstützt, aber Sie können den Code bearbeiten." Ein von einem anderen Thread zitierter Beitrag lieferte eine grobe Skizze einer Codelösung, die jedoch nicht funktioniert. (Dies ist das (*p) &= ~2 post; Zumindest in Gnupg-1.4 hat Ihr lokales GPG Ihren Schlüssel so analysiert, als ob Sie die Verwendungsflags geändert hätten, aber Ihr Schlüsselmaterial nicht geändert und es funktioniert nicht im GPG eines anderen, was Sie wollen Letztendlich.)

Da ich keine vorhandenen Lösungen gefunden habe, habe ich einen Patch für gnupg-1.4 geschrieben, um Nutzungsflags wirklich zu korrigieren, indem fast willkürliche Änderungen an Nutzungsflags in --edit-key zugelassen wurden. Es ist nicht erforderlich, den Ablauf zu ändern. Dies ist möglicherweise ein häufiger Trick, um ein Selfsig-Update zu erzwingen. Sie finden es hier, wenn Sie interessiert sind: https://github.com/xdgc/gnupg/tree/dgc/usage-1-4 .

1
dgc