Migration de clés principales GPG en tant que sous-clés vers une nouvelle clé principale

Question

Actuellement, j'ai 3 paires GPG privées qui sont toutes des clés principales. Je veux convertir ces clés en sous-clés pour une nouvelle paire de clés (et les conserver dans le coffre-fort).

J'ai lu le fil suivant http://atom.smasher.org/gpg/gpg-migrate.txt qui invoque une sorte de piratage du fichier binaire pour convertir une clé principale en une sous-clé et la remplacer avec un autre.

Est-il possible de combiner mes différentes clés en une nouvelle paire de clés unique afin qu'elles restent valides, et je peux recommander aux gens de signer ma clé principale, donc je n'ai pas à craindre de perdre ma clé secrète.

Ce que j'ai

Ici, j'ai 3 clés différentes (la clé privée est disponible).

$ 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

Ce que je veux

J'aime convertir ces clés en sous-clés et les déplacer vers une nouvelle clé principale. Il devrait plutôt ressembler à ceci:

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

Est-ce même possible de le faire? Ou sont mon meilleur espoir de révoquer mes 3 clés et de recommencer à zéro et de créer une nouvelle clé qui convient à mon utilisation.

Ce que j'ai fait jusqu'à présent

En utilisant les instructions de http://atom.smasher.org/gpg/gpg-migrate.txt

J'ai réussi à exporter et à extraire mes clés à l'aide de gpgsplit. J'ai également changé le secret_key en secret_subkey en changeant le premier octet från 0x95 en 0x9d

Alors que pgpdump dit que le secret est une sous-clé secrète

~/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) ...

J'ai ensuite fusionné toutes les clés ensemble dans une nouvelle clé ma concaténation des fichiers.

$ 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

Ce qui n'a pas l'air si mal. Mais si j'importe mes clés depuis le serveur de clés gpg2 --recv-keys 712A2BBD 72838B89 AC349218 pour récupérer les signatures. Cela se transforme en ceci:

$ 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

Ce qui reste

Après cela, j'ai 4 clés publiques dans mon trousseau de clés. Je voulais déplacer ces clés afin qu'elles dépendent de la clé principale CB577A43 comme ci-dessus sous Ce que je veux.

breakingbits · Answer

Cela peut être fait.

Les instructions sur atom.smasher.org/gpg/gpg-migrate.txt sont maintenant obsolètes.

Essaye ça. Comme toujours, faites des sauvegardes, car il est très facile de tout gâcher.

Voici donc vos "anciennes" clés:

$ 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

Et vous avez créé une nouvelle "clé principale" qui n'a pas de sous-clés:

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

Par souci de simplicité, je ne répéterai la procédure qu'en utilisant la première de vos "anciennes" clés:

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

En utilisant la même procédure, vous pouvez tous les ajouter. Je vous recommande de les ajouter tous en même temps, car chaque fois que vous cassez les clés puis les réassemblez, vous devez recréer les signatures de liaison, ce qui est pénible.

1. Utilisez gpgsplit pour diviser la "vieille" clé en ses paquets constitutifs.

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

Regardez maintenant les fichiers qu'il a créés:

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

Le premier fichier, "712A2BBD_000001-005.secret_key" contient le paquet de la clé privée principale ( balise de type de paquet 5 , d'où le "005") de votre "ancienne" clé, "712A2BBD". (Vous en aurez besoin, mais vous devrez le convertir en sous-clé si vous souhaitez le migrer dans votre nouvelle "clé principale". Dans les clés générées à l'aide des paramètres standard sur GPG, la clé privée principale a normalement des indicateurs d'utilisation "S" pour signe et "C" pour certifier, et n'a pas "E" pour chiffrer, ce qui est normalement la raison pour laquelle la clé est générée avec une sous-clé "E". Cependant, en raison de la procédure que nous utilisons, quand finalement la clé principale est transformé en sous-clé et migré vers votre nouvelle "clé principale", tous les indicateurs d'utilisation ("SCEA") seront activés. Ceci le rend probablement moins sécurisé , et c'est probablement un comportement à éviter. )

Le deuxième fichier, "712A2BBD_000002-013.user_id", est le paquet pour l'ID utilisateur ( balise de type de paquet 1 ). (Vous n'en aurez pas besoin).

Le troisième fichier, "712A2BBD_000003-002.sig", est une signature de liaison ( balise de type de paquet 2 ) pour ces paquets. (Vous n'en aurez pas besoin).

Le quatrième fichier est le paquet de la sous-clé secrète (F0B63FDA) ( balise de type de paquet 7 ). (Vous en aurez besoin. En règle générale, une sous-clé comme celle-ci a l'indicateur d'utilisation "E", ce qui signifie qu'elle est uniquement destinée au chiffrement. Cependant, lors de son importation sur votre nouvelle "clé principale", elle acquiert tous les indicateurs d'utilisation , ("SCEA"), ce qui est probablement pas une bonne chose .)

Le cinquième fichier, "712A2BBD_000005-002.sig", est la signature de liaison ( balise de type de paquet 2 ) pour la sous-clé. Vous n'en aurez pas besoin.

Enregistrez les deux fichiers dont vous avez besoin et supprimez les autres.

2. Changez la clé principale (712A2BBD) en sous-clé.

Vous n'avez rien à faire avec la sous-clé (F0B63FDA) pour la migrer vers votre nouvelle "clé principale", mais la clé principale (712A2BBD) de votre ancienne clé doit être modifiée afin de la faire fonctionner.

Ouvrez la clé principale, "712A2BBD_000001-005.secret_key", dans un éditeur capable d'effectuer des modifications hexadécimales ou binaires. J'ai utilisé ghex :

$ ghex 712A2BBD_000001-005.secret_key

Si vous utilisez un éditeur hexadécimal, le premier octet sera "95". Changez-le en "9D".

Si vous utilisez un éditeur binaire, le premier octet sera "10010101". Remplacez-le par "10011101".

Enregistrez-le, puis utilisez pgpdump pour voir si vous avez réussi à le remplacer par une sous-clé. Si vous avez réussi, vous verrez la sortie suivante:

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

**3. Ajoutez une sous-clé "factice" à votre nouvelle "clé principale" pour chacun des sous-clés que vous souhaitez ajouter.**

Tout comme dans le tutoriel à atom.smasher.org , vous devrez créer de nouvelles sous-clés "factices" sur votre "clé principale" afin de vous assurer que vous avez des signatures de liaison sur la clé principale qui peuvent accueillir (au moins au début) les sous-clés en migration.

Considérez-le comme la création de "slots" pour les anciennes sous-clés. Vous aurez besoin d'autant d'emplacements que de clés que vous souhaitez ajouter.

Dans le présent exemple, nous créerons deux sous-clés factices, mais si vous souhaitez ajouter toutes les clés que vous avez répertoriées dans votre message d'origine, vous voudrez en créer six.

$ 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

Assurez-vous, en passant par l'assistant de génération de sous-clé (qui est en mode expert, grâce à l'option --expert ci-dessus) que lorsque vous générez votre nouvelle sous-clé "factice", elle est de même ...

force de clé (2048, 4096, etc.)
type (DSA, RSA, elgamal)
utilisation (crypter, signer)

... comme sous-clé que vous avez l'intention d'ajouter dans cet "emplacement".

Puisque nous ajoutons deux sous-clés, nous terminons avec deux nouvelles sous-clés "factices" sur la "clé principale". Sauvegarder et quitter:

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. Divisez votre nouvelle "clé principale" - avec ses nouvelles sous-clés - en ses paquets constitutifs.

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

Vous devriez vous retrouver avec quelque chose comme ceci:

$ 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**

Les cinquième et septième fichiers (ceux que j'ai mis dans ** s) sont les paquets de signature de liaison de clé de sous-clé qui ont été générés lorsque vous avez généré les "sous-clés factices". Vous en aurez besoin.

Les quatrième et sixième fichiers sont les paquets de "sous-clé factice" réels. Ils peuvent maintenant être supprimés en toute sécurité (les seuls fichiers que vous devez supprimer.)

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

5. "Insérez" vos "sous-clés de migration" dans la clé principale partagée.

Les étapes un et deux vous ont laissé deux fichiers:

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".)

Maintenant, copiez-les dans le dossier avec les constituants fractionnés de la "clé principale" et renommez ces fichiers afin qu'ils remplacent les fichiers "sous-clé factice" que nous venons de supprimer.

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

Vous devriez à nouveau avoir sept fichiers (dans cet exemple), mais les fichiers quatre et six sont maintenant vos anciennes clés, tous définis et prêts à devenir des sous-clés de votre nouvelle clé principale.

$ 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. Concaténer les fichiers en fichiers de clés privées et publiques, prêts pour l'importation

Rassemblez les fichiers afin qu'ils soient concaténés consécutivement en fichiers uniques, pour faciliter l'importation plus tard.

$ 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

Utilisez la même commande, mais dirigez la sortie vers gpgsplit afin de créer des homologues publics, avant de rediriger vers un nouveau fichier:

$ 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. Sauvegardez votre trousseau de clés, puis supprimez les "anciennes" ET "clés principales", publiques et privées, de votre trousseau de clés.

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

8. Téléchargez et compilez gnupg-1.2.0.

Récemment, chaque fois que quelqu'un essaie de suivre le didacticiel sur atom.smasher.org , le problème qu'ils rencontrent est qu'avec les dernières versions de gpg, une fois qu'ils ont réassemblé la clé et l'ajoutée à leur trousseau, le les sous-clés ajoutées 1) n'ont aucun indicateur d'utilisation et 2) elles ne peuvent pas réinitialiser la date d'expiration, comme indiqué dans le tutoriel atom.smasher.org , une étape nécessaire pour créer de nouvelles signatures de liaison de touches valides. Le résultat est qu'après un cycle d'exportation/importation, les clés sont considérées comme invalides par GPG et disparaissent du trousseau de clés privé.

Pour importer avec succès les clés, vous devez télécharger et construire une ancienne version de gnupg: ne version de 2002 rien de moins. Une fois que vous l'avez construit, vous pourrez réinitialiser les dates d'expiration sur les nouvelles clés et recréer avec succès des raccourcis clavier valides pour les clés.

Téléchargez l'ancien gnupg.

$ 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

Accédez au dossier g10, qui contient votre nouveau fichier binaire gpg

$ cd g10

Afin d'utiliser ce binaire, au lieu de la construction de gpg à l'échelle du système, qui est plus récente, vous devez taper le chemin absolu vers le binaire. Si vous êtes dans le même dossier, utilisez ./gpg, par exemple:

$ ./gpg --list-keys

8. Ajoutez le nouveau fichier "clé principale" assemblé avec les sous-clés importées à vos trousseaux de clés publics et privés.

N'importez pas les clés de manière normale, car les signatures de liaison de clés ne sont pas extraites, ce qui fait que les sous-clés importées n'importeraient pas de manière normale. Au lieu de cela, placez les fichiers à la fin de vos porte-clés publics et privés.

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

Vérifiez qu'ils y sont entrés en utilisant le gnupg-1.2.0 pour lister les clés:

$ ./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. Modifiez les clés à l'aide de gnupg-1.2.0.

Assurez-vous de revenir au dossier de génération pour gnupg-1.2.0/g10 et invoquez le binaire créé pour modifier votre clé principale nouvellement importée et nouvellement assemblée, avec vos anciennes sous-clés importées:

$ ./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

Tout d'abord, réinitialisez les mots de passe.

Command> passwd

Il est probable que toutes vos anciennes clés avaient des mots de passe différents de votre nouvelle clé principale. Si vous réinitialisez le mot de passe maintenant, il vous demandera tour à tour chacun des mots de passe des anciennes clés (ainsi que l'ID de la sous-clé) et lorsque vous les aurez tous correctement entrés, il vous demandera une nouvelle clé. Une fois cela fait, ils auront tous le même mot de passe, évitant les bizarreries plus tard.

Ensuite, réinitialisez la date d'expiration sur TOUTES les clés. Commencez par la clé principale principale:

Command> expiry

Et ensuite, progressez dans chacune des sous-clés, en modifiant la date d'expiration de chacune d'entre elles.

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

Etc

Assurez-vous de le changer en une valeur sur laquelle il n'était pas déjà activé, sinon il n'y aura aucun changement. Vous pouvez la rétablir ultérieurement à sa valeur d'origine: ce qui est maintenant nécessaire est une modification, afin que gpg-1.2.0 puisse créer de nouvelles signatures de liaison de sous-clé.

Une fois que tout cela est fait, enregistrez.

Command> save

gnupg-1.2.0 va quitter et enregistrer les nouvelles signatures de liaison de touches, validant la migration de vos anciennes clés vers votre nouvelle clé principale.

10. Modifiez maintenant les clés en utilisant le gnupg standard (actuel), pour voir si cela a fonctionné.

Ouvrez la même clé pour l'édition à l'aide de la version standard de gpg à l'échelle du système, pour voir si cela a fonctionné. Si cela a fonctionné, vous verrez deux choses:

Les dates d'expiration seront les nouvelles dates d'expiration que vous venez de modifier à l'étape 9, et non les dates d'origine.
Les drapeaux d'utilisation à droite des sous-clés afficheront "utilisation: SCEA"

.

$ 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

Si cela n'a pas fonctionné, les indicateurs d'utilisation seront vides et la date d'expiration affichera désormais la modification que vous venez d'apporter à l'étape 9.

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

Enfin, vous devez le faire passer par un cycle d'exportation/importation et supprimer les clés entre les deux. S'il survit à cela, la procédure a fonctionné.

$ 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. Tâches finales.

En supposant que cela fonctionne, vous devrez maintenant certification croisée vos sous-clés, afin qu'elles puissent créer et vérifier des signatures.

$ gpg --edit-key CB577A43

Et à partir de l'invite d'édition de gpg:

gpg> cross-certify

Vous devrez également réinitialiser la confiance:

gpg> trust

Enfin, assurez-vous de tester la clé rigoureusement, pour vous assurer qu'elle fonctionne avant de la distribuer. Je me réfère au tutoriel atom.smasher.org pour ces étapes finales:

vérifiez toutes les dates d'expiration et les préférences. certaines de ces opérations peuvent avoir modifié vos dates d'expiration et vos préférences; réinitialiser si nécessaire.
tester tous les composants clés pour la création et la vérification des signatures et le chiffrement/déchiffrement. utilisez le bang (!) pour forcer chaque (sous) clé: créez et vérifiez les signatures:
$ date | gpg -u '712A2BBD!' --clearsign | gpg -v --verify $ date | gpg -u 'F0B63FDA!' --clearsign | gpg -v --verify 
crypter décrypter:
$ date | gpg -ear '712A2BBD!' | gpg -v --decrypt $ date | gpg -ear 'F0B63FDA!' | gpg -v --decrypt 
après avoir testé les clés localement, envoyez votre nouvelle clé publique à une ou deux personnes et testez tous les composants clés (en vous envoyant des messages signés/cryptés à l'aide de tous les composants clés). assurez-vous qu'ils ont d'abord supprimé (de leurs trousseaux) votre ancienne clé! et assurez-vous qu'ils comprennent que la clé ne doit PAS être distribuée tant que toutes les fonctions ne sont pas vérifiées pour fonctionner!

lors de la mise en circulation de la nouvelle clé, c'est probablement une bonne idée de faire expirer/révoquer l'ancienne clé. inclure un commentaire de révocation qui spécifie le nouvel ID de clé et les instructions pour supprimer l'ancienne clé du trousseau.

note sur la révocation de clé: selon les normes OpenPGP, une révocation générée par une sous-clé sera ignorée, sauf si cette sous-clé a été désignée (par la clé primaire) comme clé de révocation. GnuPG semble se comporter correctement, mais certaines versions de PGP (tm) peuvent ne pas l'être. si quelqu'un prétend que votre nouvelle clé a été révoquée, retirez ensuite toutes vos clés anciennes et actuelles de son trousseau: puis réimportez votre ou vos clés actuelles.

kirelagin · Answer

Il existe un moyen facile de le faire à partir, si je ne me trompe pas, de GnuPG 2.1. Vous venez de créer votre nouvelle clé primaire, puis ajoutez tout autre clé existante en tant que sous-clé.

Ici, j'ai une vieille clé:

$ 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

Je crée d'abord une clé primaire complètement nouvelle:

$ 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]

(J'ai utilisé --quick-generate-key pour la simplicité. Bien sûr, vous pouvez aller avec --generate-key ou --full-generate-key si vous le souhaitez.)

Ensuite, je vais modifier la nouvelle clé en utilisant le --expert drapeau:

$ 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>

J'utilise la sous-commande addkey et à cause de --expert flag cela me donnera une option pour ajouter une clé existante en utilisant son keygrip (c'est l'option 13 dans mon exemple, mais les nombres peuvent changer, j'ai donc choisi d'utiliser l'alias stable keygrip):

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>

(Lorsque vous êtes interrogé sur les actions autorisées, ajustez correctement les fonctionnalités clés car elles seront toujours par défaut signées et chiffrées.)

De cette façon, vous pouvez ajouter toutes les anciennes clés primaires et leurs sous-clés à votre nouvelle clé. Et n'oubliez pas de save à la fin.

Vous pouvez vérifier qu'il s'agit bien de la même clé en comparant les poignées:

$ 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

felixphew · Answer

Malheureusement, votre meilleure option serait de révoquer les clés, d'en créer une nouvelle avec les sous-clés souhaitées et de les télécharger sur le serveur de clés. J'ai essayé de faire cette opération de fractionnement et de fusion il y a quelques années et j'ai rencontré des problèmes similaires à vous. J'ai finalement rencontré un excellent article montrant pourquoi cela ne fonctionne pas, mais je n'arrive pas à le trouver. Si je le fais, je posterai le lien.

petiepooo · Answer

Cela peut simplement être une question de suppression des sous-clés de votre serveur de clés, car je pense que lorsque vous essayez d'importer les signatures, vous écrasez les types de clés à leur valeur d'origine.

Si vos clés consolidées n'ont pas les signatures que vous attendez, vous devrez peut-être vérifier qu'elles se trouvent dans les clés que vous fractionnez et qu'elles sont rajoutées correctement lors du réassemblage. Est-ce peut-être un problème de commande lorsque vous les concaténez? Ou manque-t-il des signatures du maître qui signe les sous-clés lors de leur réassemblage (type de sig 0x18: sig de liaison de sous-clé)?

Je suggérerais de créer une nouvelle clé principale avec trois sous-clés exactement comme ce à quoi vous voulez que votre produit final ressemble, puis de le vider ou de le diviser pour voir comment il est construit, et enfin d'assembler votre clé principale d'origine avec des sous-clés dans le même ordre avec tous les mêmes pièces. Faites attention aux types de signature dans pgpdump, car vous devrez peut-être en créer certains. gpg --edit-key peut aider à cela et à vérifier les signatures des clés.

Poussez ensuite vos clés mises à jour sur le serveur avant d'essayer de les télécharger à nouveau.

edit: Je devrais ajouter que si l'une des signatures de sous-clé que vous essayez de restaurer provient de l'une des autres sous-clés, elles devraient probablement être omises, car elles n'ont pas de sens dans leur nouveau contexte. En fait, je vérifierais que les sous-clés sont normalement signées du tout, ou si seule la clé principale est normalement signée.

dgc · Answer

Merci à Breakbits pour la procédure détaillée. Les indicateurs d'utilisation perdus/cassés peuvent être corrigés avec un nouveau selfsig. Ma recherche a montré plusieurs articles dans gnupg-users sur le sujet, tous disant essentiellement "non pris en charge mais vous pouvez modifier le code". Un article cité par un autre thread a fourni un aperçu d'une solution de code, mais cela ne fonctionne pas en fait. (C'est le (*p) &= ~2 Publier; dans gnupg-1.4 récent au moins, cela fait que votre gpg local analyse votre clé pour ressembler à si vous avez changé les indicateurs d'utilisation, mais ne change pas réellement votre matériau de clé et cela ne fonctionnera pas dans le gpg de quelqu'un d'autre, ce que vous voulez après tout.)

Comme je n'ai trouvé aucune solution existante, j'ai écrit un correctif pour gnupg-1.4 pour vraiment corriger les indicateurs d'utilisation en permettant des modifications d'indicateur d'utilisation presque arbitraires dans --edit-key. Il ne nécessite pas de modification de l'expiration, ce qui peut être une astuce courante pour forcer une mise à jour selfsig. Vous pouvez le trouver ici si vous êtes intéressé: https://github.com/xdgc/gnupg/tree/dgc/usage-1-4 .