it-swarm-eu.dev

Migrazione delle chiavi master GPG come sottochiavi nella nuova chiave master

Attualmente ho 3 coppie GPG private che sono tutte chiavi principali. Voglio convertire queste chiavi in ​​sottochiavi per una nuova coppia di chiavi (e tenerla nel Vault).

Ho letto il seguente thread http://atom.smasher.org/gpg/gpg-migrate.txt che invoca una sorta di hacking del file binario per convertire una chiave master in una sottochiave e sostituirla con un altro.

È possibile combinare le mie chiavi diverse in una nuova coppia di chiavi singole in modo che rimangano valide, e posso indirizzare le persone a firmare la mia chiave master, quindi non devo aver paura di perdere la mia chiave master segreta.

Quello che ho

Qui ho 3 chiavi diverse (la chiave privata è disponibile).

$ 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

Quello che voglio

Mi piace convertire queste chiavi in ​​sottochiavi e spostarle in una nuova chiave principale. Dovrebbe essere simile a questo invece:

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

È anche possibile farlo? Oppure sono la mia migliore speranza di revocare i miei 3 tasti e ricominciare da zero e creare un nuovo tasto adatto al mio uso.

Cosa ho fatto finora

Utilizzando le istruzioni di http://atom.smasher.org/gpg/gpg-migrate.txt

Sono riuscito a esportare ed estrarre le mie chiavi usando gpgsplit. Ho anche cambiato secret_key in secret_subkey modificando il primo byte da 0x95 a 0x9d

Quindi quel pgpdump dice che il segreto è una sottochiave segreta

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

Ho quindi unito tutte le chiavi insieme in una nuova chiave per concatenare i file.

$ 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

Che non sembra così male. Ma se importare le mie chiavi dal keyserver gpg2 --recv-keys 712A2BBD 72838B89 AC349218 per recuperare le firme. Si trasforma in questo:

$ 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

Cosa rimane

Dopo questo ho 4 chiavi pubbliche nel mio portachiavi. Volevo spostare questi tasti in modo che dipendano dalla chiave master CB577A43 come sopra in Cosa voglio.

42
lz.

In realtà può essere fatto.

Le istruzioni su atom.smasher.org/gpg/gpg-migrate.txt sono obsolete.

Prova questo. Come sempre, fai dei backup, perché è davvero facile rovinarlo.


Quindi queste sono le tue "vecchie" chiavi:

$ 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

E hai creato una nuova "chiave master" che non ha sottochiavi:

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

Per semplicità, proverò la procedura solo usando il primo dei tuoi "vecchi" tasti:

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

Utilizzando la stessa procedura, è possibile aggiungerli tutti. Ti consiglio di aggiungerli tutti allo stesso tempo, perché ogni volta che rompi i tasti e poi li ricomponi devi ricreare le firme vincolanti, e questo è un dolore.


1. Usa gpgsplit per dividere la chiave "vecchia" nei suoi pacchetti costitutivi.

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

Ora guarda i file che ha creato:

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

Il primo file, "712A2BBD_000001-005.secret_key" contiene il pacchetto per la chiave privata principale ( tag del tipo di pacchetto 5 , quindi "005") della tua "vecchia" chiave "712A2BBD". (Ne avrai bisogno, ma dovrai convertirlo in una sottochiave se vuoi migrarlo nella tua nuova "chiave principale". Nelle chiavi generate usando le impostazioni standard su GPG, la chiave privata principale normalmente ha flag di utilizzo "S" per segno e "C" per certificare e non ha "E" per crittografare, motivo per cui la chiave viene generata con una sottochiave "E". Tuttavia, a causa della procedura che stiamo utilizzando, quando alla fine la chiave principale è trasformato in una sottochiave e migrato nella nuova "chiave principale", avrà tutti i flag di utilizzo ("SCEA") abilitati. Questo probabilmente lo rende meno sicuro , ed è probabilmente un comportamento da evitare. )

Il secondo file, "712A2BBD_000002-013.user_id", è il pacchetto per l'id utente ( tag type pacchetto 1 ). (Non avrai bisogno di questo).

Il terzo file, "712A2BBD_000003-002.sig", è una firma vincolante ( tag type del pacchetto 2 ) per questi pacchetti. (Non avrai bisogno di questo).

Il quarto file è il pacchetto per la sottochiave segreta (F0B63FDA) ( tag type pacchetto 7 ). (Ne avrai bisogno. In genere, una sottochiave come questa ha il flag di utilizzo "E", il che significa che è solo per la crittografia. Tuttavia, nel processo di importazione nella nuova "chiave principale" acquisirà tutti i flag di utilizzo , ("SCEA"), che è probabilmente non è una buona cosa .)

Il quinto file, "712A2BBD_000005-002.sig", è la firma di associazione ( tag type del pacchetto 2 ) per la sottochiave. Non ne avrai bisogno.

Salvare i due file necessari e rimuovere gli altri.


2. Cambia la chiave principale (712A2BBD) in una sottochiave.

Non è necessario eseguire alcuna operazione sulla sottochiave (F0B63FDA) per migrarla nella nuova "chiave principale", ma è necessario modificare la chiave principale (712A2BBD) della vecchia chiave per farla funzionare.

Aprire la chiave principale, "712A2BBD_000001-005.secret_key", in un editor in grado di apportare modifiche esadecimali o binarie. Ho usato ghex :

$ ghex 712A2BBD_000001-005.secret_key

Se si utilizza un editor esadecimale, il primo byte sarà "95". Modificalo in "9D".

Se si utilizza un editor binario, il primo byte sarà "10010101". Modificalo in "10011101".

Salvalo e poi usa pgpdump per vedere se sei riuscito a cambiarlo in una sottochiave. Se hai avuto successo, vedrai il seguente output:

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

3. Aggiungi una sottochiave "fittizia" alla tua nuova "chiave principale" per ciascuno delle sottochiavi che desideri aggiungere.

Proprio come nel tutorial su atom.smasher.org , dovrai creare nuove sottochiavi "fittizie" sulla tua "chiave principale" per assicurarti di avere firme di associazione dei tasti sulla chiave principale che possano accogliere (almeno all'inizio) le sottochiavi migranti.

Pensa a come creare "slot" in cui inserire le vecchie sottochiavi. Avrai bisogno di tutti gli slot quante chiavi vuoi aggiungere.

Nel presente esempio, creeremo due sottochiavi fittizie, ma se vuoi aggiungere tutte le chiavi che hai elencato nel tuo post originale, ne vorrai fare sei.

$ 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

Assicurati, durante la procedura guidata di generazione della sottochiave (che è in modalità esperto, grazie all'opzione --expert sopra) che quando generi la tua nuova sottochiave "fittizia", ​​è della stessa ...

  • forza chiave (2048, 4096, ecc.)
  • tipo (DSA, RSA, elgamal)
  • utilizzo (crittografare, firmare)

... come sottochiave che si desidera aggiungere in quello "slot".

Dato che stiamo aggiungendo due sottochiavi, finiamo con due nuove sottochiavi "fittizie" sulla "chiave master". Salva ed esci:

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. Dividi la tua nuova "chiave master" - insieme alle sue nuove sottochiavi - nei suoi pacchetti costitutivi.

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

Dovresti finire con qualcosa di simile al seguente:

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

Il quinto e il settimo file (quelli che ho inserito in ** s) sono i pacchetti di firme di legatura delle chiavi secondarie che sono stati generati quando sono state generate le "sottochiavi fittizie". Ne avrai bisogno.

Il quarto e il sesto file sono i pacchetti effettivi "sottochiave fittizie". Ora possono essere eliminati in modo sicuro (gli unici file da eliminare).

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

5. "Inserisci" le "sottochiavi" in migrazione nella chiave master divisa.

I passaggi uno e due ti hanno lasciato con due file:

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

Ora copiali nella cartella con i componenti divisi della "chiave master" e rinomina questi file in modo che sostituiscano i file "sottochiave fittizie" che abbiamo appena eliminato.

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

Dovresti avere ancora una volta sette (in questo esempio) file, ma i file quattro e sei sono ora le tue vecchie chiavi, tutte impostate e pronte per diventare sottochiavi della tua nuova chiave 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. Concatena i file in file di chiavi pubbliche e private, pronti per l'importazione

Metti insieme i file in modo che vengano concatenati consecutivamente in singoli file, per facilitare l'importazione in un secondo momento.

$ 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

Utilizzare lo stesso comando, ma reindirizzare l'output su gpgsplit per creare controparti pubbliche, prima di reindirizzare a un nuovo file:

$ 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. Eseguire il backup del proprio portachiavi e quindi eliminare le chiavi "vecchie" E "principali", sia pubbliche che private, dal proprio portachiavi.

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

8. Scarica e crea gnupg-1.2.0.

Di recente, ogni volta che qualcuno prova a seguire il tutorial su atom.smasher.org , il problema che incontrano è che, con le versioni più recenti di gpg, una volta che hanno riassemblato la chiave e l'hanno aggiunta al loro portachiavi, il le sottochiavi aggiunte 1) non hanno flag di utilizzo e 2) non sono in grado di reimpostare la data di scadenza, come consigliato nel tutorial atom.smasher.org , un passaggio necessario per la creazione di firme di keybinding nuove e valide. Il risultato è che dopo un ciclo di esportazione/importazione, le chiavi vengono considerate non valide da GPG e scompaiono dal portachiavi privato.

Per importare correttamente le chiavi, devi scaricare e creare una vecchia versione di gnupg: na versione dal 2002 non meno. Una volta che lo hai creato, sarai in grado di reimpostare le date di scadenza sulle nuove chiavi e ricreare correttamente le combinazioni di tasti valide per le chiavi.

Scarica il vecchio 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

Passare alla cartella g10, che contiene il binario gpg di nuova generazione

$ cd g10

Per usare questo binario, invece della build di gpg a livello di sistema, che è più recente, devi digitare il percorso assoluto del binario. Se ti trovi nella stessa cartella, utilizza ./gpg, ad esempio:

$ ./gpg --list-keys

8. Aggiungi il nuovo file "chiave master" assemblato con le sottochiavi importate ai tuoi portachiavi pubblici e privati.

Non importare le chiavi nel modo normale, perché le firme di associazione dei tasti non vengono estratte, con il risultato che le sottochiavi importate non importano nel modo normale. Invece, cat i file alla fine dei vostri portachiavi pubblici e privati.

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

Verifica che siano entrati lì usando gnupg-1.2.0 per elencare le chiavi:

$ ./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. Modifica le chiavi usando gnupg-1.2.0.

Assicurati di tornare alla cartella build per gnupg-1.2.0/g10 e invocare il file binario incorporato per modificare la chiave master appena importata e appena assemblata, completa delle vecchie sottochiavi importate:

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

Innanzitutto, reimposta le password.

Command> passwd

È probabile che tutte le tue vecchie chiavi avessero password diverse dalla tua nuova chiave principale. Se reimposti ora la password, ti verrà richiesta ciascuna delle password delle vecchie chiavi a turno (insieme all'ID della sottochiave) e una volta immesse tutte correttamente, ti chiederà una nuova chiave. Fatto ciò, avranno tutti la stessa password, evitando in seguito stranezze.

In secondo luogo, reimpostare la data di scadenza su TUTTI i tasti. Inizia con la chiave principale principale:

Command> expiry

E poi fatti strada attraverso ciascuna delle sottochiavi, modificando la data di scadenza su ciascuna di esse.

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

E così via

Assicurati di cambiarlo con un valore che non era già attivo, altrimenti non ci saranno cambiamenti. Puoi ripristinarlo al valore originale in un secondo momento: ciò che è richiesto ora è una modifica, in modo che gpg-1.2.0 possa creare nuove firme di associazione di sottochiavi.

Una volta fatto tutto ciò, salva.

Command> save

gnupg-1.2.0 uscirà e salverà le nuove firme di associazione dei tasti, convalidando la migrazione delle vecchie chiavi nella nuova chiave principale.


10. Ora modifica le chiavi usando lo standard (corrente) gnupg, per vedere se ha funzionato.

Apri la stessa chiave per la modifica usando la versione standard di gpg per tutto il sistema, per vedere se ha funzionato. Se ha funzionato, vedrai due cose:

  1. Le date di scadenza saranno le nuove date di scadenza che hai appena modificato nel passaggio 9 e non quelle originali.
  2. I flag di utilizzo a destra delle sottochiavi visualizzeranno "utilizzo: 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

Se non ha funzionato, i flag di utilizzo saranno vuoti e la data di scadenza mostrerà ora la modifica appena apportata al passaggio 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: 

Infine, è necessario sottoporlo a un ciclo di esportazione/importazione ed eliminare le chiavi in ​​mezzo. Se sopravvive a questo, la procedura ha funzionato.

$ 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. Compiti finali.

Supponendo che abbia funzionato, ora dovrai certificazione incrociata le tue sottochiavi, in modo che possano creare e verificare le firme.

$ gpg --edit-key CB577A43

E dal prompt di modifica di gpg:

gpg> cross-certify

Dovrai anche ripristinare la fiducia:

gpg> trust

Infine, assicurarsi di testare rigorosamente la chiave, per assicurarsi che funzioni prima di distribuirla. Mi riferisco al tutorial atom.smasher.org per questi passaggi finali:

  • controlla tutte le date e le preferenze di scadenza. alcune di queste operazioni potrebbero aver modificato le date e le preferenze di scadenza; ripristinare se necessario.

  • testare tutti i componenti chiave per la creazione e la verifica delle firme e la crittografia/decrittografia. usa il bang (!) per forzare ogni tasto (sub): crea e verifica le firme:

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

    codifica/decodifica:

    $ date | gpg -ear '712A2BBD!' | gpg -v --decrypt
    $ date | gpg -ear 'F0B63FDA!' | gpg -v --decrypt
    
  • dopo aver testato le chiavi localmente, inviare la nuova chiave pubblica a una o due persone e testare tutti i componenti chiave (invio reciproco di messaggi firmati/crittografati utilizzando tutti i componenti chiave). assicurati che prima cancellino (dai loro portachiavi) la tua vecchia chiave! e assicurarsi che comprendano che la chiave NON deve essere fatta circolare fino a quando tutte le funzioni non sono state verificate per funzionare!

  • quando si mette in circolazione la nuova chiave, è probabilmente una buona idea far scadere/revocare la vecchia chiave. includere un commento di revoca che specifica il nuovo ID chiave e le istruzioni per eliminare la vecchia chiave dal portachiavi.

  • nota sulla revoca della chiave: secondo gli standard OpenPGP una revoca generata da una sottochiave verrà ignorata, a meno che quella sottochiave non sia stata designata (dalla chiave primaria) come chiave di revoca. GnuPG sembra comportarsi correttamente, ma alcune versioni di PGP (tm) potrebbero non esserlo. se qualcuno afferma che la tua nuova chiave è stata revocata, rimuovi dal tuo portachiavi tutte le tue chiavi vecchie e attuali: quindi reimporta le tue chiavi correnti.

36
breakingbits

C'è un modo semplice per farlo partendo, se non sbaglio, da GnuPG 2.1. È sufficiente creare la nuova chiave primaria e quindi aggiungere qualsiasi altra chiave esistente come sottochiave.

Qui ho una vecchia chiave:

$ 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

Per prima cosa creo una chiave primaria completamente nuova:

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

(Ero solito --quick-generate-key per semplicità. Certo, puoi andare con --generate-key o --full-generate-key se desideri.)

Successivamente modificherò la nuova chiave usando il --expert bandiera:

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

Uso il sottocomando addkey e grazie al --expert flag mi darà un'opzione per aggiungere una chiave esistente usando il suo keygrip (nel mio esempio è l'opzione 13, ma i numeri possono cambiare, quindi ho scelto di usare l'alias stabile 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>

(Alla domanda sulle azioni consentite, regola correttamente le funzionalità chiave in quanto saranno sempre predefinite per firmare e crittografare.)

In questo modo puoi aggiungere tutte le vecchie chiavi primarie e le loro sottochiavi alla tua nuova chiave. E non dimenticare di save alla fine.

Puoi verificare che questa sia davvero la stessa chiave confrontando i keygrip:

$ 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

Sfortunatamente, l'opzione migliore sarebbe quella di revocare le chiavi, crearne una nuova con le sottochiavi desiderate e caricarla sul keyserver. Ho provato a fare questa cosa di scissione e fusione alcuni anni fa e ho riscontrato problemi simili a te. Alla fine mi sono imbattuto in un eccellente articolo che mostra perché non funziona, ma non riesco a trovarlo. Se lo faccio, posterò il link.

1
felixphew

Questo potrebbe essere semplicemente una questione di eliminare le sottochiavi dal tuo key server, poiché penso che quando stai provando a importare le firme, stai sovrascrivendo i tipi di chiave al loro valore originale.

Se le tue chiavi consolidate non hanno le firme che ti aspetti, potrebbe essere necessario verificare che siano nelle chiavi che stai suddividendo e che vengano aggiunte correttamente quando le riassembli. È forse un problema di ordinazione quando li stai concatenando? O ti mancano le firme del master che firma le sottochiavi quando vengono riassemblate (sig tipo 0x18: sigla sottochiave)?

Suggerirei di creare una nuova chiave master con tre sottochiavi proprio come si desidera che il tuo prodotto finale appaia, quindi scaricare o dividerlo per vedere come è costruito e infine assemblare la chiave master originale con le sottochiavi nello stesso ordine con tutti gli stessi pezzi. Prestare attenzione ai tipi di firma in pgpdump, poiché potrebbe essere necessario crearne alcuni. gpg --edit-key può essere d'aiuto in questo e nel controllare quali segni hanno le chiavi.

Quindi invia le chiavi aggiornate al server prima di provare a scaricarle di nuovo.

modifica: dovrei aggiungere, se una qualsiasi delle firme delle sottochiavi che stai provando a ripristinare proviene da una qualsiasi delle altre sottochiavi, probabilmente dovrebbero essere omesse, poiché non hanno senso nel loro nuovo contesto. In effetti, verificherei che le sottochiavi sono normalmente firmate o se solo la chiave principale è normalmente firmata.

1
petiepooo

Grazie a breakbits per la procedura dettagliata. I flag di utilizzo perso/rotto possono essere corretti con una nuova auto-configurazione. La mia ricerca ha mostrato diversi post sugli utenti di gnupg sull'argomento, tutti dicendo essenzialmente "non supportato ma è possibile modificare il codice". Un post citato da un altro thread ha fornito uno schizzo approssimativo di una soluzione di codice, ma in realtà non funziona. (Questo è il (*p) &= ~2 post; almeno in recente gnupg-1.4, fa in modo che il tuo gpg locale analizzi la tua chiave per sembrare come se avessi cambiato flag di utilizzo, ma in realtà non cambia il tuo materiale chiave e non funzionerà nel gpg di qualcun altro, che è quello che vuoi Dopotutto.)

Dato che non ho trovato soluzioni esistenti, ho scritto una patch su gnupg-1.4 per correggere realmente i flag di utilizzo consentendo modifiche quasi arbitrarie ai flag di utilizzo in --edit-key. Non richiede la modifica della scadenza, che potresti sapere è un trucco comune per forzare un aggiornamento di selfsig. Puoi trovarlo qui se sei interessato: https://github.com/xdgc/gnupg/tree/dgc/usage-1-4 .

1
dgc