From gniibe at fsij.org Tue Sep 1 03:29:16 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 01 Sep 2015 10:29:16 +0900 Subject: exclusive vs. shared smart card access In-Reply-To: References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> Message-ID: <55E4FF6C.1050508@fsij.org> Hello, Jan and all, On 09/01/2015 01:20 AM, Jacob Appelbaum wrote: > I feel like I must not understand something or something is very wrong > with the best practices. Jan, I have addressed this issue multiple times since 2010. We have disagreement or we pushed different efforts. I think you sought PKCS#11, PC/SC, and opensc, while I have focused on OpenPGPcard and GnuPG. While I understand it enable closing some bug reports, I don't think shared access to smartcard is a practice. Let me explain current situation and my position. I think that access to smartcard/token should be controlled by a single application. In case of OpenPGPcard (and compatibles), it's GnuPG scdaemon. I know there are some utilities accessing smartcard/token. PIV utility of Yubikey, or firmware upgrade utility of Gnuk comes into my mind. For use of those utilities, GnuPG scdaemon should be killed beforehand. It would make sense that such a utility even had a feature killing GnuPG scdaemon beforehand (if user wants to do so). There are other kinds of tools like Poldi and Scute. It communicates through GnuPG scdaemon. This is another solution. I think that this is the practice. I mean, there is a single responsible application (= GnuPG scdaemon) and there are two ways for utilities: (a) stop the single application beforehand (b) communicate to the single application Please note that we are open to implement some other features in GnuPG scdaemon for (b). IIUC, Werner addressed this to Simon two weeks ago, wrt PIV utility. -- From drichd at tutanota.com Tue Sep 1 05:10:02 2015 From: drichd at tutanota.com (drichd at tutanota.com) Date: Tue, 1 Sep 2015 03:10:02 +0000 (UTC) Subject: Beginner questions about npth Message-ID: I came across to a post about npth http://lists.gnupg.org/pipermail/gnupg-ru/2012-August/000376.html Then I did some experiments with it like the example. But I am ?not an experienced C programmer so I have a few beginner questions: - Is the example the right way or order to use npth calls (init, create, join, exit, etc.)?- How can I utilize multiple cores when I want several threads to run on different cpu??- Is npth implemented with call/cc? Thanks? ========== Example ==========#include #include #include #include typedef struct data {? int no;? char *payload;} message; int new_message(message **msg, int no, char *str);void print_message(void *m); int main(int argc, char** argv)?{? message *msg1 = NULL, *msg2 = NULL;?? npth_attr_t t_attr1, t_attr2;? npth_t thread1, thread2;? char *str1 = "hello", *str2 = "world!"; ? new_message(&msg1, 1, str1);? new_message(&msg2, 2, str2); ? npth_init ();? npth_attr_init(&t_attr1);? npth_create(&thread1, &t_attr1, (void *)&print_message, (void *)msg1);? npth_attr_init(&t_attr2);? npth_create(&thread2, &t_attr2, (void *)&print_message, (void *)msg2);? npth_join(thread1, (void *)&t_attr1);? npth_join(thread2, (void *)&t_attr2); ? free(msg1);? free(msg2);? return 0;} int new_message(message **msg, int no, char *str)?{? if(msg && *msg == NULL) {? ? *msg = malloc(sizeof(**msg));?? ? if(NULL == *msg) {? ? ? printf("Can't allocate message.\n");? ? ? return -1;? ? }? }? if(NULL == (*msg)->payload) {? ? (*msg)->payload = malloc(sizeof(str)+1);? ? if(NULL == (*msg)->payload) {? ? ? printf("Can't allocate message payload\n");? ? ? free(*msg);? ? ? return -1;? ? }? }? strncpy((*msg)->payload, str, strlen(str));? (*msg)->no = no;? return 0;} void print_message(void *m)?{? message *msg;? msg = (message *) m;? printf("Thread %d owns %s\n", msg->no, msg->payload);? npth_exit(0);?} -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Tue Sep 1 07:50:06 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 01 Sep 2015 14:50:06 +0900 Subject: Beginner questions about npth In-Reply-To: References: Message-ID: <55E53C8E.1060508@fsij.org> Hello, nPth is a library of cooperative threads programming on top of system thread library. "Cooperative" means that only single thread can run. This condition simplifies things around mutual exclusion control and shared resource. On 09/01/2015 12:10 PM, drichd at tutanota.com wrote: > - How can I utilize multiple cores when I want several > threads to run on different cpu? You can't with nPth (by its design). Please use system thread library. > - Is npth implemented with call/cc? No. It is implemented on top of system thread library. It seems that you are confused. In an execution model where call/cc is valid, execution can proceed like tree, while it goes just up-and-down in an execution model with stack. Well, it would be possible to emulate call/cc with cooperative threads (or vice versa), but it wouldn't be so cheap or recommended. -- From andreas.schwier.ml at cardcontact.de Tue Sep 1 08:46:31 2015 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Tue, 01 Sep 2015 08:46:31 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <55E4FF6C.1050508@fsij.org> References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> Message-ID: <55E549C7.1010301@cardcontact.de> It's OK to claim exclusive access to a smart card during a session, but the software must release access if it's no longer needed. This is not the case with scdaemon that keeps the card locked as long as it runs, effectively blocking access from other applications. There is a DISCONNECT in scdaemon, but no application is really using it. Asking the user to terminate scdaemon before any other application can access the card is not a good user experience. And the one application controlling access to the card is the PC/SC daemon and *not* scdaemon. scdaemon is *one* of the applications accessing the card via PC/SC. Andreas On 09/01/2015 03:29 AM, NIIBE Yutaka wrote: > Hello, Jan and all, > > On 09/01/2015 01:20 AM, Jacob Appelbaum wrote: >> I feel like I must not understand something or something is very wrong >> with the best practices. > > Jan, I have addressed this issue multiple times since 2010. We have > disagreement or we pushed different efforts. I think you sought > PKCS#11, PC/SC, and opensc, while I have focused on OpenPGPcard and > GnuPG. > > While I understand it enable closing some bug reports, I don't think > shared access to smartcard is a practice. > > Let me explain current situation and my position. > > I think that access to smartcard/token should be controlled by a > single application. In case of OpenPGPcard (and compatibles), it's > GnuPG scdaemon. > > I know there are some utilities accessing smartcard/token. PIV > utility of Yubikey, or firmware upgrade utility of Gnuk comes into my > mind. > > For use of those utilities, GnuPG scdaemon should be killed > beforehand. It would make sense that such a utility even had a > feature killing GnuPG scdaemon beforehand (if user wants to do so). > > There are other kinds of tools like Poldi and Scute. It communicates > through GnuPG scdaemon. This is another solution. > > I think that this is the practice. I mean, there is a single > responsible application (= GnuPG scdaemon) and there are two ways for > utilities: > > (a) stop the single application beforehand > (b) communicate to the single application > > Please note that we are open to implement some other features in GnuPG > scdaemon for (b). IIUC, Werner addressed this to Simon two weeks ago, > wrt PIV utility. > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Sch?lerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com From simon at josefsson.org Tue Sep 1 09:15:10 2015 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 01 Sep 2015 09:15:10 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: (Jacob Appelbaum's message of "Mon, 31 Aug 2015 16:20:14 +0000") References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> Message-ID: <87r3mi391d.fsf@latte.josefsson.org> Jacob Appelbaum writes: > It sounds like there is a problem with the authentication protocol for > the card, doesn't it? Yes, smartcard authentication is comparable to 1980's Unix authentication: send a password in clear text. It is the same with all major smartcard protocols that I'm aware of. What you want is to have something that could be called "application-level pairing", where the application creates a secure channel to the smartcard instead of trusting intermediares to proxy cleartext data properly. Then proof of the PIN can be proven over that secure channel (not necessarily by sending it over directly). One advantage with this is that access to the smartcard is available only to the application that opened it, and not any random process on the host. Then shared access to the smartcard would not be a problem. Earlier versions of the U2F protocol had this property, but it was removed. I don't know of any published smartcard protocol with this feature. It would be cool if future versions of the OpenPGP Card specification would support this. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From drichd at tutanota.com Tue Sep 1 09:19:32 2015 From: drichd at tutanota.com (drichd at tutanota.com) Date: Tue, 1 Sep 2015 07:19:32 +0000 (UTC) Subject: Beginner questions about npth In-Reply-To: <55E53C8E.1060508@fsij.org> References: <> <55E53C8E.1060508@fsij.org> Message-ID: Thanks for the reply it's clear and helpful!? 1. Sep 2015 13:50 by gniibe at fsij.org: > Hello, > > nPth is a library of cooperative threads programming on top of system > thread library. "Cooperative" means that only single thread can run. > This condition simplifies things around mutual exclusion control and > shared resource. > > On 09/01/2015 12:10 PM, > drichd at tutanota.com> wrote: >> - How can I utilize multiple cores when I want several >> threads to run on different cpu? > > You can't with nPth (by its design). Please use system thread > library. > >> - Is npth implemented with call/cc? > > No. It is implemented on top of system thread library. > > It seems that you are confused. In an execution model where call/cc > is valid, execution can proceed like tree, while it goes just > up-and-down in an execution model with stack. Well, it would be > possible to emulate call/cc with cooperative threads (or vice versa), > but it wouldn't be so cheap or recommended. > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Tue Sep 1 09:23:16 2015 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 01 Sep 2015 09:23:16 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <55E4FF6C.1050508@fsij.org> (NIIBE Yutaka's message of "Tue, 01 Sep 2015 10:29:16 +0900") References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> Message-ID: <87mvx638nv.fsf@latte.josefsson.org> NIIBE Yutaka writes: > I think that access to smartcard/token should be controlled by a > single application. In case of OpenPGPcard (and compatibles), it's > GnuPG scdaemon. That works in the OpenPGP-only context. The problem hits as soon as card support more than one application, which almost all smartcard does. Currently, PCSC takes the role of controlling the smartcard, and allows multi-protocols. GnuPG's scdaemon could take that role too, but it is not supported today, and you would still have the conflict with PCSC. > I know there are some utilities accessing smartcard/token. PIV > utility of Yubikey, or firmware upgrade utility of Gnuk comes into my > mind. There is U2F too which is supported by Chrome (works in Debian Stable). > For use of those utilities, GnuPG scdaemon should be killed > beforehand. It would make sense that such a utility even had a > feature killing GnuPG scdaemon beforehand (if user wants to do so). Yes -- killing scdaemon appears to be best recommend practice now. It is what I'm using when switching between GnuPG and PIV, see for example: http://blog.josefsson.org/2015/06/16/ssh-host-certificates-with-yubikey-neo/ > There are other kinds of tools like Poldi and Scute. It communicates > through GnuPG scdaemon. This is another solution. > > I think that this is the practice. I mean, there is a single > responsible application (= GnuPG scdaemon) and there are two ways for > utilities: > > (a) stop the single application beforehand > (b) communicate to the single application > > Please note that we are open to implement some other features in GnuPG > scdaemon for (b). IIUC, Werner addressed this to Simon two weeks ago, > wrt PIV utility. It would be great if there were a PIV PKCS#11 library that talked to scdaemon. I'm not sure if it is possible to build that without changes in scdaemon, do you have an opinion on that? Since you can send arbitrary APDUs, it should probably be possible, but I'm not certain. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From gniibe at fsij.org Tue Sep 1 09:27:45 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 01 Sep 2015 16:27:45 +0900 Subject: exclusive vs. shared smart card access In-Reply-To: <55E549C7.1010301@cardcontact.de> References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <55E549C7.1010301@cardcontact.de> Message-ID: <55E55371.5000606@fsij.org> On 09/01/2015 03:46 PM, Andreas Schwier wrote: > It's OK to claim exclusive access to a smart card during a session, but > the software must release access if it's no longer needed. > > This is not the case with scdaemon that keeps the card locked as long as > it runs, effectively blocking access from other applications. > > There is a DISCONNECT in scdaemon, but no application is really using > it. Asking the user to terminate scdaemon before any other application > can access the card is not a good user experience. Thank you for your opinion. I think that it would be true for smartcard in general. I am talking specifically for OpenPGPcard and its usage by scdaemon. The name "scdaemon" would be misleading, it is something like "openpgpcard-agent". As one of implementer of (variant of) OpenPGPcard and its user, I were afraid if shared access were considered as a "practice" for OpenPGPcard. Admittedly, I understand current way of scdaemon holding and watching the card-reader/token exclusively forever is not the best thing. It should be improved (say, with timeout or more user-friendly way), but I never consider allowing shared access for OpenPGPcard is a good thing. In case of Gnuk Token, those applications accessing token are for some other features which are out of scope of OpenPGPcard specification. I think that It's OK to require stopping scdaemon for that. Perhaps, Nitrokey has some other features, which require shared access somehow. However, if it requires the change of the default assumption of OpenPGPcard access, the impact would be huge. If possible, please consider other ways. > And the one application controlling access to the card is the PC/SC > daemon and *not* scdaemon. scdaemon is *one* of the applications > accessing the card via PC/SC. It seems that you assume shared access to OpenPGPcard is a good thing, while I don't think so. -- From andreas.schwier.ml at cardcontact.de Tue Sep 1 09:29:16 2015 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Tue, 01 Sep 2015 09:29:16 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <87r3mi391d.fsf@latte.josefsson.org> References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <87r3mi391d.fsf@latte.josefsson.org> Message-ID: <55E553CC.2010602@cardcontact.de> This is what we are doing in the SmartCard-HSM. The application authenticates the device using ECDH and establishes a secure communication channel that binds user authentication. This way the application and SmartCard-HSM pair. An application intercepting the communication will force the SmartCard-HSM to terminate the secure session and clear authentication states. Without such a mechanism an application must indicate to PC/SC to reset the card at the end of a session, effectively clearing authentication states. The new version even implements public key authentication with a n-of-m threshold scheme to allow shared control for very sensitive keys. Andreas On 09/01/2015 09:15 AM, Simon Josefsson wrote: > Jacob Appelbaum writes: > >> It sounds like there is a problem with the authentication protocol for >> the card, doesn't it? > > Yes, smartcard authentication is comparable to 1980's Unix > authentication: send a password in clear text. > > It is the same with all major smartcard protocols that I'm aware of. > > What you want is to have something that could be called > "application-level pairing", where the application creates a secure > channel to the smartcard instead of trusting intermediares to proxy > cleartext data properly. Then proof of the PIN can be proven over that > secure channel (not necessarily by sending it over directly). One > advantage with this is that access to the smartcard is available only to > the application that opened it, and not any random process on the host. > Then shared access to the smartcard would not be a problem. Earlier > versions of the U2F protocol had this property, but it was removed. I > don't know of any published smartcard protocol with this feature. > > It would be cool if future versions of the OpenPGP Card specification > would support this. > > /Simon > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Sch?lerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com From andreas.schwier.ml at cardcontact.de Tue Sep 1 09:38:15 2015 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Tue, 01 Sep 2015 09:38:15 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <55E55371.5000606@fsij.org> References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <55E549C7.1010301@cardcontact.de> <55E55371.5000606@fsij.org> Message-ID: <55E555E7.5000705@cardcontact.de> >> And the one application controlling access to the card is the PC/SC >> daemon and *not* scdaemon. scdaemon is *one* of the applications >> accessing the card via PC/SC. > > It seems that you assume shared access to OpenPGPcard is a good thing, > while I don't think so. That is not what I'm saying. Sharing a card is O.K while the PIN is not authenticated. Once the PIN is authenticated, an application should have exclusive access. However this period should be as short as possible and an application must release exclusive access either explicitly by user request or time-out. Hijacking the card is pretty much like gnome-keyring-daemon hijacking gpg-agent. > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Sch?lerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Sch?lerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com From gniibe at fsij.org Tue Sep 1 09:54:07 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 01 Sep 2015 16:54:07 +0900 Subject: exclusive vs. shared smart card access In-Reply-To: <87mvx638nv.fsf@latte.josefsson.org> References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <87mvx638nv.fsf@latte.josefsson.org> Message-ID: <55E5599F.60501@fsij.org> On 09/01/2015 04:23 PM, Simon Josefsson wrote: > There is U2F too which is supported by Chrome (works in Debian Stable). I didn't know that. Is it implemented parallel to OpenPGPcard as a feature in a single smartcard? How does it work with Yubikey? If it's implemented by another interface of USB device, it's simpler, it can co-exist. Well, I'd imagine that it is now somehow very frustrated for a user, using OpenPGPcard and U2F simultaneously, if it's implemented as a single smartcard. This would be a use case where shared access is somehow required. Is it possible for the application of U2F for Yubikey to communicate to scdaemon (like Poldi and Scute)? The reason why I ask is that I think that OpenPGPcard assumes exclusive access to the card and scdaemon holds information of card status, if there were "another channel" to access the card, I don't know how I can implement it correctly... Or, I think that it is somehow easily possible to write an application of U2F which communicates gpg-agent, so that a user can use an authentication subkey for U2F. For me, this sounds the way to go. How do you think this direction? -- From gniibe at fsij.org Tue Sep 1 10:06:25 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 01 Sep 2015 17:06:25 +0900 Subject: exclusive vs. shared smart card access In-Reply-To: <55E555E7.5000705@cardcontact.de> References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <55E549C7.1010301@cardcontact.de> <55E55371.5000606@fsij.org> <55E555E7.5000705@cardcontact.de> Message-ID: <55E55C81.8050603@fsij.org> On 09/01/2015 04:38 PM, Andreas Schwier wrote: > Sharing a card is O.K while the PIN is not authenticated. Once the PIN > is authenticated, an application should have exclusive access. > > However this period should be as short as possible and an application > must release exclusive access either explicitly by user request or time-out. Thank you for the clarification. I understand well. I'll try to improve scdaemon following this practice. The situation of OpenPGPcard is that, (when it is configured as not-forcing PIN authentication for every signing request,) the period is forever currently. -- From andreas.schwier.ml at cardcontact.de Tue Sep 1 10:30:33 2015 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Tue, 01 Sep 2015 10:30:33 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <55E55C81.8050603@fsij.org> References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <55E549C7.1010301@cardcontact.de> <55E55371.5000606@fsij.org> <55E555E7.5000705@cardcontact.de> <55E55C81.8050603@fsij.org> Message-ID: <55E56229.9030209@cardcontact.de> On 09/01/2015 10:06 AM, NIIBE Yutaka wrote: > The situation of OpenPGPcard is that, (when it is configured as > not-forcing PIN authentication for every signing request,) the period > is forever currently. I hope it's only until the next card reset ;-) > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Sch?lerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com From achim at pietig.com Tue Sep 1 10:48:05 2015 From: achim at pietig.com (Achim Pietig) Date: Tue, 1 Sep 2015 10:48:05 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <55E55C81.8050603@fsij.org> References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <55E549C7.1010301@cardcontact.de> <55E55371.5000606@fsij.org> <55E555E7.5000705@cardcontact.de> <55E55C81.8050603@fsij.org> Message-ID: <55E56645.3000805@pietig.com> Hi all, as Andreas told the most secure way to communicate with a smart card is a secure channel, several wide spread cards like GeldKarte or eGK (health card) in Germany work with that. But these card systems work with x.509-certificates and the cards have an inbuilt root-certificate and accept only certificates from the same authority - at the begining of a communication a secure messaging channel is established from the pub keys of both partners, resulting in AES session keys. In the OpenPGP world we do not have such an authority, the OpenPGP card allows secure messaging with a closed symmetric scheme - that is designed for companies, universities etc. But it will not help here because there is no way to store the needed secret in the PC of the user - it will work only with HSMs or severs. I think other protocols have the same problem - where can we store the secrets for the communication channel? For that reason it is important to have exclusive access to the card if a security condition like password is fulfilled. At the end of a session a card should be powered down so that it looses all internal access states. It will be helpful if scdaemon can release the card including power down by a special command that can be used from other applications. Or the user can define a timeout (e. g. in gpg.conf) after that the card is released if he works with several independant card tools at the same PC. Regards Achim Am 01.09.2015 um 10:06 schrieb NIIBE Yutaka: > On 09/01/2015 04:38 PM, Andreas Schwier wrote: >> Sharing a card is O.K while the PIN is not authenticated. Once the PIN >> is authenticated, an application should have exclusive access. >> >> However this period should be as short as possible and an application >> must release exclusive access either explicitly by user request or time-out. > > Thank you for the clarification. I understand well. I'll > try to improve scdaemon following this practice. > > The situation of OpenPGPcard is that, (when it is configured as > not-forcing PIN authentication for every signing request,) the period > is forever currently. > From simon at josefsson.org Tue Sep 1 11:58:04 2015 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 01 Sep 2015 11:58:04 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <55E5599F.60501@fsij.org> (NIIBE Yutaka's message of "Tue, 01 Sep 2015 16:54:07 +0900") References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <87mvx638nv.fsf@latte.josefsson.org> <55E5599F.60501@fsij.org> Message-ID: <87bndm31hv.fsf@latte.josefsson.org> NIIBE Yutaka writes: > On 09/01/2015 04:23 PM, Simon Josefsson wrote: >> There is U2F too which is supported by Chrome (works in Debian Stable). > > I didn't know that. Is it implemented parallel to OpenPGPcard as a > feature in a single smartcard? How does it work with Yubikey? > > If it's implemented by another interface of USB device, it's simpler, > it can co-exist. I forgot to mention some details -- U2F is not CCID but a different USB-based protocol. Locking CCID will not prevent U2F from working, I believe. > Or, I think that it is somehow easily possible to write an application > of U2F which communicates gpg-agent, so that a user can use an > authentication subkey for U2F. For me, this sounds the way to go. > How do you think this direction? I can imagine other applications wanting U2F functionality eventually, but I don't have a good use-case in mind right now. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From dirkx at webweaving.org Tue Sep 1 13:24:03 2015 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Tue, 1 Sep 2015 13:24:03 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <87bndm31hv.fsf@latte.josefsson.org> References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <87mvx638nv.fsf@latte.josefsson.org> <55E5599F.60501@fsij.org> <87bndm31hv.fsf@latte.josefsson.org> Message-ID: <5BBA9661-C17E-4CBB-B497-A650309C5BB1@webweaving.org> > On 01 Sep 2015, at 11:58, Simon Josefsson wrote: > > NIIBE Yutaka writes: > >> On 09/01/2015 04:23 PM, Simon Josefsson wrote: >>> There is U2F too which is supported by Chrome (works in Debian Stable). >> >> I didn't know that. Is it implemented parallel to OpenPGPcard as a >> feature in a single smartcard? How does it work with Yubikey? >> >> If it's implemented by another interface of USB device, it's simpler, >> it can co-exist. > > I forgot to mention some details -- U2F is not CCID but a different > USB-based protocol. Locking CCID will not prevent U2F from working, I > believe. This is indeed correct; we?ve found it perfectly possible to have a PKCS ?view? of a token to be visible to OpenSC; whilst it U2F identity was claimed by another process/user. Dw. From thomas at duboucher.eu Wed Sep 2 09:33:02 2015 From: thomas at duboucher.eu (Thomas Duboucher) Date: Wed, 2 Sep 2015 09:33:02 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <55E56645.3000805@pietig.com> References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <55E549C7.1010301@cardcontact.de> <55E55371.5000606@fsij.org> <55E555E7.5000705@cardcontact.de> <55E55C81.8050603@fsij.org> <55E56645.3000805@pietig.com> Message-ID: <55E6A62E.3070407@duboucher.eu> Hi all, First of all, sorry if this response seems confuse as I will try to answer several things at once. :) Currently, exclusive access is not considered as a good practice; If the application that requests exclusive access hang, then the users is required to cold reset the smartcard, i.e. remove it, in order to use it again. Shared access is the de-facto way to go. Even then, exclusive access does not solve everything. Before closing the channel, the application should also reset PIN states, for instance by issuing a warm reset. If the application is closed before, then any other application connecting to the card will have the PIN already verified. A few weeks ago there was a short discussion on Twitter concerning usage of PGPCard over NFC in a smartphone and Yubikey setup. The raised issue was the PIN in the VERIFY PIN command is sent in cleartext over a radio channel. The common pattern here is how can we prove knowledge of a PIN over an unreliable network without requiring to authenticating first with e.g. an asymmetric scheme using public certification authority? One of the answer is the PACE key agreement protocol. This protocol provides mutual proof of a knowledge of a low entropy secret, e.g. a PIN, during agreement of a strong high entropy secret. It is already commonly used in smartcard applications such as passports. PACE is described in: - Technical Guideline TR-03111, Elliptic Curve Cryptography, Version 2.0[TR3111], for an introduction of PACE over elliptic curves - Supplemental Access Control for Machine Readable Travel Documents Version 1.01[SAC], for an introduction of PACE for smartcards Additionally: - ISO/IEC 7816-4, for a description of GENERAL AUTHENTICATE I started drafting a proposal to add PACE support as an optional replacement for PIN in PGPCard. However, I still have a few questions to answer before: - PACE is *mostly* patent-unencumbered and I still have to sort this out. - I am not sure yet if my company would agree me working during my spare time on the specification of another smartcard application. Please, feel free to comment on this. I'll give more details tomorrow if you are interested or have questions on the subject. Regards, [TR3111] https://www.bsi.bund.de/cae/servlet/contentblob/471398/publicationFile/30615/BSI-TR-03111_pdf.pdf [SAC] http://www.icao.int/security/mrtd/downloads/technical%20reports/technical%20report.pdf Le 01/09/2015 10:48, Achim Pietig a ?crit : > Hi all, > > as Andreas told the most secure way to communicate with a smart card is a secure channel, several wide spread cards like GeldKarte or eGK (health card) in Germany work with that. > But these card systems work with x.509-certificates and the cards have an inbuilt root-certificate and accept only certificates from the same authority - at the begining of a communication a secure > messaging channel is established from the pub keys of both partners, resulting in AES session keys. > > In the OpenPGP world we do not have such an authority, the OpenPGP card allows secure messaging with a closed symmetric scheme - that is designed for companies, universities etc. > But it will not help here because there is no way to store the needed secret in the PC of the user - it will work only with HSMs or severs. > I think other protocols have the same problem - where can we store the secrets for the communication channel? > > For that reason it is important to have exclusive access to the card if a security condition like password is fulfilled. > At the end of a session a card should be powered down so that it looses all internal access states. > > It will be helpful if scdaemon can release the card including power down by a special command that can be used from other applications. > Or the user can define a timeout (e. g. in gpg.conf) after that the card is released if he works with several independant card tools at the same PC. > > Regards -- Thomas Duboucher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Sep 2 13:23:51 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Sep 2015 13:23:51 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <55E549C7.1010301@cardcontact.de> (Andreas Schwier's message of "Tue, 01 Sep 2015 08:46:31 +0200") References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <55E549C7.1010301@cardcontact.de> Message-ID: <878u8pjc8o.fsf@vigenere.g10code.de> On Tue, 1 Sep 2015 08:46, andreas.schwier.ml at cardcontact.de said: > It's OK to claim exclusive access to a smart card during a session, but > the software must release access if it's no longer needed. GnuPG requires the card all the time. 1. It is not acceptable for a user to wait several seconds for the decryption of each mail or an ssh authentication. 2. Scdaemon caches data read from the card the first time the card is accessed. This greatly helps with 1. 3. Without exclusive access to the card we have no guarantee that the cached data is fresh. Another application may have created a new key or changed DOs. 4. Without exclusive access other users get access to card and the keys. This is a no-go. To avoid this we would need to do a power-off after each operation. > And the one application controlling access to the card is the PC/SC > daemon and *not* scdaemon. scdaemon is *one* of the applications > accessing the card via PC/SC. Nope. PC/SC is a system wide service but we don't want other users to access a card we have in use. Iff PC/SC would provide a request/notification mechanism to tell that another clients needs access to the card, we can add a feature to reset the card and disconnect. Salam-Shalom, Werner From wk at gnupg.org Wed Sep 2 13:33:06 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Sep 2015 13:33:06 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <55E56645.3000805@pietig.com> (Achim Pietig's message of "Tue, 1 Sep 2015 10:48:05 +0200") References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <55E549C7.1010301@cardcontact.de> <55E55371.5000606@fsij.org> <55E555E7.5000705@cardcontact.de> <55E55C81.8050603@fsij.org> <55E56645.3000805@pietig.com> Message-ID: <874mjdjbt9.fsf@vigenere.g10code.de> On Tue, 1 Sep 2015 10:48, achim at pietig.com said: > It will be helpful if scdaemon can release the card including power > down by a special command that can be used from other applications. $ gpgconf --kill scdaemon does this. > Or the user can define a timeout (e. g. in gpg.conf) after that the > card is released if he works with several independant card tools at > the same PC. Put card-timeout 1 into scdaemon.conf and run $ gpg-connect-agent 'SCD DISCONNECT' /bye if you need to get access to the card. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Sep 2 14:13:17 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Sep 2015 14:13:17 +0200 Subject: Beginner questions about npth In-Reply-To: <55E53C8E.1060508@fsij.org> (NIIBE Yutaka's message of "Tue, 01 Sep 2015 14:50:06 +0900") References: <55E53C8E.1060508@fsij.org> Message-ID: <87zj15hvdu.fsf@vigenere.g10code.de> On Tue, 1 Sep 2015 07:50, gniibe at fsij.org said: > You can't with nPth (by its design). Please use system thread > library. Actually you can do that with nPth if you really know what you are doing. This is sometimes necessary when calling functions from other libraries or system functions not wrapped bu nPth: for (npth_unprotect (), item = ldap_first_entry (ld, msg), npth_protect (); item; npth_unprotect (), item = ldap_next_entry (ld, item), npth_protect ()) { foo (); } Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jeroen.ooms at stat.ucla.edu Fri Sep 4 12:42:58 2015 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Fri, 4 Sep 2015 12:42:58 +0200 Subject: Suggestions for gpgme on mingw-w64 Message-ID: I am writing gpgme bindings for the R statistical programming language which need to run on linux, mac and windows. I noticed there has been some work on windows support in gpgme 1.6.0 and have a few questions/suggestions. ## w32spawn It is explicitly noted in the changelog that gpgme-w32spawn.exe has to be in the installation directory. However in my case this is unfortunately impossible. R installs packages (modules) in the user home directory, and then dynamically loads them when needed. Therefore _gpgme_get_inst_dir() returns the installation directory of the main R software, which is not writable by the user. It would be really nice if we could manually set the path to gpgme-w32spawn.exe, for example with a runtime environment variable or via gpgme_set_global_flag("gpgme-w32spawn", ...) or something similar. Alternatively gpgme could search the PATH as well. One final suggestion is that the error message in _gpgme_get_w32spawn_path could be improved a bit. I spent a lot of time debugging "CreateProcess failed: ec=87". This is probably a fairly common problem, a small hint about missing gpgme-w32spawn.exe would be great. ## finding gpgconf There are several methods described to find gpg, and none of them worked on my windows 64 system, though I have a completely standard gpg4win installation. According to the documentation, gpgme searches the PATH for gpgconf or gpg2. There is a function walk_path() in posix-util.c but unless I am missing something, this has not been implemented in w32-util.c. Is this a deliberate choice? Windows has PathFindOnPath(), though that would introduce a dependency on Shlwapi.dll. The docs also state that the directory can be set manually using: #define GPG4WIN "C:/Program Files (x86)/GNU/GnuPG/gpg2.exe" gpgme_set_engine_info(GPGME_PROTOCOL_OpenPGP, GPG4WIN, NULL) However I tried all possible combinations of this function, and none worked on windows. Finally, the find_program_at_standard_place() function in w32-util.c checks CSIDL_PROGRAM_FILES (which corresponds to c:/program files/). However on a windows 64 machine, the default directory of gpg4win is actually in CSIDL_PROGRAM_FILESX86 (which corresponds to c:/program files (x86)/), so gpgme should check this dir as well. After I changed this in the gpgme source code, I finally got my bindings to work, both for win32 and win64! Yay! I am very glad I finally figured this out locally, but in order to release this software it will need to be able to find a gpg installation on an arbitrary windows system. On Linux and Mac, gpgme does a good job in searching the PATH, hopefully this can be improved on Windows. Please let me know if I can help testing. I am writing bindings to From wk at gnupg.org Fri Sep 4 13:32:58 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Sep 2015 13:32:58 +0200 Subject: Suggestions for gpgme on mingw-w64 In-Reply-To: (Jeroen Ooms's message of "Fri, 4 Sep 2015 12:42:58 +0200") References: Message-ID: <87fv2uh11x.fsf@vigenere.g10code.de> On Fri, 4 Sep 2015 12:42, jeroen.ooms at stat.ucla.edu said: > ## w32spawn > home directory, and then dynamically loads them when needed. Therefore > _gpgme_get_inst_dir() returns the installation directory of the main R > software, which is not writable by the user. You should really try to use the gpgme DLL and not link it statically - this will return the installation directory of the DLL. However, I know that this is sometimes not easy to achieve. > It would be really nice if we could manually set the path to > gpgme-w32spawn.exe, for example with a runtime environment variable or > via gpgme_set_global_flag("gpgme-w32spawn", ...) or something similar. Well, if that is really required it can be done. Dymnamically loaded code has a lot of problems which we can fortunately solve on Windows by using a DLL. If you don't see a chance to use a DLL, such an option can be added. > Alternatively gpgme could search the PATH as well. No. That may turn up an incompatible versions of the helper and we get trouble analyzing bug reports. > One final suggestion is that the error message in > _gpgme_get_w32spawn_path could be improved a bit. I spent a lot of Good idea. > ## finding gpgconf > > There are several methods described to find gpg, and none of them > worked on my windows 64 system, though I have a completely standard > gpg4win installation. Thing will be better with GnuPG 2.1 - the installer uses a weel-known installation directory and the latest gpgme knows about it and only falls back to the standard gpgwin install directories if no 2.1 is installed. > Finally, the find_program_at_standard_place() function in w32-util.c > checks CSIDL_PROGRAM_FILES (which corresponds to c:/program files/). > However on a windows 64 machine, the default directory of gpg4win is > actually in CSIDL_PROGRAM_FILESX86 (which corresponds to c:/program > files (x86)/), so gpgme should check this dir as well. After I changed Interesting. Does that mean that for a 64 bit process, the CSIDL_PROGRAM_FILES is different for than for a 32 bit process? I guess that makes sense. Okay to check CSIDL_PROGRAM_FILESX86 after CSIDL_PROGRAM_FILES on a 64 bit Windows? For my understanding this would also prefer a 64 bit version of GnuPG (which does not yet exist) over a 32 bit version. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jeroen.ooms at stat.ucla.edu Fri Sep 4 16:55:25 2015 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Fri, 4 Sep 2015 16:55:25 +0200 Subject: Suggestions for gpgme on mingw-w64 In-Reply-To: <87fv2uh11x.fsf@vigenere.g10code.de> References: <87fv2uh11x.fsf@vigenere.g10code.de> Message-ID: On Fri, Sep 4, 2015 at 1:32 PM, Werner Koch wrote: > Well, if that is really required it can be done. Dymnamically loaded > code has a lot of problems which we can fortunately solve on Windows by > using a DLL. If you don't see a chance to use a DLL, such an option can > be added. That would be really great. > Okay to check CSIDL_PROGRAM_FILESX86 after CSIDL_PROGRAM_FILES on a 64 > bit Windows? For my understanding this would also prefer a 64 bit > version of GnuPG (which does not yet exist) over a 32 bit version. Yes, that makes sense. The full table on what CSIDL_PROGRAM_FILES{,X86,X64} refer to for 32/64bit processes on windows 32 and 64 is here: https://msdn.microsoft.com/en-us/library/bb762584(VS.85).aspx (scroll down to the table names FOLDERID_ProgramFiles) From twim at riseup.net Sat Sep 5 13:05:13 2015 From: twim at riseup.net (Ivan Markin) Date: Sat, 05 Sep 2015 11:05:13 +0000 Subject: Extra data in APDU response when signing by OpenPGP card Message-ID: <55EACC69.6070106@riseup.net> Hello everyone, I have tried to send APDUs to OpenPGP card via pcscd. It works perfectly. When I'm trying to send APDUs via 'scd apdu ...' everything is OK, except digest signing. As far as I can see scdaemon adds extra data into a signature. Diffs of the signature (header + diff_data + footer): 392532352bdd2cc27a2ded2530445d38 - APDU response from scdaemon 3925____2bdd2cc27a2ded__0d__5d38 - raw APDU response via pcscd (w/out scdaemon) 3925____2BDD2CC27A2DED__0D__5D38 - raw response to APDU sent via scdaemon, sniffed via pcscd Is it right? If it is, what's the purpose? Thanks, -- header = 1499e16e19140b122ba0e7340927ca3907dafea926282c6669f9c780351aa86380bcc34136ccb6c4e0ed0909cf8dd5ca54361daa52fb11de90209da4ab7314b4c13484bcab27 footer = 17ed847391b9e8916760bd9162c8a7518c850e8cfc285c61494290725bb98a52dbe44d5eaeb9d8e812cd29a784aa -- Ivan Markin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From andreas.schwier.ml at cardcontact.de Sat Sep 5 19:47:37 2015 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Sat, 05 Sep 2015 19:47:37 +0200 Subject: Integrating n-of-m threshold scheme Message-ID: <55EB2AB9.50506@cardcontact.de> Good evening, as an alternative authentication mechanism for access to sensitive keys, we've implemented a public key authentication mechanism with an n-of-m threshold scheme for the SmartCard-HSM. Now I'm looking for ideas how this scheme could be integrated with scdaemon. As of today scdaemon supports an user PIN for authentication towards a SmartCard-HSM. Public key authentication uses a challenge response mechanism where the user seeking access signs a challenge generated by the target device with a private key on his own device. If access to the device is shared, multiple user must authenticate in order to enable access to keys. In the n-of-m threshold scheme, m keys are configured for authentication, while at least n keys must authenticate for access. Main purpose of the scheme is to ensure better control over very sensitive keys on the device. One idea is to provide an additional set of commands in scdaemon that allow a secondary application to perform authentication. The other idea is to provide a separate tool like pinentry that performs the authentication steps. Ideally the scheme should allow remote authentication, e.g. where key custodians can connect over the Internet to authenticate toward the device. Andreas -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Sch?lerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com From egarcia74 at gmail.com Sun Sep 6 11:07:20 2015 From: egarcia74 at gmail.com (Eduardo Garcia-Prieto) Date: Sun, 6 Sep 2015 19:07:20 +1000 Subject: PIN Entry in Android does not allow non-numeric PIN Message-ID: Hiya, When trying to using a PIN-protected YubiKey to sign or encrypt a message in Gnu Privacy Guard for Android, the PIN entry screen comes up and unfortuantely it only allows numbers to be entered. The PIN used to protect GPG keys on a YubiKey can also consist of alphabetic and punctuation characters. Is it possible to allow alphabetic & punctuation characters too in the PIN Entry screen?? Thanks!! Eddie -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Mon Sep 7 02:05:16 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 07 Sep 2015 09:05:16 +0900 Subject: Extra data in APDU response when signing by OpenPGP card In-Reply-To: <55EACC69.6070106@riseup.net> References: <55EACC69.6070106@riseup.net> Message-ID: <55ECD4BC.60107@fsij.org> On 09/05/2015 08:05 PM, Ivan Markin wrote: > 392532352bdd2cc27a2ded2530445d38 - APDU response from scdaemon > 3925____2bdd2cc27a2ded__0d__5d38 - raw APDU response via pcscd (w/out > scdaemon) > 3925____2BDD2CC27A2DED__0D__5D38 - raw response to APDU sent via > scdaemon, sniffed via pcscd It is because of the encoding in gpg-agent/scdaemon. (1) 25 32 35 is: % 2 5 (2) 25 20 44 is: % 0 D (1) is to escape '%' (ASCII value 0x25). (2) is to represent CR (ASCII value 0x0d). -- From twim at riseup.net Mon Sep 7 03:37:35 2015 From: twim at riseup.net (Ivan Markin) Date: Mon, 07 Sep 2015 01:37:35 +0000 Subject: Extra data in APDU response when signing by OpenPGP card In-Reply-To: <55ECD4BC.60107@fsij.org> References: <55EACC69.6070106@riseup.net> <55ECD4BC.60107@fsij.org> Message-ID: <55ECEA5F.3050908@riseup.net> NIIBE Yutaka: > It is because of the encoding in gpg-agent/scdaemon. > > (1) 25 32 35 is: % 2 5 > (2) 25 20 44 is: % 0 D > > (1) is to escape '%' (ASCII value 0x25). > (2) is to represent CR (ASCII value 0x0d). Thanks! Where I can read more about it? Are these encodings the only ones? -- Ivan Markin From gniibe at fsij.org Mon Sep 7 06:57:28 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 07 Sep 2015 13:57:28 +0900 Subject: scdaemon changes Message-ID: <55ED1938.5000106@fsij.org> Hello, I haven't yet decided how to change key attribute from ECC to RSA (scdaemon doesn't know about the card format of key attribute for RSA), RSA key attribute change for different key size and RSA to ECC should be supported. Here is a change forcing key attribute change at KEYTOCARD. I'm going to commit this change together with minor clean up of scdaemon. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index f7ad274..8f7c8b0 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -2729,6 +2729,43 @@ change_keyattr (app_t app, int keyno, const unsigned char *buf, size_t buflen, } +static gpg_error_t +change_rsa_keyattr (app_t app, int keyno, unsigned int nbits, + gpg_error_t (*pincb)(void*, const char *, char **), + void *pincb_arg) +{ + gpg_error_t err = 0; + unsigned char *buf; + size_t buflen; + void *relptr; + + /* Read the current attributes into a buffer. */ + relptr = get_one_do (app, 0xC1+keyno, &buf, &buflen, NULL); + if (!relptr) + err = gpg_error (GPG_ERR_CARD); + else if (buflen < 6 || buf[0] != PUBKEY_ALGO_RSA) + { + /* Attriutes too short or not an RSA key. */ + xfree (relptr); + err = gpg_error (GPG_ERR_CARD); + } + else + { + /* We only change n_bits and don't touch anything else. Before we + do so, we round up NBITS to a sensible way in the same way as + gpg's key generation does it. This may help to sort out problems + with a few bits too short keys. */ + nbits = ((nbits + 31) / 32) * 32; + buf[1] = (nbits >> 8); + buf[2] = nbits; + err = change_keyattr (app, keyno, buf, buflen, pincb, pincb_arg); + xfree (relptr); + } + + return err; +} + + /* Helper to process an setattr command for name KEY-ATTR. In (VALUE,VALUELEN), it expects following string: RSA: "--force rsa" @@ -2779,36 +2816,7 @@ change_keyattr_from_string (app_t app, else if (nbits > 4096) err = gpg_error (GPG_ERR_TOO_LARGE); else - { - unsigned char *buf; - size_t buflen; - void *relptr; - - /* Read the current attributes into a buffer. */ - relptr = get_one_do (app, 0xC1+keyno, &buf, &buflen, NULL); - if (!relptr) - { - err = gpg_error (GPG_ERR_CARD); - goto leave; - } - if (buflen < 6 || buf[0] != PUBKEY_ALGO_RSA) - { - /* Attriutes too short or not an RSA key. */ - xfree (relptr); - err = gpg_error (GPG_ERR_CARD); - goto leave; - } - - /* We only change n_bits and don't touch anything else. Before we - do so, we round up NBITS to a sensible way in the same way as - gpg's key generation does it. This may help to sort out problems - with a few bits too short keys. */ - nbits = ((nbits + 31) / 32) * 32; - buf[1] = (nbits >> 8); - buf[2] = nbits; - err = change_keyattr (app, keyno, buf, buflen, pincb, pincb_arg); - xfree (relptr); - } + err = change_rsa_keyattr (app, keyno, nbits, pincb, pincb_arg); } else if (algo == PUBKEY_ALGO_ECDH || algo == PUBKEY_ALGO_ECDSA || algo == PUBKEY_ALGO_EDDSA) @@ -2971,6 +2979,14 @@ rsa_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), if (opt.verbose) log_info ("RSA modulus size is %u bits (%u bytes)\n", nbits, (unsigned int)rsa_n_len); + if (nbits && nbits != maxbits + && app->app_local->extcap.algo_attr_change) + { + /* Try to switch the key to a new length. */ + err = change_rsa_keyattr (app, keyno, nbits, pincb, pincb_arg); + if (!err) + maxbits = app->app_local->keyattr[keyno].rsa.n_bits; + } if (nbits != maxbits) { log_error (_("RSA modulus missing or not of size %d bits\n"), @@ -3327,9 +3343,22 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), || app->app_local->keyattr[keyno].ecc.oid != oidstr || app->app_local->keyattr[keyno].ecc.flags != flag_djb_tweak) { - log_error ("key attribute on card doesn't match\n"); - err = gpg_error (GPG_ERR_INV_VALUE); - goto leave; + if (app->app_local->extcap.algo_attr_change) + { + unsigned char keyattr[oid_len]; + + keyattr[0] = algo; + memcpy (keyattr+1, oidbuf+1, oid_len-1); + err = change_keyattr (app, keyno, keyattr, oid_len, pincb, pincb_arg); + if (err) + goto leave; + } + else + { + log_error ("key attribute on card doesn't match\n"); + err = gpg_error (GPG_ERR_INV_VALUE); + goto leave; + } } if (opt.verbose) -- From gniibe at fsij.org Mon Sep 7 07:54:37 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 07 Sep 2015 14:54:37 +0900 Subject: Extra data in APDU response when signing by OpenPGP card In-Reply-To: <55ECEA5F.3050908@riseup.net> References: <55EACC69.6070106@riseup.net> <55ECD4BC.60107@fsij.org> <55ECEA5F.3050908@riseup.net> Message-ID: <55ED269D.8070802@fsij.org> On 09/07/2015 10:37 AM, Ivan Markin wrote: > Where I can read more about it? Are these encodings the only ones? There is another: LF (0x0A). It is described in Assual manual: Developing with Assuan, section 3.1 Server responses: https://www.gnupg.org/documentation/manuals/assuan/Server-responses.html#Server-responses -- From wk at gnupg.org Mon Sep 7 11:47:34 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Sep 2015 11:47:34 +0200 Subject: PIN Entry in Android does not allow non-numeric PIN In-Reply-To: (Eduardo Garcia-Prieto's message of "Sun, 6 Sep 2015 19:07:20 +1000") References: Message-ID: <878u8iftmx.fsf@vigenere.g10code.de> On Sun, 6 Sep 2015 11:07, egarcia74 at gmail.com said: > unfortuantely it only allows numbers to be entered. The PIN used to > protect GPG keys on a YubiKey can also consist of alphabetic and > punctuation characters. Right, but you will run into severe problems if you want to enter them on a PIN-Pad (which has only digits). Note that a PIN and a passphrase have different properties and thus a few digits are sufficient to protect access to a smartcard. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Sep 7 19:24:29 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Sep 2015 19:24:29 +0200 Subject: Integrating n-of-m threshold scheme In-Reply-To: <55EB2AB9.50506@cardcontact.de> (Andreas Schwier's message of "Sat, 05 Sep 2015 19:47:37 +0200") References: <55EB2AB9.50506@cardcontact.de> Message-ID: <87lhcidtwy.fsf@vigenere.g10code.de> On Sat, 5 Sep 2015 19:47, andreas.schwier.ml at cardcontact.de said: > One idea is to provide an additional set of commands in scdaemon that > allow a secondary application to perform authentication. The other idea > is to provide a separate tool like pinentry that performs the > authentication steps. Ideally the scheme should allow remote > authentication, e.g. where key custodians can connect over the Internet FWIW: There used to be a remote feature in scdaemon (RAPDU) to access card services from remote using an ssh connection. It actually worked once upon a time but it was not finished due bankrupt of the customer. The main problem with secret sharing is obviously the user interface and the very reason why we do not yet have this in GnuPG. There was an interesting project which might be useful for ideas: https://lists.gnupg.org/pipermail/gnupg-devel/2008-July/024506.html https://lists.gnupg.org/pipermail/gnupg-devel/2008-November/024662.html http://nwl.cc/cgi-bin/git/gitweb.cgi?p=ssd.git;a=summary What are the use cases you have in mind? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From andreas.schwier.ml at cardcontact.de Mon Sep 7 20:39:22 2015 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Mon, 07 Sep 2015 20:39:22 +0200 Subject: Integrating n-of-m threshold scheme In-Reply-To: <87lhcidtwy.fsf@vigenere.g10code.de> References: <55EB2AB9.50506@cardcontact.de> <87lhcidtwy.fsf@vigenere.g10code.de> Message-ID: <55EDD9DA.9080406@cardcontact.de> > What are the use cases you have in mind? The feature was actually developed based on a customer request. It will be used for 3 different use cases 1. Protect access to CA signing keys In the CA procedure the CA key store may only be activated by two key custodians acting together. Because key custodians have different times on duty, a group of 6 persons are authorized and two must act together to enable CA keys. 2. Key escrow User documents are encrypted for a private key controlled by the document owner. If the document owner can no longer take control, a group of people come together to enable access to the escrow key, for which a copy of each document is encrypted. In the scheme 5 out of 10 key custodians must work together. 3. Shared control SSH access There exists a dedicated and quite expensive hardware box that allows to share control for important SSH keys. Using a SmartCard-HSM to store the SSH key and the a n-of-m scheme allows a less costly alternative using standard tools. Of course there are more applications, like safeguarding code signing keys for example. The other application is remote activation where the SmartCard-HSM connects to an authentication server for activation. For the PKCS#11 interface we are looking to use the remote management interface available in the ScriptingServer of the OpenSCDP project. That is basically a HTTP protocol (RAMoverHTTP from Global Platform) that connects the SmartCard-HSM via the P11 module with a remote server. Purpose of the server is to manage the authentication protocol, i.e. provide a website to the key custodian and support the authentication protocol for both sides, the SmartCard-HSM performing the n-of-m scheme and the device with the private authentication key. Sounds to me like the remote APDU feature is similar. Where would I find the code ? > > > Salam-Shalom, > > Werner > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Sch?lerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com From wk at gnupg.org Tue Sep 8 09:06:38 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Sep 2015 09:06:38 +0200 Subject: [Announce] Libgcrypt 1.6.4 released Message-ID: <877fo1e6f5.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.6.4. This is a maintenance release with a minor security fix. Libgcrypt is a general purpose library of cryptographic building blocks. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required for proper use of Libgcrypt. Noteworthy changes in version 1.6.4 =================================== * Speed up the random number generator by requiring less extra seeding. * New flag "no-keytest" for ECC key generation. Due to a bug in the parser that flag will also be accepted but ignored by older version of Libgcrypt. * Always verify a created RSA signature to avoid private key leaks due to hardware failures. * Fix alignment bug in the AESNI code on Windows > 7. * Support FreeBSD 10 and later. * Other minor bug fixes. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html . On the primary server the source tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.4.tar.bz2 (2490k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.4.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.4.tar.gz (2901k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.4.tar.gz.sig The same files are also available via HTTP: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.6.4.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.6.4.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.6.4.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.6.4.tar.gz.sig In order to check that the version of Libgcrypt you are going to build is an original and unmodified one, you can do it in one of the following ways: * Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.6.4.tar.bz2 you would use this command: gpg --verify libgcrypt-1.6.4.tar.bz2.sig libgcrypt-1.6.4.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one of the release signing keys. See https://gnupg.org/signature_key.html . * If you are not able to use GnuPG, you have to verify the SHA-1 checksum: sha1sum libgcrypt-1.6.4.tar.bz2 and check that the output matches the first line from the following list: ed52add1ce635deeb2f5c6650e52667debd4ec70 libgcrypt-1.6.4.tar.bz2 da6507d7ba902d7482cc09e1114ccaf3ab495c76 libgcrypt-1.6.4.tar.gz Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Maintenance and development of GnuPG is possible due to many individual and corporate donations; for a list of non-anonymous donors see . For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gcrypt-devel 'at' gnupg.org mailing lists. [1] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] https://www.gnupg.org/service.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Tue Sep 8 13:39:23 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Sep 2015 13:39:23 +0200 Subject: [admin] Closing the gpa-dev list Message-ID: <87oahdcf84.fsf@vigenere.g10code.de> Hi! This is the last message to the gpa-dev list. Due to a lack of traffic that list will now be closed. Development discussions around GPA should now be directed to the gnupg-devel at gnupg.org list. The 256 current subscribers will not automatically be migrated to gnupg-devel; please do this yourself: See . Question on the use of GPA should be directed to the gnupg-users mailing list: . Thanks for taking part in GPA development over the last 15 years and I hope to read you again over at gnupg-devel. Special thanks to Bernd Eckenfels who moderated this list (and many others) and thus kept it free of spam. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: From wk at gnupg.org Tue Sep 8 17:44:29 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Sep 2015 17:44:29 +0200 Subject: [Announce] GnuPG 2.0.29 (stable) released Message-ID: <877fo0dig2.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2.0 release: Version 2.0.29. This is a maintenance release which fixes a couple of bugs. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features including support for ECC. - GnuPG "stable" (2.0) - which this is about - is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in 2.0.29 ==================== * gpg: Print a PGP-2 fingerprint again instead of a row of "0". * gpg: Fixed a race condition from multiple several "gpg --verify". * gpg: Print FAILURE status lines to help GPGME. * gpgsm: Fixed a regression in CSR generation. * scdaemon: Fixed problems with some pinpads. * Fixed a few other bugs. Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: Source code is hosted at the GnuPG FTP server and its mirrors as listed at . On the primary server the source tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.29.tar.bz2 (2490k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.0.29.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs for GnuPG-2. A Windows version will soon be released at . If you are new to GnuPG please consider to use the "modern" version 2.1.7. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.0.29.tar.bz2 you would use this command: gpg --verify gnupg-2.0.29.tar.bz2.sig gnupg-2.0.29.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.0.29.tar.bz2, you would run the command like this: sha1sum gnupg-2.0.29.tar.bz2 and check that the output matches the next line: 87eb0df18f9953675f979405a1af10ab6c5322b3 gnupg-2.0.29.tar.bz2 Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 using an already installed version of gpg. Remeber to check the fingerprints against the above list (which you also find on the flip side of our printed visit cards). The keys are also available at and in the released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using my standard PGP key. Documentation ============= The file gnupg.info has the complete user manual of the system. Separate man pages are included as well; however they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at https://www.gnupg.org/documentation/manuals/gnupg-2.0/ or in Portable Document Format at https://www.gnupg.org/documentation/manuals/gnupg-2.0.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . We also have a dedicated service directory at: https://www.gnupg.org/service.html If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Maintenance and development of GnuPG is possible due to many individual and corporate donations; for a list of non-anonymous donors see . For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users 'at' gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Wed Sep 9 10:52:33 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Sep 2015 10:52:33 +0200 Subject: [Announce] GPA 0.9.8 released Message-ID: <878u8gasa6.fsf@vigenere.g10code.de> Hello! We are pleased to announce GPA version 0.9.8. GPA is a graphical frontend for the GNU Privacy Guard (GnuPG). GPA can be used for most operations supported by GnuPG using either the OpenPGP or the S/MIME protocols. A smartcard manager and a generic user interface server are included as well. Noteworthy changes in version 0.9.8 (2015-09-09) ================================================ * Does start with the clipboard view after a key has been created. * Limit the size of dialogs by truncating too long user ids. * Make the window frame's close button work as expected. * With a decent version of libgpgme the key algorithm and size is shown using the GnuPG 2.1 format. Download ======== You can find the source code here: ftp://ftp.gnupg.org/gcrypt/gpa/gpa-0.9.8.tar.bz2 (720k) ftp://ftp.gnupg.org/gcrypt/gpa/gpa-0.9.8.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gpa/gpa-0.9.8.tar.bz2 (720k) https://gnupg.org/ftp/gcrypt/gpa/gpa-0.9.8.tar.bz2.sig and soon on all ftp.gnupg.org mirrors. A binary version for Windows will be part of the next Gpg4win release. The SHA1 checksum for this release is: d21650e3c9b07043d69e783717da4aae870e382c gpa-0.9.8.tar.bz2 Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . We also have a dedicated service directory at: . If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Maintenance and development of GPA is possible due to many individual and corporate donations; for a list of non-anonymous donors see . For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users 'at' gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Wed Sep 9 11:38:08 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Sep 2015 11:38:08 +0200 Subject: [Announce] GPA 0.9.9 released (fixing 0.9.8) Message-ID: <874mj4aq67.fsf@vigenere.g10code.de> Hello! We are pleased to announce GPA version 0.9.9. GPA is a graphical frontend for the GNU Privacy Guard (GnuPG). GPA can be used for most operations supported by GnuPG using either the OpenPGP or the S/MIME protocols. A smartcard manager and a generic user interface server are included as well. Noteworthy changes in version 0.9.9 (2015-09-09) ================================================ * This release fixes a build problem in 0.9.8. 0.9.8 will be removed from the server. * Does start with the clipboard view after a key has been created. * Limit the size of dialogs by truncating too long user ids. * Make the window frame's close button work as expected. * With a soon to be released version of libgpgme the key algorithm and size will shown using the GnuPG 2.1 format. Download ======== You can find the source code here: ftp://ftp.gnupg.org/gcrypt/gpa/gpa-0.9.9.tar.bz2 (721k) ftp://ftp.gnupg.org/gcrypt/gpa/gpa-0.9.9.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gpa/gpa-0.9.9.tar.bz2 (721k) https://gnupg.org/ftp/gcrypt/gpa/gpa-0.9.9.tar.bz2.sig and soon on all ftp.gnupg.org mirrors. A binary version for Windows will be part of the next Gpg4win release. The SHA1 checksum for this release is: 1cf86c9e38aa553fdb880c55cbc6755901ad21a4 gpa-0.9.9.tar.bz2 Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . We also have a dedicated service directory at: . If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Maintenance and development of GPA is possible due to many individual and corporate donations; for a list of non-anonymous donors see . For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users 'at' gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From jeroen.ooms at stat.ucla.edu Thu Sep 10 00:48:47 2015 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Thu, 10 Sep 2015 00:48:47 +0200 Subject: Retrieving a key from a keyserver with gpgme Message-ID: Here is a simplified version of my binding to retrieve some public keys from a keyserver: https://gist.github.com/jeroenooms/29e203d23afd36a3d113. Not sure if this is the best way of doing this. A few questions: 1) Is there any way I can check if gpg.conf has a keyserver configured? Or better: can I set a keyserver in gpgme, rather than use the one from gpg.conf (i.e. the --keyserver param in gpg) 2) Currently the export step fails for some keys. For example: the first one succeeds, but the second one does not. Why is this? ./lookup 0x7638D0442B90D010e ./lookup 0x924FC6ADC80B5E36 3) After calling gpgme_op_export_keys for the first time, the all subsequent calls to gpgme_op_keylist_next return GPG_ERR_INV_VALUE. From leo at gaspard.io Thu Sep 10 01:42:46 2015 From: leo at gaspard.io (Leo Gaspard) Date: Thu, 10 Sep 2015 01:42:46 +0200 Subject: Retrieving a key from a keyserver with gpgme In-Reply-To: References: Message-ID: <55F0C3F6.70803@gaspard.io> On 09/10/2015 12:48 AM, Jeroen Ooms wrote: > Here is a simplified version of my binding to retrieve some public > keys from a keyserver: > https://gist.github.com/jeroenooms/29e203d23afd36a3d113. Not sure if > this is the best way of doing this. A few questions: > > 1) Is there any way I can check if gpg.conf has a keyserver > configured? Or better: can I set a keyserver in gpgme, rather than use > the one from gpg.conf (i.e. the --keyserver param in gpg) As far as I can tell, there is no option for setting a keyserver in gpgme. I once sent a patch [1] to this mailing list, which has been refused for not being useful -- maybe it would still work for you, if you can afford redistributing a patched gpgme, and it being written by an untrusted used doesn't bother you. Unfortunately, I was not good at mailing lists at that time, so the discussion is spread throughout 2012-July to 2012-August... Basically, you are supposed to use gpgconf to set this. Searching again in the manuals today, it seems there is still no ideal way of doing this: you should most likely change the configuration file before using gpgme -- use [2] on a copied home directory if you do not feel like modifying the main gnupg configuration file. Cheers & HTH, Leo [1] http://lists.gnupg.org/pipermail/gnupg-devel/2012-August/026879.html [2] https://gnupg.org/documentation/manuals/gpgme/Engine-Configuration.html#Engine-Configuration > 2) Currently the export step fails for some keys. For example: the > first one succeeds, but the second one does not. Why is this? > > ./lookup 0x7638D0442B90D010e > ./lookup 0x924FC6ADC80B5E36 > > 3) After calling gpgme_op_export_keys for the first time, the all > subsequent calls to gpgme_op_keylist_next return GPG_ERR_INV_VALUE. > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Thu Sep 10 12:55:32 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Sep 2015 12:55:32 +0200 Subject: Retrieving a key from a keyserver with gpgme In-Reply-To: (Jeroen Ooms's message of "Thu, 10 Sep 2015 00:48:47 +0200") References: Message-ID: <87fv2ma6hn.fsf@vigenere.g10code.de> On Thu, 10 Sep 2015 00:48, jeroen.ooms at stat.ucla.edu said: > 1) Is there any way I can check if gpg.conf has a keyserver > configured? Or better: can I set a keyserver in gpgme, rather than use > the one from gpg.conf (i.e. the --keyserver param in gpg) You can use gpgme to manage options. Or on the command line use gpgconf --list-options gpg | awk -F: '$1=="keyserver" && $2!=1 {print $10} You need to decode the output; in particular the leading '"' indicates that a string follows which is percent escaped. > 2) Currently the export step fails for some keys. For example: the > first one succeeds, but the second one does not. Why is this? > > ./lookup 0x7638D0442B90D010e > ./lookup 0x924FC6ADC80B5E36 Assuming lookup takes a standard gpg user id, the _first_ one has one hexdigit to much. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Sep 10 21:26:05 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Sep 2015 21:26:05 +0200 Subject: [Announce] GnuPG 2.1.8 released Message-ID: <87wpvy84aa.fsf@vigenere.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.8. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about this branch. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. Noteworthy changes in version 2.1.8 =================================== * gpg: Sending very large keys to the keyservers works again. * gpg: Validity strings in key listings are now again translatable. * gpg: Emit FAILURE status lines to help GPGME. * gpg: Does not anymore link to Libksba to reduce dependencies. * gpgsm: Export of secret keys via Assuan is now possible. * agent: Raise the maximum passphrase length from 100 to 255 bytes. * agent: Fix regression using EdDSA keys with ssh. * Does not anymore use a build timestamp by default. * The fallback encoding for broken locale settings changed from Latin-1 to UTF-8. * Many code cleanups and improved internal documentation. * Various minor bug fixes. A detailed description of the changes found in the 2.1 branch can be found at . Please be aware that there are still known bugs which we are working on. Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing list archives for known problems and workarounds. Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.1.8 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.8.tar.bz2 (4786k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.8.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.8.tar.bz2 (4786k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.8.tar.bz2.sig An installer for Windows without any graphical frontend except for a basic Pinentry tool is available here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.8_20150910.exe (2579k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.8_20150910.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.8_20150910.exe (2579k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.8_20150910.exe.sig Note that on Windows TLS access to keyservers is not yet available. The sources used to build the installer can be found in the same directory with a ".tar.xz" suffix. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.8.tar.bz2 you would use this command: gpg --verify gnupg-2.1.8.tar.bz2.sig gnupg-2.1.8.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.8.tar.bz2, you run the command like this: sha1sum gnupg-2.1.8.tar.bz2 and check that the output matches the next line: 61f5bc656dd7fddd4ab67b720d47ef0651bfb727 gnupg-2.1.8.tar.bz2 fb70068a7e77f28946c24ac29a508fb5f419ffeb gnupg-w32-2.1.8_20150910.exe 504ec0f678a7a5eea144aed5a2d1691ce83e62ab gnupg-w32-2.1.8_20150910.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using by a different key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2074 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow postings at https://gnupg.org/blob/. Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Maintenance and development of GnuPG is possible due to many individual and corporate donations; for a list of non-anonymous donors see . For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From gniibe at fsij.org Tue Sep 15 10:02:43 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 15 Sep 2015 17:02:43 +0900 Subject: [PATCH] agent: Fix registering SSH Key of Ed25519 Message-ID: <55F7D0A3.8060707@fsij.org> Hello, GnuPG 2.1.7 was broken for OpenPGP authentication key of Ed25519 when it is used for SSH. I fixed this by removing the first byte. This fix itself is correct. However, there is another code path which we need to fix for SSH with Ed25519 key. That is, we need to fix the code of registering SSH key by ssh-agent feature of gpg-agent (through ssh-add). Since released version of libgcrypt puts prefix 0x40 to the Ed25519 key, we should follow this format. Here is the change. This fixes: https://bugs.gnupg.org/gnupg/issue2096 Possibly, also, http://bugs.debian.org/798956 diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 8868620..8be1255 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -580,8 +580,9 @@ stream_read_string (estream_t stream, unsigned int secure, /* Read a binary string from STREAM and store it as an opaque MPI at - R_MPI. Depending on SECURE use secure memory. If the string is - too large for key material return an error. */ + R_MPI, adding 0x40 (this is the prefix for EdDSA key in OpenPGP). + Depending on SECURE use secure memory. If the string is too large + for key material return an error. */ static gpg_error_t stream_read_blob (estream_t stream, unsigned int secure, gcry_mpi_t *r_mpi) { @@ -607,9 +608,9 @@ stream_read_blob (estream_t stream, unsigned int secure, gcry_mpi_t *r_mpi) /* Allocate space. */ if (secure) - buffer = xtrymalloc_secure (length? length:1); + buffer = xtrymalloc_secure (length+1); else - buffer = xtrymalloc (length?length:1); + buffer = xtrymalloc (length+1); if (!buffer) { err = gpg_error_from_syserror (); @@ -617,11 +618,12 @@ stream_read_blob (estream_t stream, unsigned int secure, gcry_mpi_t *r_mpi) } /* Read data. */ - err = stream_read_data (stream, buffer, length); + err = stream_read_data (stream, buffer + 1, length); if (err) goto leave; - *r_mpi = gcry_mpi_set_opaque (NULL, buffer, 8*length); + buffer[0] = 0x40; + *r_mpi = gcry_mpi_set_opaque (NULL, buffer, 8*(length+1)); buffer = NULL; leave: -- From wk at gnupg.org Wed Sep 16 17:21:37 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 Sep 2015 17:21:37 +0200 Subject: keydb.[ch], internal docs Message-ID: <87oah21jb2.fsf@vigenere.g10code.de> Hi Neal, I noticed that you greatly improved the documentation of g10/keydb.c - very good. For some functions you moved the comment from keydb.c to keydb.h. For example in keydb.c we have: --8<---------------cut here---------------start------------->8--- /* For documentation see keydb.h. */ gpg_error_t enum_secret_keys (void **context, PKT_public_key *sk) --8<---------------cut here---------------end--------------->8--- and in keydb.h: --8<---------------cut here---------------start------------->8--- /* Enumerate some secret keys (specifically, those specified with --default-key and --try-secret-key). Use the following procedure: 1) Initialize a void pointer to NULL [...long and detailed description...] */ gpg_error_t enum_secret_keys (void **context, PKT_public_key *sk); --8<---------------cut here---------------end--------------->8--- Not beeing a C++ ahcker, I am used to look directly at the code and not to switch back and forth between .c and .h. Thus I would prefer to have at least a short comment in the .c file to make it easier to understand what it is about. I know this raises the problem of syncing code and comments but it is really helpful for quick reading. What about this: --8<---------------cut here---------------start------------->8--- /* Enumerate some secret keys (specifically, those specified with --default-key and --try-secret-key). For detailed documentation see keydb.h. */ gpg_error_t enum_secret_keys (void **context, PKT_public_key *sk) --8<---------------cut here---------------end--------------->8--- BTW, it is likely that there will soon be a project which requires us to formalize the way we do internal documentation; thus we need to something here anyway. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Wed Sep 16 20:58:20 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 16 Sep 2015 20:58:20 +0200 Subject: keydb.[ch], internal docs In-Reply-To: <87oah21jb2.fsf@vigenere.g10code.de> References: <87oah21jb2.fsf@vigenere.g10code.de> Message-ID: <871tdy199v.wl-neal@walfield.org> At Wed, 16 Sep 2015 17:21:37 +0200, Werner Koch wrote: > I noticed that you greatly improved the documentation of g10/keydb.c - > very good. For some functions you moved the comment from keydb.c to > keydb.h. For example in keydb.c we have: FWIW, I moved the comments for the public APIs (not static functions). > --8<---------------cut here---------------start------------->8--- > /* For documentation see keydb.h. */ > gpg_error_t > enum_secret_keys (void **context, PKT_public_key *sk) > --8<---------------cut here---------------end--------------->8--- > > and in keydb.h: > > --8<---------------cut here---------------start------------->8--- > /* Enumerate some secret keys (specifically, those specified with > --default-key and --try-secret-key). Use the following procedure: > > 1) Initialize a void pointer to NULL > [...long and detailed description...] > */ > gpg_error_t enum_secret_keys (void **context, PKT_public_key *sk); > --8<---------------cut here---------------end--------------->8--- > > Not beeing a C++ ahcker, I am used to look directly at the code and not > to switch back and forth between .c and .h. Thus I would prefer to have > at least a short comment in the .c file to make it easier to understand > what it is about. I know this raises the problem of syncing code and > comments but it is really helpful for quick reading. What about this: I didn't realize that this is a C++ thing. I picked it up from glibc. The basic idea (or at least what I find appealing about it) is that it places all of the documentation for a particular module is in a single place without the noise of the implementations or other internal functions. The trade-off is that the documentation is clearly less accessible when looking at some particular function's implementation. Personally, I find that the advantage of this approach much out weighs the disadvantage. Does this explanation change your opinion at all? Perhaps it is possible to configure emacs so that find-tag also visits prototypes. I haven't investigated this. Neal From branko at majic.rs Wed Sep 16 22:24:24 2015 From: branko at majic.rs (=?UTF-8?B?0JHRgNCw0L3QutC+INCc0LDRmNC40Zs=?=) Date: Wed, 16 Sep 2015 22:24:24 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <878u8pjc8o.fsf@vigenere.g10code.de> References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <55E549C7.1010301@cardcontact.de> <878u8pjc8o.fsf@vigenere.g10code.de> Message-ID: <20150916222424.4242d757@majic.rs> ???? Wed, 02 Sep 2015 13:23:51 +0200 Werner Koch ??????: > On Tue, 1 Sep 2015 08:46, andreas.schwier.ml at cardcontact.de said: > > It's OK to claim exclusive access to a smart card during a session, > > but the software must release access if it's no longer needed. > > GnuPG requires the card all the time. Sorry for chiming in on this one so late, but had to work my way through the mail backlog (and this topic is of interest to me, so can't let it pass by). At work I work with X.509 CAs, OCSPs etc. In many cases I need to be able to use smart-cards through the PKCS#11 for accessing the installation for administrative purposes etc (mostly for testing deployments for customers). In parallel I also use the OpenPGP card for private purposes. However, if I have used the OpenPGP card at least once (and therefore the scdaemon is all up and running), I will not be able to use the non-OpenPGP card through the PKCS#11 middleware/interface afterwards. I don't know much about the internals (and sorry if I don't make much sense here), but can the scdaemon be modified so it does not try to get exclusive access to non-OpenPGP cards? Although this would not cover the dual-applet card scenario, it would at least allow people with non-OpenPGP cards to use them "in parallel" (well, one after another) without additional effort. At least I have this issue with GnuPG 2.0.28, perhaps this has already been fixed/implemented in GnuPG 2.1.x? Best regards -- Branko Majic Jabber: branko at majic.rs Please use only Free formats when sending attachments to me. ?????? ????? ?????: branko at majic.rs ????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Sep 17 03:20:46 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 16 Sep 2015 21:20:46 -0400 Subject: [LIBGPG-ERROR PATCH] update build architectures to support i[456]86-pc{, -linux, -kfreebsd}-gnu.h Message-ID: <1442452846-9115-1-git-send-email-dkg@fifthhorseman.net> i486-pc, i586-pc, and i686-pc all use the same ABI given the GNU userland and a specific kernel. This changeset updates the arch-specific lock-obj header generation to treat the hardware aliases explicitly and should improve cross-building for anyone wanting to target any of these 9 architectures. It also removes src/syscfg/lock-obj-pub.i486-pc-linux-gnu.h, which should be handled by the alias to src/syscfg/lock-obj-pub.i686-pc-linux-gnu.h Debian-Bug-Id: 799177 --- src/mkheader.c | 4 ++++ src/syscfg/lock-obj-pub.i486-pc-gnu.h | 24 ------------------------ src/syscfg/lock-obj-pub.i486-pc-kfreebsd-gnu.h | 23 ----------------------- src/syscfg/lock-obj-pub.i486-pc-linux-gnu.h | 23 ----------------------- src/syscfg/lock-obj-pub.i686-pc-gnu.h | 24 ++++++++++++++++++++++++ src/syscfg/lock-obj-pub.i686-pc-kfreebsd-gnu.h | 23 +++++++++++++++++++++++ 6 files changed, 51 insertions(+), 70 deletions(-) delete mode 100644 src/syscfg/lock-obj-pub.i486-pc-gnu.h delete mode 100644 src/syscfg/lock-obj-pub.i486-pc-kfreebsd-gnu.h delete mode 100644 src/syscfg/lock-obj-pub.i486-pc-linux-gnu.h create mode 100644 src/syscfg/lock-obj-pub.i686-pc-gnu.h create mode 100644 src/syscfg/lock-obj-pub.i686-pc-kfreebsd-gnu.h diff --git a/src/mkheader.c b/src/mkheader.c index b8fd783..875a0f5 100644 --- a/src/mkheader.c +++ b/src/mkheader.c @@ -77,6 +77,10 @@ canon_host_triplet (const char *triplet) } tbl[] = { {"i486-pc-linux-gnu", "i686-pc-linux-gnu" }, {"i586-pc-linux-gnu" }, + {"i486-pc-gnu", "i686-pc-gnu"}, + {"i586-pc-gnu"}, + {"i486-pc-kfreebsd-gnu", "i686-pc-kfreebsd-gnu"}, + {"i586-pc-kfreebsd-gnu"}, { NULL } }; diff --git a/src/syscfg/lock-obj-pub.i486-pc-gnu.h b/src/syscfg/lock-obj-pub.i486-pc-gnu.h deleted file mode 100644 index 59b61e1..0000000 --- a/src/syscfg/lock-obj-pub.i486-pc-gnu.h +++ /dev/null @@ -1,24 +0,0 @@ -## lock-obj-pub.i486-pc-gnu.h -## File created by gen-posix-lock-obj - DO NOT EDIT -## To be included by mkheader into gpg-error.h - -typedef struct -{ - long _vers; - union { - volatile char _priv[32]; - long _x_align; - long *_xp_align; - } u; -} gpgrt_lock_t; - -#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ - 0,0,0,0,0,0,0,0, \ - 0,0,0,0,0,0,0,0, \ - 0,0,0,0,0,0,0,0}}} -## -## Local Variables: -## mode: c -## buffer-read-only: t -## End: -## diff --git a/src/syscfg/lock-obj-pub.i486-pc-kfreebsd-gnu.h b/src/syscfg/lock-obj-pub.i486-pc-kfreebsd-gnu.h deleted file mode 100644 index 8a680d1..0000000 --- a/src/syscfg/lock-obj-pub.i486-pc-kfreebsd-gnu.h +++ /dev/null @@ -1,23 +0,0 @@ -## lock-obj-pub.i486-pc-kfreebsd-gnu.h -## File created by gen-posix-lock-obj - DO NOT EDIT -## To be included by mkheader into gpg-error.h - -typedef struct -{ - long _vers; - union { - volatile char _priv[24]; - long _x_align; - long *_xp_align; - } u; -} gpgrt_lock_t; - -#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ - 0,0,0,0,0,0,0,0, \ - 0,0,0,0,0,0,0,0}}} -## -## Local Variables: -## mode: c -## buffer-read-only: t -## End: -## diff --git a/src/syscfg/lock-obj-pub.i486-pc-linux-gnu.h b/src/syscfg/lock-obj-pub.i486-pc-linux-gnu.h deleted file mode 100644 index f1849c4..0000000 --- a/src/syscfg/lock-obj-pub.i486-pc-linux-gnu.h +++ /dev/null @@ -1,23 +0,0 @@ -## lock-obj-pub.i486-pc-linux-gnu.h -## File created by gen-posix-lock-obj - DO NOT EDIT -## To be included by mkheader into gpg-error.h - -typedef struct -{ - long _vers; - union { - volatile char _priv[24]; - long _x_align; - long *_xp_align; - } u; -} gpgrt_lock_t; - -#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ - 0,0,0,0,0,0,0,0, \ - 0,0,0,0,0,0,0,0}}} -## -## Local Variables: -## mode: c -## buffer-read-only: t -## End: -## diff --git a/src/syscfg/lock-obj-pub.i686-pc-gnu.h b/src/syscfg/lock-obj-pub.i686-pc-gnu.h new file mode 100644 index 0000000..0522462 --- /dev/null +++ b/src/syscfg/lock-obj-pub.i686-pc-gnu.h @@ -0,0 +1,24 @@ +## lock-obj-pub.i686-pc-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[32]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## diff --git a/src/syscfg/lock-obj-pub.i686-pc-kfreebsd-gnu.h b/src/syscfg/lock-obj-pub.i686-pc-kfreebsd-gnu.h new file mode 100644 index 0000000..4cf12fc --- /dev/null +++ b/src/syscfg/lock-obj-pub.i686-pc-kfreebsd-gnu.h @@ -0,0 +1,23 @@ +## lock-obj-pub.i686-pc-kfreebsd-gnu.h +## File created by gen-posix-lock-obj - DO NOT EDIT +## To be included by mkheader into gpg-error.h + +typedef struct +{ + long _vers; + union { + volatile char _priv[24]; + long _x_align; + long *_xp_align; + } u; +} gpgrt_lock_t; + +#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0, \ + 0,0,0,0,0,0,0,0}}} +## +## Local Variables: +## mode: c +## buffer-read-only: t +## End: +## -- 2.5.1 From wk at gnupg.org Thu Sep 17 09:22:46 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Sep 2015 09:22:46 +0200 Subject: [LIBGPG-ERROR PATCH] update build architectures to support i[456]86-pc{, -linux, -kfreebsd}-gnu.h In-Reply-To: <1442452846-9115-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 16 Sep 2015 21:20:46 -0400") References: <1442452846-9115-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87oah1zf09.fsf@vigenere.g10code.de> On Thu, 17 Sep 2015 03:20, dkg at fifthhorseman.net said: > This changeset updates the arch-specific lock-obj header generation to > treat the hardware aliases explicitly and should improve Thanks. Push commit 9decdd7. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dimitri.j.ledkov at intel.com Thu Sep 17 12:35:09 2015 From: dimitri.j.ledkov at intel.com (Dimitri John Ledkov) Date: Thu, 17 Sep 2015 11:35:09 +0100 Subject: Steps to enable OpenPGP smartcard support on a new distro Message-ID: Hello, I'm trying to enable OpenPGP smartcard support in gnupg 2.0.x on clearlinux.org. It would be useful to have instructions somewhere, at a low level, how to enable stuff - something like the linux from scratch book articles. So far I have: * gnupg 2.0.x with scdaemon et.al. * pcsc-lite * pcsc-tools I'm guessing I am missing udev rules or smart card definitions. gnupg --card-status generates messages from scdaemon that there is unknown error. The same yubikey operates fine on Ubuntu system as an OpenPGP smartcard. But I'm failing to trace, what makes it work on my Ubuntu machine vs clearlinux.org. Is pcsc-lite required? Does gnupg required to be configured with some specific options? Are there udev rules or similar required, that may be missing? Any help troubleshooting this would be very appreciated. -- Regards, Dimitri. 99 sleeps till Christmas https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. From wk at gnupg.org Thu Sep 17 09:02:59 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Sep 2015 09:02:59 +0200 Subject: exclusive vs. shared smart card access In-Reply-To: <20150916222424.4242d757@majic.rs> (=?utf-8?B?ItCR0YDQsNC9?= =?utf-8?B?0LrQviDQnNCw0ZjQuNGbIidz?= message of "Wed, 16 Sep 2015 22:24:24 +0200") References: <0507f793213856ea05955bfbeee9d117@suhr.org> <87io81qbyb.fsf@vigenere.g10code.de> <55E06AE4.3020903@nitrokey.com> <55E4FF6C.1050508@fsij.org> <55E549C7.1010301@cardcontact.de> <878u8pjc8o.fsf@vigenere.g10code.de> <20150916222424.4242d757@majic.rs> Message-ID: <87si6dzfx8.fsf@vigenere.g10code.de> On Wed, 16 Sep 2015 22:24, branko at majic.rs said: > However, if I have used the OpenPGP card at least once (and therefore > the scdaemon is all up and running), I will not be able to use the > non-OpenPGP card through the PKCS#11 middleware/interface afterwards. There are two options: 1. "gpgconf --kill scdaemon" on Unix you may also use "pkill scdaemon" 2. Put "card-timeout 1" int scdaemon.conf and run "gpg-connect-agent disconnect /bye" if you do not need the OpenPGP card anymore. The first gives up on the card immediately; the second delays it until all scdaemon clients have send a disconnect. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dgouttegattat at incenp.org Sat Sep 19 17:00:48 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 19 Sep 2015 17:00:48 +0200 Subject: Steps to enable OpenPGP smartcard support on a new distro In-Reply-To: References: Message-ID: <55FD78A0.4060909@incenp.org> On 09/17/2015 12:35 PM, Dimitri John Ledkov wrote: > Is pcsc-lite required? Usually, yes. Scdaemon has an internal CCID driver to talk directly with some USB card readers without any middleware, but as a comment in the source code of that driver (scd/ccid-driver.c:61) says: This is a fallback driver to be used when nothing else works or the system should be kept minimal for security reason. > Does gnupg required to be configured with some specific options? No, unless the pcsc-lite package in your distribution installs the libpcsclite.so library in an unusual location or with an unusual name (in which case you may use Scdaemon's --pcsc-driver option to specify the location of that library). > Are there udev rules or similar required, that may be missing? It depends on your pcsc-lite setup. If the pcscd(8) daemon runs under its own user account, you will need to make sure that user account is allowed to access the card reader. For example, I use the following Udev rule on my system: ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="04e6", \ ATTR{idProduct}=="5410", OWNER="scard", GROUP="scard", MODE="660" to allow pcscd (which runs under the `scard` system account) to access an Identive SCR3500 reader. Hope that helps, Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From castrillo.miguel at gmail.com Sat Sep 19 18:26:01 2015 From: castrillo.miguel at gmail.com (Miguel Castrillo) Date: Sat, 19 Sep 2015 18:26:01 +0200 Subject: Fwd: gpgme-w32spawn problem on Windows In-Reply-To: References: Message-ID: Hello, I have a problem regarding GPGME and Windows. I have searched for information on the list and on the Web but I couldn't get much more information on it. What I wanted is to create a program on C++ using OpenPGP. I did it and on Linux it works perfectly, but I have to make it working on Windows also. I am running Visual Studio 2013 and I followed the instructions here http://jensge.org/tag/crypto/ , comipling with Mingw32 on a Windows 32 machine, in order to get the def and lib files to link the DLL in implicit way. I did it and everything runs, the problem is when the code arrives to gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP) which gives an Invalid Engine Error. If I look at the debug output I get the following: gpgme:reader: leave _gpgme_io_close: leave: result=0 _gpgme_io_pipe: enter: filedes=0030ef10, inherit_idx=1 (GPGME uses it for reading) _gpgme_io_pipe: leave: read=0x0 (0000008c/0x0), write=0x1 (00000084/0x0) _gpgme_io_spawn: enter: path=001d2e00, path=C:\Program Files\GNU\GnuPG\gpgconf.exe _gpgme_io_spawn: check: path=001d2e00, argv[ 0] = C:\Program Files\GNU\GnuPG\gpgconf.exe _gpgme_io_spawn: check: path=001d2e00, argv[ 1] = --version _gpgme_io_spawn: check: path=001d2e00, tmp_name = C:\Users\XXXXX\AppData\Local\Temp\gpgme-yvRGCz _gpgme_io_spawn: check: path=001d2e00, CreateProcess ready: hProcess=00000090, hThread=00000094, dwProcessID=4968, dwThreadId=2980 _gpgme_io_spawn: check: path=001d2e00, process=00000090 _gpgme_io_close: enter: fd=00000001 _gpgme_io_close: check: fd=00000001, fd=1 -> handle=00000084 socket=-1 dupfrom=-1 _gpgme_io_close: leave: result=0 _gpgme_io_spawn: check: path=001d2e00, fd[0] = 0x1 -> 0x4 (stdout) _gpgme_io_spawn: leave: result=0 _gpgme_io_read: enter: fd=00000000, buffer=0030ef44, count=79 gpgme:create_reader: enter: fd=00000000 gpgme:create_reader: check: fd=00000000, fd=0 -> handle=0000008c socket=-1 dupfrom=-1 gpgme:get_desired_thread_priority: call: 0=00000000, 2 (default) gpgme:create_reader: leave _gpgme_io_read: check: fd=00000000, waiting for data from thread 00000084 gpgme:reader: enter: ctx->file_hd=0000008c, file_sock=-1, thread=00000084 gpgme:reader: check: ctx->file_hd=0000008c, reading 4095 bytes gpgme:reader: check: ctx->file_hd=0000008c, got EOF (broken pipe) gpgme:reader: check: ctx->file_hd=0000008c, waiting for close _gpgme_io_read: check: fd=00000000, data from thread 00000084 available _gpgme_io_read: leave: result=0 _gpgme_io_close: enter: fd=00000000 _gpgme_io_close: check: fd=00000000, fd=0 -> handle=0000008c socket=-1 dupfrom=-1 _gpgme_io_close: leave: result=0 gpgme:reader: leave gpgme_new: leave: ctx=001d2a08 gpgme_set_protocol: enter: ctx=001d2a08, protocol=0 (OpenPGP) gpgme_set_protocol: leave gpgme_set_armor: call: ctx=001d2a08, use_armor=1 (yes) engine.c:365: returning error: Invalid crypto engine engine.c:155: returning error: Invalid crypto engine What it could be the problem? Have you an idea? Thanks in advance! -- ---------------------------------------------- Miguel Castrillo Melguizo -- ---------------------------------------------- Miguel Castrillo Melguizo From gniibe at fsij.org Fri Sep 18 14:57:06 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 18 Sep 2015 21:57:06 +0900 Subject: [PATCH] scd: Fix KEYTOCARD for ECC. Message-ID: <55FC0A22.3030703@fsij.org> Hello, During the tests of Gnuk Token, I found that KEYTOCARD doesn't work sometimes. Only public keys of Ed25519 and Curve25519 are in native format. It just worked for a specific private key with MSB=0. Tested with Ed25519 and Curve25519 keys. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 8f7c8b0..d43db5b 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -3243,11 +3243,12 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), { const unsigned char **buf2; size_t *buf2len; + int native = flag_djb_tweak; switch (*tok) { case 'q': buf2 = &ecc_q; buf2len = &ecc_q_len; break; - case 'd': buf2 = &ecc_d; buf2len = &ecc_d_len; break; + case 'd': buf2 = &ecc_d; buf2len = &ecc_d_len; native = 0; break; default: buf2 = NULL; buf2len = NULL; break; } if (buf2 && *buf2) @@ -3257,13 +3258,16 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), } if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) goto leave; - if (tok && buf2 && !flag_djb_tweak) - /* It's MPI. Strip off leading zero bytes and save. */ - for (;toklen && !*tok; toklen--, tok++) - ; + if (tok && buf2) + { + if (!native) + /* Strip off leading zero bytes and save. */ + for (;toklen && !*tok; toklen--, tok++) + ; - *buf2 = tok; - *buf2len = toklen; + *buf2 = tok; + *buf2len = toklen; + } } /* Skip until end of list. */ last_depth2 = depth; -- From koto at google.com Fri Sep 18 16:08:16 2015 From: koto at google.com (Krzysztof Kotowicz) Date: Fri, 18 Sep 2015 16:08:16 +0200 Subject: Checksum error importing (unencrypted) ecdsa private key In-Reply-To: <55C95259.9000006@fsij.org> References: <1422491615.27984.YahooMailBasic@web125805.mail.ne1.yahoo.com> <55C95259.9000006@fsij.org> Message-ID: On Tue, Aug 11, 2015 at 3:39 AM, NIIBE Yutaka wrote: > Hello, > > Sorry for late response. Thanks a lot for your bug report with > reproducible case. It helps us to debug. > It looks like it hasn't been fixed yet, as I'm getting the same error in 2.1.8. Do you have a bug# to track this? We have another reproductible case at https://github.com/google/end-to-end/issues/326#issuecomment-123585977 > On 01/29/2015 09:33 AM, KB Sriram wrote: > > command 'IMPORT_KEY' failed: Checksum error > > etc. > > > > I may be wrong, but it seems like the issue is triggered around here: > > > > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/cvt-openpgp.c;h=8cf00233e4178ee34592273c167875d083406a17;hb=0c2bfd9d5a49a6134188f8f7820f6ccdebd9f181#l831 > > > > The line > > if (is_enc || curve) > > { > > > > and subsequent comment assumes that encrypted parameters or ecc > > parameters should be stored as opaque gcry_mpi_t numbers; but seems > > to me that unencrypted ecc values should not enter this clause? > > You are right. I confirmed that the code is wrong and your proposed > fix is right. > > > I think that agent/cvt-openpgp.c needs some more clean up, because we > have some experimental code remained (for ECC), and there are some > confusions about handling of opaque buffer. > > I'll do that after 2.1.7 release, possibly this week. > > In the libgcrypt computation of ECC, it uses opaque buffer for public > key of modern curves (Ed25519 and Curve25519), instead of (big endian) > MPI, as those keys are defined in little endian. > > In GnuPG, the code under g10/ (gpg frontend) just treats it as if it > were MPI, and it works well because of the prefix 0x40 for keys of > modern curves. It should be also no problem for the code under agent/ > (gpg-agent) to treat it as if it were MPI, and it does so successfully > at most parts. > > Currentlyu, we have some code in agent/cvt-openpgp.c, trying > differently somehow, and it is not correct for both of modern curves > and traditional curves (NIST, Brainpool, etc.), unfortunately. > > If we would do that faithfully, we need to distinguish the curve if > its key is opaque in libgcrypt or not. But for conversion from/to > openpgp to libgcrypt format, and for handling public key, I think > that we can treat it as if it were MPI. > > Because GnuPG 2.1 doesn't allow exporting private key with no > protection, this bug can be only encountered with external keys. > -- > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- koto@ / Krzysztof Kotowicz / Google -------------- next part -------------- An HTML attachment was scrubbed... URL: From castrillo.miguel at gmail.com Fri Sep 18 16:16:07 2015 From: castrillo.miguel at gmail.com (Miguel Castrillo) Date: Fri, 18 Sep 2015 16:16:07 +0200 Subject: gpgme-w32spawn problem on Windows Message-ID: Hello, First of all I have to ask that you CC me because my subscription request is still not accepted. Well, I have a problem regarding GPGME and Windows. I have searched for information on the list and on the Web but I couldn't get much more information on it. What I wanted is to create a program on C++ using OpenPGP. I did it and on Linux it works perfectly, but I have to make it working on Windows also. I am running Visual Studio 2013 and I followed the instructions here http://jensge.org/tag/crypto/ , comipling with Mingw32 on a Windows 32 machine, in order to get the def and lib files to link the DLL in implicit way. I did it and everything runs, the problem is when the code arrives to gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP) which gives an Invalid Engine Error. If I look at the debug output I get the following: gpgme:reader: leave _gpgme_io_close: leave: result=0 _gpgme_io_pipe: enter: filedes=0030ef10, inherit_idx=1 (GPGME uses it for reading) _gpgme_io_pipe: leave: read=0x0 (0000008c/0x0), write=0x1 (00000084/0x0) _gpgme_io_spawn: enter: path=001d2e00, path=C:\Program Files\GNU\GnuPG\gpgconf.exe _gpgme_io_spawn: check: path=001d2e00, argv[ 0] = C:\Program Files\GNU\GnuPG\gpgconf.exe _gpgme_io_spawn: check: path=001d2e00, argv[ 1] = --version _gpgme_io_spawn: check: path=001d2e00, tmp_name = C:\Users\XXXXX\AppData\Local\Temp\gpgme-yvRGCz _gpgme_io_spawn: check: path=001d2e00, CreateProcess ready: hProcess=00000090, hThread=00000094, dwProcessID=4968, dwThreadId=2980 _gpgme_io_spawn: check: path=001d2e00, process=00000090 _gpgme_io_close: enter: fd=00000001 _gpgme_io_close: check: fd=00000001, fd=1 -> handle=00000084 socket=-1 dupfrom=-1 _gpgme_io_close: leave: result=0 _gpgme_io_spawn: check: path=001d2e00, fd[0] = 0x1 -> 0x4 (stdout) _gpgme_io_spawn: leave: result=0 _gpgme_io_read: enter: fd=00000000, buffer=0030ef44, count=79 gpgme:create_reader: enter: fd=00000000 gpgme:create_reader: check: fd=00000000, fd=0 -> handle=0000008c socket=-1 dupfrom=-1 gpgme:get_desired_thread_priority: call: 0=00000000, 2 (default) gpgme:create_reader: leave _gpgme_io_read: check: fd=00000000, waiting for data from thread 00000084 gpgme:reader: enter: ctx->file_hd=0000008c, file_sock=-1, thread=00000084 gpgme:reader: check: ctx->file_hd=0000008c, reading 4095 bytes gpgme:reader: check: ctx->file_hd=0000008c, got EOF (broken pipe) gpgme:reader: check: ctx->file_hd=0000008c, waiting for close _gpgme_io_read: check: fd=00000000, data from thread 00000084 available _gpgme_io_read: leave: result=0 _gpgme_io_close: enter: fd=00000000 _gpgme_io_close: check: fd=00000000, fd=0 -> handle=0000008c socket=-1 dupfrom=-1 _gpgme_io_close: leave: result=0 gpgme:reader: leave gpgme_new: leave: ctx=001d2a08 gpgme_set_protocol: enter: ctx=001d2a08, protocol=0 (OpenPGP) gpgme_set_protocol: leave gpgme_set_armor: call: ctx=001d2a08, use_armor=1 (yes) engine.c:365: returning error: Invalid crypto engine engine.c:155: returning error: Invalid crypto engine What it could be the problem? Have you an idea? Thanks in advance! -- ---------------------------------------------- Miguel Castrillo Melguizo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Mon Sep 21 09:00:46 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 21 Sep 2015 16:00:46 +0900 Subject: Steps to enable OpenPGP smartcard support on a new distro In-Reply-To: References: Message-ID: <55FFAB1E.9060603@fsij.org> On 09/17/2015 07:35 PM, Dimitri John Ledkov wrote: > I'm trying to enable OpenPGP smartcard support in gnupg 2.0.x on > clearlinux.org. It would be useful to have instructions somewhere, at > a low level, how to enable stuff - something like the linux from > scratch book articles. > Is pcsc-lite required? No, if your purpose is OpenPGP only. If you need to use another card for anoter application, pcsc-lite would be needed. > Does gnupg required to be configured with some specific options? No, not needed. > Are there udev rules or similar required, that may be missing? You need to configure udev rules for your card readers. On my Debian box, I have this file installed for Gnuk Token for udev. ======================= /etc/udev/rules.d/69-gnuk.rules SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="234b", ATTR{idProduct}=="0000", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg" ======================= where 234b:0000 is USB ID of Gnuk Token. I don't know the detail of udev and systemd (the detail has been changed so far). The effect of having udev setting is configuring ACL for desktop user. For example, when I inserted Gnuk Token which became: Bus 002 Device 003: ID 234b:0000 (that's lsusb output). Then, I have the ACL for me to the path: ======================== $ getfacl /dev/bus/usb/002/003 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/002/003 # owner: root # group: root user::rw- user:gniibe:rw- group::rw- mask::rw- other::r-- ======================== -- From castrillo.miguel at gmail.com Mon Sep 21 10:51:24 2015 From: castrillo.miguel at gmail.com (Miguel Castrillo) Date: Mon, 21 Sep 2015 10:51:24 +0200 Subject: gpgme-w32spawn problem under Windows Message-ID: Hello, I have a problem regarding GPGME and Windows. I have searched for information on the list and on the Web but I couldn't get much more information on it. What I wanted is to create a program on C++ using OpenPGP. I did it and on Linux it works perfectly, but I have to make it working on Windows also. I am running Visual Studio 2013 and I followed the instructions here http://jensge.org/tag/crypto/ , comipling with Mingw32 on a Windows 32 machine, in order to get the def and lib files to link the DLL in implicit way. I did it and everything runs, the problem is when the code arrives to gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP) which gives an Invalid Engine Error. If I look at the debug output I get the following: gpgme:reader: leave _gpgme_io_close: leave: result=0 _gpgme_io_pipe: enter: filedes=0030ef10, inherit_idx=1 (GPGME uses it for reading) _gpgme_io_pipe: leave: read=0x0 (0000008c/0x0), write=0x1 (00000084/0x0) _gpgme_io_spawn: enter: path=001d2e00, path=C:\Program Files\GNU\GnuPG\gpgconf.exe _gpgme_io_spawn: check: path=001d2e00, argv[ 0] = C:\Program Files\GNU\GnuPG\gpgconf.exe _gpgme_io_spawn: check: path=001d2e00, argv[ 1] = --version _gpgme_io_spawn: check: path=001d2e00, tmp_name = C:\Users\XXXXX\AppData\Local\Temp\gpgme-yvRGCz _gpgme_io_spawn: check: path=001d2e00, CreateProcess ready: hProcess=00000090, hThread=00000094, dwProcessID=4968, dwThreadId=2980 _gpgme_io_spawn: check: path=001d2e00, process=00000090 _gpgme_io_close: enter: fd=00000001 _gpgme_io_close: check: fd=00000001, fd=1 -> handle=00000084 socket=-1 dupfrom=-1 _gpgme_io_close: leave: result=0 _gpgme_io_spawn: check: path=001d2e00, fd[0] = 0x1 -> 0x4 (stdout) _gpgme_io_spawn: leave: result=0 _gpgme_io_read: enter: fd=00000000, buffer=0030ef44, count=79 gpgme:create_reader: enter: fd=00000000 gpgme:create_reader: check: fd=00000000, fd=0 -> handle=0000008c socket=-1 dupfrom=-1 gpgme:get_desired_thread_priority: call: 0=00000000, 2 (default) gpgme:create_reader: leave _gpgme_io_read: check: fd=00000000, waiting for data from thread 00000084 gpgme:reader: enter: ctx->file_hd=0000008c, file_sock=-1, thread=00000084 gpgme:reader: check: ctx->file_hd=0000008c, reading 4095 bytes gpgme:reader: check: ctx->file_hd=0000008c, got EOF (broken pipe) gpgme:reader: check: ctx->file_hd=0000008c, waiting for close _gpgme_io_read: check: fd=00000000, data from thread 00000084 available _gpgme_io_read: leave: result=0 _gpgme_io_close: enter: fd=00000000 _gpgme_io_close: check: fd=00000000, fd=0 -> handle=0000008c socket=-1 dupfrom=-1 _gpgme_io_close: leave: result=0 gpgme:reader: leave gpgme_new: leave: ctx=001d2a08 gpgme_set_protocol: enter: ctx=001d2a08, protocol=0 (OpenPGP) gpgme_set_protocol: leave gpgme_set_armor: call: ctx=001d2a08, use_armor=1 (yes) engine.c:365: returning error: Invalid crypto engine engine.c:155: returning error: Invalid crypto engine What it could be the problem? Have you an idea? Thanks in advance! -- ---------------------------------------------- Miguel Castrillo Melguizo From wk at gnupg.org Mon Sep 21 11:56:10 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Sep 2015 11:56:10 +0200 Subject: gpgme-w32spawn problem on Windows In-Reply-To: (Miguel Castrillo's message of "Fri, 18 Sep 2015 16:16:07 +0200") References: Message-ID: <87si68rt8l.fsf@vigenere.g10code.de> On Fri, 18 Sep 2015 16:16, castrillo.miguel at gmail.com said: > First of all I have to ask that you CC me because my subscription request > is still not accepted. We had some problems with the list to a full disk state. I had to remove all pending subscription requests, thus please try again if you did not received the confirmation request. > am running Visual Studio 2013 and I followed the instructions here > http://jensge.org/tag/crypto/ , comipling with Mingw32 on a Windows 32 > machine, in order to get the def and lib files to link the DLL in implicit I have not looked at these instructions. However some mingw versions are broken and I would not suggest to build on Windows but use the cross build tools. I would also suggest to try the libgpgme*.dll from gpg4win and the distributed header and lib files and copy them to the directory of your application. You also need to copy the matching helper program to that directory. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From castrillo.miguel at gmail.com Mon Sep 21 14:40:44 2015 From: castrillo.miguel at gmail.com (Miguel Castrillo) Date: Mon, 21 Sep 2015 14:40:44 +0200 Subject: gpgme-w32spawn problem on Windows In-Reply-To: <87si68rt8l.fsf@vigenere.g10code.de> References: <87si68rt8l.fsf@vigenere.g10code.de> Message-ID: Thank you, now I see that I submitted multiple messages, thinking that they were not arriving. Sorry for that... I don't sure if I understand. As far as I know libgpgme*.dll is not distributed. The same happens with the lib files. From gpgme source I can get the headers, but in order to have .lib and .def files I had to compile the gpgme source. The gpg4win I installed provides libgpg-error-0.dll, appart from others, but not libgpgme*.dll. So maybe you mean to download gpg4win source and compile it under Linux? 2015-09-21 11:56 GMT+02:00 Werner Koch : > On Fri, 18 Sep 2015 16:16, castrillo.miguel at gmail.com said: > >> First of all I have to ask that you CC me because my subscription request >> is still not accepted. > > We had some problems with the list to a full disk state. I had to > remove all pending subscription requests, thus please try again if you > did not received the confirmation request. > >> am running Visual Studio 2013 and I followed the instructions here >> http://jensge.org/tag/crypto/ , comipling with Mingw32 on a Windows 32 >> machine, in order to get the def and lib files to link the DLL in implicit > > I have not looked at these instructions. However some mingw versions > are broken and I would not suggest to build on Windows but use the cross > build tools. I would also suggest to try the libgpgme*.dll from gpg4win > and the distributed header and lib files and copy them to the directory > of your application. You also need to copy the matching helper program > to that directory. > > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -- ---------------------------------------------- Miguel Castrillo Melguizo From wk at gnupg.org Mon Sep 21 16:01:45 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Sep 2015 16:01:45 +0200 Subject: gpgme-w32spawn problem on Windows In-Reply-To: (Miguel Castrillo's message of "Mon, 21 Sep 2015 14:40:44 +0200") References: <87si68rt8l.fsf@vigenere.g10code.de> Message-ID: <87pp1brhva.fsf@vigenere.g10code.de> On Mon, 21 Sep 2015 14:40, castrillo.miguel at gmail.com said: > I don't sure if I understand. As far as I know libgpgme*.dll is not > distributed. The same happens with the lib files. From gpgme source I It might be that the vanilla installer does not distibute gpgme. The light and standard installers do that: bin/libgpgme-11.dll bin/libgpgme-glib-11.dll bin/gpgme-w32spawn.exe lib/libgpgme.dll.a lib/libgpgme-glib.dll.a include/gpgme.h The *dll.a are the import files. The GnuPG 2.1 installer has these files: File bin/libgpgme-11.dll File bin/gpgme-w32spawn.exe File lib/libgpgme.dll.a File include/gpgme.h for a new project I would suggest to use 2.1. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From castrillo.miguel at gmail.com Mon Sep 21 17:19:01 2015 From: castrillo.miguel at gmail.com (Miguel Castrillo) Date: Mon, 21 Sep 2015 17:19:01 +0200 Subject: gpgme-w32spawn problem on Windows In-Reply-To: <87pp1brhva.fsf@vigenere.g10code.de> References: <87si68rt8l.fsf@vigenere.g10code.de> <87pp1brhva.fsf@vigenere.g10code.de> Message-ID: As it is used to say... I should have figured it out. Lately I thought in installing the complete version of gpg2win, but finally discarded that option because I didn't think it included gpme also... What I did, in case it is useful for anybody: - Installed gpg4win. - Copied dll files and gpgme-w32spawn.exe to my aplication's run dir. (I had to copy the spawning exe there, because it didn't run from C:/Program Files/GNU/GnuPG, although it finds succesfully the gpgconf.exe in that path). - Included to my project VS 2013 the .h and .imp files. PS: I used the gpg4win 2.2.6 version to give it a try and it included .imp files instead of .a files in /lib, which I think is better for me for including it in VS. I don't really know much about the difference between .lib files and .imp files but it seems to work. With .a files I think is not so straightforward. Thank you very much I was getting crazy with this problem, 2015-09-21 16:01 GMT+02:00 Werner Koch : > On Mon, 21 Sep 2015 14:40, castrillo.miguel at gmail.com said: > >> I don't sure if I understand. As far as I know libgpgme*.dll is not >> distributed. The same happens with the lib files. From gpgme source I > > It might be that the vanilla installer does not distibute gpgme. The > light and standard installers do that: > > bin/libgpgme-11.dll > bin/libgpgme-glib-11.dll > bin/gpgme-w32spawn.exe > lib/libgpgme.dll.a > lib/libgpgme-glib.dll.a > include/gpgme.h > > The *dll.a are the import files. > > The GnuPG 2.1 installer has these files: > > File bin/libgpgme-11.dll > File bin/gpgme-w32spawn.exe > File lib/libgpgme.dll.a > File include/gpgme.h > > for a new project I would suggest to use 2.1. > > > Shalom-Salam, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -- ---------------------------------------------- Miguel Castrillo Melguizo From wk at gnupg.org Mon Sep 21 18:11:10 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Sep 2015 18:11:10 +0200 Subject: gpgme-w32spawn problem on Windows In-Reply-To: (Miguel Castrillo's message of "Mon, 21 Sep 2015 17:19:01 +0200") References: <87si68rt8l.fsf@vigenere.g10code.de> <87pp1brhva.fsf@vigenere.g10code.de> Message-ID: <87h9mnrbvl.fsf@vigenere.g10code.de> On Mon, 21 Sep 2015 17:19, castrillo.miguel at gmail.com said: > between .lib files and .imp files but it seems to work. With .a files We use the dll.a suffix instead of .imp - the fils are identical. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From arthur2e5 at aosc.xyz Tue Sep 22 01:07:06 2015 From: arthur2e5 at aosc.xyz (Mingye Wang (Arthur2e5)) Date: Mon, 21 Sep 2015 19:07:06 -0400 Subject: [libgpg-error][L10n@TP] Inconsistent state on TP and in Git Repo. Message-ID: <56008D9A.7040703@aosc.xyz> Hey all, I have found that `libgpg-error`'s translations in your [git po/] has diverted with that on [TranslationProject]. I have noticed the TP Coord, and it seems that two of the translation contributors haven't signed that GNU translation disclaimer, causing TP unable to merge the translations in. In some other childishly-strict words, you upstream violated two rules: * You set the TP domain as need-disclaimer, but let non-disclaimed translations come in your git tree. It's violating the rules you made. * Generally you shouldn't edit or change the PO files in your repository directly, ?as this would undermine the authority of the language teams and defeat their purpose.? ([TP Maint Info]) To make things work, you can either remove the disclaimer requirement (which is risky and weird for GNU projects), or wait for the translators to disclaim. Or you can mark the translations as `external` on TP, I have seen a few projects doing that already. And for translators that I have CCed to, please join the TP teams of your locale and sign the [disclaimer]. * * * Links: [git po/]:http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=tree;f=po;hb=HEAD [TP Domain]:https://translationproject.org/domain/libgpg-error.html [TP Maint Info]:https://translationproject.org/html/maintainers.html [disclaimer]:https://my.fsf.org/civicrm/profile/create?gid=91&reset=1 * * * To TP Coord Benno, I think it would be possible to do a partial merge, excluding the non-disclaimed languages, pt and ru. Well I don't really need them now, so.. -- Regards, Arthur2e5 (0x222D7BDA) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Tue Sep 22 03:45:09 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 22 Sep 2015 10:45:09 +0900 Subject: RSA signature verification in gpg-agent? Message-ID: <5600B2A5.2040505@fsij.org> Hello, I'd like to discuss RSA signature verification by gpg-agent. Especially, for signature generated by smartcard. The context is Florian Weimer' paper, Factoring RSA Keys With TLS Perfect Forward Secrecy. In libgcrypt, we had a following commit. ======================================== commit c17f84bd02d7ee93845e92e20f6ddba814961588 Author: Werner Koch Date: Mon Aug 31 23:13:27 2015 +0200 rsa: Add verify after sign to avoid Lenstra's CRT attack. * cipher/rsa.c (rsa_sign): Check the CRT. -- Failures in the computation of the CRT (e.g. due faulty hardware) can lead to a leak of the private key. The standard precaution against this is to verify the signature after signing. GnuPG does this itself and even has an option to disable this. However, the low performance impact of this extra precaution suggest that it should always be done and Libgcrypt is the right place here. For decryption is not done because the application will detect the failure due to garbled plaintext and in any case no key derived material will be send to the user. Signed-off-by: Werner Koch ======================================== In gnupg/g10/sign.c, we have following code after generating signature. ======================================== /* Check that the signature verification worked and nothing is * fooling us e.g. by a bug in the signature create code or by * deliberately introduced faults. Because Libgcrypt 1.7 does this * for RSA internally there is no need to do it here again. */ if (!err #if GCRYPT_VERSION_NUMBER >= 0x010700 /* Libgcrypt >= 1.7 */ && !is_RSA (pksk->pubkey_algo) #endif /* Libgcrypt >= 1.7 */ ) { ======================================== I wonder if it should be done in gpg-agent, since signing can be done for ssh and gpgsm as well. Besides, I think that it would be good for gpg-agent to check signature for smartcard, too. Well, it only protects against possible attack with gpg-agent, though. Note that Gnuk doesn't verify signature after generating, currently. It should be done by the smartcard implementation itself if we want to protect correctly, but there are existing implementations, too. Thus, I think that it might make sense for gpg-agent to verigy RSA signature generated by smartcard, before returning it to user. Any thoughts? -- From wk at gnupg.org Tue Sep 22 08:51:21 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Sep 2015 08:51:21 +0200 Subject: [libgpg-error][L10n@TP] Inconsistent state on TP and in Git Repo. In-Reply-To: <56008D9A.7040703@aosc.xyz> (Mingye Wang's message of "Mon, 21 Sep 2015 19:07:06 -0400") References: <56008D9A.7040703@aosc.xyz> Message-ID: <87y4fzosk6.fsf@vigenere.g10code.de> On Tue, 22 Sep 2015 01:07, arthur2e5 at aosc.xyz said: > I have found that `libgpg-error`'s translations in your [git po/] has > diverted with that on [TranslationProject]. I have noticed the TP Coord, GnuPG does not make use the translation robot/project for more than a decade. Translations should be send to translations@ or the i18n@ ML. Further: The need for copyright assignments to the FSF has been waived on 2013-03-29; the need for copyright disclaimers for translations already in December 2012. Salam-Shalom, Werner p.s. I wish people would give on using these silly top level domains or check with the Gnus developers to first get them implemented there. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From Juergen.Schaepker at giepa.de Tue Sep 22 10:50:43 2015 From: Juergen.Schaepker at giepa.de (=?Windows-1252?Q?J=FCrgen_Sch=E4pker?=) Date: Tue, 22 Sep 2015 10:50:43 +0200 Subject: gpg-preset-passphrase not included in gnupg-w32-2.1.x Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51AAF662CE6@S2008SBS.intern.giepa.de> Hi, gpg-preset-passphrase seems to be missing from Win32 GnuPG 2.1 binaries while it is included in Linux builds. Just forgotten or was it removed intentionally? Best regards, J?rgen From dkg at fifthhorseman.net Fri Sep 25 05:41:19 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 24 Sep 2015 23:41:19 -0400 Subject: RSA signature verification in gpg-agent? In-Reply-To: <5600B2A5.2040505@fsij.org> References: <5600B2A5.2040505@fsij.org> Message-ID: <87twqjcgio.fsf@alice.fifthhorseman.net> On Mon 2015-09-21 21:45:09 -0400, NIIBE Yutaka wrote: > Thus, I think that it might make sense for gpg-agent to verify RSA > signature generated by smartcard, before returning it to user. This seems sensible to me. Given the performance characteristics of RSA and of hardware smartcards, i can't imagine that this imposes much of a performance cost either. Thanks for thinking about this, gniibe. --dkg From dkg at fifthhorseman.net Fri Sep 25 06:17:07 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 25 Sep 2015 00:17:07 -0400 Subject: please do not change "Directory Manager" to "Network Maanager" Message-ID: <87lhbvcev0.fsf@alice.fifthhorseman.net> hi all-- 819bba75aaed11ecef2e274add173718358212b9 changes the component name of dirmngr from "Directory Manager" to "Network Manager". "Network Manager" is already used by a widely known project: https://wiki.gnome.org/Projects/NetworkManager I think it may confuse users to think that GnuPG might be talking to the Network Manager daemon, when actually it's talking to its own dirmngr. How about "Directory Network Access" or "Network Access Manager" or something like that instead? --dkg From kristian.fiskerstrand at sumptuouscapital.com Fri Sep 25 22:28:34 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 25 Sep 2015 22:28:34 +0200 Subject: please do not change "Directory Manager" to "Network Maanager" In-Reply-To: <87lhbvcev0.fsf@alice.fifthhorseman.net> References: <87lhbvcev0.fsf@alice.fifthhorseman.net> Message-ID: <5605AE72.3040700@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/25/2015 06:17 AM, Daniel Kahn Gillmor wrote: > hi all-- > > 819bba75aaed11ecef2e274add173718358212b9 > > changes the component name of dirmngr from "Directory Manager" to > "Network Manager". > > "Network Manager" is already used by a widely known project: Seconded - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Adde parvum parvo magnus acervus erit Add little to little and there will be a big pile -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJWBa5uAAoJECULev7WN52FtRAH/iwwGLHNibW/Z0qp3YPg/acg 0MJyAXMOT6P0sS15OovI3wngO3s4RuukZEZ6W3ux63b6TIvUylHl0N3ypqTWkUp5 PybPBNNAMmkQ3DHDGGuG21Vrhhbo+d0+84Vi5rRL54xV7pCmbpJoNAH5gedTNje7 EiBX50x8y3E9bEM04ZkY93OBPnVmmsnnYBgz0J26SYh9OY9Gmgj9Z46LSUR3/iWw eeyRa4S5tk2gy1RBDN3VJOYOjNcj1JYDQtPCAeOk19Etwh+c8i91ZXqoEUKNRIqB JNXdJvdBVzmA1xQ7AInJi7qM/TERthxFlCGWDnNE4PK0UlYHVA6tS0iE5YcfDQc= =Qnvm -----END PGP SIGNATURE----- From wk at gnupg.org Sat Sep 26 00:03:00 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 26 Sep 2015 00:03:00 +0200 Subject: please do not change "Directory Manager" to "Network Maanager" In-Reply-To: <87lhbvcev0.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 25 Sep 2015 00:17:07 -0400") References: <87lhbvcev0.fsf@alice.fifthhorseman.net> Message-ID: <87y4fugnsb.fsf@vigenere.g10code.de> On Fri, 25 Sep 2015 06:17, dkg at fifthhorseman.net said: > How about "Directory Network Access" or "Network Access Manager" or Too long for the tab in GPA's backend preferences dialog. What about just "Network Access"? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Sep 26 00:00:48 2015 From: wk at gnupg.org (Werner Koch) Date: Sat, 26 Sep 2015 00:00:48 +0200 Subject: RSA signature verification in gpg-agent? In-Reply-To: <87twqjcgio.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 24 Sep 2015 23:41:19 -0400") References: <5600B2A5.2040505@fsij.org> <87twqjcgio.fsf@alice.fifthhorseman.net> Message-ID: <8737y2i2gf.fsf@vigenere.g10code.de> On Fri, 25 Sep 2015 05:41, dkg at fifthhorseman.net said: > This seems sensible to me. Given the performance characteristics of RSA > and of hardware smartcards, i can't imagine that this imposes much of a > performance cost either. Definitely not a problem. Algorithm generate 100*priv 100*public ------------------------------------------------ RSA 1024 bit 30ms 70ms 0ms RSA 2048 bit 80ms 390ms 10ms RSA 3072 bit 3490ms 1050ms 20ms RSA 4096 bit 3590ms 2220ms 20ms Thus for a 2k key the public key operation (verify) takes only 2% of the secret key operation (signing). Thus it is barely noticeable even if you consider that the signing requires some random bytes. For the way slower smartcard signing the extra verify on the host does not have any measurable effect. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sam_uk at riseup.net Sat Sep 26 12:36:57 2015 From: sam_uk at riseup.net (sam_uk at riseup.net) Date: Sat, 26 Sep 2015 11:36:57 +0100 Subject: Own Mail: PGP running on local server; Is it secure Message-ID: <20150926113657.Horde.oqbo4_PTIvtpEXqQNLv9yrE@slackmail.co.uk> Hi I spotted this project: https://www.own-mailbox.com/#HowWork Their aim seems to be to make PGP more accessible by selling a pre-configured plug and play email server for non tech people to use. I'm considering getting one but I wondered if their proposed architecture is good? They are also proposing a HTTPS web interface, I guess this relies on trusting the certificate authority? Is this a good project on balance? Thanks Sam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-keys Size: 1348 bytes Desc: PGP Public Key URL: From dkg at fifthhorseman.net Sat Sep 26 18:43:03 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 26 Sep 2015 12:43:03 -0400 Subject: please do not change "Directory Manager" to "Network Maanager" In-Reply-To: <87y4fugnsb.fsf@vigenere.g10code.de> References: <87lhbvcev0.fsf@alice.fifthhorseman.net> <87y4fugnsb.fsf@vigenere.g10code.de> Message-ID: <87612xnnc8.fsf@alice.fifthhorseman.net> On Fri 2015-09-25 18:03:00 -0400, Werner Koch wrote: > On Fri, 25 Sep 2015 06:17, dkg at fifthhorseman.net said: > >> How about "Directory Network Access" or "Network Access Manager" or > > Too long for the tab in GPA's backend preferences dialog. What about > just "Network Access"? sure, "Network Access" is better than "Network Manager". --dkg From neal at walfield.org Sun Sep 27 15:11:53 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 27 Sep 2015 15:11:53 +0200 Subject: please do not change "Directory Manager" to "Network Maanager" In-Reply-To: <87y4fugnsb.fsf@vigenere.g10code.de> References: <87lhbvcev0.fsf@alice.fifthhorseman.net> <87y4fugnsb.fsf@vigenere.g10code.de> Message-ID: <87zj089fc6.wl-neal@walfield.org> At Sat, 26 Sep 2015 00:03:00 +0200, Werner Koch wrote: > On Fri, 25 Sep 2015 06:17, dkg at fifthhorseman.net said: > > > How about "Directory Network Access" or "Network Access Manager" or > > Too long for the tab in GPA's backend preferences dialog. What about > just "Network Access"? I don't think Network Access is a good name. I think we want an adjective followed by a verb that has been nominalized. Thus, using these words, I'd prefer "Network Accessor," but I don't like the sound of that one. The directory manager is primary responsible for uploading and downloading keys and CRLs. Perhaps, "Key Acquirer" or "Key Manager" is acceptable. (Both fit the above pattern.) Neal From wk at gnupg.org Sun Sep 27 18:25:43 2015 From: wk at gnupg.org (Werner Koch) Date: Sun, 27 Sep 2015 18:25:43 +0200 Subject: please do not change "Directory Manager" to "Network Maanager" In-Reply-To: <87zj089fc6.wl-neal@walfield.org> (Neal H. Walfield's message of "Sun, 27 Sep 2015 15:11:53 +0200") References: <87lhbvcev0.fsf@alice.fifthhorseman.net> <87y4fugnsb.fsf@vigenere.g10code.de> <87zj089fc6.wl-neal@walfield.org> Message-ID: <87mvw7hlrs.fsf@vigenere.g10code.de> On Sun, 27 Sep 2015 15:11, neal at walfield.org said: > The directory manager is primary responsible for uploading and > downloading keys and CRLs. Perhaps, "Key Acquirer" or "Key Manager" > is acceptable. (Both fit the above pattern.) The term Key Manager is commonly used for tools to manage a key (GPA, Kleopatra, and those included in MUAs). Thus this would be confusing; in particular if a GPA or Kleopatra display that term. One reason why I changed the name is to make it clear that all access to the net is done via dirmngr and thus not installing dirmngr will effectivly disable all web bugs. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From patrick at enigmail.net Sun Sep 27 19:14:05 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 27 Sep 2015 19:14:05 +0200 Subject: please do not change "Directory Manager" to "Network Maanager" In-Reply-To: <87mvw7hlrs.fsf@vigenere.g10code.de> References: <87lhbvcev0.fsf@alice.fifthhorseman.net> <87y4fugnsb.fsf@vigenere.g10code.de> <87zj089fc6.wl-neal@walfield.org> <87mvw7hlrs.fsf@vigenere.g10code.de> Message-ID: <560823DD.3080409@enigmail.net> On 27.09.15 18:25, Werner Koch wrote: > On Sun, 27 Sep 2015 15:11, neal at walfield.org said: > >> The directory manager is primary responsible for uploading and >> downloading keys and CRLs. Perhaps, "Key Acquirer" or "Key Manager" >> is acceptable. (Both fit the above pattern.) > > The term Key Manager is commonly used for tools to manage a key (GPA, > Kleopatra, and those included in MUAs). Thus this would be confusing; in > particular if a GPA or Kleopatra display that term. > > One reason why I changed the name is to make it clear that all access to > the net is done via dirmngr and thus not installing dirmngr will > effectivly disable all web bugs. How about Web Manager (webmngr) or Internet Access Manager? -Patrick From oleg at gurevich.de Sun Sep 27 19:27:02 2015 From: oleg at gurevich.de (Oleg Gurevich) Date: Sun, 27 Sep 2015 19:27:02 +0200 Subject: please do not change "Directory Manager" to "Network Maanager" In-Reply-To: <560823DD.3080409@enigmail.net> References: <87lhbvcev0.fsf@alice.fifthhorseman.net> <87y4fugnsb.fsf@vigenere.g10code.de> <87zj089fc6.wl-neal@walfield.org> <87mvw7hlrs.fsf@vigenere.g10code.de> <560823DD.3080409@enigmail.net> Message-ID: <560826E6.4080707@gurevich.de> what is about "key directory manager" ? It manages access to keys or revocation staff on key servers aka directory .... mit freundlichen Gr??en/ ? ?????????/ best regards Oleg Gurevich PGP fingerprint: 38A0 D0CC BD23 1707 B0AF D158 E9D7 6E3F E74A 0B0C On 09/27/2015 07:14 PM, Patrick Brunschwig wrote: > On 27.09.15 18:25, Werner Koch wrote: >> On Sun, 27 Sep 2015 15:11, neal at walfield.org said: >> >>> The directory manager is primary responsible for uploading and >>> downloading keys and CRLs. Perhaps, "Key Acquirer" or "Key Manager" >>> is acceptable. (Both fit the above pattern.) >> >> The term Key Manager is commonly used for tools to manage a key (GPA, >> Kleopatra, and those included in MUAs). Thus this would be confusing; in >> particular if a GPA or Kleopatra display that term. >> >> One reason why I changed the name is to make it clear that all access to >> the net is done via dirmngr and thus not installing dirmngr will >> effectivly disable all web bugs. > > How about Web Manager (webmngr) or Internet Access Manager? > > -Patrick > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From gniibe at fsij.org Mon Sep 28 07:37:46 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 28 Sep 2015 14:37:46 +0900 Subject: ssh: Add Ed25519 test key Message-ID: <5608D22A.7020008@fsij.org> Hello, I found we need another change for SSH's Ed25519 key. And adding a key for test is good. diff --git a/common/ssh-utils.c b/common/ssh-utils.c index fab798d..58586a1 100644 --- a/common/ssh-utils.c +++ b/common/ssh-utils.c @@ -196,6 +196,8 @@ get_fingerprint (gcry_sexp_t key, void **r_fpr, size_t *r_len, int as_string) err = gpg_err_make (default_errsource, GPG_ERR_INV_SEXP); goto leave; } + blob++; + bloblen--; lenbuf[0] = bloblen >> 24; lenbuf[1] = bloblen >> 16; lenbuf[2] = bloblen >> 8; diff --git a/common/t-ssh-utils.c b/common/t-ssh-utils.c index 9639584..961f451 100644 --- a/common/t-ssh-utils.c +++ b/common/t-ssh-utils.c @@ -163,6 +163,25 @@ static struct { const char *key; const char *fpr; } sample_keys[] = { ")", /* Passphrase="abc" */ "1e:a6:94:ab:bd:81:73:5f:22:bc:0e:c7:89:f6:68:df" }, + { /* OpenSSH 6.7p1 generated key: */ + "(protected-private-key " + "(ecc " + "(curve Ed25519)" + "(flags eddsa)" + "(q #40A3577AA7830C50EBC15B538E9505DB2F0D2FFCD57EA477DD83dcaea530f3c277#)" + "(protected openpgp-s2k3-sha1-aes-cbc " + "(" + "(sha1 #FA8123F1A37CBC1F# \"3812352\")" + "#7671C7387E2DD931CC62C35CBBE08A28#)" + "#75e928f4698172b61dffe9ef2ada1d3473f690f3879c5386e2717e5b2fa46884" + "b189ee409827aab0ff37f62996e040b5fa7e75fc4d8152c8734e2e648dff90c9" + "e8c3e39ea7485618d05c34b1b74ff59676e9a3d932245cc101b5904777a09f86#)" + "(protected-at \"20150928T050210\")" + ")" + "(comment \"eddsa w/o comment\")" + ")", /* Passphrase="abc" */ + "f1:fa:c8:a6:40:bb:b9:a1:65:d7:62:65:ac:26:78:0e" + }, { NULL, NULL -- From gniibe at fsij.org Mon Sep 28 08:33:34 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 28 Sep 2015 15:33:34 +0900 Subject: RSA signature verification in gpg-agent? In-Reply-To: <8737y2i2gf.fsf@vigenere.g10code.de> References: <5600B2A5.2040505@fsij.org> <87twqjcgio.fsf@alice.fifthhorseman.net> <8737y2i2gf.fsf@vigenere.g10code.de> Message-ID: <5608DF3E.7000606@fsij.org> Hello, So, here is the change to move signature checking to gpg-agent. It goes through 'make check' without failure. diff --git a/agent/pksign.c b/agent/pksign.c index 1d3d3d8..243c49d 100644 --- a/agent/pksign.c +++ b/agent/pksign.c @@ -290,10 +290,12 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, const void *overridedata, size_t overridedatalen) { gcry_sexp_t s_skey = NULL, s_sig = NULL; + gcry_sexp_t s_hash = NULL; unsigned char *shadow_info = NULL; unsigned int rc = 0; /* FIXME: gpg-error? */ const unsigned char *data; int datalen; + int check_signature = 0; if (overridedata) { @@ -352,6 +354,7 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, if (is_RSA) { + check_signature = 1; if (*buf & 0x80) { len++; @@ -431,8 +434,7 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, else { /* No smartcard, but a private key */ - gcry_sexp_t s_hash = NULL; - int dsaalgo; + int dsaalgo = 0; /* Put the hash into a sexp */ if (agent_is_eddsa_key (s_skey)) @@ -454,6 +456,10 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, if (rc) goto leave; + if (dsaalgo == 0 && GCRYPT_VERSION_NUMBER < 0x010700) + /* It's RSA and Libgcrypt < 1.7 */ + check_signature = 1; + if (DBG_CRYPTO) { gcry_log_debugsxp ("skey", s_skey); @@ -462,7 +468,6 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, /* sign */ rc = gcry_pk_sign (&s_sig, s_hash, s_skey); - gcry_sexp_release (s_hash); if (rc) { log_error ("signing failed: %s\n", gpg_strerror (rc)); @@ -473,11 +478,42 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, gcry_log_debugsxp ("rslt", s_sig); } + /* Check that the signature verification worked and nothing is + * fooling us e.g. by a bug in the signature create code or by + * deliberately introduced faults. Because Libgcrypt 1.7 does this + * for RSA internally there is no need to do it here again. */ + if (check_signature) + { + if (s_hash == NULL) + { + if (ctrl->digest.algo == MD_USER_TLS_MD5SHA1) + rc = do_encode_raw_pkcs1 (data, datalen, + gcry_pk_get_nbits (s_skey), + &s_hash); + else + rc = do_encode_md (data, datalen, + ctrl->digest.algo, + &s_hash, + ctrl->digest.raw_value); + } + + rc = gcry_pk_verify (s_sig, s_hash, s_skey); + + if (rc) + { + log_error (_("checking created signature failed: %s\n"), + gpg_strerror (rc)); + gcry_sexp_release (s_sig); + s_sig = NULL; + } + } + leave: *signature_sexp = s_sig; gcry_sexp_release (s_skey); + gcry_sexp_release (s_hash); xfree (shadow_info); return rc; diff --git a/g10/sign.c b/g10/sign.c index 7a8d697..4a30f1e 100644 --- a/g10/sign.c +++ b/g10/sign.c @@ -229,7 +229,6 @@ do_sign (PKT_public_key *pksk, PKT_signature *sig, gcry_md_hd_t md, int mdalgo, const char *cache_nonce) { gpg_error_t err; - gcry_mpi_t frame; byte *dp; char *hexgrip; @@ -292,35 +291,6 @@ do_sign (PKT_public_key *pksk, PKT_signature *sig, } xfree (hexgrip); - /* Check that the signature verification worked and nothing is - * fooling us e.g. by a bug in the signature create code or by - * deliberately introduced faults. Because Libgcrypt 1.7 does this - * for RSA internally there is no need to do it here again. */ - if (!err -#if GCRYPT_VERSION_NUMBER >= 0x010700 /* Libgcrypt >= 1.7 */ - && !is_RSA (pksk->pubkey_algo) -#endif /* Libgcrypt >= 1.7 */ - ) - { - PKT_public_key *pk = xmalloc_clear (sizeof *pk); - - if (get_pubkey (pk, sig->keyid )) - err = gpg_error (GPG_ERR_NO_PUBKEY); - else - { - frame = encode_md_value (pk, md, sig->digest_algo ); - if (!frame) - err = gpg_error (GPG_ERR_GENERAL); - else - err = pk_verify (pk->pubkey_algo, frame, sig->data, pk->pkey); - gcry_mpi_release (frame); - } - if (err) - log_error (_("checking created signature failed: %s\n"), - gpg_strerror (err)); - free_public_key (pk); - } - if (err) log_error (_("signing failed: %s\n"), gpg_strerror (err)); else -- From gniibe at fsij.org Mon Sep 28 10:54:35 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 28 Sep 2015 17:54:35 +0900 Subject: ssh: Fix allocation of pinentry buffer Message-ID: <5609004B.2070706@fsij.org> Hello, This is a possible fix for Issue 2111 & 2112, but I know it is yet wrong for alignment. The bug has been around, and I think that the recent change (of introducing the macro MAX_PASSPHRASE_LEN=255) reveals the bug. Allocation of PI is correct. I fixed adding - 1 because the structure has pin[1]. The bug was adding (sizeof *pi + MAX_PASSPHRASE_LEN + 1). The intention was apparently adding (sizeof *pi + MAX_PASSPHRASE_LEN + 1)-byte, but it's (sizeof *pi + MAX_PASSPHRASE_LEN + 1)* sizeof (struct pin_entry_info_s). I changed the pointer calculation using the cast to (char *), but it is wrong still, because it doesn't care about alignment of the structure. It should be rounded up to the alignment. I have to leave now, I'll be back tomorrow. diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 8be1255..90d9dca 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -3101,13 +3101,14 @@ ssh_identity_register (ctrl_t ctrl, ssh_key_type_spec_t *spec, goto out; } - pi = gcry_calloc_secure (2, sizeof (*pi) + MAX_PASSPHRASE_LEN + 1); + pi = gcry_calloc_secure (2, sizeof (*pi) - 1 + MAX_PASSPHRASE_LEN + 1); if (!pi) { err = gpg_error_from_syserror (); goto out; } - pi2 = pi + (sizeof *pi + MAX_PASSPHRASE_LEN + 1); + pi2 = (struct pin_entry_info_s *)((char *)pi + (sizeof (*pi) - 1 + + MAX_PASSPHRASE_LEN + 1)); pi->max_length = MAX_PASSPHRASE_LEN + 1; pi->max_tries = 1; pi->with_repeat = 1; -- From wk at gnupg.org Mon Sep 28 12:41:02 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Sep 2015 12:41:02 +0200 Subject: ssh: Fix allocation of pinentry buffer In-Reply-To: <5609004B.2070706@fsij.org> (NIIBE Yutaka's message of "Mon, 28 Sep 2015 17:54:35 +0900") References: <5609004B.2070706@fsij.org> Message-ID: <8737xyhlmp.fsf@vigenere.g10code.de> On Mon, 28 Sep 2015 10:54, gniibe at fsij.org said: > I changed the pointer calculation using the cast to (char *), but it > is wrong still, because it doesn't care about alignment of the > structure. It should be rounded up to the alignment. Yep. We better do separate mallocs for PI and PI2. Overoptimizing things is never good. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Sep 28 12:46:15 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Sep 2015 12:46:15 +0200 Subject: RSA signature verification in gpg-agent? In-Reply-To: <5608DF3E.7000606@fsij.org> (NIIBE Yutaka's message of "Mon, 28 Sep 2015 15:33:34 +0900") References: <5600B2A5.2040505@fsij.org> <87twqjcgio.fsf@alice.fifthhorseman.net> <8737y2i2gf.fsf@vigenere.g10code.de> <5608DF3E.7000606@fsij.org> Message-ID: <87y4fqg6tk.fsf@vigenere.g10code.de> On Mon, 28 Sep 2015 08:33, gniibe at fsij.org said: > So, here is the change to move signature checking to gpg-agent. Very good. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Sep 29 04:08:32 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 29 Sep 2015 11:08:32 +0900 Subject: ssh: Fix allocation of pinentry buffer In-Reply-To: <8737xyhlmp.fsf@vigenere.g10code.de> References: <5609004B.2070706@fsij.org> <8737xyhlmp.fsf@vigenere.g10code.de> Message-ID: <5609F2A0.1050301@fsij.org> On 09/28/2015 07:41 PM, Werner Koch wrote: > On Mon, 28 Sep 2015 10:54, gniibe at fsij.org said: > >> I changed the pointer calculation using the cast to (char *), but it >> is wrong still, because it doesn't care about alignment of the >> structure. It should be rounded up to the alignment. > > Yep. We better do separate mallocs for PI and PI2. Overoptimizing > things is never good. I did consider your suggestion of: two allocations and two free-s, as well as changing the structure itself (to have the field: pin[MAX_PASSPHRASE_LEN + 1]). I realized that sizeof operator cares alignment. Given the situation MAX_PASSPHRASE_LEN==255, following patch is minimum change. I think that this is good for the fix for minimum impact. I added a comment at MAX_PASSPHRASE_LEN. diff --git a/agent/agent.h b/agent/agent.h index b3e8470..9e066c9 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -50,7 +50,8 @@ /* The maximum length of a passphrase (in bytes). Note: this is further contrained by the Assuan line length (and any other text on the same line). However, the Assuan line length is 1k bytes so - this shouldn't be a problem in practice. */ + this shouldn't be a problem in practice. + (MAX_PASSPHRASE_LEN + 1) should be multiple of alignment size. */ #define MAX_PASSPHRASE_LEN 255 diff --git a/agent/command-ssh.c b/agent/command-ssh.c index 8be1255..3f63f76 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -3107,7 +3107,8 @@ ssh_identity_register (ctrl_t ctrl, ssh_key_type_spec_t *spec, err = gpg_error_from_syserror (); goto out; } - pi2 = pi + (sizeof *pi + MAX_PASSPHRASE_LEN + 1); + pi2 = (struct pin_entry_info_s *)((char *)pi + (sizeof (*pi) + + MAX_PASSPHRASE_LEN + 1)); pi->max_length = MAX_PASSPHRASE_LEN + 1; pi->max_tries = 1; pi->with_repeat = 1; diff --git a/agent/genkey.c b/agent/genkey.c index 13858ca..54b7149 100644 --- a/agent/genkey.c +++ b/agent/genkey.c @@ -375,7 +375,8 @@ agent_ask_new_passphrase (ctrl_t ctrl, const char *prompt, } pi = gcry_calloc_secure (2, sizeof (*pi) + MAX_PASSPHRASE_LEN + 1); - pi2 = pi + (sizeof *pi + MAX_PASSPHRASE_LEN + 1); + pi2 = (struct pin_entry_info_s *)((char *)pi + (sizeof (*pi) + + MAX_PASSPHRASE_LEN + 1)); pi->max_length = MAX_PASSPHRASE_LEN + 1; pi->max_tries = 3; pi->with_qualitybar = 1; -- From gniibe at fsij.org Wed Sep 30 02:22:25 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 30 Sep 2015 09:22:25 +0900 Subject: ssh: Fix allocation of pinentry buffer In-Reply-To: <5609F2A0.1050301@fsij.org> References: <5609004B.2070706@fsij.org> <8737xyhlmp.fsf@vigenere.g10code.de> <5609F2A0.1050301@fsij.org> Message-ID: <560B2B41.4050207@fsij.org> On 09/29/2015 11:08 AM, NIIBE Yutaka wrote: > I think that this is good for the fix for minimum impact. I added a > comment at MAX_PASSPHRASE_LEN. I'd like to commit this change to master, and to backport it to 2.0. Since the size was smaller, 2.0 doesn't dump core (for some OS), but same bug is there. Then, for master, improvement can be considered later, if needed. OK to commit? -- From neal at walfield.org Wed Sep 30 10:48:16 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 30 Sep 2015 10:48:16 +0200 Subject: ssh: Fix allocation of pinentry buffer In-Reply-To: <5609F2A0.1050301@fsij.org> References: <5609004B.2070706@fsij.org> <8737xyhlmp.fsf@vigenere.g10code.de> <5609F2A0.1050301@fsij.org> Message-ID: <87si5w9ttb.wl-neal@walfield.org> Hi Niibe, At Tue, 29 Sep 2015 11:08:32 +0900, NIIBE Yutaka wrote: > > On 09/28/2015 07:41 PM, Werner Koch wrote: > > On Mon, 28 Sep 2015 10:54, gniibe at fsij.org said: > > > >> I changed the pointer calculation using the cast to (char *), but it > >> is wrong still, because it doesn't care about alignment of the > >> structure. It should be rounded up to the alignment. > > > > Yep. We better do separate mallocs for PI and PI2. Overoptimizing > > things is never good. > > I did consider your suggestion of: two allocations and two free-s, as > well as changing the structure itself (to have the field: > pin[MAX_PASSPHRASE_LEN + 1]). > > I realized that sizeof operator cares alignment. Given the situation > MAX_PASSPHRASE_LEN==255, following patch is minimum change. > > I think that this is good for the fix for minimum impact. I added a > comment at MAX_PASSPHRASE_LEN. I think your patch is correct, but I'd prefer a change that increases robustness rather than one that preserves this fragility. Second, this bug is also present in agent/genkey.c. Can you fix it there as well? Thanks, Neal From gniibe at fsij.org Wed Sep 30 13:04:51 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 30 Sep 2015 20:04:51 +0900 Subject: common: Fix call to xtrycalloc Message-ID: <560BC1D3.3030709@fsij.org> Hello, While grep'ing use cases of calloc, I found a simple error in strsplit. Even if it's not correct, it works well (allocation of memory can be larger, because of alignment requirement of element). Here's a correction. diff --git a/common/stringhelp.c b/common/stringhelp.c index 576c2ea..38c3832 100644 --- a/common/stringhelp.c +++ b/common/stringhelp.c @@ -1230,7 +1230,7 @@ strsplit (char *string, char delim, char replacement, int *count) for (t = strchr (string, delim); t; t = strchr (t + 1, delim)) fields ++; - result = xtrycalloc (sizeof (*result), (fields + 1)); + result = xtrycalloc ((fields + 1), sizeof (*result)); if (! result) return NULL; -- From neal at walfield.org Wed Sep 30 14:59:10 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 30 Sep 2015 14:59:10 +0200 Subject: common: Fix call to xtrycalloc In-Reply-To: <560BC1D3.3030709@fsij.org> References: <560BC1D3.3030709@fsij.org> Message-ID: <87r3lg9i75.wl-neal@walfield.org> Hi Niibe, At Wed, 30 Sep 2015 20:04:51 +0900, NIIBE Yutaka wrote: > While grep'ing use cases of calloc, I found a simple error in > strsplit. Even if it's not correct, it works well (allocation of > memory can be larger, because of alignment requirement of element). > > Here's a correction. > > diff --git a/common/stringhelp.c b/common/stringhelp.c > index 576c2ea..38c3832 100644 > --- a/common/stringhelp.c > +++ b/common/stringhelp.c > @@ -1230,7 +1230,7 @@ strsplit (char *string, char delim, char replacement, int *count) > for (t = strchr (string, delim); t; t = strchr (t + 1, delim)) > fields ++; > > - result = xtrycalloc (sizeof (*result), (fields + 1)); > + result = xtrycalloc ((fields + 1), sizeof (*result)); > if (! result) > return NULL; Good catch. This looks reasonable, please check it in. Neal From kevin at kevinlocke.name Wed Sep 30 09:16:52 2015 From: kevin at kevinlocke.name (Kevin Locke) Date: Wed, 30 Sep 2015 00:16:52 -0700 Subject: Optimization-dependent behavior with GnuPG 1.4.19 and GCC 5 Message-ID: <20150930071652.GA22565@kevinolos> Hello all, I'm encountering a rather odd issue and I would appreciate some help confirming my suspicions about the cause and in fixing the issue. The basic issue is that I am unable to install Google Cloud SDK packages on Debian testing due to signature validation failure. In tracking down the issue, I realized that gnupg 1.4.19-5 (present in testing) fails to validate the signature while 1.4.18-7 (present in Jessie) validates the signature as good. Further investigation revealed that when compiled from pristine sources with -O1, 1.4.19 will validate the signature as good, while compilation with -O2 will cause the validation to fail. To reproduce the issue: (on Debian testing using gcc "(Debian 5.2.1-17) 5.2.1 20150911") # Build a version with -O2 (default) and -O1 tar -xjf gnupg-1.4.19.tar.bz2 cd gnupg-1.4.19 ./configure && make mv g10/gpg gpg.O2 make clean && CFLAGS="-g -O1" ./configure && make mv g10/gpg gpg.O1 # Get the signed file and import the key into a keyring curl -O http://packages.cloud.google.com/apt/dists/cloud-sdk-jessie/InRelease curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | gpg --no-default-keyring --keyring ./google-cloud-sdk.gpg --import # Attempt to verify the signature with each binary ./gpg.O2 --verbose --no-default-keyring --keyring ./google-cloud-sdk.gpg --verify InRelease ./gpg.O1 --verbose --no-default-keyring --keyring ./google-cloud-sdk.gpg --verify InRelease On my machine, running with gpg.O2 results in the following output: gpg: Signature made Sun 27 Sep 2015 12:33:10 PM PDT using RSA key ID A7317B0F gpg: assuming bad signature from key A7317B0F due to an unknown critical bit gpg: BAD signature from "Google Cloud Packages Automatic Signing Key " While running with gpg.O1 results in the following output: gpg: Signature made Sun 27 Sep 2015 12:33:10 PM PDT using RSA key ID A7317B0F gpg: Good signature from "Google Cloud Packages Automatic Signing Key " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: D0BC 747F D8CA F711 7500 D6FA 3746 C208 A731 7B0F Debugging the behavior in gdb shows that in parse_signature at g10/parse-packet.c:1413, sig->unhashed is NULL. This results in taking the branch at g10/parse-packet.c:1185 in enum_sig_subpkt which returns the address of the pktbuf argument. Although the code expects this to result in a non-NULL value, it appears that the compiler optimizations at -O2 result in returning a NULL value. I'm unsure if this is a compiler error, or if this is allowed as undefined behavior when using the address of an argument after a function has returned. Thoughts? Is anyone else seeing this behavior? Does this analysis seem correct? Think it is a GCC bug? Regardless, would it be acceptable to return either a constant or the address of a global symbol to avoid the issue? Is there anything odd about the InRelease file which causes the issue? More importantly, is there a way to avoid causing this issue, so that users of affected versions of GPG can still install signed packages from the Google Cloud SDK, presumably by making sig->unhashed non-NULL? Thanks for your time and efforts! Kevin -- Cheers, | kevin at kevinlocke.name | XMPP: kevin at kevinlocke.name Kevin | https://kevinlocke.name | IRC: kevinoid on freenode