Delete secret key without public key
Hi! I've got a secret key which is useless (ID AB756AEB) and I want to delete it from my keyring. This secret key has no associated public key. The problem is, that it only shows up in the gpg2 --edit-key mode after typing toggle followed by return. It doesn't show up on gpg2 --list-secret-keys. I read the FAQ and found this: http://www.gnupg.org/faq.html#q4.6 So I tried out to find the long keyID for my problematic secret key. But the --use-colons-option doesn't really work with --edit-key after a toggle, it only gives me my user IDs. gpg2 --delete-secret-key AB756AEB doesn't work either. So how can I get the long keyID or how can I delete this secret-key? Please add me as CC in replies to this Mail. Thank you very much, André = shematic output: $ gpg2 --help gpg (GnuPG/MacGPG2) 2.0.14 libgcrypt 1.4.5 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. [...] $ gpg2 --edit-key andre Geheimer Schlüssel ist vorhanden. pub 1024D/ACA3438B erzeugt: 2003-12-05 verfällt: niemals Aufruf: SC Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt sub 1536g/7469868B erzeugt: 2003-12-05 verfallen: 2010-03-08 Aufruf: E sub 2048g/8605C6C9 erzeugt: 2010-03-07 verfällt: 2012-03-06 Aufruf: E [ uneing.] (1). André Ludwig an...@bluesalamand.de [widerrufen] (2) André Ludwig an...@klabitur.de [ uneing.] (3) André Ludwig andre-lud...@gmx.de [ uneing.] (4) André Ludwig ludw...@students.uni-marburg.de Befehl toggle sec 1024D/ACA3438B erzeugt: 2003-12-05 verfällt: niemals ssb 1536g/7469868B erzeugt: 2003-12-05 verfällt: niemals ssb 2048g/AB756AEB erzeugt: 2010-03-07 verfällt: niemals WANT TO DELETE THIS ONE ssb 2048g/8605C6C9 erzeugt: 2010-03-07 verfällt: niemals (1) André Ludwig an...@bluesalamand.de (2) André Ludwig andre-lud...@gmx.de (3) André Ludwig an...@klabitur.de $ gpg2 --with-colons --list-keys andre tru::1:1268680745:1310335397:3:1:5 pub:u:1024:17:33ACE6FBACA3438B:1070622740:::u:::scESC: uid:u1267979329::3332EBD5F03657462C477121634ACECA1B92423F::André Ludwig an...@bluesalamand.de: uid:r::C27A194598C48F51B5829D63E8A4ED95C71F6DE9::André Ludwig an...@klabitur.de: uid:u1267979337::9FBFE293AE50491B3A9D79825E2EC28E0DA3C8EE::André Ludwig andre-lud...@gmx.de: uid:u1267979337::D26CA709DCA720197ECFF757A1D118968B041E9E::André Ludwig ludw...@students.uni-marburg.de: sub:e:1536:16:8125E9097469868B:1070622743:1268065682:e: sub:u:2048:16:4523360E8605C6C9:1267979156:1331051156:e: $ gpg2 --with-colons --list-secret-keys andre sec::1024:17:33ACE6FBACA3438B:1070622740::scESC uid:1267979329::3332EBD5F03657462C477121634ACECA1B92423F::André Ludwig an...@bluesalamand.de: uid:::C27A194598C48F51B5829D63E8A4ED95C71F6DE9::André Ludwig an...@klabitur.de: uid:1267979337::9FBFE293AE50491B3A9D79825E2EC28E0DA3C8EE::André Ludwig andre-lud...@gmx.de: uid:1267979337::D26CA709DCA720197ECFF757A1D118968B041E9E::André Ludwig ludw...@students.uni-marburg.de: ssb::1536:16:8xx4469868B:10xx3:1268x82:e ssb::2048:16:467x0E8605C6C9:126xx56:13xx156:e $ gpg2 --with-colons --edit-key andre Geheimer Schlüssel ist vorhanden. pub:u:1024:17:33ACE6FBACA3438B:1070622740:0::u:::sc fpr:985A4829196EE9198B530CF033ACE6FBACA3438B: sub:e:1536:16:xxx097469868B:10xx43:182:e fpr:0A02031164C31753F6614F9B8125E9097469868B: sub:u:2048:16:45xxxE8605C6C9:12xxx6:1356:e fpr:18CBAFB85E09304E13A0D523360E8605C6C9: uid:uAndré Ludwig an...@bluesalamand.de:::S9 S8 S7 S3 S2 H2 H3 Z2 Z1,mdc,no-ks-modify:1,p: uid:rAndré Ludwig an...@klabitur.de:::,no-ks-modify:2,r: uid:uAndré Ludwig andre-lud...@gmx.de:::S9 S8 S7 S3 S2 H2 H3 Z2 Z1,mdc,no-ks-modify:3,: uid:uAndré Ludwig ludw...@students.uni-marburg.de:::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1,mdc,no-ks-modify:4,: Befehl toggle uid:uAndré Ludwig an...@bluesalamand.de1,: uid:uAndré Ludwig andre-lud...@gmx.de2,: uid:uAndré Ludwig an...@klabitur.de3,: PGP.sig Description: Signierter Teil der Nachricht ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Delete secret key without public key
Am Samstag 20 März 2010 15:17:55 schrieb André Ludwig: So I tried out to find the long keyID for my problematic secret key. But the --use-colons-option doesn't really work with --edit-key after a toggle, it only gives me my user IDs. gpg2 --delete-secret-key AB756AEB doesn't work either. So how can I get the long keyID or how can I delete this secret-key? I think this solves your problem: gpg --keyid-format long --edit-key ... Hauke 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: 2.0.14 --gen-key interface nit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Sunday 21 March 2010 at 2:10:34 AM, in mid:4ba5801a.1000...@dougbarton.us, Doug Barton wrote: Howdy, Playing around with key generation there was something banging around in the back of my mind and it finally hit me: Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify Authenticate (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished The thing that stands out to me is the lack of an option to toggle the certify capability. --- Real name: Douglas Barton Email address: do...@dougbarton.us Comment: You selected this USER-ID: Douglas Barton do...@dougbarton.us Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o The Q option behaves inconsistently between these two menus. In the capabilities menu it means we're done, and all is well; in the uid section O (oh) means Ok, but Q bails out of the whole key generation process. The easiest way to fix this would probably be to change the capabilities menu since that's an --expert option. I always interpreted the capabilities menu as a sub-menu of the key generation process, so it seemed logical that quitting the sub-menu would revert to the parent menu. Are you advocating (when in the capabilities menu) an okay or save selection to keep the changes you've made and for quit to discard the changes? - -- Best regards MFPAmailto:expires2...@ymail.com Puns are bad but poetry is verse. -BEGIN PGP SIGNATURE- iQCVAwUBS6dnSaipC46tDG5pAQprVAP/VQRTNbu//skcjHhd3ucPrRL2TDIzjykm DuL5OxiQmhd45cGSKFgtZaqUm6hQrDrlowmUaGq800lZRZHnfmNGSrJA843YM5e9 lz63miC0vaZSBJ5wj7/bWk4SjQvjjx0A6KeE9hhE9f9fnRI1G2kynVIZ24SggIGc IzN8dxnTkzY= =dohn -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: 2.0.14 --gen-key interface nit
On Mar 22, 2010, at 8:48 AM, MFPA wrote: Howdy, Playing around with key generation there was something banging around in the back of my mind and it finally hit me: Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify Authenticate (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished The thing that stands out to me is the lack of an option to toggle the certify capability. That is by design, though the reason why is different for primary keys and subkeys. For primary keys, OpenPGP requires this. All primary keys must be able to certify. For subkeys, the web of trust is built between signatures on primary keys, so a certifying subkey would not actually serve any purpose (signatures from it would be ignored). Note there is no official standard web of trust document that defines this, but it is the convention that all current programs that use the web of trust adhere to. Real name: Douglas Barton Email address: do...@dougbarton.us Comment: You selected this USER-ID: Douglas Barton do...@dougbarton.us Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o The Q option behaves inconsistently between these two menus. In the capabilities menu it means we're done, and all is well; in the uid section O (oh) means Ok, but Q bails out of the whole key generation process. The easiest way to fix this would probably be to change the capabilities menu since that's an --expert option. I always interpreted the capabilities menu as a sub-menu of the key generation process, so it seemed logical that quitting the sub-menu would revert to the parent menu. That was my intent when I added that feature. That doesn't make it ideal, of course :) I'm open to changing it, but ideally this would be in a backwards compatible way. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: using a smartcard without keytocard
Hauke Laging wrote: I have just bought a gnupg smartcard, copied my subkeys to it, and it works. I have been using a key on several computers. Now I want the other systems to use the smartcard, too, so that I can delete the private keys there. The content of the smartcard is shown by --card-status and I could even use the authentication key for an SSH connection. For SSH connections gpg-agent looks at tha smartcard by default but it does not for normal key lookup. I just get an error message (something like no private key found) if I delete the private keys. Is there an official way to tell gpg to use the smartcard? Anything except copying the keys to the card again (executing keytocard on all systems)? I think deleting the the private key and issuing a 'gpg --card-status' should be enough. With that, gpg should automatically generate the secret key stubs which refer to the keys on that specific card. (Alternatively, you could export the secret key stubs on the machine where you have moved the keys to your card. An import these stubs on the machines on which you want to use the card.) I had the idea that exporting the secret keys on the system which initialized the smartcard might work. But for convenience I decided not to use the smartcard at home so I imported the secret keys there... I'm not sure what exactly you are getting at but if you have used the keytocard command to transfer the keys to the card then the secret keys in your keyring have been replaced by stubs. I.e. they are now only stored on the smartcard and can't be retrieved anymore, unless you had a copy stored elsewhere. If you want to use the same keys without the smartcard at home, you have to have a copy of the secret keys before you moved them to the card. Make sure to import the real secret keys and not the stubs on that machine. (I assume you have thought about the security implications of doing so.) BTW: Does it make sense that the smartcard number is stored with the secret key stub after the keytocard command? I haven't tried but I guess that copying the same key to another card wouldn't work. I think it just tells gnupg which card to use (or to request if it's not inserted). In order to copy the same key to multiple cards you have to make a copy of the secret keys before you move them to the first card, because 'keytocard' will replace the secret keys by stubs as explained above. Then you can re-import the secret keys from that copy and move them to another card. Marco -- OpenPGP Key ID: 0x62937F7F signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: using a smartcard without keytocard
On Mar 22, 2010, at 12:11 AM, Hauke Laging wrote: Hello, I have just bought a gnupg smartcard, copied my subkeys to it, and it works. I have been using a key on several computers. Now I want the other systems to use the smartcard, too, so that I can delete the private keys there. The content of the smartcard is shown by --card-status and I could even use the authentication key for an SSH connection. For SSH connections gpg-agent looks at tha smartcard by default but it does not for normal key lookup. I just get an error message (something like no private key found) if I delete the private keys. Is there an official way to tell gpg to use the smartcard? Anything except copying the keys to the card again (executing keytocard on all systems)? Yes. If I understand what you are asking, the easiest way to do this is to delete the secret key on those systems, then insert the card, and do a 'gpg --card-status'. That recreates the secret key stub so GPG knows to look at the card for that key. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
