Re: Inability to export and then import my secret key
On 12/08/15 12:25, Mirimir wrote: I got that OP is migrating to new hardware, so I don't see why identical installations would be problematic. Right, yes, then a full copy makes a whole lot more sense. I got thrown off by the fact that the error message seems to indicate the key already existed, and completely forgot about the introduction at the top of the message :). Such an exceptionally short attention span seems to indicate an acute lack of caffeine, I've taken swift action to remedy that! Anyway, on-topic: don't copy random_seed though. And be aware that some options in the *.conf files might only be applicable on the old system, and not on the new one. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Inability to export and then import my secret key
On 08/12/2015 03:58 AM, Peter Lebbing wrote: On 12/08/15 04:00, Mirimir wrote: It's simplest to just copy the gpg folder. Importing private keys is broken by design. I don't think I agree with either statement. Copying the folder comes with its own caveats: don't copy random_seed, and you might not want two identical installations with regard to present private keys and such. I got that OP is migrating to new hardware, so I don't see why identical installations would be problematic. And broken by design implies to me that GnuPG doesn't *want* to support merging secret keys; which would be odd given that the latest version, GnuPG 2.1, does support it. I also can't remember ever hearing a reason why it would be bad. Well, GnuPG 1.4 _definitely_ doesn't support importing secret keys. But maybe I'm wrong about broken by design. I vaguely recall reading something about that a year or two ago. Anyway, the reason I think Bryant is seeing this issue, is that GnuPG 1.4 and 2.0 don't support merging new things into existing secret keys. I suppose the key already existed on the other system but you added new subkeys and are trying to import those? If you can get the up-to-date system (sys1) to export the secret key as you want it to be on the other computer (sys2), it boils down to: sys1 $ gpg2 -o sec.gpg --export-secret-keys 1C0B95E5 [copy sec.gpg to sys2] sys2 $ gpg2 -o sec_backup.gpg --export-secret-keys 1C0B95E5 sys2 $ gpg2 --delete-secret-keys 1C0B95E5 sys2 $ gpg2 --import sec.gpg Now check if everything is okay on sys2, and if so, you can delete sec_backup.gpg. I think this should be safe, since you keep a backup of the local copy until you are sure the deletion didn't delete unintended stuff. That is for sure a more elegant path :) HTH, Peter. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Inability to export and then import my secret key
On Wed, 12 Aug 2015 12:25, miri...@riseup.net said: Well, GnuPG 1.4 _definitely_ doesn't support importing secret keys. But That is not correct. All version support import of secret keys. What versions 2.1 don't allow is merging (updating) a secret key. This can be problematic in some cases but most of the time it is sufficient to delete the secret key first and then import the other version of the secret key. 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: Inability to export and then import my secret key
On 12/08/15 04:00, Mirimir wrote: It's simplest to just copy the gpg folder. Importing private keys is broken by design. I don't think I agree with either statement. Copying the folder comes with its own caveats: don't copy random_seed, and you might not want two identical installations with regard to present private keys and such. And broken by design implies to me that GnuPG doesn't *want* to support merging secret keys; which would be odd given that the latest version, GnuPG 2.1, does support it. I also can't remember ever hearing a reason why it would be bad. Anyway, the reason I think Bryant is seeing this issue, is that GnuPG 1.4 and 2.0 don't support merging new things into existing secret keys. I suppose the key already existed on the other system but you added new subkeys and are trying to import those? If you can get the up-to-date system (sys1) to export the secret key as you want it to be on the other computer (sys2), it boils down to: sys1 $ gpg2 -o sec.gpg --export-secret-keys 1C0B95E5 [copy sec.gpg to sys2] sys2 $ gpg2 -o sec_backup.gpg --export-secret-keys 1C0B95E5 sys2 $ gpg2 --delete-secret-keys 1C0B95E5 sys2 $ gpg2 --import sec.gpg Now check if everything is okay on sys2, and if so, you can delete sec_backup.gpg. I think this should be safe, since you keep a backup of the local copy until you are sure the deletion didn't delete unintended stuff. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Inability to export and then import my secret key
On 08/12/2015 04:39 AM, Werner Koch wrote: On Wed, 12 Aug 2015 12:25, miri...@riseup.net said: Well, GnuPG 1.4 _definitely_ doesn't support importing secret keys. But That is not correct. All version support import of secret keys. What versions 2.1 don't allow is merging (updating) a secret key. This can be problematic in some cases but most of the time it is sufficient to delete the secret key first and then import the other version of the secret key. I clearly recall 1) exporting both my private and public keys from an old system, 2) importing them into a new system with no existing keys, and 3) finding that I could decrypt, but not sign. But I must have done something wrong. Sorry to confuse things. Shalom-Salam, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to deal with a 2nd OpenPGP Summit?
-- Message: 3 Date: Wed, 12 Aug 2015 07:44:24 +0200 From: n...@enigmail.net n...@enigmail.net To: GnuPG-Users Gnupg-users@gnupg.org Subject: How to deal with a 2nd OpenPGP Summit? Message-ID: 55cadd38.5030...@enigmail.net Content-Type: text/plain; charset=utf-8 Hi all, in April 2015 we had a first OpenPGP summit. It was a meeting where the technical experts of projects and tools dealing with OpenPGP with a focus on email encryption met to getting to know each other personally and discuss several issues. For details, see e.g. - https://www.gnupg.org/blog/20150426-openpgp-summit.html - https://www.mailpile.is/blog/2015-04-20_OpenPGP_Email_Summit.html The meting initially was organized by me to bring together a few guys/projects working in that area, but it became pretty big (about 30 people). This caused some problems, because we had a host with limited space (so I finally even had to reject some people wanting to attend). We also discussed there how to continue. On one hand we wanted to have the meeting open so that anybody wanting to attend could do that and to give trust by transparency. On the other hand we want to be able to continue to focus on technical issues (having a well signal to noise ratio) in a not-too-large group of experts. We didn't find an appropriate way yet to deal with both interests. Now, I am about to organize a second meeting at the end of this year. And I want to take the wisdom of this crowd to discuss this issue. What I currently have in mind is a meeting open to the public but with some limitations (one reason is to focus the work, another is simply limited space although I don't know where we can meet this time). For example: - Some priority for those who did attend the first meeting - Some priority for other experts, which didn't join the first meeting (but how do we handle that?) - Some limitations that a person plays a significant role in the community - Some limitation so that a tool/project should normally send only 1 or 2 guys The obvious other option is to open the meeting to everybody willing to come, which raises a couple of risks (simply too many people, too many non-experts or people who want to change the focus, ...). So, my questions are: = Is it OK for the public/community, if we meet in a way that is limited as describe above (just for practical reasons)? Is it OK even if we can't promise full transparency (e.g. by video taping sessions)? Would it even be OK, if we meet and constraint what is spoken there to the Chatham House Rule (see https://en.wikipedia.org/wiki/Chatham_House_Rule). Some people requested that because if anything they say might become public, they might or even have to be careful what they say. Any general thoughts or proposals about how to deal with this? Note that I don't want to have it too complicated. I organize this meeting in my free time to bring the issues of this community forward. And just having too many people is already a problem. I need an approach I can handle. Or is it better to have no meeting at all instead of a meeting with some limitations? Best Nico Dear Nico, I think you are trying to achieve a compromise that is not possible. If I understood correctly you are trying to reconcile developers interest with layman's enthusiasm. I myself belong to the second group. A good idea would be to organize one event for the developers and another open event so everyone can join. Then I think everybody would be happy. Note that some overlap between groups is expected and healthy for the community. Kind regards, -- Felipe Martins Vieira Public PGP key: http://pgp.surfnet.nl Key Fingerprint: 9640 F192 63DA D637 6750 AC08 7BCA 19BB 0E69 E45D signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Card reader success report (openpgp card v2.1)
On Tuesday, 11. August 2015 12:10:28 NIIBE Yutaka wrote: Three readers were tested: - Cherry ST-2000 - SCM SPR332 - Reiner SCT cyberjack go plus I think that USB vendor ID and product ID are: Cherry ST-2000 046a:003e Please confirm that and please let me know IDs for those new products of SCM SPR332 and Reiner SCT cyberjack go plus. here are the USB IDs from lsusb: 0c4b:0504 Reiner SCT Kartensysteme GmbH cyberJack go / go plus 04e6:e003 SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader 046a:003e Cherry GmbH SmartTerminal ST-2xxx Funny that the SPR332 (that's the name on the backside of the reader) announces itself as a SPR532. That's because I maintain pages: http://wiki.gnupg.org/CardReader/PinpadInput https://wiki.debian.org/GnuPG/CCID_Driver ... along with the scdaemon implementation. that page made me buy those specific readers :) Chances were good they work fine with the openpgp card and I really want the pinpad to work. Besides, if you can include information of your operating system and its version, it helps other users. I tested it on Fedora 22 that ships gnupg 2.1.5. I manually upgraded to gnupg 2.1.6 (recompiled the .rpm package with the updated source tarball) to get the Cherry ST-2000 up and running. Later on I also tested git HEAD. Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Inability to export and then import my secret key
Thank you all for your rapid assistance. I think I have the problem solved but will know for sure in an hour or so when I test it out thoroughly at the office. *Bryant Evans* ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Inability to export and then import my secret key
On Wed, 12 Aug 2015 13:01, pe...@digitalbrains.com said: Anyway, on-topic: don't copy random_seed though. And be aware that some options It would not be a catastrophically failure, though. Here is a comment from the function reading random_seed: Note: Multiple instances of applications sharing the same random seed file can be started in parallel, in which case they will read out the same pool and then race for updating it (the last update overwrites earlier updates). They will differentiate only by the weak entropy that is added in read_seed_file based on the PID and clock, and up to 16 bytes of weak random non-blockingly. The consequence is that the output of these different instances is correlated to some extent. In the perfect scenario, the attacker can control (or at least guess) the PID and clock of the application, and drain the system's entropy pool to reduce the up to 16 bytes above to 0. Then the dependencies of the initial states of the pools are completely known. */ The above is for the general case of asking for random, for example session keys. When generating a new public key pair gpg (and Libgcrypt) takes an extra step by making sure that at least 128 bit of fresh entropy (e.g. from /dev/random) have been inserted into the pool. 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
Possible bug when using smartcards and gpg-agent2.0 as the ssh-agent
Hello, I'm using gpg-agent 2.0.28 (Debian Stretch) as the ssh agent, with enable-ssh-suport. I have disabled the Gnome Keyring, and I'm only using gpg-agent. I have a properly configured Yubikey Neo with an auth subkey, and the Yubikey is correctly configured and in use. I have a clean ~/.gnupg/sshcontrol file, and no ~/.ssh directory at all. At first instance everything works fine, 'ssh-add -l' and 'ssh-add -L' show my key when I have my Yubikey connected: (I'm redacting the key and the card number) $ ssh-add -l 2048 **:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:** cardno:00060*** (RSA) Yet when I try to use it to connect to the server by ssh I get a GUI popup that says: take out the current card and insert the one with the serial number: D*060*** (In my case, in spanish, Retire tarjeta actual e inserte la que tiene número de serie: ) The serial number on ssh-add -L is the same card-no that appears next to the auth subkey in gpg --card-status, which is 12 chars long. The gpg-agent pop-up serial numbers seems to correspond to the Application ID displayed in gpg --card-status, which is 32 chars long. This seems like a bug. Am I missing something? Should I post this on gnupg-devel? Thanks in advance, -- Víctor -- E-Mail: m...@viccuad.me, OpenPGP-Key-ID: 0xA2591E231E251F36 Key fingerprint: E3C5 114C 0C5B 4C49 BA03 0991 A259 1E23 1E25 1F36 My signed E-Mails are trustworthy. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: How to deal with a 2nd OpenPGP Summit?
Hi, Just a thought: Have a Star chamber meeting for the technical group, invitation only. After that have a 1/2 to 1 hour session open to all where the technical people can present their progress and invite comment. This way you have a focused working session with the key people, but maintain community trust by allowing general input. Thanks, Bob Cavanaugh -Original Message- From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of fmv1...@gmail.com Sent: Wednesday, August 12, 2015 5:24 AM To: gnupg-users@gnupg.org; n...@enigmail.net Subject: Re: How to deal with a 2nd OpenPGP Summit? -- Message: 3 Date: Wed, 12 Aug 2015 07:44:24 +0200 From: n...@enigmail.net n...@enigmail.net To: GnuPG-Users Gnupg-users@gnupg.org Subject: How to deal with a 2nd OpenPGP Summit? Message-ID: 55cadd38.5030...@enigmail.net Content-Type: text/plain; charset=utf-8 Hi all, in April 2015 we had a first OpenPGP summit. It was a meeting where the technical experts of projects and tools dealing with OpenPGP with a focus on email encryption met to getting to know each other personally and discuss several issues. For details, see e.g. - https://www.gnupg.org/blog/20150426-openpgp-summit.html - https://www.mailpile.is/blog/2015-04-20_OpenPGP_Email_Summit.html The meting initially was organized by me to bring together a few guys/projects working in that area, but it became pretty big (about 30 people). This caused some problems, because we had a host with limited space (so I finally even had to reject some people wanting to attend). We also discussed there how to continue. On one hand we wanted to have the meeting open so that anybody wanting to attend could do that and to give trust by transparency. On the other hand we want to be able to continue to focus on technical issues (having a well signal to noise ratio) in a not-too-large group of experts. We didn't find an appropriate way yet to deal with both interests. Now, I am about to organize a second meeting at the end of this year. And I want to take the wisdom of this crowd to discuss this issue. What I currently have in mind is a meeting open to the public but with some limitations (one reason is to focus the work, another is simply limited space although I don't know where we can meet this time). For example: - Some priority for those who did attend the first meeting - Some priority for other experts, which didn't join the first meeting (but how do we handle that?) - Some limitations that a person plays a significant role in the community - Some limitation so that a tool/project should normally send only 1 or 2 guys The obvious other option is to open the meeting to everybody willing to come, which raises a couple of risks (simply too many people, too many non-experts or people who want to change the focus, ...). So, my questions are: = Is it OK for the public/community, if we meet in a way that is limited as describe above (just for practical reasons)? Is it OK even if we can't promise full transparency (e.g. by video taping sessions)? Would it even be OK, if we meet and constraint what is spoken there to the Chatham House Rule (see https://en.wikipedia.org/wiki/Chatham_House_Rule). Some people requested that because if anything they say might become public, they might or even have to be careful what they say. Any general thoughts or proposals about how to deal with this? Note that I don't want to have it too complicated. I organize this meeting in my free time to bring the issues of this community forward. And just having too many people is already a problem. I need an approach I can handle. Or is it better to have no meeting at all instead of a meeting with some limitations? Best Nico Dear Nico, I think you are trying to achieve a compromise that is not possible. If I understood correctly you are trying to reconcile developers interest with layman's enthusiasm. I myself belong to the second group. A good idea would be to organize one event for the developers and another open event so everyone can join. Then I think everybody would be happy. Note that some overlap between groups is expected and healthy for the community. Kind regards, -- Felipe Martins Vieira Public PGP key: http://pgp.surfnet.nl Key Fingerprint: 9640 F192 63DA D637 6750 AC08 7BCA 19BB 0E69 E45D ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Temporary lock files?
gpg (GnuPG) 2.0.22 My ~/.gnupg directory is getting filled with files named like .#lk0x7feb6a637540.hostname.26914. Shouldn't these get deleted automagically? -- aslam a k'wala's SciTech Daily http://paper.li/akwala/1306116714 PGP key http://is.gd/aslampgpmit fingerprint: 736C D83E 32DB A2FD 0208 9113 0FC8 BA7D FECF 84FB /Join World Community Grid https://www.worldcommunitygrid.org/reg/viewRegister.do?recruiterId=877175. Help power cutting-edge research in health, poverty and sustainability./ signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Possible bug when using smartcards and gpg-agent2.0 as the ssh-agent
On 12/08/15 20:55, Víctor Cuadrado Juan wrote: This seems like a bug. The serial number is part of the application ID, it's not a bug. The one is more verbose than the other. The AID ends in four zeroes, but the part before that is the serial number and manufacturer ID. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
