Same key on different smart cards
Hi, I want to have a second and third smart card as fallback. For full disk encryption and ssh it would be ok to have different keys. But as far as I understand, for eMail signing and decryption, it needs to be the same key on all cards. I set up two crypto sticks to contain the same sub keys. But the unique id of the card seems to be stored in the private key stub (~/.gnupg/secring.gpg). Thus if I try to use the second card, I get an error telling me to insert the correct card. Is it possible to manage the same identity with multiple smart cards? Of course I could use a separate smart card with every computer and have the stub match the card, but I want to be able to use whatever smart card I have closest. And in case one breaks, just use the next one. An what is the best approach for this? Rgds Richard ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Same key on different smart cards
On Thu, 13 Dec 2012 08:43, ricu...@gmail.com said: (~/.gnupg/secring.gpg). Thus if I try to use the second card, I get an error telling me to insert the correct card. You need to delete the secret key stub and then gpg should be able to re-create it using the current card. I am not sure about the details because I am using 2.1 for a long time now. 2.1 works a bit different in this regard Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Same key on different smart cards
Am Do 13.12.2012, 08:43:53 schrieb Richi Lists: But as far as I understand, for eMail signing and decryption, it needs to be the same key on all cards. I have not checked that but I don't think so. Wouldn't make sense. When using key A, why should gpg-agent care, where key B is stored? I set up two crypto sticks to contain the same sub keys. But the unique id of the card seems to be stored in the private key stub (~/.gnupg/secring.gpg). Thus if I try to use the second card, I get an error telling me to insert the correct card. What do you want? The signing key on one smartcard, the decryption key on the other? If so, why have you stored both keys on the same card? Is it possible to manage the same identity with multiple smart cards? That is a different problem. This is not directly supported by GnuPG but possible by a workaround: After changing the smartcard you can delete the secret keys and register the smartcard afterwards. Then the card reference is updated. Hauke -- ☺ PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A few newbie questions, I'am doing this right?
On 12/13/12 at 02:21am, Hauke Laging wrote: Am Mi 12.12.2012, 19:28:18 schrieb Roy Sindre Norangshol: I'm trying to setup my gpg setup properly for the first time, and wondering if this setup seems fine: Best practice is often subjective. Indeed, fighting between security vs usability. Master keypair with only the «certificate» as it's only role, this master keypair I'll only use for: * signing someone else's key * creating a new subkey * revoking a subkey I would add signing ability at any rate and (depending on the circumstances perhaps) even encryption. This allows you to make very secure signatures. This is very useful for a key policy document (--set-policy-url). I was orginally only thinking of having 1 main key pair, hence having the main key with certificate ability. Signing I will do with my assigned signing subkey. If you do not have another key another key which is more secure then your mainkey allows you encrypt data more safely which from time to time can be useful. I don't, my plan was to have the main key to be this most secured item, which have the ability to create myself a new subkeypair if I've been unlucky and compromised. Full disk encryption does not make a system secure. Get a safe boot medium. (And store it physically secure... ;-) ) Not a bad idea :-) (planning to buy a cryptostick[2] after new years) Security is much better with a card reader which has a PIN pad. Any recommendations? cryptostick was recommended by fellow friends at the university as it was open source and fully open. And if using a cryptostick, even if attaching it to a compromised computer they will never be able to access the private key, so that's why I'm thinking of ordering one. So I've created 3 seperate subkeys for each role: * sign (2y expire) * auth (2y expire) * encryption (never) I assume two year expire on sign and auth is good and requirements me to redo sign and auth subkeypairs every each year to «show I'am alive and kicking». This can be shown by extending the expiration date of existing keys, too. One argument for expiration dates is that they stop others from using your key if you have lost the private (main) key. I use a time limit of one year. Encryption is set to never, if it gets compromised I'll have to reencrypt all my stuff that I want to keep safe anyway and wipe existing old copies. This has nothing to do with the expiration date, does it? It just sounds weird for me having to renew the encryption key, what about old documents encrypted with the old subkey? Kind of usabilty vs security. Encryption key I will only have at home, laptop and server stationed at my parents (used for mutt) which are all fully encrypted. The real danger should be online attacks. I would not consider a system secure which is used for WWW or email. Again a usability vs security, if I want to start using GPG actively I don't want having to write my email at my local pc, encrypt it and send it over to my private server to attach it. I've attached two identities (roy.sin...@norangshol.no and my current identity at work.) Is roy.sin...@norangshol.no a private address? In general I would not mix private and business addresses within a key. Yes, that's my private address (first name at last name) and I doubt I'll ever change that in my life time. Is it that bad? You could simply revoke the identity if you no longer use it. I'm just afraid if I choose a too complex setup I end up not using it at all. I thought I could create two additional subkeys (sign and auth) for use at work for my work identity, in case these subkeys gets compromised I can easily revoke these two keys and create new ones to use at work One more reason to create different mainkeys. Subkeys are not bound to UIDs. Both subkeys and UIDs are bound to the mainkey. And what if someone wants to send encrypted mail to your work account? I do not see any advantage in mixing the IDs (and environments), just problems. Not able to generate a own dedicated subkeypair for encryption if the requirements shows up for using encryption at work? (if I end up using only one main key pair) Kinda want to properly setup this before attending any kind of signing parties. Thank you in advance! Further recommendations for a proper setup: • add a UID without email (just your name and a comment; this will be valid forever) Still suggesting this even if I doubt I'll ever in my life time swap out my private email? (see comment above) • configure a preferred keyserver (--default-keyserver-url) • configure a policy URL (even if you write the real document later; --set- policy-url) • configure your cipher and digest preferences (--default-preference-list) Thanks for info, I'll dig into the manual and set these. • don't make non-local (lsign) certifications before you have finished your
Re: A few newbie questions, I'am doing this right?
Am Do 13.12.2012, 11:03:07 schrieb Roy Sindre Norangshol: I would add signing ability at any rate and (depending on the circumstances perhaps) even encryption. This allows you to make very secure signatures. This is very useful for a key policy document (--set-policy-url). I was orginally only thinking of having 1 main key pair, hence having the main key with certificate ability. Signing I will do with my assigned signing subkey. Sure you will. But that has nothing to do with my argument. There are arguments against giving the main key decryption capability (because you do not control what is encrypted for this key). But as you completely control which signatures you make I don't think there is any serious argument against signing capability. If you do not have another key another key which is more secure then your mainkey allows you encrypt data more safely which from time to time can be useful. I don't, my plan was to have the main key to be this most secured item, OK but you unnecessarily limit your benifit of this higher security to certifications. Why? Security is much better with a card reader which has a PIN pad. Any recommendations? I have a SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader. I have never had problems with it. It seems to me that this is a popular product among GnuPG users. This is the only card reader I have used so I cannot compare it to others. cryptostick was recommended by fellow friends at the university as it was open source and fully open. Doesn't replace a PIN pad... And if using a cryptostick, even if attaching it to a compromised computer they will never be able to access the private key, so that's why I'm thinking of ordering one. They will not be able to steal the key from the stick, that's correct. But the attacker is capable of using the stick without limit. Unfortunately (I don't know the reason for this policy difference) the same is true for PIN pads and encryption. But for signatures the damage can be limited. It just sounds weird for me having to renew the encryption key, what about old documents encrypted with the old subkey? I don't understand the question. The expiration date is relevant for the public keys only. OpenPGP applications refuse to encrypt for an expired key. But you can always use it for decryption. Again a usability vs security, if I want to start using GPG actively I don't want having to write my email at my local pc, encrypt it and send it over to my private server to attach it. Of course. That's why you create a key with subkeys which have limited security. That is perfectly OK. The key security has to meet the key usage and it should be well known to anyone who is affected. The aim of keys is not to increase the security requirements for the respective application. Is it that bad? You could simply revoke the identity if you no longer use it. You lose the certifications for this UID which may damage your position in the Web of Trust. I'm just afraid if I choose a too complex setup I end up not using it at all. I don't see that risk. Why should you not use OpenPGP or use it less just because you have an additional UID? Or because your key has a policy URL, preference settings and a mainky with signing ability? The only possible problem I can imagine is that you fail in creating such a key (which is very improbable IMHO). But after creation all that does not make a relevant difference in everyday use. Not able to generate a own dedicated subkeypair for encryption if the requirements shows up for using encryption at work? No. You are capable of generating a new subkey for encryption but you cannot generate one which is dedicated to work. Usually the newest subkey (the one with the newest self signature) will be chosen by all senders (both to your private and work account). The UID bound preferences don't cover the subkey to be used, just the symmetric cipher. • add a UID without email (just your name and a comment; this will be valid forever) Still suggesting this even if I doubt I'll ever in my life time swap out my private email? (see comment above) I still suggest that because I promote all keys to have this structure. So even if especially you don't have to be afraid of problems you can still be an example for others. • don't make non-local (lsign) certifications before you have finished your certification policy Thought of fetching 3 local close co-workers signatures before leaving for xmas vacation, does that affect the --set-policy-url if set later? I am not sure what you mean by fetch signatures. You can have them verify and publicly certify your key, that's not a problem. And you can verify their keys and even certify them: either locally or regularly as long as you don't export your signature to anyone. My general advice is to create a dedicated key for local signatures because it is quite unconvenient to always have to use the real
Re: A few newbie questions, I'am doing this right?
On 12/13/12 at 02:21am, Hauke Laging wrote: *snip* This is very useful for a key policy document (--set-policy-url). Could you please show me an example of how you set such a key policy document? I tried «gpg2 --edit-key 0xMyPublicKey --set-policy-url static-www-link-to-my-gpg-policy-webpage-which-is-blank-atm» without any success. Kinda had the same issues with setting my keyserver, but at least I could do it interactivly in gpg-shell. (I'll follow up rest of your questions later this evening hopefully, again: thanks for your input!) -- Roy Sindre Norangshol roy.sin...@norangshol.no ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A few newbie questions, I'am doing this right?
On 12/13/12 at 02:43pm, Roy Sindre Norangshol wrote: On 12/13/12 at 02:21am, Hauke Laging wrote: *snip* This is very useful for a key policy document (--set-policy-url). Could you please show me an example of how you set such a key policy document? I tried «gpg2 --edit-key 0xMyPublicKey --set-policy-url static-www-link-to-my-gpg-policy-webpage-which-is-blank-atm» without any success. Figured this out, it should be used when signing others public key. Doh :-) -- Roy Sindre Norangshol roy.sin...@norangshol.no ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
