Hi, Thanks to you and Erich for your answers.
On Sat, Dec 12, 2020 at 06:45:46PM +0100, Ingo Klöcker wrote: > > > As far as I understand it, for encryption, if I have several encryption > > subkeys, people who send me encrypted messages will encrypt for single > > subkey. > > Yes, unless they explicitly specify multiple subkeys gpg will use the most > recently created valid encryption subkey. I guess I hould better not expect others to do so. ;-) > Yes, but why a second smartcard? The reason for making a backup of the > encryption (sub)key is that this will allow you to decrypt messages even if > the smartcard dies. But if your second smartcard also dies, then all is lost > ... unless you have an off-card backup of the private encryption key. But > this > off-card backup would allow you to create a new smartcard _after_ the first > smartcard dies. So, instead of setting up two smartcards with identical > encryption keys I suggest to save the money for the second smartcard and > instead create an off-card backup of the private encryption key that you > store > somewhere safe (see Erich's mail). To be honnest, I don’t feel comfortable with storing an off-card backup of my private encryption card. My inner feeling is that it defeats the point of using a smartcard: if someone finds it, it can easily be copied (without me knowing it was copied) and it is protected with a passphrase with limited entropy (because I can’t remember a random 128-bit number). My idea was that there was little chance that a smartcard fails (Werner Koch told me that the failure I experienced was exceptionnal) and if it does I can set up a new encryption key and, using the second smartcard, decrypt all the files that were encrypted for the old key and re-encrypt them for the new key. Another idea would be to encrypt the off-card backup of the encryption key with the encryption key. I think it would be safer than having it protected with a passphrase. Then, if a smartcard fails, I get a new one, and then use the second smartcard to decrypt the off-card backup and then send it to the new card. > Yes, but what purpose serves the second smartcard? Again, you can easily > setup > a replacement smartcard _after_ the first smartcard dies. Typically, you > would > create the signature (sub)key on-card to avoid any risk of compromise of the > private key. I agree that there is no problem with creating a replacement signature subkey after the previous one failed. But if I use two smartcards to store the encryption subkey, I think I should better use both (so I can detect if one fails), and then it seems to me it would be more comfortable to also have a sigature subkey on each. > > As a bonus question: given that my “master” private key is also stored > > on a smartcard, is there a way to ask GnuPG to generate a signature > > subkey on a second smartcard, while signing it with the first smartcard? > > Yes, but only with the unreleased development version of GnuPG. With 2.2.25 > trying to add a subkey from an existing key from card failed here. There have > been quite some fixes with regard to smartcard support in the development > version in the last few weeks. > > What I did: > Remove the first smartcard. Insert the second smartcard. Then > $ gpg --edit-key mas...@example.net > gpg (GnuPG) 2.3.0-beta1490; Copyright (C) 2020 Free Software Foundation, Inc. > [...] > sec ed25519/B16F599516474ABA > created: 2020-08-03 expires: 2022-08-03 usage: SC > card-no: [s/n of first card] > trust: ultimate validity: ultimate > sub cv25519/2BBE9540CAF56DC9 > created: 2020-08-03 expires: never usage: E > [ultimate] (1). mas...@example.net > > gpg> addkey > Secret parts of primary key are stored on-card. > Please select what kind of key you want: > (3) DSA (sign only) > (4) RSA (sign only) > (5) Elgamal (encrypt only) > (6) RSA (encrypt only) > (10) ECC (sign only) > (12) ECC (encrypt only) > (14) Existing key from card > Your selection? 14 > Serial number of the card: D2760001240100000006090745820000 > Available keys: > (1) 930509C5F5BD42B2ABCB4C7BDC2FD64BE59086CE OPENPGP.1 rsa2048 (cert,sign*) > (2) AEA62514505EBDDB4C2FF8AF27B02F221ECAFBCE OPENPGP.2 rsa2048 (encr*) > (3) 56EBCBEEA72DBF1BFAFE583F7FF36CBCB895C265 OPENPGP.3 rsa2048 (sign,auth*) > Your selection? 1 > 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) > Key does not expire at all > Is this correct? (y/N) y > Really create? (y/N) y > -> "Please insert the card with serial number: [s/n of first card]" > -> "Please unlock the card" [s/n of first card] > -> "Please unlock the card" [s/n of second card] Do these step work if I have both cards inserted (in 2 readers) or would I have to remove one card to insert the other one? > sec ed25519/B16F599516474ABA > created: 2020-08-03 expires: 2022-08-03 usage: SC > card-no: [s/n of first card] > trust: ultimate validity: ultimate > sub cv25519/2BBE9540CAF56DC9 > created: 2020-08-03 expires: never usage: E > ssb rsa2048/06B697821DAABF4B > created: 2020-12-04 expires: never usage: S > card-no: [s/n of first [sic] card] <-- This is a bug. > [ultimate] (1). mas...@example.net > > gpg> save > > Now let's try to sign (and immediately verify) something. > $ gpg --clearsign | gpg --verify > bla > ^D > -> "Please insert the card with serial number: [s/n of first [sic] card]" > -> I insert the second (!) card Hmmm… That’s a funny bug… You mean gnupg asks for the first card, but it needs and accepts the second one? Just curious, do you know how this is possible? I might understand that it could store the wrong s/n is the subkey stub, but why does it accept the card whose s/n does not match? Can’t you then fix this by deleting the stub and then learning the second card? > -> "Please unlock the card" [s/n of second card] > gpg: Signature made Sa 12 Dez 2020 18:35:47 CET > gpg: using RSA key AF440A8368A6C258DB22AC2C06B697821DAABF4B > gpg: Good signature from "mas...@example.net" [ultimate] > > -> Success! Thanks for the explanation about that incoming feature. It looks great! :-) Cheers, -- Nicolas _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
