Thanks for this fast, complete and clear answer. I am going to see if I can still pick up somewhere or just remove all I did and start all over by following your steps.
This is the confirmation I needed! Thanks! On 8/19/22 15:25, Andrew Gallagher wrote: > On 19 Aug 2022, at 13:48, kho via Gnupg-users <gnupg-users@gnupg.org> wrote: >> 5. What is at the end the best way to setup 2 smartcards that can be >> used in encryption, signing and decryption? And additionally both >> smartscard should work, I have 2 smartcards for redundancy. > If you want the two smartcards to be redundant copies of each other, then > they MUST contain exactly the same key material. It is possible to generate > multiple signing/authentication subkeys that will be treated the same for > practical purposes, since most software will try each valid sig/auth-capable > (sub)key in turn during verification. There is no equivalent ability for > encryption subkeys, as clients will encrypt to only the most recent valid > encryption subkey. If you lose/break the smartcard with the only copy of an > encryption subkey then there is no way to recover. > > You can save the same key material to multiple smartcards using the gnupg > command line interface: > > 1. Run gnupg and follow the usual process for generating (sub)keys, but > “save” to save and exit before transferring subkeys to the smartcard. This > ensures that you have a copy on disk before continuing. > > 2. Run gnupg again and copy the subkey(s) to the card, but afterwards you > should say “quit” to exit *without* saving (not “save”). That way the subkeys > will not be deleted from disk and you can use them again. > > 3. Repeat step 2 for the second (third, fourth,…) smartcard. Only choose > “save” to save-and-exit after copying to the last smartcard, however be aware > that “last” in this context really means “last”. No take-backs. > > If you have to generate a new subkey for whatever reason (say you had to > revoke the previous one) you must follow a similar save/quit sequence, > remembering the order “run, generate, save, run, copy, quit, run, copy, quit, > … run, copy, save" > > To keep open the possibility of provisioning extra cards in the future, you > could back up your entire .gnupg directory to a secure offline storage medium > (such as an encrypted thumb drive) after generating the keys but before > transferring to smartcard(s). Or you could perform the whole process of > generating and managing your keys using a secure live system such as Tails > with an encrypted persistent partition (remembering to “quit” after copying > even the last time so that there is always a copy on disk). If you do either > of these you only need one smartcard, so long as you don’t mind waiting for a > replacement smartcard to arrive in the post if your original breaks. > > On any given machine, gnupg will only ask for one smartcard. You should > therefore consider one smartcard your working copy and one your emergency > backup (if you have multiple machines, you could assign different primary > cards to each machine). To force gnupg to ask for the other smartcard, you > can delete the stub `.key` files under ~/.gnupg/private-keys-v1.d (on > Linux/Mac, I forget the Windows equivalent). To work out which files to > delete, incant `gpg -K --with-keygrip` and note the “Keygrip” lines under the > three subkeys. Delete the corresponding `.key` files only, then plug in the > replacement smartcard and incant `killall gpg-agent; gpg --card-status` > (again Linux/Mac only). gnupg should now recognise the replacement card as > the primary, and will ask consistently for that one until you repeat the > process. > > A > _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
