From gnupg-devel at spodhuis.org Sun Dec 2 06:34:56 2012 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Sun, 2 Dec 2012 00:34:56 -0500 Subject: Keyserver/security bug 1447 (and 1446 too) Message-ID: <20121202053456.GA61902@redoubt.spodhuis.org> Hi, wondering if the bug-tracker is considered stale and the devel mailing-list is preferred, as there's been no reaction to a security impacting bug (1447) while the lesser 1446 which was mentioned on-list did get a response. This first bug (1447) is a security-impacting bug; not too bad, since PGP has message-level security, so the key data isn't impacted, but it does permit MitM attacks for discerning what's happening. GnuPG uses data from insecure DNS for presenting to an HTTPS-enabled keyserver as TLS SNI and for verifying certificates. So if DNS responses are tampered with, the injected bad server will verify fine for the client. https://bugs.g10code.com/gnupg/issue1447 TLS hostname selection uses insecure SRV data Unless DNSSEC is used and verified by a validating recursor, it's definitely wrong to be using identities from DNS for presentation. Instead, the name configured for GnuPG (in the trusted config) should be used for verifying identity. If this is fixed, then PGP keyserver pool-maintainers can sensibly issue TLS certs to be used by individual keyservers and have clients verify correctly. This affects "hkps.pool.sks-keyservers.net" and is the reason that there are currently no SRV records published. With the CA cert from: and forcing the pool to resolve to my host, I can confirm this presents the correct certificate: $ curl \ --cacert ~/.gnupg/CA/sks-keyservers.netCA.pem \ --resolve "hkps.pool.sks-keyservers.net:443:94.142.241.93" \ -sv "https://hkps.pool.sks-keyservers.net/pks/lookup?op=stats" >/dev/null Hopefully it's clear that, until that certificate verification works in GnuPG (--keyserver-option check-cert left on), something is going wrong with the names that GnuPG is presenting to keyservers. The other bug affects keyserver interop and did get commented upon; if it can be fixed in the same release as the 1447 bug, then we keyserver operators will know that any client that can validate identity can use ports from SRV records and not have to worry as much about older clients which can't verify anyway. https://bugs.g10code.com/gnupg/issue1446 hkps SRV lookup discards port from SRV The code I pointed to is apparently not the current code, but the flaw remains present, with the same impact. Thanks, -Phil From wk at gnupg.org Sun Dec 2 12:22:28 2012 From: wk at gnupg.org (Werner Koch) Date: Sun, 02 Dec 2012 12:22:28 +0100 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <20121202053456.GA61902@redoubt.spodhuis.org> (Phil Pennock's message of "Sun, 2 Dec 2012 00:34:56 -0500") References: <20121202053456.GA61902@redoubt.spodhuis.org> Message-ID: <87k3t04s23.fsf@vigenere.g10code.de> On Sun, 2 Dec 2012 06:34, gnupg-devel at spodhuis.org said: > Hi, wondering if the bug-tracker is considered stale and the devel > mailing-list is preferred, as there's been no reaction to a security > impacting bug (1447) while the lesser 1446 which was mentioned on-list I don't consider this a security bug. Search for discussions related to TLS access to keyservers. It has always been the case that you can get arbitrary data from keyservers. Keyservers provide no security at all! They are just a convenient way to distribute keys which usually works. Right, it might be used to inhibit the receiving of revocation certificates. However, there are many other ways of doing that. In case of a compromise, it is good practise to send out revocation certificates by private mail this has a better chance that they are actually noticed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Sun Dec 2 17:13:33 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 02 Dec 2012 11:13:33 -0500 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <87k3t04s23.fsf@vigenere.g10code.de> References: <20121202053456.GA61902@redoubt.spodhuis.org> <87k3t04s23.fsf@vigenere.g10code.de> Message-ID: <50BB7E2D.3000009@fifthhorseman.net> On 12/02/2012 06:22 AM, Werner Koch wrote: > On Sun, 2 Dec 2012 06:34, gnupg-devel at spodhuis.org said: >> Hi, wondering if the bug-tracker is considered stale and the devel >> mailing-list is preferred, as there's been no reaction to a security >> impacting bug (1447) while the lesser 1446 which was mentioned on-list > > I don't consider this a security bug. Search for discussions related to > TLS access to keyservers. It has always been the case that you can get > arbitrary data from keyservers. Keyservers provide no security at all! > They are just a convenient way to distribute keys which usually works. I agree with Werner that the risk of tampering with the data is not an issue here -- people can upload arbitrary data to the keyservers already. But this is still a security issue. In particular, people i've spoken to want to use HKPS for one of (at least) two reasons: 0) they trust the operator of a given keyserver to not leak or log their queries. 1) they know that a given keyserver is the place where revocation certificates that they care about will be published (the keyserver in question might not even be peered with the dominant pool). For both of these, getting the identity of the keyserver right is critical. Being subject to DNS spoofing is not acceptable. > Right, it might be used to inhibit the receiving of revocation > certificates. However, there are many other ways of doing that. In > case of a compromise, it is good practise to send out revocation > certificates by private mail this has a better chance that they are > actually noticed. Not everyone who uses OpenPGP has an easy path from a mailbox to their keyring. And not everyone who needs to revoke their key knows everyone they need to send the revocation certificate to. It's a reasonable (and simple) "best practice" to refresh your keyring from the keyservers regularly to pull in updates. HKPS lets you do this while potentially limiting the exposure of your keyring contents to a single keyserver. --dkg From dshaw at jabberwocky.com Sun Dec 2 18:57:39 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 2 Dec 2012 12:57:39 -0500 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <20121202053456.GA61902@redoubt.spodhuis.org> References: <20121202053456.GA61902@redoubt.spodhuis.org> Message-ID: On Dec 2, 2012, at 12:34 AM, Phil Pennock wrote: > This first bug (1447) is a security-impacting bug; not too bad, since > PGP has message-level security, so the key data isn't impacted, but it > does permit MitM attacks for discerning what's happening. GnuPG uses > data from insecure DNS for presenting to an HTTPS-enabled keyserver as > TLS SNI and for verifying certificates. So if DNS responses are > tampered with, the injected bad server will verify fine for the client. Allow me to restate the problem to make sure I understand what you're saying. GnuPG does a SRV lookup for hkps under (for example) my-hkps-pool.example.com, and resolves to some-keyserver-in-the-pool.example.net. It then makes a https call to that host, but is using keyserver-in-the-pool.example.net as the SNI, as that matches the host name. You are arguing that it should have used my-hkps-pool.example.com as the SNI? If that's the issue, I agree that is not ideal. It's sort of a side effect of how we're doing SRV with Curl. Since Curl doesn't do SRV at all, we have a wrapper around libcurl that does a minimal emulation of true SRV and then forces the URL to be what it should be, according to the SRV. As far as I know, libcurl uses the host from the passed-in URL for SNI and there isn't a direct option to set the SNI to an arbitrary value, but looking at the options, CURLOPT_RESOLVE could be used to fix this by feeding in a record with the pool name and the address of the chosen server. Ideally, libcurl would handle SRVs internally, but that's a problem and solution of a different order. David From gnupg-devel at spodhuis.org Mon Dec 3 04:55:54 2012 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Sun, 2 Dec 2012 22:55:54 -0500 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: References: <20121202053456.GA61902@redoubt.spodhuis.org> Message-ID: <20121203035553.GA14522@redoubt.spodhuis.org> On 2012-12-02 at 12:57 -0500, David Shaw wrote: > On Dec 2, 2012, at 12:34 AM, Phil Pennock wrote: > > This first bug (1447) is a security-impacting bug; not too bad, since > > PGP has message-level security, so the key data isn't impacted, but it > > does permit MitM attacks for discerning what's happening. GnuPG uses > > data from insecure DNS for presenting to an HTTPS-enabled keyserver as > > TLS SNI and for verifying certificates. So if DNS responses are > > tampered with, the injected bad server will verify fine for the client. > > Allow me to restate the problem to make sure I understand what you're > saying. GnuPG does a SRV lookup for hkps under (for example) > my-hkps-pool.example.com, and resolves to > some-keyserver-in-the-pool.example.net. It then makes a https call to > that host, but is using keyserver-in-the-pool.example.net as the SNI, > as that matches the host name. You are arguing that it should have > used my-hkps-pool.example.com as the SNI? Correct. That's the only verifiably trustworthy name available. All other names could have been tampered with, without detection (unless DNSSEC is in use and verified). > If that's the issue, I agree that is not ideal. It's sort of a side > effect of how we're doing SRV with Curl. Since Curl doesn't do SRV at > all, we have a wrapper around libcurl that does a minimal emulation of > true SRV and then forces the URL to be what it should be, according to > the SRV. I hear you. Sounds truly awkward with some kludging needed to fix. As an application maintainer who has to work around library awkwardness myself, you have my sympathy. > As far as I know, libcurl uses the host from the passed-in URL for SNI > and there isn't a direct option to set the SNI to an arbitrary value, > but looking at the options, CURLOPT_RESOLVE could be used to fix this > by feeding in a record with the pool name and the address of the > chosen server. That matches what I've done on the curl(1) command-line to test the setup in the past. I concur, I can't find an API to hook into DNS resolution to change things otherwise, nor to change the SNI presented. Looks like CURLOPT_RESOLVE is the only available mechanism. So, as I understand it, to handle SRV, ports and SNI in combination, it's: * take the original hostname OHost * look for SRV record for _pgpkey-http/_pgpkey-https._tcp.$OHost, ignore this logic if neither SRV is found because we're connecting to something where the hostname resolves directly to what's neeeded * for each SRV record, take the hostname and port * resolve the per-srv-record hostname to IP addresses * iterate for each IP address: * construct a curl_slist, populate with one triple of $OHost:per-srv-record-Port:IP-Address * curl_easy_setopt() with CURLOPT_RESOLVE to set that triple * attempt to connect with curl, on the port from SRV, using the $OHost hostname * curl_easy_setopt()/CURLOPT_RESOLVE/ "-$OHost:per-srv-record-Port" There doesn't appear to be a way to provide multiple IPs for one hostname. Curl_loadhostpairs() shows that the clean-up is overkill, but I'm not confident in the resiliency of this API to a later change to permit multiple records for one hostname, especially since some of the usage comments don't even include the port field. > Ideally, libcurl would handle SRVs internally, Complete APIs from a library? Any library? Thou jesteth. Sorry to have been the bearer of bad news about the size of the can of worms you opened when adding SRV support. -Phil From gnupg-devel at spodhuis.org Mon Dec 3 08:27:20 2012 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Mon, 3 Dec 2012 02:27:20 -0500 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: References: <20121202053456.GA61902@redoubt.spodhuis.org> Message-ID: <20121203072720.GA42204@redoubt.spodhuis.org> On 2012-12-02 at 12:57 -0500, David Shaw wrote: > As far as I know, libcurl uses the host from the passed-in URL for SNI > and there isn't a direct option to set the SNI to an arbitrary value, > but looking at the options, CURLOPT_RESOLVE could be used to fix this > by feeding in a record with the pool name and the address of the > chosen server. It's not going to help for deployed application code, where you need to deal with the library as it exists on machines in the wild, but you might be interested in playing with Kristian Fiskerstrand's patch, described at: http://blog.sumptuouscapital.com/2012/10/curl-and-using-http-host-header-for-sni/ Basically, "Copy the SNI from the HTTP Host: header". -Phil From wk at gnupg.org Mon Dec 3 11:04:37 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Dec 2012 11:04:37 +0100 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <20121203035553.GA14522@redoubt.spodhuis.org> (Phil Pennock's message of "Sun, 2 Dec 2012 22:55:54 -0500") References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> Message-ID: <87r4n730zu.fsf@vigenere.g10code.de> On Mon, 3 Dec 2012 04:55, gnupg-devel at spodhuis.org said: >> saying. GnuPG does a SRV lookup for hkps under (for example) >> my-hkps-pool.example.com, and resolves to >> some-keyserver-in-the-pool.example.net. It then makes a https call to >> that host, but is using keyserver-in-the-pool.example.net as the SNI, >> as that matches the host name. You are arguing that it should have >> used my-hkps-pool.example.com as the SNI? > > Correct. That's the only verifiably trustworthy name available. All > other names could have been tampered with, without detection (unless I have some more questions: What root CA is to be used? One of the usual PKIX ones or a dedicated for the pool or all keyservers? If the latter, who is in charge of creating the certificates? Do you demand the servers should use a certificate issued by the pool operators (e.g. as Sub CA)? Or shall they merely use the pool name as an alternative server name? Why do do you think the pool's name is more trustworthy than the individual server name? We are still talking about round-robin DNS, right? > Sorry to have been the bearer of bad news about the size of the can of > worms you opened when adding SRV support. The problem is more that you want to use PKIX for a system which was not designed for it. Salam-Shalom, Werner p.s. It is a pitty that the keyserver-folks list is dead or that the SKS(?) operators don't discuss infrastructure topics on a gnupg.org list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Mon Dec 3 12:16:45 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 03 Dec 2012 15:16:45 +0400 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <87r4n730zu.fsf@vigenere.g10code.de> References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> Message-ID: <50BC8A1D.3060305@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/03/2012 02:04 PM, Werner Koch wrote: > On Mon, 3 Dec 2012 04:55, gnupg-devel at spodhuis.org said: > ... Greetings, just dropping in quickly and saying hi from my vacation in Russia here. > > What root CA is to be used? One of the usual PKIX ones or a > dedicated for the pool or all keyservers? If the latter, who is in > charge of creating the certificates? > > Do you demand the servers should use a certificate issued by the > pool operators (e.g. as Sub CA)? Or shall they merely use the pool > name as an alternative server name? > Currently we're testing with a Root CA that can be downloaded from https://sks-keyservers.net/sks-keyservers.netCA.pem , that is issuing a cert for the individual server and adding a subjectAltName corresponding to the hkps pool. [0] > Why do do you think the pool's name is more trustworthy than the > individual server name? We are still talking about round-robin > DNS, right? > The way I understand it - whether the specified name is a pool or an individual server isn't the issue - but rather that further from this it can be modified in the SRV record which can potentially be poisoned. As long as no CAs are activated by default this will be less of an issue (as the cert check should fail), but as soon as someone package curl / any client with some pre-defined root CAs, "any" server can take over the request. ... > p.s. It is a pitty that the keyserver-folks list is dead or that > the SKS(?) operators don't discuss infrastructure topics on a > gnupg.org list. This is mostly discussed at the sks-devel list[1] [0] https://sks-keyservers.net/overview-of-pools.php [1] https://lists.nongnu.org/mailman/listinfo/sks-devel - -- - ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk - ---------------------------- "The power of accurate observation is commonly called cynicism by those who have not got it." George Bernard Shaw - ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ - ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0-beta100 (GNU/Linux) iQIcBAEBCAAGBQJQvIoZAAoJEAt/i2Dj7frjeA4P/0mTDOG2XZ6cDzmQMP5jPs53 DJJw+fpdTv458wZvMSS80DIyAFIkYnxlM7hX5J2v16v5fmyb/7CsiI+6JorasgGO imTgh8s55kKnp/csDFsqHpMT3Nw0h68FI3pRy+vpDGan3ALtF+BeRcxmEpld1GMc OIMomLNB5+W9iW5VcK4zbP4H4P2o8cfcPm3HuIekAjR7+oF3YyiHAZPubNJc4Ipr X3KYmlpYgHLH8RQx6J2fCnvM0HUtS4117HFRMi4CoaeJE6Ny3AOkd09Mq6PuWI0+ 7ZqZ4L6ZIeKAs0lnS6oosRp5ktomNa8jgzWs5mqEXRFXYZTAw4e43LdtQB6sam1Z AlwdkCH1np7rCqPeJaQsgCjhHLt5E5IrmQbRDrfqNam8troUaUOoRz/yTKSXbgZP sTCsIGh3svNPicxggycsDf7HUwExF2NEapZfhft5AyLcAcZPLcnKaxKwg+McQw73 BcMnc8kBS3rK5FZzM9t2vVRPksKi7ezZxHdgMroTRfBgIdAxmcuLEY8PKc5L3UEc +fdqYiYseDBsLDhnjNcx2YYprC7XHUp5PWkMLryzpnkJ1arAZFL+FgM14zcFRanV Vr+mPkP4YbeF5rCAXSyuYM9p5IKSg6xYEV1mnWvzj9ZIQrmH1K//wEovhHAIK4Vd mAHnd245VvTJEdR3xf6Z =3gtU -----END PGP SIGNATURE----- From kristian.fiskerstrand at sumptuouscapital.com Mon Dec 3 13:06:59 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 03 Dec 2012 16:06:59 +0400 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <20121203130150.89586fcc.jeanjacquesbrucker@gmail.com> References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <50BC8A1D.3060305@sumptuouscapital.com> <20121203130150.89586fcc.jeanjacquesbrucker@gmail.com> Message-ID: <50BC95E3.9010200@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/03/2012 04:01 PM, jbar wrote: > ... > I means we could use OpenPGP certificate and Web of Trust to > authenticate hkp key servers, either by linking GnuPG and sks with > GnuTLS to use the RFC6091 about TLS+OpenPGP [0], or by using the > protocol I have quickly draft [1] and began to implement on my own > key server thttpgpd/ludd [2]. To have it mentioned; Monkeysphere[0] also has a hkpms keyserver handler that could be used for a WoT approach[1]. [0] http://web.monkeysphere.info/ [1] http://lists.nongnu.org/archive/html/sks-devel/2012-10/msg00002.html - -- - ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Aut dosce, aut disce, aut discede Either teach, or study, or leave - ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ - ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0-beta100 (GNU/Linux) iQIcBAEBCAAGBQJQvJXjAAoJEAt/i2Dj7frjiQcQAJwwCrBINau8MiTDLUlfhLVr 5IrNiIHYMgZNEJmtG3jGV0OsyFPWUe1DOV6AT32qpOVidrrsTfdphHCM+VV6w1kw BFK83KzMulB1Mkx1xGXb77X73w0+sl9S4pxq3et3CuaU0skZkARER3Ht3f20Pjto KsD9sGZuOp9KyxYLQGcbYe0TORNgz6fkg/P9d835A3NrVP0UTaIaGqkq1834hHOv FNPZ+W40xR4JFrLmIORk0uyfuxiFlSvW43F/8jSXrATwm/qPyYbhw7G415lLw4Bd aTbg3W4KpGa+S48hyIg9GQt0Ji5z8PnDq3Npb9wGofw33rheYBSUsTSBnCFyoEex VysAjKS1nyTbokVgwu/r01rdWuYtMdCZEJh8I+Fihbort839iRfDE2igdIb0FTH+ 0BhDqzLBCftJYYJ4/GIplokgIcj3kKY+PmpldBSEobd33Ztre80UEY6uiV281ogG 8s7d6k8XgH5gep332+z8Cv+h/fmqQ/MNon2at2GCwC4U33QRC2gKkGTW3a5pmyPZ mQ5FEvOJyFXZ3cbw9yhOvgXEHXkhkxvRgd5X+a/rjO4oBhFfwT2wKnaKxfpSkBd7 0JhTDuY8PwFpjl3/Yb11pw7ys5riAV+hh3kn6R/EyxUXS8MVkFTySVkuPoHIA4z0 iZw1uLcxhj3aNkbRHY3Q =FN9r -----END PGP SIGNATURE----- From jeanjacquesbrucker at gmail.com Mon Dec 3 13:01:50 2012 From: jeanjacquesbrucker at gmail.com (jbar) Date: Mon, 3 Dec 2012 13:01:50 +0100 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <50BC8A1D.3060305@sumptuouscapital.com> References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <50BC8A1D.3060305@sumptuouscapital.com> Message-ID: <20121203130150.89586fcc.jeanjacquesbrucker@gmail.com> What I didn't understand, is that some are still trying to rely security with DNS (or DNSSEC sometime) and X509 certificates, when we have all the required stuff with OpenPGP without taking care of the 2 other technologies (which sucks on many points AMHA... :-]). I means we could use OpenPGP certificate and Web of Trust to authenticate hkp key servers, either by linking GnuPG and sks with GnuTLS to use the RFC6091 about TLS+OpenPGP [0], or by using the protocol I have quickly draft [1] and began to implement on my own key server thttpgpd/ludd [2]. My (very) drafted protocol is an "over-HTTP" solution to make authentication upon some datas instead of the channel. Using it will may be not being as performant or secure as managing a SessionID after a succesfull RFC6091 mutual authentication and using encrypted session, but it simpler to use and may be usefull in some case (e.g. when not managing a SessionId or cookies). Note: the man page of thttpgpd, my HTTP/HKP server is always updated and may be usefull [3]. And you may test the PGP signing of data by my keyserver using curl like this : $ curl -v -H "Accept: multipart/msigned" "http://domesticserver.org:11371/pks/lookup?search=jbar&search=loubov" [0]: http://www.gnu.org/software/gnutls/openpgp.html [1]: https://github.com/Open-UDC/open-udc/blob/master/docs/HTTP_OpenPGP_Authentication.draft.txt [2]: http://domesticserver.org:11371/pks/ [3]: https://github.com/Open-UDC/open-udc/blob/master/ludd/src/ludd.8.in -- jbar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From wk at gnupg.org Mon Dec 3 13:57:50 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Dec 2012 13:57:50 +0100 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <50BC8A1D.3060305@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Mon, 03 Dec 2012 15:16:45 +0400") References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <50BC8A1D.3060305@sumptuouscapital.com> Message-ID: <87sj7n1eep.fsf@vigenere.g10code.de> On Mon, 3 Dec 2012 12:16, kristian.fiskerstrand at sumptuouscapital.com said: > Currently we're testing with a Root CA that can be downloaded from > https://sks-keyservers.net/sks-keyservers.netCA.pem , that is issuing > a cert for the individual server and adding a subjectAltName > corresponding to the hkps pool. [0] Okay, makes sense. > The way I understand it - whether the specified name is a pool or an > individual server isn't the issue - but rather that further from this > it can be modified in the SRV record which can potentially be Now I understand. Frankly, I was not anymore aware that a SRV record may also include a hostname and that this mechanism is used instead of A record based round-robin. > poisoned. As long as no CAs are activated by default this will be less > of an issue (as the cert check should fail), but as soon as someone > package curl / any client with some pre-defined root CAs, "any" server > can take over the request. Right. Given that HKPS is not yet widely used (right?), what about setting this up correctly than eventually ending up with jumble of different schemes? Requiring that the poolname is also in the keyserver's certificate, seems to be the easiest scheme. With 2.1 it will be pretty easy to implement any kind of certificate validation. We could even provide default certificates for a number of different pools [1]. I am not keen to implement that for 2.0, with the keyserver helpers and TLS support only via Curl. > This is mostly discussed at the sks-devel list[1] I once unsubscribed because the development stuff was not that interesting to me. Feel free to cross-post to gnupg-devel for strategic discussions. Shalom-Salam, Werner [1] I doubt that you can provide the organizational security to use an 4k RSA key for the root certificate. But well, this has been discussed too often, thus I will try not to further comment ;-) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 3 14:11:32 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Dec 2012 14:11:32 +0100 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <20121203130150.89586fcc.jeanjacquesbrucker@gmail.com> (jbar's message of "Mon, 3 Dec 2012 13:01:50 +0100") References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <50BC8A1D.3060305@sumptuouscapital.com> <20121203130150.89586fcc.jeanjacquesbrucker@gmail.com> Message-ID: <87mwxv1drv.fsf@vigenere.g10code.de> On Mon, 3 Dec 2012 13:01, jeanjacquesbrucker at gmail.com said: > What I didn't understand, is that some are still trying to rely > security with DNS (or DNSSEC sometime) and X509 certificates, when we DNSSEC is actually not too bad - compared to PKIX. However, we don't need to use the global PKIX but we can use the already deployed software in a more simple but secure way. Instead of specifying a CA file, we associate the fingerprint of a certificate with a given keyserver or poolname and only use this fingerprint to validate the root CA. Downloading the actual CA file could be automated; the important part is that it is easy to enter the fingerprint in a conf file. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Mon Dec 3 17:32:04 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 3 Dec 2012 11:32:04 -0500 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <20121203072720.GA42204@redoubt.spodhuis.org> References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203072720.GA42204@redoubt.spodhuis.org> Message-ID: <51110B85-ACE5-48B0-A176-35CD569445DF@jabberwocky.com> On Dec 3, 2012, at 2:27 AM, Phil Pennock wrote: > On 2012-12-02 at 12:57 -0500, David Shaw wrote: >> As far as I know, libcurl uses the host from the passed-in URL for SNI >> and there isn't a direct option to set the SNI to an arbitrary value, >> but looking at the options, CURLOPT_RESOLVE could be used to fix this >> by feeding in a record with the pool name and the address of the >> chosen server. > > It's not going to help for deployed application code, where you need to > deal with the library as it exists on machines in the wild, but you > might be interested in playing with Kristian Fiskerstrand's patch, > described at: > > http://blog.sumptuouscapital.com/2012/10/curl-and-using-http-host-header-for-sni/ > > Basically, "Copy the SNI from the HTTP Host: header". I'm all for that patch, but yeah, it doesn't really help for deployed code. I certainly wouldn't cry if the Curl people adopted it, or something similar. David From kristian.fiskerstrand at sumptuouscapital.com Mon Dec 3 17:55:25 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 3 Dec 2012 17:55:25 +0100 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <51110B85-ACE5-48B0-A176-35CD569445DF@jabberwocky.com> References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203072720.GA42204@redoubt.spodhuis.org> <51110B85-ACE5-48B0-A176-35CD569445DF@jabberwocky.com> Message-ID: Sent from my iPad On Dec 3, 2012, at 5:32 PM, David Shaw wrote: > On Dec 3, 2012, at 2:27 AM, Phil Pennock wrote: > >> On 2012-12-02 at 12:57 -0500, David Shaw wrote: >>> As far as I know, libcurl uses the host from the passed-in URL for SNI >>> and there isn't a direct option to set the SNI to an arbitrary value, >>> but looking at the options, CURLOPT_RESOLVE could be used to fix this >>> by feeding in a record with the pool name and the address of the >>> chosen server. >> >> It's not going to help for deployed application code, where you need to >> deal with the library as it exists on machines in the wild, but you >> might be interested in playing with Kristian Fiskerstrand's patch, >> described at: >> >> http://blog.sumptuouscapital.com/2012/10/curl-and-using-http-host-header-for-sni/ >> >> Basically, "Copy the SNI from the HTTP Host: header". > > I'm all for that patch, but yeah, it doesn't really help for deployed code. I certainly wouldn't cry if the Curl people adopted it, or something similar. For what it is worth, the respective thread on the curl mailing list for this is [0] , but the use case can be mostly mitigated by the use of CURLOPT_RESOLVE, so I'm using the patch in my local crawler, but haven't pushed for it upstream. [0] http://curl.haxx.se/mail/lib-2012-11/0109.html Kristian From dshaw at jabberwocky.com Mon Dec 3 18:26:24 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 3 Dec 2012 12:26:24 -0500 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <87sj7n1eep.fsf@vigenere.g10code.de> References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <50BC8A1D.3060305@sumptuouscapital.com> <87sj7n1eep.fsf@vigenere.g10code.de> Message-ID: <9E29E1A0-9BF5-4473-8C24-A67D3D3B9697@jabberwocky.com> On Dec 3, 2012, at 7:57 AM, Werner Koch wrote: >> poisoned. As long as no CAs are activated by default this will be less >> of an issue (as the cert check should fail), but as soon as someone >> package curl / any client with some pre-defined root CAs, "any" server >> can take over the request. > > Right. Given that HKPS is not yet widely used (right?), what about > setting this up correctly than eventually ending up with jumble of > different schemes? > > Requiring that the poolname is also in the keyserver's certificate, > seems to be the easiest scheme. With 2.1 it will be pretty easy to > implement any kind of certificate validation. We could even provide > default certificates for a number of different pools [1]. I am not keen > to implement that for 2.0, with the keyserver helpers and TLS support > only via Curl. I think it's reasonable to leave future enhancements like default certificates to 2.1, but I also think we need to make at least a minimal fix in 2.0 as it is actively doing the wrong thing by passing the wrong SNI and Host header so can't readily interoperate with what will come later in 2.1. How about this: we fix 1447 in 2.0 only by passing the correct Host header (for both curl-shim and real curl) and SNI for real curl. This is very simple to do in the curl-shim, and only slightly more messy for the real curl. Issue 1446 should just be fixed (I'm testing a fix for this already) - it's a straightforward bug. David From wk at gnupg.org Mon Dec 3 18:54:33 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Dec 2012 18:54:33 +0100 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <9E29E1A0-9BF5-4473-8C24-A67D3D3B9697@jabberwocky.com> (David Shaw's message of "Mon, 3 Dec 2012 12:26:24 -0500") References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <50BC8A1D.3060305@sumptuouscapital.com> <87sj7n1eep.fsf@vigenere.g10code.de> <9E29E1A0-9BF5-4473-8C24-A67D3D3B9697@jabberwocky.com> Message-ID: <871uf710o6.fsf@vigenere.g10code.de> On Mon, 3 Dec 2012 18:26, dshaw at jabberwocky.com said: > How about this: we fix 1447 in 2.0 only by passing the correct Host > header (for both curl-shim and real curl) and SNI for real curl. This > is very simple to do in the curl-shim, and only slightly more messy > for the real curl. Issue 1446 should just be fixed (I'm testing a fix Okay. Will you take this up? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupg-devel at spodhuis.org Mon Dec 3 23:48:15 2012 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Mon, 3 Dec 2012 17:48:15 -0500 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <87r4n730zu.fsf@vigenere.g10code.de> References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> Message-ID: <20121203224814.GA52496@redoubt.spodhuis.org> On 2012-12-03 at 11:04 +0100, Werner Koch wrote: > What root CA is to be used? One of the usual PKIX ones or a dedicated > for the pool or all keyservers? If the latter, who is in charge of > creating the certificates? The root CA happens to be private, what matters is the intermediate CA which signs the certs. The certs are signed by the operator of the pool. > Do you demand the servers should use a certificate issued by the pool > operators (e.g. as Sub CA)? Or shall they merely use the pool name as > an alternative server name? We settled on "all clients are sending SNI nowadays, so we can safely dispatch on that, knowing that any client not sending SNI probably isn't verifying anyway". So the TLS handshake sends ServerNameIndication, which is used for selecting a server-side vhost, which includes a certificate which covers that SNI hostname. So: any given keyserver operator can be a member of an arbitrary number of pools. Any pool which wants to be sure that clients _can_ validate can liaise to have a vhost which is pool-specific, using the correct key/cert for that pool. There's no exclusivity or lock-in, and keyserver operators can work with whatever pool operators they trust to do a competent enough job and not create headaches down the road. Kristian's doing proof-of-concept work and pushing the boundary of improvement here. I can fully understand the GnuPG folks wanting to ensure that they run the root CA used for any default verification by GnuPG and wanting to work with keyserver operators. So I for one am happy to add a cert for a keys.gnupg.net hostname issued by the GnuPG folks. (The trust in the other direction is a different issue) At present, my main SSL vhost uses a cert issued from my private CA, which provides as much assurance as anything ever did in this realm but isn't so useful for others. It includes (and has for a year or so) keys.gnupg.net as a subjectAltName. The difference would be changing the vhost used for that name and giving it a different cert. > Why do do you think the pool's name is more trustworthy than the > individual server name? We are still talking about round-robin DNS, > right? The pool name was set in ~/.gnupg/gpg.conf or given with --keyserver, so has been chosen and passed to the tool via some trusted path. > The problem is more that you want to use PKIX for a system which was not > designed for it. No, we're using PKIX for security host-to-host communications with TLS. The problem is that a common library makes it hard to do the right thing in the presence of SRV records. By contrast (to respond to another person here), using PGP for link security instead of the X.509 PKIX tells me that folks are iffy on "message-based security" vs "live link security" and on the impact of timing-based attacks. As a keyserver operator, someone happy providing a public service to assist in OpenPGP usage, I'm not going to put PGP-based link security into place without a lot more operational impact analysis of the crypto code in GnuPG's resilience to timing attacks, and more. Both models of security have their place. When used correctly, they can complement each other well. We're using PKIX for what it's designed for, in such a way as to actively preserve privacy of people using PGP clients if they use an hkps:// keyserver they trust. Regards, -Phil From Qi.Chen at windriver.com Tue Dec 4 04:04:05 2012 From: Qi.Chen at windriver.com (ChenQi) Date: Tue, 4 Dec 2012 11:04:05 +0800 Subject: add pkgconfig support to libksba and libassuan Message-ID: <50BD6825.5090701@windriver.com> Hi all, Attached are two patches that add pkgconfig support to libksba and libassuan. These two packages don't deliver pkgconfig (.pc) files, but I think they should. This is useful when somebody wants to use a unified interface (pkg-config) to query packages in his system. Sorry if I'm sending this to the wrong ML. (If so, could someone tell me which mailing list I should go to?) Best Regards, Chen Qi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: libassuan-add-pkgconfig-support.patch Type: text/x-patch Size: 1529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ksba-add-pkgconfig-support.patch Type: text/x-patch Size: 1253 bytes Desc: not available URL: From dshaw at jabberwocky.com Tue Dec 4 05:46:04 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 3 Dec 2012 23:46:04 -0500 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <871uf710o6.fsf@vigenere.g10code.de> References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <50BC8A1D.3060305@sumptuouscapital.com> <87sj7n1eep.fsf@vigenere.g10code.de> <9E29E1A0-9BF5-4473-8C24-A67D3D3B9697@jabberwocky.com> <871uf710o6.fsf@vigenere.g10code.de> Message-ID: <9A8AD11D-A1E2-4789-96AA-3242A893823E@jabberwocky.com> On Dec 3, 2012, at 12:54 PM, Werner Koch wrote: > On Mon, 3 Dec 2012 18:26, dshaw at jabberwocky.com said: > >> How about this: we fix 1447 in 2.0 only by passing the correct Host >> header (for both curl-shim and real curl) and SNI for real curl. This >> is very simple to do in the curl-shim, and only slightly more messy >> for the real curl. Issue 1446 should just be fixed (I'm testing a fix > > Okay. Will you take this up? No problem, I'll work it out soon. David From wk at gnupg.org Tue Dec 4 07:43:46 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Dec 2012 07:43:46 +0100 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <20121203224814.GA52496@redoubt.spodhuis.org> (Phil Pennock's message of "Mon, 3 Dec 2012 17:48:15 -0500") References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <20121203224814.GA52496@redoubt.spodhuis.org> Message-ID: <87a9tuz599.fsf@vigenere.g10code.de> On Mon, 3 Dec 2012 23:48, gnupg-devel at spodhuis.org said: > So: any given keyserver operator can be a member of an arbitrary number > of pools. Any pool which wants to be sure that clients _can_ validate That's fine. > improvement here. I can fully understand the GnuPG folks wanting to > ensure that they run the root CA used for any default verification by > GnuPG and wanting to work with keyserver operators. So I for one am I don't want run a root CA. > happy to add a cert for a keys.gnupg.net hostname issued by the GnuPG > folks. (The trust in the other direction is a different issue) If you want me to delegate keys.gnupg.net to another pool operator group, please let me know. > No, we're using PKIX for security host-to-host communications with TLS. > The problem is that a common library makes it hard to do the right thing > in the presence of SRV records. See my other reply. > a public service to assist in OpenPGP usage, I'm not going to put > PGP-based link security into place without a lot more operational impact > analysis of the crypto code in GnuPG's resilience to timing attacks, and GnuTLS uses OpenCDK and not GnuPG for OpenPGP authentication. > We're using PKIX for what it's designed for, in such a way as to Designed as a way to enforce a tax for secure Internet ;-). I consider a non-PKIX approach, i.e. a two tier hierarchy with fingerprint matching of the top tier certificate, better. However, that can be implemented by the client without the help of the servers. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Dec 4 07:44:41 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Dec 2012 07:44:41 +0100 Subject: add pkgconfig support to libksba and libassuan In-Reply-To: <50BD6825.5090701@windriver.com> (ChenQi's message of "Tue, 4 Dec 2012 11:04:05 +0800") References: <50BD6825.5090701@windriver.com> Message-ID: <87624iz57q.fsf@vigenere.g10code.de> On Tue, 4 Dec 2012 04:04, Qi.Chen at windriver.com said: > Attached are two patches that add pkgconfig support to libksba and > libassuan. No. This has been discussed several time and it will not happen. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Dec 4 07:56:59 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 04 Dec 2012 15:56:59 +0900 Subject: Let scdaemon exit when no reader is available In-Reply-To: <1353550127.2908.2.camel@cfw2.gniibe.org> References: <1353461849.2749.5.camel@cfw2.gniibe.org> <87haojial5.fsf@vigenere.g10code.de> <1353550127.2908.2.camel@cfw2.gniibe.org> Message-ID: <1354604219.5408.0.camel@cfw2.gniibe.org> On 2012-11-22 at 11:08 +0900, NIIBE Yutaka wrote: > OK, I'll try another approach: > > (1) (As original proposal) Fix the function > update_reader_status_file not to call get_current_reader. This > fix has a impact that the insertion of a card reader will be > detected only when user tries to access his card. > > (2) Fix not to give up in the case of reader_disabled == 1 in the > function scd_command_handler. (In the first place.) > > (3) (Optionally, or in future) Fix the main routine of scdaemon to > enable the timer only when there is a card reader available. > > With this approach, scdaemon will be more robust and it will have same > good result as "adding exit to scdaemon" patch (mostly). Here are two changes (#1 and #2 above). Besides, I think that NEED_PCSC_WRAPPER can be undefined for 2.1 now. >From 40e42372e9b5be4915a481a2072abe3c877cca68 Mon Sep 17 00:00:00 2001 From: NIIBE Yutaka Date: Thu, 22 Nov 2012 16:04:51 +0900 Subject: [PATCH 1/2] Don't keep opening unavailable card reader. * scd/command.c (update_reader_status_file): Don't call get_current_reader. -- This fix has a impact that the insertion of a card reader will not be detected upon the insertion, but will be deferred until user tries to access his card. --- scd/command.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/scd/command.c b/scd/command.c index 17da5b7..932db6c 100644 --- a/scd/command.c +++ b/scd/command.c @@ -2282,11 +2282,6 @@ update_reader_status_file (int set_card_removed_flag) int idx; unsigned int status, changed; - /* Make sure that a reader has been opened. Like get_current_reader, - this part of the code assumes that there is only one reader. */ - if (!vreader_table[0].valid) - (void)get_current_reader (); - /* Note, that we only try to get the status, because it does not make sense to wait here for a operation to complete. If we are busy working with a card, delays in the status file update should -- 1.7.10.4 >From 2b33f18592d56a8db38d68f4184cba55f6f8dee7 Mon Sep 17 00:00:00 2001 From: NIIBE Yutaka Date: Tue, 4 Dec 2012 14:37:56 +0900 Subject: [PATCH 2/2] Revert SCD changes of 2010-05-03. * scd/apdu.c (pcsc_no_service): Remove. (open_pcsc_reader_direct, open_pcsc_reader_wrapped): Remove pcsc_no_service support. (apdu_open_reader): Remove R_NO_SERVICE. * scd/apdu.h (apdu_open_reader): Remove R_NO_SERVICE. * scd/command.c (reader_disabled): Remove. (get_current_reader): Follow the change of R_NO_SERVICE. (open_card, cmd_serialno, scd_command_handler): Remove reader_disabled support. * scd/sc-copykeys.c (main): Follow the change of R_NO_SERVICE. -- Daemon should handle all possible cases. Even if such a difficult case like reader_disabled, it should not exit. --- scd/apdu.c | 20 +------------------- scd/apdu.h | 2 +- scd/command.c | 23 ++++------------------- scd/sc-copykeys.c | 2 +- 4 files changed, 7 insertions(+), 40 deletions(-) diff --git a/scd/apdu.c b/scd/apdu.c index 43c807e..68d4e99 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -323,9 +323,6 @@ long (* DLSTDCALL pcsc_control) (unsigned long card, unsigned long recv_len, unsigned long *bytes_returned); -/* Flag set if PC/SC returned the no-service error. */ -static int pcsc_no_service; - /* Prototypes. */ static int pcsc_get_status (int slot, unsigned int *status); @@ -1693,11 +1690,8 @@ open_pcsc_reader_direct (const char *portstr) log_error ("pcsc_establish_context failed: %s (0x%lx)\n", pcsc_error_string (err), err); reader_table[slot].used = 0; - if (err == PCSC_E_NO_SERVICE) - pcsc_no_service = 1; return -1; } - pcsc_no_service = 0; err = pcsc_list_readers (reader_table[slot].pcsc.context, NULL, NULL, &nreader); @@ -1796,7 +1790,6 @@ open_pcsc_reader_wrapped (const char *portstr) { log_error ("can't run PC/SC access module '%s': %s\n", wrapperpgm, strerror (errno)); - pcsc_no_service = 1; return -1; } @@ -1893,8 +1886,6 @@ open_pcsc_reader_wrapped (const char *portstr) ; #undef WAIT - pcsc_no_service = 1; - /* Now send the open request. */ msgbuf[0] = 0x01; /* OPEN command. */ len = portstr? strlen (portstr):0; @@ -1927,15 +1918,11 @@ open_pcsc_reader_wrapped (const char *portstr) { log_error ("PC/SC returned a too large ATR (len=%lx)\n", (unsigned long)len); - pcsc_no_service = 0; goto command_failed; } err = PCSC_ERR_MASK ((msgbuf[5] << 24) | (msgbuf[6] << 16) | (msgbuf[7] << 8 ) | msgbuf[8]); - if (err != PCSC_E_NO_SERVICE) - pcsc_no_service = 0; - if (err) { log_error ("PC/SC OPEN failed: %s\n", pcsc_error_string (err)); @@ -2817,7 +2804,7 @@ unlock_slot (int slot) error. If PORTSTR is NULL we default to a suitable port (for ctAPI: the first USB reader. For PC/SC the first listed reader). */ int -apdu_open_reader (const char *portstr, int *r_no_service) +apdu_open_reader (const char *portstr) { static int pcsc_api_loaded, ct_api_loaded; int slot; @@ -2825,9 +2812,6 @@ apdu_open_reader (const char *portstr, int *r_no_service) if (DBG_READER) log_debug ("enter: apdu_open_reader: portstr=%s\n", portstr); - if (r_no_service) - *r_no_service = 0; - #ifdef HAVE_LIBUSB if (!opt.disable_ccid) { @@ -2988,8 +2972,6 @@ apdu_open_reader (const char *portstr, int *r_no_service) } slot = open_pcsc_reader (portstr); - if (slot == -1 && r_no_service && pcsc_no_service) - *r_no_service = 1; if (DBG_READER) log_debug ("leave: apdu_open_reader => slot=%d [pc/sc]\n", slot); diff --git a/scd/apdu.h b/scd/apdu.h index 7502546..bf55346 100644 --- a/scd/apdu.h +++ b/scd/apdu.h @@ -84,7 +84,7 @@ enum { /* Note, that apdu_open_reader returns no status word but -1 on error. */ -int apdu_open_reader (const char *portstr, int *r_no_service); +int apdu_open_reader (const char *portstr); int apdu_open_remote_reader (const char *portstr, const unsigned char *cookie, size_t length, int (*readfnc) (void *opaque, diff --git a/scd/command.c b/scd/command.c index 932db6c..40e61a4 100644 --- a/scd/command.c +++ b/scd/command.c @@ -79,10 +79,6 @@ == locked_session->ctrl_backlink->server_local->vreader_idx)) -/* Flag indicating that the reader has been disabled. */ -static int reader_disabled; - - /* This structure is used to keep track of user readers. To eventually accommodate this structure for RFID cards, where more than one card is used per reader, we name it virtual reader. */ @@ -444,9 +440,7 @@ get_current_reader (void) /* Try to open the reader. */ if (vr->slot == -1) { - int no_service_flag; - - vr->slot = apdu_open_reader (opt.reader_port, &no_service_flag); + vr->slot = apdu_open_reader (opt.reader_port); /* If we still don't have a slot, we have no readers. Invalidate for now until a reader is attached. */ @@ -454,12 +448,6 @@ get_current_reader (void) { vr->valid = 0; } - - if (no_service_flag) - { - log_info ("no card services - disabling scdaemon\n"); - reader_disabled = 1; - } } /* Return the vreader index or -1. */ @@ -474,9 +462,6 @@ open_card (ctrl_t ctrl, const char *apptype) gpg_error_t err; int vrdr; - if (reader_disabled) - return gpg_error (GPG_ERR_NOT_OPERATIONAL); - /* If we ever got a card not present error code, return that. Only the SERIALNO command and a reset are able to clear from that state. */ @@ -512,7 +497,7 @@ open_card (ctrl_t ctrl, const char *apptype) vrdr = get_current_reader (); ctrl->server_local->vreader_idx = vrdr; if (vrdr == -1) - err = gpg_error (reader_disabled? GPG_ERR_NOT_OPERATIONAL: GPG_ERR_CARD); + err = gpg_error (GPG_ERR_CARD); else { /* Fixme: We should move the apdu_connect call to @@ -570,7 +555,7 @@ cmd_serialno (assuan_context_t ctx, char *line) /* Clear the remove flag so that the open_card is able to reread it. */ retry: - if (!reader_disabled && ctrl->server_local->card_removed) + if (ctrl->server_local->card_removed) { if ( IS_LOCKED (ctrl) ) return gpg_error (GPG_ERR_LOCKED); @@ -2122,7 +2107,7 @@ scd_command_handler (ctrl_t ctrl, int fd) BUG (); sl->next_session = ctrl->server_local->next_session; } - stopme = ctrl->server_local->stopme || reader_disabled; + stopme = ctrl->server_local->stopme; xfree (ctrl->server_local); ctrl->server_local = NULL; diff --git a/scd/sc-copykeys.c b/scd/sc-copykeys.c index 0056dd7..3f34d69 100644 --- a/scd/sc-copykeys.c +++ b/scd/sc-copykeys.c @@ -139,7 +139,7 @@ main (int argc, char **argv ) if (argc != 1) usage (1); - slot = apdu_open_reader (reader_port, NULL); + slot = apdu_open_reader (reader_port); if (slot == -1) exit (1); if (apdu_connect (slot)) -- 1.7.10.4 From Qi.Chen at windriver.com Tue Dec 4 07:57:18 2012 From: Qi.Chen at windriver.com (ChenQi) Date: Tue, 4 Dec 2012 14:57:18 +0800 Subject: add pkgconfig support to libksba and libassuan In-Reply-To: <87624iz57q.fsf@vigenere.g10code.de> References: <50BD6825.5090701@windriver.com> <87624iz57q.fsf@vigenere.g10code.de> Message-ID: <50BD9ECE.1050207@windriver.com> On 12/04/2012 02:44 PM, Werner Koch wrote: > On Tue, 4 Dec 2012 04:04, Qi.Chen at windriver.com said: > >> Attached are two patches that add pkgconfig support to libksba and >> libassuan. > No. This has been discussed several time and it will not happen. > > > Salam-Shalom, > > Werner > Thank you for your prompt reply. Could you please tell me why? Because it might be important to us. I'm currently working for YOCTO (http://www.yoctoproject.org/) and someone suggests that we provide a unified interface to query packages in our system. So, I'd really appreciate it if you could give me some more information about this. Thanks, Chen Qi From wk at gnupg.org Tue Dec 4 09:24:42 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Dec 2012 09:24:42 +0100 Subject: add pkgconfig support to libksba and libassuan In-Reply-To: <50BD9ECE.1050207@windriver.com> (ChenQi's message of "Tue, 4 Dec 2012 14:57:18 +0800") References: <50BD6825.5090701@windriver.com> <87624iz57q.fsf@vigenere.g10code.de> <50BD9ECE.1050207@windriver.com> Message-ID: <871uf6z0l1.fsf@vigenere.g10code.de> On Tue, 4 Dec 2012 07:57, Qi.Chen at windriver.com said: > packages in our system. So, I'd really appreciate it if you could > give me some more information about this. pkg-config adds a lot of extra dependencies which needs to be resolved before you can start to build even a simple project. It even requires the huge glib. That contradicts the goal of configure which has been designed to allow building on pre-POSIX platforms. Cross-building does not work correctly with pkg-config; you may need to write a wrapper to cope for inconsistencies of the system. pkg-config might be useful in the GNOME or KDE environment where you have lots of not so well defined libraries. However, it adds nothing to portability of code. Using a shell script instead of pkg-config is more flexible and solves the same purposes. Right, it is annoying to see several identical -I and -L options on the cc line, but that is mostly an aesthetic issue. Maintaining a shell script and a .pc file will lead to inconsistency and weird bug reports. Thus it is a waste of time. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Dec 4 09:30:30 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Dec 2012 09:30:30 +0100 Subject: Let scdaemon exit when no reader is available In-Reply-To: <1353550127.2908.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 22 Nov 2012 11:08:47 +0900") References: <1353461849.2749.5.camel@cfw2.gniibe.org> <87haojial5.fsf@vigenere.g10code.de> <1353550127.2908.2.camel@cfw2.gniibe.org> Message-ID: <87wqwyxlqx.fsf@vigenere.g10code.de> On Thu, 22 Nov 2012 03:08, gniibe at fsij.org said: > However, please note that after a card reader removal (reader_disabled > == 1), scdaemon will exit at the end of next session of gpg-agent, in > the function scd_command_handler, anyway. From this viewpoint, the Okay, I was not aware of that. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Dec 4 10:50:53 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Dec 2012 10:50:53 +0100 Subject: Let scdaemon exit when no reader is available In-Reply-To: <1354604219.5408.0.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Tue, 04 Dec 2012 15:56:59 +0900") References: <1353461849.2749.5.camel@cfw2.gniibe.org> <87haojial5.fsf@vigenere.g10code.de> <1353550127.2908.2.camel@cfw2.gniibe.org> <1354604219.5408.0.camel@cfw2.gniibe.org> Message-ID: <877goyxi0y.fsf@vigenere.g10code.de> On Tue, 4 Dec 2012 07:56, gniibe at fsij.org said: > Here are two changes (#1 and #2 above). Pushed. Please feel free to push such changes yourself. > Besides, I think that NEED_PCSC_WRAPPER can be undefined for 2.1 now. I'll take care of it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupg-devel at spodhuis.org Tue Dec 4 10:21:13 2012 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Tue, 4 Dec 2012 04:21:13 -0500 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <87a9tuz599.fsf@vigenere.g10code.de> References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <20121203224814.GA52496@redoubt.spodhuis.org> <87a9tuz599.fsf@vigenere.g10code.de> Message-ID: <20121204092113.GA62639@redoubt.spodhuis.org> On 2012-12-04 at 07:43 +0100, Werner Koch wrote: > If you want me to delegate keys.gnupg.net to another pool operator > group, please let me know. If you want to get out of the issue entirely, I recommend taking a look at and pick one to CNAME to. I suggest "ha.pool.sks-keyservers.net". My estimate of the attitude of the SKS keyserver operators is that there is no contention in stating that Kristian's keyserver DNS pools are a de facto standard. The only other pools in operation that I even know of are run by me, and they deliberately have obnoxiously long names to discourage public use. If you want to avoid tying into SKS and want to maintain closer control than a CNAME, then the code I use (written in Go) is at and includes the DNS creation script in contrib/. It only examines SKS, but if you want to handle more than that then it's a reasonable starting point. Regards, -Phil From kristian.fiskerstrand at sumptuouscapital.com Tue Dec 4 13:45:23 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 04 Dec 2012 16:45:23 +0400 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <20121204092113.GA62639@redoubt.spodhuis.org> References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <20121203224814.GA52496@redoubt.spodhuis.org> <87a9tuz599.fsf@vigenere.g10code.de> <20121204092113.GA62639@redoubt.spodhuis.org> Message-ID: <50BDF063.5090308@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/04/2012 01:21 PM, Phil Pennock wrote: > On 2012-12-04 at 07:43 +0100, Werner Koch wrote: >> If you want me to delegate keys.gnupg.net to another pool >> operator group, please let me know. > > If you want to get out of the issue entirely, I recommend taking a > look at and > pick one to CNAME to. I suggest "ha.pool.sks-keyservers.net". iirc this is the case already[0]. The only issue with (in particular the HA pool) is that not all of the servers behind reverse proxies are configured for this vhost. Maybe it would make sense to put up a pool for servers specificially not behind a reverse proxy, but that'd be another can of worm. So I'll see if I can get around to adding some additional vhost (HTTP Host Header) checks somewhere. [0] http://lists.gnupg.org/pipermail/gnupg-users/2012-May/044504.html - -- - ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Ne nuntium necare Don't kill the messenger - ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ - ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0-beta100 (GNU/Linux) iQIcBAEBCAAGBQJQvfBfAAoJEAt/i2Dj7frjTQQP/10A6T2T+cDIJUMJGTMurxGn Sh7zP3g2si8mJp0/1M+Bvvn85sAmXIXd1FoPbwSC6GZgjLIyHBO73awaxzVniGpj /bofFNIWxSVtvA784TBqBXqyWTyM0krstYT4VCP3w+2A8Nn36jF8+l4EnqAgnuOW vOG2XuwtbRkS8GJ26OB32lTCvtN2xnoA8JimGdkYckNlbAW+UyAWHY9bSTGym/rc bd36Psz3+zGfB3ay9noCajp8zLJDxj6N47ft5gYWhaVh+dR2klzXcAtI/V3Dm5Bt fLegZXGJcZDGr63SakdTbzssfr2u46uveNUVpMMeXmuC/bC63MFc6+emg283M4PL 1NhLFrwMEwmTH6eFejpUBmhnPhcVprgwQ2tKhtXSW2dOs9imn6GaY/DejXIjTxu/ Pq4r4cNLTHs1JBcOoReHh5Nnw1cn1IjD02dLb39nHaGfnWGI+gu3TXoWXJf3wLYp MgOIn9zFyfBV36vEvI8YALMwfkykrypAt+n4jkVhw5QzX7lpKjwNCWr0gAe06xc1 RhK3CfIF9GQeved/jYZILrhlJaq0yY5GgRPeJ4e82FuFr5LSHpQRfwyQ7DHQ79EA wzkoDNxsgW8GrJF+MzHMCM4gb5Y+OHWWe7bDQUUmVXFDdH9ZAkrhYOY8l0/GJBP6 9ZJEZrX+HpPrIMuUJ1kV =hASg -----END PGP SIGNATURE----- From wk at gnupg.org Tue Dec 4 14:54:47 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Dec 2012 14:54:47 +0100 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <20121204092113.GA62639@redoubt.spodhuis.org> (Phil Pennock's message of "Tue, 4 Dec 2012 04:21:13 -0500") References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <20121203224814.GA52496@redoubt.spodhuis.org> <87a9tuz599.fsf@vigenere.g10code.de> <20121204092113.GA62639@redoubt.spodhuis.org> Message-ID: <87vcchx6qg.fsf@vigenere.g10code.de> On Tue, 4 Dec 2012 10:21, gnupg-devel at spodhuis.org said: > If you want to get out of the issue entirely, I recommend taking a look > at and pick one to > CNAME to. I suggest "ha.pool.sks-keyservers.net". Well, that is what I use since 20120619: keys.gnupg.net. 86400 IN CNAME pool.sks-keyservers.net. http-keys.gnupg.net. 86400 IN CNAME ha.pool.sks-keyservers.net. > If you want to avoid tying into SKS and want to maintain closer control No time to maintain that - I did this in the past but gave up and switched to a CNAME. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Tue Dec 4 17:59:45 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 04 Dec 2012 11:59:45 -0500 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <20121203224814.GA52496@redoubt.spodhuis.org> References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <20121203224814.GA52496@redoubt.spodhuis.org> Message-ID: <50BE2C01.60201@fifthhorseman.net> On 12/03/2012 05:48 PM, Phil Pennock wrote: > By contrast (to respond to another person here), using PGP for link > security instead of the X.509 PKIX tells me that folks are iffy on > "message-based security" vs "live link security" and on the impact of > timing-based attacks. As a keyserver operator, someone happy providing > a public service to assist in OpenPGP usage, I'm not going to put > PGP-based link security into place without a lot more operational impact > analysis of the crypto code in GnuPG's resilience to timing attacks, and > more. The actual crypto code used to sign the TLS handshake (the basis of the "live link security") is going to be the RSA implementation in the underlying crypto toolkit (e.g. OpenSSL, nettle, NSS, or gcrypt). This is irrespective of the packaging format of the certificate (how the RSA public key material is presented). If you believe that there are (e.g.) timing issues related to these crypto toolkits in live link situations, please please report them! They are actively in use by many systems on the public 'net today, whether with OpenPGP certificates or otherwise. --dkg From gnupg-devel at spodhuis.org Tue Dec 4 18:52:12 2012 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Tue, 4 Dec 2012 12:52:12 -0500 Subject: Keyserver/security bug 1447 (and 1446 too) In-Reply-To: <87vcchx6qg.fsf@vigenere.g10code.de> References: <20121202053456.GA61902@redoubt.spodhuis.org> <20121203035553.GA14522@redoubt.spodhuis.org> <87r4n730zu.fsf@vigenere.g10code.de> <20121203224814.GA52496@redoubt.spodhuis.org> <87a9tuz599.fsf@vigenere.g10code.de> <20121204092113.GA62639@redoubt.spodhuis.org> <87vcchx6qg.fsf@vigenere.g10code.de> Message-ID: <20121204175212.GA68113@redoubt.spodhuis.org> On 2012-12-04 at 14:54 +0100, Werner Koch wrote: > On Tue, 4 Dec 2012 10:21, gnupg-devel at spodhuis.org said: > > If you want to get out of the issue entirely, I recommend taking a look > > at and pick one to > > CNAME to. I suggest "ha.pool.sks-keyservers.net". > > Well, that is what I use since 20120619: > > keys.gnupg.net. 86400 IN CNAME pool.sks-keyservers.net. > http-keys.gnupg.net. 86400 IN CNAME ha.pool.sks-keyservers.net. Oops, sorry. Hadn't noticed that it was now a CNAME. Duh. Thanks. :) -Phil From gniibe at fsij.org Wed Dec 5 03:14:07 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 05 Dec 2012 11:14:07 +0900 Subject: Let scdaemon exit when no reader is available In-Reply-To: <877goyxi0y.fsf@vigenere.g10code.de> References: <1353461849.2749.5.camel@cfw2.gniibe.org> <87haojial5.fsf@vigenere.g10code.de> <1353550127.2908.2.camel@cfw2.gniibe.org> <1354604219.5408.0.camel@cfw2.gniibe.org> <877goyxi0y.fsf@vigenere.g10code.de> Message-ID: <1354673647.2856.7.camel@cfw2.gniibe.org> On 2012-12-04 at 10:50 +0100, Werner Koch wrote: > Pushed. Please feel free to push such changes yourself. Thank you. I will, in future. Same treatment is also needed in 2.0 branch. I am currently using 2.1.x with the change. When I won't see any problem, say, for a week or two, I will apply similar modification to 2.0 branch. * * * I think that all my modifications are in master branch now, and all problems I reported are solved somehow. Next will be supporting some card reader with keypad which doesn't have variable length input capability. -- From wk at gnupg.org Wed Dec 5 09:45:21 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Dec 2012 09:45:21 +0100 Subject: Let scdaemon exit when no reader is available In-Reply-To: <1354673647.2856.7.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Wed, 05 Dec 2012 11:14:07 +0900") References: <1353461849.2749.5.camel@cfw2.gniibe.org> <87haojial5.fsf@vigenere.g10code.de> <1353550127.2908.2.camel@cfw2.gniibe.org> <1354604219.5408.0.camel@cfw2.gniibe.org> <877goyxi0y.fsf@vigenere.g10code.de> <1354673647.2856.7.camel@cfw2.gniibe.org> Message-ID: <87d2yovqe6.fsf@vigenere.g10code.de> On Wed, 5 Dec 2012 03:14, gniibe at fsij.org said: > Same treatment is also needed in 2.0 branch. I am currently using > 2.1.x with the change. When I won't see any problem, say, for a week > or two, I will apply similar modification to 2.0 branch. Okay. Note that I would like to do a new 2.0 release this month. It is not a hard deadline, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 6 15:44:11 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Dec 2012 15:44:11 +0100 Subject: [admin] Mailing lists outage notice Message-ID: <87txrzp7er.fsf@vigenere.g10code.de> Hi, please be prepared that the mailing lists will be down for a few days due to a server upgrade. It would be too much work to move them temporary to another server. FTP will be down as well. The Web, Git, and the BTS should continue to work. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jim at meyering.net Fri Dec 7 07:25:53 2012 From: jim at meyering.net (Jim Meyering) Date: Fri, 07 Dec 2012 07:25:53 +0100 Subject: ECDSA support status? Message-ID: <87d2ymv0ni.fsf@rho.meyering.net> Hi Werner, In http://lists.gnupg.org/pipermail/gnupg-devel/2012-August/026845.html you mentioned that ECDSA support was in the works. Is there anything we can experiment with? Thanks, Jim From wk at gnupg.org Fri Dec 7 11:01:36 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Dec 2012 11:01:36 +0100 Subject: ECDSA support status? In-Reply-To: <87d2ymv0ni.fsf@rho.meyering.net> (Jim Meyering's message of "Fri, 07 Dec 2012 07:25:53 +0100") References: <87d2ymv0ni.fsf@rho.meyering.net> Message-ID: <87zk1qji4f.fsf@vigenere.g10code.de> On Fri, 7 Dec 2012 07:25, jim at meyering.net said: > In http://lists.gnupg.org/pipermail/gnupg-devel/2012-August/026845.html > you mentioned that ECDSA support was in the works. > Is there anything we can experiment with? Unfortunately no. I started with it but decided to cleanup up some things first. It is one of the tasks I really want to do for the next (beta) release. The plan is to have at least a beta this year. But well, it is only a plan. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jim at meyering.net Sat Dec 8 00:44:03 2012 From: jim at meyering.net (Jim Meyering) Date: Sat, 08 Dec 2012 00:44:03 +0100 Subject: ECDSA support status? In-Reply-To: <87zk1qji4f.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 07 Dec 2012 11:01:36 +0100") References: <87d2ymv0ni.fsf@rho.meyering.net> <87zk1qji4f.fsf@vigenere.g10code.de> Message-ID: <87boe5tol8.fsf@rho.meyering.net> Werner Koch wrote: > On Fri, 7 Dec 2012 07:25, jim at meyering.net said: > >> In http://lists.gnupg.org/pipermail/gnupg-devel/2012-August/026845.html >> you mentioned that ECDSA support was in the works. >> Is there anything we can experiment with? > > Unfortunately no. I started with it but decided to cleanup up some > things first. It is one of the tasks I really want to do for the next > (beta) release. The plan is to have at least a beta this year. But > well, it is only a plan. With barely 3 weeks left in the year, getting that feature into a beta by then would be awesome. Thanks! From bernhard at intevation.de Mon Dec 10 20:59:11 2012 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 10 Dec 2012 20:59:11 +0100 Subject: issue tracker problems Message-ID: <2163688.pPClWJmIoY@kymo.gruen> Hi Werner, I'm having problems with the issue tracker bugs.g10code.com tonight. With a number of searches I get: "An error has occurred A problem was encountered processing your request. The tracker maintainers have been notified of the problem." Also when trying to display some issues like: https://bugs.g10code.com/gnupg/issue1287 A corrupted database? Let me know if I can help. Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From gniibe at fsij.org Tue Dec 11 02:12:24 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 11 Dec 2012 10:12:24 +0900 Subject: libassuan version number? Message-ID: <1355188344.2809.4.camel@cfw2.gniibe.org> Hello, I committed SCD changes to STABLE-BRANCH-2_0. When I test my changes for STABLE-BRANCH-2_0 and master, I found an issue of libassuan (development version). On Debian testing (GNU/Linux), I'm doing: * GnuPG STABLE-BRANCH-2_0 with libassuan-dev of Debian 2.0.3-1 * GnuPG master with libassuan master libassuan is installed with prefix /usr/local The problem is that libassuan 2.0.3 and libassuan master are not compatible (libassuan master has more symbols). An executable linked to newer libassuan doesn't work with older libassuan. I think that newer libassuan should have different SONAME. Don't we need to update LIBASSUAN_LT_CURRENT, LIBASSUAN_LT_AGE? I don't have much knowledge of libtools. All that I can say is that if ABI is different, shared libraries should have different SONAME (so that libraries implementations can co-exist). -- From remo.hertig at bluewin.ch Tue Dec 11 08:39:50 2012 From: remo.hertig at bluewin.ch (remo.hertig at bluewin.ch) Date: Tue, 11 Dec 2012 07:39:50 +0000 (GMT+00:00) Subject: A Probabilistic Trust Model for GnuPG (2006) Message-ID: <1371764.14111355211590324.JavaMail.webmail@bluewin.ch> A Probabilistic Trust Model for GnuPG was proposed 2006 in this paper: http://www.iam.unibe.ch/~jonczy/papers/JWH06.pdf However i cannot find this functionality in recent gpg (1.4.11). Why was this functionality never implemented? Remo From nicholas.cole at gmail.com Tue Dec 11 10:31:14 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 11 Dec 2012 09:31:14 +0000 Subject: A Probabilistic Trust Model for GnuPG (2006) In-Reply-To: <1371764.14111355211590324.JavaMail.webmail@bluewin.ch> References: <1371764.14111355211590324.JavaMail.webmail@bluewin.ch> Message-ID: On Tue, Dec 11, 2012 at 7:39 AM, remo.hertig at bluewin.ch wrote: > A Probabilistic Trust Model for GnuPG was proposed 2006 in this paper: http://www.iam.unibe.ch/~jonczy/papers/JWH06.pdf > > > However i cannot find this functionality in recent gpg (1.4.11). > > Why was this functionality never implemented? > > Remo Dear Remo, I can't speak for the developers, but there are some serious problems with the model that paper proposes. I think the problem is captured by the discussion of figure 2 in the paper. The author suggests that the PGP trust model produces a "counter-intuitive" result. I don't see that this is really the case at all. I can't see any compelling reason to implement that particular trust model. Worse, to the extent that it produces different outcomes to the standard models, I don't see that what it proposes is an improvement. But perhaps I am missing something. Nicholas From wk at gnupg.org Tue Dec 11 11:18:48 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Dec 2012 11:18:48 +0100 Subject: libassuan version number? In-Reply-To: <1355188344.2809.4.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Tue, 11 Dec 2012 10:12:24 +0900") References: <1355188344.2809.4.camel@cfw2.gniibe.org> Message-ID: <871uewhoxj.fsf@vigenere.g10code.de> On Tue, 11 Dec 2012 02:12, gniibe at fsij.org said: > The problem is that libassuan 2.0.3 and libassuan master are not > compatible (libassuan master has more symbols). An executable > linked to newer libassuan doesn't work with older libassuan. Yes, master has an API change, but that should be compatible: ASSUAN_SYSTEM_NPTH_IMPL NEW macro. ASSUAN_SYSTEM_NPTH NEW macro. __assuan_read NEW (private). __assuan_write NEW (private). __assuan_recvmsg NEW (private). __assuan_sendmsg NEW (private). __assuan_waitpid NEW (private). > I think that newer libassuan should have different SONAME. I don't think so. It is a compatible ABI change. Thus on glibc systems only the minor SO number will be updated with the next release. Updating it during the development is not a good idea, because - well - it is a development version and we might need to revert changes before the release. > I don't have much knowledge of libtools. All that I can say is that > if ABI is different, shared libraries should have different SONAME (so > that libraries implementations can co-exist). Right. In the commit for a release you will notices some thing like: Release version 2.0.3. * configure.ac: Bump LT version to C3/A3/R0. The details are in configure.ac: # LT Version numbers, remember to change them just *before* a release. # (Code changed: REVISION++) # (Interfaces added/removed/changed:CURRENT++, REVISION=0) # (Interfaces added: AGE++) # (Interfaces removed/changed: AGE=0) # LIBASSUAN_LT_CURRENT=3 LIBASSUAN_LT_AGE=3 LIBASSUAN_LT_REVISION=0 Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Dec 11 11:28:51 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Dec 2012 11:28:51 +0100 Subject: issue tracker problems In-Reply-To: <2163688.pPClWJmIoY@kymo.gruen> (Bernhard Reiter's message of "Mon, 10 Dec 2012 20:59:11 +0100") References: <2163688.pPClWJmIoY@kymo.gruen> Message-ID: <87wqwog9wc.fsf@vigenere.g10code.de> On Mon, 10 Dec 2012 20:59, bernhard at intevation.de said: > Also when trying to display some issues like: > https://bugs.g10code.com/gnupg/issue1287 Only that bug seems to be affected. The body of the message might be Please add decrypt-only mode for gpg that decrypts message but leaves original signature intact. The output would be like --clearsign or --sign modes generate. I do have backups, but it is a bit cumbersome to figure out the version it went bogus. Please let me know if you stumble on other problems. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From abel at guardianproject.info Tue Dec 11 14:31:31 2012 From: abel at guardianproject.info (Abel Luck) Date: Tue, 11 Dec 2012 13:31:31 +0000 Subject: ttyname in gpgme when running Android In-Reply-To: <876250jpp4.fsf@vigenere.g10code.de> References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> <87pq48c7xh.fsf@vigenere.g10code.de> <5087F060.70600@guardianproject.info> <87d307dhvi.fsf@vigenere.g10code.de> <50A503AA.8060402@guardianproject.info> <87boeybuiv.fsf@vigenere.g10code.de> <50AA9E88.8020305@guardianproject.info> <876250jpp4.fsf@vigenere.g10code.de> Message-ID: <50C735B3.6050203@guardianproject.info> Werner Koch: > On Mon, 19 Nov 2012 22:03, abel at guardianproject.info said: > >> I'll pull gnupg master every now and then to see when it's been added. > > Sorry, I have not yet come around to fix that. I let you know. > Hi Werner, any updates on making Android avoid the ttyname() codepaths? Unfortunately, this is our current blocker in pinentry porting, which in turn is our blocker for a gnupg-for-android release. Cheers, ~abel From wk at gnupg.org Tue Dec 11 14:15:41 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Dec 2012 14:15:41 +0100 Subject: ttyname in gpgme when running Android In-Reply-To: <50C735B3.6050203@guardianproject.info> (Abel Luck's message of "Tue, 11 Dec 2012 13:31:31 +0000") References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> <87pq48c7xh.fsf@vigenere.g10code.de> <5087F060.70600@guardianproject.info> <87d307dhvi.fsf@vigenere.g10code.de> <50A503AA.8060402@guardianproject.info> <87boeybuiv.fsf@vigenere.g10code.de> <50AA9E88.8020305@guardianproject.info> <876250jpp4.fsf@vigenere.g10code.de> <50C735B3.6050203@guardianproject.info> Message-ID: <87k3sog26a.fsf@vigenere.g10code.de> On Tue, 11 Dec 2012 14:31, abel at guardianproject.info said: > Hi Werner, any updates on making Android avoid the ttyname() codepaths? Please disregard my previous mail. It should work since some time but I probably missed to tell you: commit 835698b72bc509565aad52b0753f1c56c1a8f062 Author: Werner Koch Date: Tue Nov 20 19:01:13 2012 +0100 Do not use a broken ttyname. * configure.ac (HAVE_BROKEN_TTYNAME): New ac_define set for Android systems. * common/util.h (gnupg_ttyname): New macro. Change all callers of ttyname to use this macro instead. (ttyname) [W32]: Rename to _gnupg_ttyname and use also if HAVE_BROKEN_TTYNAME is defined. * common/simple-pwquery.c (agent_send_all_options): Keep on using ttyname unless HAVE_BROKEN_TTYNAME is set. This is because this file may be used standalone. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From abel at guardianproject.info Tue Dec 11 15:29:09 2012 From: abel at guardianproject.info (Abel Luck) Date: Tue, 11 Dec 2012 14:29:09 +0000 Subject: ttyname in gpgme when running Android In-Reply-To: <87k3sog26a.fsf@vigenere.g10code.de> References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> <87pq48c7xh.fsf@vigenere.g10code.de> <5087F060.70600@guardianproject.info> <87d307dhvi.fsf@vigenere.g10code.de> <50A503AA.8060402@guardianproject.info> <87boeybuiv.fsf@vigenere.g10code.de> <50AA9E88.8020305@guardianproject.info> <876250jpp4.fsf@vigenere.g10code.de> <50C735B3.6050203@guardianproject.info> <87k3sog26a.fsf@vigenere.g10code.de> Message-ID: <50C74335.7040209@guardianproject.info> Werner Koch: > On Tue, 11 Dec 2012 14:31, abel at guardianproject.info said: > >> Hi Werner, any updates on making Android avoid the ttyname() codepaths? > > Please disregard my previous mail. It should work since some time but I > probably missed to tell you: > > commit 835698b72bc509565aad52b0753f1c56c1a8f062 > Author: Werner Koch > Date: Tue Nov 20 19:01:13 2012 +0100 > > Do not use a broken ttyname. > > * configure.ac (HAVE_BROKEN_TTYNAME): New ac_define set for Android > systems. > * common/util.h (gnupg_ttyname): New macro. Change all callers of > ttyname to use this macro instead. > (ttyname) [W32]: Rename to _gnupg_ttyname and use also if > HAVE_BROKEN_TTYNAME is defined. > * common/simple-pwquery.c (agent_send_all_options): Keep on using > ttyname unless HAVE_BROKEN_TTYNAME is set. This is because this file > may be used standalone. > > Yes, I've tested this commit. But it just causes linker errors (as should be expected): In function `session_env_getenv_or_default': ~src/guardian/gnupg-for-android/external/gnupg/common/session-env.c:341: undefined reference to `broken_native_ttyname' On android we want to avoid the ttyname code all together (presumably like W32 does?). In gpgme we the REPLACE_TTYNAME magic from gpgme/m4/gnupg-ttyname.m4 needs to be ported to gnupg as well. ~abel > > Salam-Shalom, > > Werner > > From wk at gnupg.org Tue Dec 11 16:08:42 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Dec 2012 16:08:42 +0100 Subject: ttyname in gpgme when running Android In-Reply-To: <50C74335.7040209@guardianproject.info> (Abel Luck's message of "Tue, 11 Dec 2012 14:29:09 +0000") References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> <87pq48c7xh.fsf@vigenere.g10code.de> <5087F060.70600@guardianproject.info> <87d307dhvi.fsf@vigenere.g10code.de> <50A503AA.8060402@guardianproject.info> <87boeybuiv.fsf@vigenere.g10code.de> <50AA9E88.8020305@guardianproject.info> <876250jpp4.fsf@vigenere.g10code.de> <50C735B3.6050203@guardianproject.info> <87k3sog26a.fsf@vigenere.g10code.de> <50C74335.7040209@guardianproject.info> Message-ID: <87ehiwfwxx.fsf@vigenere.g10code.de> On Tue, 11 Dec 2012 15:29, abel at guardianproject.info said: > In function `session_env_getenv_or_default': > ~src/guardian/gnupg-for-android/external/gnupg/common/session-env.c:341: > undefined reference to `broken_native_ttyname' I can't see and reference to that symbol. May it be that there is some cruft from an older patch? > On android we want to avoid the ttyname code all together (presumably > like W32 does?). That is what the commit does. It defines HAVE_BROKEN_TTYNAME and in util.h we use: #if !defined(HAVE_TTYNAME) || defined(HAVE_BROKEN_TTYNAME) # define gnupg_ttyname(n) _gnupg_ttyname ((n)) /* Systems without ttyname (W32) will merely return NULL. */ static inline char * _gnupg_ttyname (int fd) { (void)fd; return NULL; } #else /*HAVE_TTYNAME*/ # define gnupg_ttyname(n) ttyname ((n)) #endif /*HAVE_TTYNAME */ On Windows HAVE_TTYNAME is not defined and on Android HAVE_BROKEN_TTYNAME is defined. Thus the macro and the inline function is used. > In gpgme we the REPLACE_TTYNAME magic from gpgme/m4/gnupg-ttyname.m4 > needs to be ported to gnupg as well. That was too different from what we use in GnuPG. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Wed Dec 12 01:52:15 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 12 Dec 2012 09:52:15 +0900 Subject: libassuan version number? In-Reply-To: <871uewhoxj.fsf@vigenere.g10code.de> References: <1355188344.2809.4.camel@cfw2.gniibe.org> <871uewhoxj.fsf@vigenere.g10code.de> Message-ID: <1355273535.2814.2.camel@cfw2.gniibe.org> Thanks for the explanation. I understand the policy not updating version number during the development. That's being said, let me talk my point about compatibility. Replacing old libassuan to new libassuan can be done with no problem. For my debugging purpose, I didn't want to replace, but want to keep old libassuan as is. On 2012-12-11 at 11:18 +0100, Werner Koch wrote: > Yes, master has an API change, but that should be compatible: > > ASSUAN_SYSTEM_NPTH_IMPL NEW macro. > ASSUAN_SYSTEM_NPTH NEW macro. > __assuan_read NEW (private). > __assuan_write NEW (private). > __assuan_recvmsg NEW (private). > __assuan_sendmsg NEW (private). > __assuan_waitpid NEW (private). Yes, new libassuan can be backword compatible to old libassuan. That is, executables which are linked to old libassuan can work well with new libassuan. But not vice versa. I had new gpg-agent which is compiled with new libassuan. This new gpg-agent uses new functions (__assuan_write, __assuan_read, __assuan_recvmsg, __assuan_sendmsg, and __assuan_waitpid). Thus, it requires new libassuan. It doesn't work with old libassuan. Since I needed to test both of: * GnuPG 2.0.x with old libassuan * GnuPG master with new libassuan I changed SONAME of new libassuan (for me), so that two different libassuan can coexist in a single system. Well, there is another ways, such that installing new libassuan to private directory and using LD_LIBRARY_PATH. -- From rjh at sixdemonbag.org Wed Dec 12 04:01:56 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 11 Dec 2012 22:01:56 -0500 Subject: A Probabilistic Trust Model for GnuPG (2006) In-Reply-To: <1371764.14111355211590324.JavaMail.webmail@bluewin.ch> References: <1371764.14111355211590324.JavaMail.webmail@bluewin.ch> Message-ID: <50C7F3A4.8030702@sixdemonbag.org> On 12/11/2012 2:39 AM, remo.hertig at bluewin.ch wrote: > Why was this functionality never implemented? I also forgot to mention: it was never implemented because it would break the OpenPGP spec. If you want to see this included, your best bet is to argue on the IETF OpenPGP Working Group mailing list for it to be added to the next revision of the OpenPGP standard. From gniibe at fsij.org Wed Dec 12 07:03:24 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 12 Dec 2012 15:03:24 +0900 Subject: SCD: no keys detected after key import / key generation Message-ID: <1355292204.8285.3.camel@cfw2.gniibe.org> Hello, While testing Gnuk extensively, I found that GnuPG doesn't detect keys after key import (or key generation). We need to remove and re-insert Gnuk Token (or kill and start scdaemon again). For gpg --card-status, GnuPG keeps saying: [...] Signature key ....: [none] Encryption key....: [none] Authentication key: [none] General key info..: [none] although Gnuk Token has keys. Even if a user does "gpg-connect-agent learn /bye", GnuPG doesn't detect keys. I think that this is because of data handling of KEY-FPR and KEY-TIME of OpenPGPcard specification. The data access is a kind of asymmetric. When reading, it's accessed as an array of three data, but when writing, it is accessed individually. Note that it is not composite data object. My theory is that something like following fixes this issue. After testing, I will commit this change both of master and STABLE-BRANCH-2-0. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 141b2b7..98af5e8 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -688,9 +688,9 @@ store_fpr (app_t app, int keynumber, u32 timestamp, xfree (buffer); tag = (card_version > 0x0007? 0xC7 : 0xC6) + keynumber; - flush_cache_item (app, tag); + flush_cache_item (app, 0xC5); tag2 = 0xCE + keynumber; - flush_cache_item (app, tag2); + flush_cache_item (app, 0xCD); rc = iso7816_put_data (app->slot, 0, tag, fpr, 20); if (rc) -- From gnupg-devel at spodhuis.org Wed Dec 12 11:46:20 2012 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Wed, 12 Dec 2012 05:46:20 -0500 Subject: SHA3 IANA registration - method? Message-ID: <20121212104620.GA35659@redoubt.spodhuis.org> Sorry for asking here, but mail to is bouncing, so it looks as though the ietf-openpgp list is now completely dead. The only IETF forum I can spot is the concluded openpgp WG: http://www.ietf.org/wg/concluded/openpgp.html So: what's the best mechanism for registering a "Hash Algorithms" entry in http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xml for SHA-3 ? RFC without implementation or implementation based on PRIVATE USE code-points and then RFC? I'm guessing that a working implementation using a PRIVATE USE code-point, per RFC4880 section 13.10, is a decent way to go? Or is PGP one of the protocols where folks have settled on avoiding private use fields because of the difficulty in migrating away from them? Does anyone know of someone already writing the necessary RFC for the IETF Consensus mechanism? Thanks, -Phil From nicholas.cole at gmail.com Wed Dec 12 13:29:03 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed, 12 Dec 2012 12:29:03 +0000 Subject: A Probabilistic Trust Model for GnuPG (2006) In-Reply-To: <50C7F3A4.8030702@sixdemonbag.org> References: <1371764.14111355211590324.JavaMail.webmail@bluewin.ch> <50C7F3A4.8030702@sixdemonbag.org> Message-ID: On Wed, Dec 12, 2012 at 3:01 AM, Robert J. Hansen wrote: > On 12/11/2012 2:39 AM, remo.hertig at bluewin.ch wrote: >> Why was this functionality never implemented? > > I also forgot to mention: it was never implemented because it would > break the OpenPGP spec. > > If you want to see this included, your best bet is to argue on the IETF > OpenPGP Working Group mailing list for it to be added to the next > revision of the OpenPGP standard. In fact, the OpenPGP standard DOES allow for fine-grained levels of trust, or could be easily extended to do so - it's just that having 120 (or 255) levels of trusted introducer is of very marginal value. It is hard to think of a real-world case where the 2 we have wouldn't do. What this proposal wanted to do was to introduce the idea that marginal levels of trust in the web of trust might nevertheless result in a key that was "probably good enough". While an interesting proposal to reflect upon, this proposal is not a useful or sensible one, and I'm glad that it has been mostly forgotten. Best wishes, N. From dshaw at jabberwocky.com Wed Dec 12 17:04:57 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 12 Dec 2012 11:04:57 -0500 Subject: SHA3 IANA registration - method? In-Reply-To: <20121212104620.GA35659@redoubt.spodhuis.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> Message-ID: <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> On Dec 12, 2012, at 5:46 AM, Phil Pennock wrote: > Sorry for asking here, but mail to is > bouncing, so it looks as though the ietf-openpgp list is now completely > dead. The only IETF forum I can spot is the concluded openpgp WG: > http://www.ietf.org/wg/concluded/openpgp.html The IETF OpenPGP WG completed their work, so that list was closed. There is another list, however, for ongoing discussions: https://www.ietf.org/mailman/listinfo/openpgp. That would be the appropriate place to discuss adding SHA-3 support to OpenPGP. > So: what's the best mechanism for registering a "Hash Algorithms" entry > in http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xml for > SHA-3 ? RFC without implementation or implementation based on PRIVATE > USE code-points and then RFC? It's pretty simple to propose a new algorithm for OpenPGP: discuss it on the OpenPGP list, and then write and submit an RFC. The RFC is mainly boilerplate that says "This extends OpenPGP, here's a new hash algorithm, it's specified in such-and-such document, and its algorithm number is XXX. All the usual statements about hash algorithms from RFC-4880 apply here as well." IANA changes XXX to the algorithm number on publication. Take a look at the one I did for Camellia (http://tools.ietf.org/html/rfc5581) and feel free to steal any or all of it. > I'm guessing that a working implementation using a PRIVATE USE > code-point, per RFC4880 section 13.10, is a decent way to go? Or is PGP > one of the protocols where folks have settled on avoiding private use > fields because of the difficulty in migrating away from them? The private algorithm numbers are useful for internal use and testing, but I would not ship code that uses them, except for interop testing and similar. Otherwise, the private algorithm number effectively becomes public, and implementers need to support the real number and the temporary private number for a long time, if not indefinitely. David From wk at gnupg.org Wed Dec 12 18:53:35 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 12 Dec 2012 18:53:35 +0100 Subject: ECDSA support for GnuPG's ssh-agent. Message-ID: <87txrrcg2o.fsf@vigenere.g10code.de> Hi, master has now support for ECDSA keys for the ssh-agent protocol. Salam-Shalom, Werner ==== commit 649b31c Author: Werner Koch Date: Wed Dec 12 18:47:21 2012 +0100 ssh: Support ECDSA keys. * agent/command-ssh.c (SPEC_FLAG_IS_ECDSA): New. (struct ssh_key_type_spec): Add fields CURVE_NAME and HASH_ALGO. (ssh_key_types): Add types ecdsa-sha2-nistp{256,384,521}. (ssh_signature_encoder_t): Add arg spec and adjust all callers. (ssh_signature_encoder_ecdsa): New. (sexp_key_construct, sexp_key_extract, ssh_receive_key) (ssh_convert_key_to_blob): Support ecdsa. (ssh_identifier_from_curve_name): New. (ssh_send_key_public): Retrieve and pass the curve_name. (key_secret_to_public): Ditto. (data_sign): Add arg SPEC and change callers to pass it. (ssh_handler_sign_request): Get the hash algo from SPEC. * common/ssh-utils.c (get_fingerprint): Support ecdsa. * agent/protect.c (protect_info): Add flag ECC_HACK. (agent_protect): Allow the use of the "curve" parameter. * agent/t-protect.c (test_agent_protect): Add a test case for ecdsa. * agent/command-ssh.c (ssh_key_grip): Print a better error code. -- The 3 standard curves are now supported in gpg-agent's ssh-agent protocol implementation. I tested this with all 3 curves and keys generated by OpenSSH 5.9p1. Using existing non-ssh generated keys will likely fail for now. To fix this, the code should first undergo some more cleanup; then the fixes are pretty straightforward. And yes, the data structures are way too complicated. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jim at meyering.net Wed Dec 12 19:10:51 2012 From: jim at meyering.net (Jim Meyering) Date: Wed, 12 Dec 2012 19:10:51 +0100 Subject: ECDSA support for GnuPG's ssh-agent. In-Reply-To: <87txrrcg2o.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 12 Dec 2012 18:53:35 +0100") References: <87txrrcg2o.fsf@vigenere.g10code.de> Message-ID: <87hanrjg44.fsf@rho.meyering.net> Werner Koch wrote: > master has now support for ECDSA keys for the ssh-agent protocol. Wow. That was quick. Ask and ye shall receive :-) Thanks for the awesome support! From openpgp at brainhub.org Wed Dec 12 22:09:08 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Wed, 12 Dec 2012 13:09:08 -0800 Subject: SHA3 IANA registration - method? In-Reply-To: <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> Message-ID: <50C8F274.2050701@brainhub.org> I wrote a draft to support SHA-3 Keccak in OpenPGP. I slowed down thinking about what to do about SHA1 fingerprints before I was distracted by unrelated things. My thought was that perhaps this draft should be used to resolve the issue of a SHA1 fingerprint by introducing a hardwired Keccac fingerprint. Ignoring the fingerprint issue, the rest of the spec should be straighforward. I am attaching the document that I created. Is it OK if I submit this document in the next few weeks to IETF (has to be as a personal work, since there is no WG anymore)? I will announce this on openpgp and we go from there. Is there interest to discuss the fingerprint issue on the openpgp list? Regarding the immediate implementation, I suppose you can just post the private Keccak IDs that you used, promising that these IDs will be temporary before we get the IANA numbers. Thank you. On 12/12/2012 08:04 AM, David Shaw wrote: > On Dec 12, 2012, at 5:46 AM, Phil Pennock wrote: > >> Sorry for asking here, but mail to is >> bouncing, so it looks as though the ietf-openpgp list is now completely >> dead. The only IETF forum I can spot is the concluded openpgp WG: >> http://www.ietf.org/wg/concluded/openpgp.html > > The IETF OpenPGP WG completed their work, so that list was closed. There is another list, however, for ongoing discussions: https://www.ietf.org/mailman/listinfo/openpgp. That would be the appropriate place to discuss adding SHA-3 support to OpenPGP. > >> So: what's the best mechanism for registering a "Hash Algorithms" entry >> in http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xml for >> SHA-3 ? RFC without implementation or implementation based on PRIVATE >> USE code-points and then RFC? > > It's pretty simple to propose a new algorithm for OpenPGP: discuss it on the OpenPGP list, and then write and submit an RFC. The RFC is mainly boilerplate that says "This extends OpenPGP, here's a new hash algorithm, it's specified in such-and-such document, and its algorithm number is XXX. All the usual statements about hash algorithms from RFC-4880 apply here as well." IANA changes XXX to the algorithm number on publication. Take a look at the one I did for Camellia (http://tools.ietf.org/html/rfc5581) and feel free to steal any or all of it. > >> I'm guessing that a working implementation using a PRIVATE USE >> code-point, per RFC4880 section 13.10, is a decent way to go? Or is PGP >> one of the protocols where folks have settled on avoiding private use >> fields because of the difficulty in migrating away from them? > > The private algorithm numbers are useful for internal use and testing, but I would not ship code that uses them, except for interop testing and similar. Otherwise, the private algorithm number effectively becomes public, and implementers need to support the real number and the temporary private number for a long time, if not indefinitely. > > David > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- Network Workign Group A. Jivsov Internet-Draft Symantec Corporation Intended status: Standards Track October 17, 2012 Expires: April 20, 2013 The use of Secure Hash Algorithm 3 in OpenPGP draft-jivsov-openpgp-sha3-00 Abstract This document presents the necessary information to use the SHA-3 hash algorithm with the OpenPGP format. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 20, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Jivsov Expires April 20, 2013 [Page 1] Internet-Draft SHA-3 in OpenPGP October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 3. Overview of the hash algorithm use in OpenPGP . . . . . . . . . 3 4. Supported SHA-3 algorithms . . . . . . . . . . . . . . . . . . 4 5. Use with RSA digital signatures . . . . . . . . . . . . . . . . 4 6. Interoperability concerns arising from an introduction of a new hash algorithm . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Jivsov Expires April 20, 2013 [Page 2] Internet-Draft SHA-3 in OpenPGP October 2012 1. Introduction The OpenPGP format [RFC4880] supports multiple hash algorithms. This document provides the necessary information to use the Secure Hash Algorithm 3 (SHA-3) hash algorithm with the OpenPGP format. National Institute of Standards and Technology (NIST) selected [Keccak] as the SHA-3 algorithm for its elegant design, its ability to run well on different computing devices, higher performance in hardware implementations, and different internal structure that provides assurances against attacks on its predecessors from the SHA-1 and SHA-2 family [Announcement]. This document has following external dependencies that must be resolved prior to the publication: TODO 1: Add the reference to the official SHA-3 specification by NIST (only Keccak author's information is currently available) TODO 2: Review NIST-recommended SHA-3 output sizes (256, 384, 512 are currently included; exclude 224 if it's in the list?). TODO 3: Add ASN.1 OIDs for RSA signatures (the OIDs are not created yet) 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Overview of the hash algorithm use in OpenPGP Hash algorithm is used in [RFC4880] in digital signatures, in modification detection code, and in key fingerprints. Only digital signatures allow algorithm agility and are most vulnerable to various attacks on hash functions. Thus, the focus of this document is on the use of SHA-3 hash with OpenPGP digital signatures. The use of hash algorithm with digital signatures in OpenPGP falls into two categories. The first one is the digital signatures over messages, and another one is the certifications of the key material. The latter area includes self-signatures, which convey key preference information, among other tasks. The rest of key certifications are third party key signatures. These categories will be considered Jivsov Expires April 20, 2013 [Page 3] Internet-Draft SHA-3 in OpenPGP October 2012 separately in more details in Section 6 for the impact on interoperability. 4. Supported SHA-3 algorithms SHA-3 specification REF defines a single cryptographic hash function that is parameterized to produce hash output of certain sizes. This document refers to these instantiations of the same hash algorithm as SHA-3 hash algorithms and treats them as different hash algorithms. This is needed because OpenPGP format expects a fully specified hash algorithm, in particular, a hash algorithm identifier (ID) is associated with a single fixed hash size. The SHA-3 algorithm with the output size of 256, 384, and 512 bits MAY be used as a hash algorithm with digital signatures. The input size to the hash algorithm in OpenPGP MUST be even to 8 bits, in other words, the input is always represented as a sequence of full 8-bit octets. It is possible to implement all SHA-3 algorithms with a single unified implementation, such that the only variable that distinguishes these algorithms is an integer representing the hash output size. For example, there are no special tables or magic constants that are specific to the hash output size of the SHA-3 algorithms. For this reason an application MUST implement signature verification for all 3 hash output sizes of SHA-3 algorithm if it implements at least one of them. Application MAY generate signatures with SHA-3- 256, SHA-3-384, and SHA-3-512 hash algorithms. Applications MAY use any SHA-3 digital signature algorithm described in [RFC4880] and with Elliptic Curve DSA algorithm described in [RFC6637]. 5. Use with RSA digital signatures Section 5.2.2 of [RFC4880] describes the Version 3 Signature Packet Format. One of allowed public key algorithms in that section is the RSA digital signature algorithm. RSA signatures use the PKCS#1 encoding to format (cryptographically "pad") the output of the hash algorithm. The padding includes the DER-encoded prefix that remain fixed for the given hash algorithm. While this prefix is an DER encoding of an ASN.1 Object Identifier (OID), the length value of the hash output, and other fields, it's possible to specify the prefix as a fixed sequence of octets for convenience. These prefixes are Jivsov Expires April 20, 2013 [Page 4] Internet-Draft SHA-3 in OpenPGP October 2012 defined bellow. Algorithm ASN.1 OID DER of the OID --------------------- --------------------- --------------------- SHA-3-256 x.y.z ... XX XX XX ... SHA-3-384 x.y.z ... XX XX XX ... SHA-3-512 x.y.z ... XX XX XX ... SHA-3 hash IDs The full DER-encoded hash prefixes are provided bellow. Algorithm Full DER prefix --------------------- ------------------------------------------- SHA-3-256 XX XX XX ... SHA-3-384 XX XX XX ... SHA-3-512 XX XX XX ... SHA-3 hash full DER prefixes 6. Interoperability concerns arising from an introduction of a new hash algorithm This section provides interoperability considerations to help the adoption of the SHA-3 algorithm. Note that these interoperability concerns are not unique to SHA-3. For example, exactly the same concerns apply during the introduction of a new digital signature algorithm. Informally speaking, these concerns are the result of the process by which we create a data structure that will be processed by unknown parties at an undetermined future moment. The digital signature validation is dependent on wide support of the selected hash algorithm by deployed OpenPGP implementations that will be verifying the digital signature. The consequence of the absence of the support for a particular message hash is a public key considered invalid, a message reported as that it is tampered with, or both. In general, there is no method in OpenPGP by which a party that issues a digital signature can be certain about the support of a hash algorithm by other implementations. The safest method to mitigate these challenges is a phased deployment of the new hash algorithm support, as follows: o Implement the hash algorithm, test it thoroughly. o Enable its use with the supported digital signature algorithms and test signature generation and verification with your Jivsov Expires April 20, 2013 [Page 5] Internet-Draft SHA-3 in OpenPGP October 2012 implementation and, if possible, others' implementations as well. Then disable the signature generation in the production code (i.e. leave the "read support" only). o Wait sufficiently long for the deployment of the applications that can verify digital signatures with the new hash algorithm. The above steps make enabling the generation of signatures with the new hash algorithm at a future time safer. Two categories of digital signatures in OpenPGP, as described in Section 3, have different impact on interoperability. The use of new hash algorithm in a public key certifications, especially in self- signatures, too early can make the key unusable in the large extent of the OpenPGP ecosystem. On the other hand, the impact of the use of the new hash algorithm in a digital signature over a message is limited to users who will be verifying this message. The idea of introducing the new hash algorithm first to protect messages is consistent with the security risks. Collision resistance is the most difficult to accomplish requirement of the hash algorithm. Collision attacks are most effective when an attacker is free to use arbitrary data as a signed plaintext. It follows that such attacks are easier on OpenPGP signed messages as opposed to key certifications, therefore, signed messages will benefit the most from a stronger hash algorithm. In cases when the message is both encrypted and signed, the application knows the keys of the entities who will be performing signature verification. The application SHOULD rely on Hash Algorithm Preferences of the recipients public keys to learn about SHA-3 support. This preference is described in the Section 13.3.2 of [RFC4880]. 7. IANA Considerations This document asks to allocate the consecutive hash algorithm IDs from the Hash Algorithm ID range, defined in the Section 9.4 of [RFC4880]. The starting ID is not important, but the properties that the IDs are sequential and that they are in the given order are expected to simplify implementation. Jivsov Expires April 20, 2013 [Page 6] Internet-Draft SHA-3 in OpenPGP October 2012 ID Algorithm Text Name ------ --------------------------- ----------- 17 SHA-3 with 256 bit output "SHA-3-256" 18 SHA-3 with 384 bit output "SHA-3-384" 19 SHA-3 with 512 bit output "SHA-3-512" Table 1: SHA-3 hash IDs 8. Security Considerations The choice of the SHA-3 hash algorithm SHOULD not be weaker than the desired level of security of the message signature or the key certification. The security bit strength of the hash algorithm is assumed to be half of the hash output size; this value is equal to the key size of the symmetric key algorithm of equivalent strength. For example, the strength of the SHA-3 256 is equivalent to the strength of the AES- 128 [AES]. Using the security bit strength of the hash algorithm, Table 2 from [SP 800-57 Part1] SHOULD be used to determine the corresponding strength of the public key algorithm. For example, the SHA-3 256 has equivalent security strength to the NIST curve P-256 [RFC6637]. 9. References 9.1. Normative References [Keccak] Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche, "The Keccak sponge function family", 2012, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 9.2. Informative References [AES] NIST, "Specification for the ADVANCED ENCRYPTION STANDARD (AES)", November 2001, . [Announcement] Jivsov Expires April 20, 2013 [Page 7] Internet-Draft SHA-3 in OpenPGP October 2012 NIST, "NIST Selects Winner of Secure Hash Algorithm (SHA-3) Competition", October 2012, . [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in OpenPGP", RFC 6637, June 2012. [SP 800-57 Part1] NIST, "Recommendation for Key Management -- Part 1: General (Revision 3)", July 2012, . Author's Address Andrey Jivsov Symantec Corporation Email: openpgp at brainhub.org Jivsov Expires April 20, 2013 [Page 8] From rjh at sixdemonbag.org Thu Dec 13 01:57:23 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 12 Dec 2012 19:57:23 -0500 Subject: A Probabilistic Trust Model for GnuPG (2006) In-Reply-To: References: <1371764.14111355211590324.JavaMail.webmail@bluewin.ch> <50C7F3A4.8030702@sixdemonbag.org> Message-ID: <50C927F3.5060403@sixdemonbag.org> On 12/12/2012 7:29 AM, Nicholas Cole wrote: > In fact, the OpenPGP standard DOES allow for fine-grained levels of > trust, or could be easily extended to do so My understanding is it's the latter. Yes, it could be easily extended, but that extension would break interoperability with every other implementation that doesn't grok this. Further, some implementations (*coughcough* PGP *cough*) are damn near hostile to the idea of any kind of gradations: look at how many hoops you have to jump through in order to give any kind of certification other than "generic". So, yeah. The proposal breaks interop, and for that reason alone (IMO) deserves to be put on the shelf. As near as I can tell it solves a problem that doesn't exist and does it in a way that breaks interop. All it needs to do in addition is raise my taxes and it's the hat trick of badness. From gniibe at fsij.org Thu Dec 13 06:02:13 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 13 Dec 2012 14:02:13 +0900 Subject: SCD: no keys detected after key import / key generation In-Reply-To: <1355292204.8285.3.camel@cfw2.gniibe.org> References: <1355292204.8285.3.camel@cfw2.gniibe.org> Message-ID: <1355374933.14880.0.camel@cfw2.gniibe.org> fOn 2012-12-12 at 15:03 +0900, NIIBE Yutaka wrote: > My theory is that something like following fixes this issue. After > testing, I will commit this change both of master and > STABLE-BRANCH-2-0. I tested and confirmed that the patch fixes the issue. Applied the patch to both branches (and pushed to both). -- From wk at gnupg.org Thu Dec 13 10:26:09 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Dec 2012 10:26:09 +0100 Subject: SHA3 IANA registration - method? In-Reply-To: <50C8F274.2050701@brainhub.org> (Andrey Jivsov's message of "Wed, 12 Dec 2012 13:09:08 -0800") References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> Message-ID: <878v92cngu.fsf@vigenere.g10code.de> On Wed, 12 Dec 2012 22:09, openpgp at brainhub.org said: > I wrote a draft to support SHA-3 Keccak in OpenPGP. Did I missed something or has SHA-3 already been finalzied? IIRC, NIST has no final specification yet. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From abel at guardianproject.info Thu Dec 13 14:39:25 2012 From: abel at guardianproject.info (Abel Luck) Date: Thu, 13 Dec 2012 13:39:25 +0000 Subject: remaining gnupg changes for Android support In-Reply-To: <87ehjy7uo4.fsf@gnupg.org> References: <87ip9a7v78.fsf@gnupg.org> <87ehjy7uo4.fsf@gnupg.org> Message-ID: <50C9DA8D.8000208@guardianproject.info> Werner Koch: > Here we go: > This commit works! Sorry for the huge delay, I applied it months ago and forgot to let you know. Could we get it merged? Thanks ~abel >>From a1fa77e34574b309b20fa2b1ef8be5d56e59c66f Mon Sep 17 00:00:00 2001 > From: Werner Koch > Date: Mon, 12 Nov 2012 15:18:49 +0100 > Subject: [PATCH] utf8conv.c: Add hacks for Android. > > * common/utf8conv.c [HAVE_ANDROID_SYSTEM]: Do not include iconv.h. > (iconv_open, iconv_close, load_libiconv) [HAVE_ANDROID_SYSTEM]: New > dummy functions. > (set_native_charset) [HAVE_ANDROID_SYSTEM]: Force use of "utf-8". > (jnlib_iconv_open) [HAVE_ANDROID_SYSTEM]: Act the same as under W32. > (jnlib_iconv) [HAVE_ANDROID_SYSTEM]: Ditto. > (jnlib_iconv_close) [HAVE_ANDROID_SYSTEM]: Ditto. > -- > > Co-authored-by: Hans of Guardian > --- > common/utf8conv.c | 69 ++++++++++++++++++++++++++++++++++++++++++---------- > 1 files changed, 55 insertions(+), 14 deletions(-) > > diff --git a/common/utf8conv.c b/common/utf8conv.c > index 1d64933..a45bb63 100644 > --- a/common/utf8conv.c > +++ b/common/utf8conv.c > @@ -38,7 +38,7 @@ > #include > #endif > #include > -#ifndef HAVE_W32_SYSTEM > +#if !defined HAVE_W32_SYSTEM && !defined HAVE_ANDROID_SYSTEM > # include > #endif > > @@ -56,9 +56,48 @@ static int no_translation; /* Set to true if we let simply pass through. */ > static int use_iconv; /* iconv comversion fucntions required. */ > > > +#ifdef HAVE_ANDROID_SYSTEM > +/* Fake stuff to get things building. */ > +typedef void *iconv_t; > +#define ICONV_CONST > + > +static iconv_t > +iconv_open (const char *tocode, const char *fromcode) > +{ > + (void)tocode; > + (void)fromcode; > + return (iconv_t)(-1); > +} > + > +static size_t > +iconv (iconv_t cd, char **inbuf, size_t *inbytesleft, > + char **outbuf, size_t *outbytesleft) > +{ > + (void)cd; > + (void)inbuf; > + (void)inbytesleft; > + (void)outbuf; > + (void)outbytesleft; > + return (size_t)(0); > +} > + > +static int > +iconv_close (iconv_t cd) > +{ > + (void)cd; > + return 0; > +} > + > + > +static int > +load_libiconv (void) > +{ > + return -1; > +} > + > +#elif defined HAVE_W32_SYSTEM > /* Under W32 we dlopen the iconv dll and don't require any iconv > related headers at all. However we need to define some stuff. */ > -#ifdef HAVE_W32_SYSTEM > typedef void *iconv_t; > #ifndef ICONV_CONST > #define ICONV_CONST > @@ -170,7 +209,9 @@ set_native_charset (const char *newset) > > if (!newset) > { > -#ifdef HAVE_W32_SYSTEM > +#ifdef HAVE_ANDROID_SYSTEM > + newset = "utf-8"; > +#elif defined HAVE_W32_SYSTEM > static char codepage[30]; > unsigned int cpno; > const char *aliases; > @@ -218,7 +259,7 @@ set_native_charset (const char *newset) > } > } > > -#else /*!HAVE_W32_SYSTEM*/ > +#else /*!HAVE_W32_SYSTEM && !HAVE_ANDROID_SYSTEM*/ > > #ifdef HAVE_LANGINFO_CODESET > newset = nl_langinfo (CODESET); > @@ -252,7 +293,7 @@ set_native_charset (const char *newset) > } > newset = codepage; > #endif /*!HAVE_LANGINFO_CODESET*/ > -#endif /*!HAVE_W32_SYSTEM*/ > +#endif /*!HAVE_W32_SYSTEM && !HAVE_ANDROID_SYSTEM*/ > } > > full_newset = newset; > @@ -291,10 +332,10 @@ set_native_charset (const char *newset) > { > iconv_t cd; > > -#ifdef HAVE_W32_SYSTEM > +#if defined HAVE_W32_SYSTEM || defined HAVE_ANDROID_SYSTEM > if (load_libiconv ()) > return -1; > -#endif /*HAVE_W32_SYSTEM*/ > +#endif /*HAVE_W32_SYSTEM || HAVE_ANDROID_SYSTEM*/ > > cd = iconv_open (full_newset, "utf-8"); > if (cd == (iconv_t)-1) > @@ -717,10 +758,10 @@ utf8_to_native (const char *string, size_t length, int delim) > jnlib_iconv_t > jnlib_iconv_open (const char *tocode, const char *fromcode) > { > -#ifdef HAVE_W32_SYSTEM > +#if defined HAVE_W32_SYSTEM || defined HAVE_ANDROID_SYSTEM > if (load_libiconv ()) > return (jnlib_iconv_t)(-1); > -#endif /*HAVE_W32_SYSTEM*/ > +#endif /*HAVE_W32_SYSTEM || HAVE_ANDROID_SYSTEM*/ > > return (jnlib_iconv_t)iconv_open (tocode, fromcode); > } > @@ -734,10 +775,10 @@ jnlib_iconv (jnlib_iconv_t cd, > char **outbuf, size_t *outbytesleft) > { > > -#ifdef HAVE_W32_SYSTEM > +#if defined HAVE_W32_SYSTEM || defined HAVE_ANDROID_SYSTEM > if (load_libiconv ()) > return 0; > -#endif /*HAVE_W32_SYSTEM*/ > +#endif /*HAVE_W32_SYSTEM || HAVE_ANDROID_SYSTEM*/ > > return iconv ((iconv_t)cd, (char**)inbuf, inbytesleft, outbuf, outbytesleft); > } > @@ -747,10 +788,10 @@ jnlib_iconv (jnlib_iconv_t cd, > int > jnlib_iconv_close (jnlib_iconv_t cd) > { > -#ifdef HAVE_W32_SYSTEM > +#if defined HAVE_W32_SYSTEM || defined HAVE_ANDROID_SYSTEM > if (load_libiconv ()) > return 0; > -#endif /*HAVE_W32_SYSTEM*/ > +#endif /*HAVE_W32_SYSTEM || HAVE_ANDROID_SYSTEM*/ > > return iconv_close ((iconv_t)cd); > } > @@ -826,4 +867,4 @@ utf8_to_wchar (const char *string) > } > return result; > } > -#endif /*HAVE_W32_SYSTEM*/ > +#endif /*HAVE_W32_SYSTEM || HAVE_ANDROID_SYSTEM*/ > From bernhard at intevation.de Thu Dec 13 16:09:19 2012 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 13 Dec 2012 16:09:19 +0100 Subject: Sponsor Werner's work! (Re: ECDSA support for GnuPG's ssh-agent.) In-Reply-To: <87hanrjg44.fsf@rho.meyering.net> References: <87txrrcg2o.fsf@vigenere.g10code.de> <87hanrjg44.fsf@rho.meyering.net> Message-ID: <201212131609.27571.bernhard@intevation.de> Am Mittwoch, 12. Dezember 2012 19:10:51 schrieb Jim Meyering: > Werner Koch wrote: > > master has now support for ECDSA keys for the ssh-agent protocol. > > Wow. ?That was quick. ?Ask and ye shall receive :-) > Thanks for the awesome support! If you like Werner's work for Free Software, spread the word about his company www.g10code.com: "g10code is the driving force behind the development of the GNU Privacy Guard (GnuPG) and related software. [..] If you are using GnuPG to secure your data - either on server based systems or for example by email applications on the desktop - it is in your own interest to keep this software alive and well maintained. You can help GnuPG and thus yourself by: Sponsoring the development [1] Purchasing a support contract Engaging us for custom enhancements """ [1] http://g10code.com/gnupg-donation.html Join the 28 sponsors of 2012! -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Thu Dec 13 16:47:27 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 13 Dec 2012 10:47:27 -0500 Subject: SHA3 IANA registration - method? In-Reply-To: <50C8F274.2050701@brainhub.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> Message-ID: <4C6AFF5F-6FC8-4875-836B-6D2FF3B258EA@jabberwocky.com> On Dec 12, 2012, at 4:09 PM, Andrey Jivsov wrote: > I wrote a draft to support SHA-3 Keccak in OpenPGP. > > I slowed down thinking about what to do about SHA1 fingerprints before I was distracted by unrelated things. My thought was that perhaps this draft should be used to resolve the issue of a SHA1 fingerprint by introducing a hardwired Keccac fingerprint. > > Ignoring the fingerprint issue, the rest of the spec should be straighforward. I am attaching the document that I created. I'm pretty against combining the fingerprint issue and SHA-3. They're not really related, and combining them just ensures that the SHA-3 draft (which should be trivial and noncontroversial) will take many months if not longer. Changing fingerprints touches a huge amount of deployed code and needs careful design, but SHA-3 just needs an algorithm number allocated. I'm all for a SHA-3 draft on its own, but is SHA-3 in a state where a draft is appropriate? There is no OID yet, and there is no RFC to refer to (there isn't even a NIST spec to refer to). I'd wait a little while until these things are finished, and then the OpenPGP SHA-3 draft can just point to them. David From wk at gnupg.org Thu Dec 13 17:07:37 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Dec 2012 17:07:37 +0100 Subject: SHA3 IANA registration - method? In-Reply-To: <4C6AFF5F-6FC8-4875-836B-6D2FF3B258EA@jabberwocky.com> (David Shaw's message of "Thu, 13 Dec 2012 10:47:27 -0500") References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <4C6AFF5F-6FC8-4875-836B-6D2FF3B258EA@jabberwocky.com> Message-ID: <8738zaaqba.fsf@vigenere.g10code.de> On Thu, 13 Dec 2012 16:47, dshaw at jabberwocky.com said: > I'm pretty against combining the fingerprint issue and SHA-3. They're > not really related, and combining them just ensures that the SHA-3 > draft (which should be trivial and noncontroversial) will take many Right. It is even not clear that SHA-3 will ever be used. Even NIST seems to view SHA-3 as a kind of fallback solution. Given that hardware is only slowly integrating SHA-2 engines, I doubt that we will see SHA-3 engines any time soon. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 13 17:11:50 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Dec 2012 17:11:50 +0100 Subject: remaining gnupg changes for Android support In-Reply-To: <50C9DA8D.8000208@guardianproject.info> (Abel Luck's message of "Thu, 13 Dec 2012 13:39:25 +0000") References: <87ip9a7v78.fsf@gnupg.org> <87ehjy7uo4.fsf@gnupg.org> <50C9DA8D.8000208@guardianproject.info> Message-ID: <87vcc69bjt.fsf@vigenere.g10code.de> On Thu, 13 Dec 2012 14:39, abel at guardianproject.info said: > This commit works! Sorry for the huge delay, I applied it months ago and > forgot to let you know. I forgot it too; I had this branch only on my laptop. > Could we get it merged? Done. 6177fb3. BTW, I merged the internal Git repo and the public one. Thus there should be no more delay. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 13 17:14:48 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Dec 2012 17:14:48 +0100 Subject: SCD: no keys detected after key import / key generation In-Reply-To: <1355292204.8285.3.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Wed, 12 Dec 2012 15:03:24 +0900") References: <1355292204.8285.3.camel@cfw2.gniibe.org> Message-ID: <87r4mu9bev.fsf@vigenere.g10code.de> On Wed, 12 Dec 2012 07:03, gniibe at fsij.org said: > My theory is that something like following fixes this issue. After > testing, I will commit this change both of master and > STABLE-BRANCH-2-0. Thanks for looking at it. I see whether I can backport it to 1.4 as well. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From zecapistolas at gmail.com Thu Dec 13 17:03:38 2012 From: zecapistolas at gmail.com (=?UTF-8?Q?Jos=C3=A9_Carlos_de_Campos?=) Date: Thu, 13 Dec 2012 16:03:38 +0000 Subject: Search keys on a keyserver with GPGME Message-ID: Hello everyone, I am developing a app that needs a interface to access to GnuPG, so I find the GPGME, and I am really happy with this choice. GPGME is really fantastic and very easy to use. But I have a problem which I cannot find the right solution. My app needs to search on a keyserver (anyone) for any public keys necessary. For example: "To send an encrypted file to someone, first myApp search on a keyserver for the keys that aren't in the keyring, import those keys and after that make the encryption." I have already this piece of code: // set protocol err = gpgme_set_protocol(ctx, GPGME_PROTOCOL_OpenPGP); // use GPGME_KEYLIST_MODE_EXTERN err = gpgme_set_keylist_mode (ctx, GPGME_KEYLIST_MODE_EXTERN); // start keylist err = gpgme_op_keylist_start (ctx, ID.c_str(), 0); while (!(err = gpgme_op_keylist_next (ctx, &key))) { printf ("keyid : %s\n", key->subkeys?nonnull (key->subkeys->keyid):"?"); } // stop keylist err = gpgme_op_keylist_end (ctx); but this doesn't return anything... How can I do this, how can I make a search on a keyserver using GPGME? -- Cheers, Z?Carlos From dkg at fifthhorseman.net Thu Dec 13 18:21:13 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 13 Dec 2012 12:21:13 -0500 Subject: SHA3 IANA registration - method? In-Reply-To: <878v92cngu.fsf@vigenere.g10code.de> References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <878v92cngu.fsf@vigenere.g10code.de> Message-ID: <50CA0E89.90301@fifthhorseman.net> On 12/13/2012 04:26 AM, Werner Koch wrote: > On Wed, 12 Dec 2012 22:09, openpgp at brainhub.org said: >> I wrote a draft to support SHA-3 Keccak in OpenPGP. > > Did I missed something or has SHA-3 already been finalzied? IIRC, NIST > has no final specification yet. As of 2012-10-02, SHA-3 is KECCAK: http://www.nist.gov/itl/csd/sha-100212.cfm https://en.wikipedia.org/wiki/SHA-3 Regards, --dkg From dshaw at jabberwocky.com Thu Dec 13 19:30:11 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 13 Dec 2012 13:30:11 -0500 Subject: SHA3 IANA registration - method? In-Reply-To: <50CA0E89.90301@fifthhorseman.net> References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <878v92cngu.fsf@vigenere.g10code.de> <50CA0E89.90301@fifthhorseman.net> Message-ID: On Dec 13, 2012, at 12:21 PM, Daniel Kahn Gillmor wrote: > On 12/13/2012 04:26 AM, Werner Koch wrote: >> On Wed, 12 Dec 2012 22:09, openpgp at brainhub.org said: >>> I wrote a draft to support SHA-3 Keccak in OpenPGP. >> >> Did I missed something or has SHA-3 already been finalzied? IIRC, NIST >> has no final specification yet. > > As of 2012-10-02, SHA-3 is KECCAK: > > http://www.nist.gov/itl/csd/sha-100212.cfm > > https://en.wikipedia.org/wiki/SHA-3 There is no SHA-3 document akin to the SHA-2 FIPS 180-2 yet. David From ldv at altlinux.org Thu Dec 13 21:01:14 2012 From: ldv at altlinux.org (Dmitry V. Levin) Date: Fri, 14 Dec 2012 00:01:14 +0400 Subject: [PATCH] Fix potential heap corruption in "gpg -v --version" In-Reply-To: <87hapc8e7m.fsf@vigenere.g10code.de> References: <20121026221247.GA18127@altlinux.org> <87d303c19b.fsf@vigenere.g10code.de> <20121027200724.GA26481@altlinux.org> <87hapc8e7m.fsf@vigenere.g10code.de> Message-ID: <20121213200114.GA3751@altlinux.org> On Tue, Oct 30, 2012 at 11:08:13AM +0100, Werner Koch wrote: > On Sat, 27 Oct 2012 22:07, ldv at altlinux.org said: > > > In multibyte locales translated strings are usually longer (in bytes) than > > in C locale. The 1st argument of build_list() is a translated string. > > Okay, that is the keyword which makes it clear. > > > Besides that, build_list() does other funny things with memory allocation > > and string operations, e.g. its only purpose of doing "xmalloc( 21 + n )" > > is confusing an observer because it doesn't need these extra 21 bytes, > > I'll look at this too. Is there any progress with the fix? -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From JPClizbe at tx.rr.com Thu Dec 13 19:40:57 2012 From: JPClizbe at tx.rr.com (John Clizbe) Date: Thu, 13 Dec 2012 12:40:57 -0600 Subject: SHA3 IANA registration - method? In-Reply-To: <50CA0E89.90301@fifthhorseman.net> References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <878v92cngu.fsf@vigenere.g10code.de> <50CA0E89.90301@fifthhorseman.net> Message-ID: <50CA2139.4060106@tx.rr.com> Daniel Kahn Gillmor wrote: > On 12/13/2012 04:26 AM, Werner Koch wrote: >> On Wed, 12 Dec 2012 22:09, openpgp at brainhub.org said: >>> I wrote a draft to support SHA-3 Keccak in OpenPGP. >> >> Did I missed something or has SHA-3 already been finalzied? IIRC, NIST >> has no final specification yet. > > As of 2012-10-02, SHA-3 is KECCAK: > > http://www.nist.gov/itl/csd/sha-100212.cfm > > https://en.wikipedia.org/wiki/SHA-3 Indeed, however the governing standard document, FIPS 180-4, has yet to be updated. It was last revised in March, 2012. http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf Other references also still updating, an OID needs assigned, etc... Having an algorithm alone does not a standard make. NIST doesn't appear to be in a hurry, why should we jump the gun? Wait for FIPS 180-5. -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From openpgp at brainhub.org Thu Dec 13 21:46:51 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Thu, 13 Dec 2012 12:46:51 -0800 Subject: SHA3 IANA registration - method? In-Reply-To: References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <878v92cngu.fsf@vigenere.g10code.de> <50CA0E89.90301@fifthhorseman.net> Message-ID: <50CA3EBB.6060901@brainhub.org> Yes, there is no FIPS document that specifies the SHA-3 yet. We should expect that NIST will be produce it a few months; it is mostly an editorial matter at this point. There are test vectors on http://keccak.noekeon.org/ that should continue to work. The main unknown that the FIPS document will solve is which hash sizes it will decide to mandate, plus, the fact that we need a hard reference to list in the OpenPGP Keccak spec. We also need to wait for the OIDs for the hash algorithms (remember that's what we do in OpenPGP). These dependencies are listed on the front page of the spec I sent. If there is no interest to fix collision weakness of OpenPGP fingerprints in the same spec, this makes things easier. The issue in my mind is that OpenPFP fingerprint and SHA-3 may be dependent if the OpenPGP community is to adapt the hardwired SHA-3 fingerprints. In this case we would have two methods: old/new SHA-1/SHA-3 fingerprints. With this situation one would need to differentiate/optimize regarding which fingerprint to use and so things like hash preferences on the keys may play some role here. While I also agree that SHA-3 in OpenPGP should only be concerned with SHA-3, it would be ideal if we wrote it with good ideas for the direction in which fingerprints will evolve. Thank you From wk at gnupg.org Fri Dec 14 12:24:30 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 14 Dec 2012 12:24:30 +0100 Subject: SHA3 IANA registration - method? In-Reply-To: <50CA3EBB.6060901@brainhub.org> (Andrey Jivsov's message of "Thu, 13 Dec 2012 12:46:51 -0800") References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <878v92cngu.fsf@vigenere.g10code.de> <50CA0E89.90301@fifthhorseman.net> <50CA3EBB.6060901@brainhub.org> Message-ID: <8738z8anbl.fsf@vigenere.g10code.de> On Thu, 13 Dec 2012 21:46, openpgp at brainhub.org said: > fingerprints in the same spec, this makes things easier. The issue in > my mind is that OpenPFP fingerprint and SHA-3 may be dependent if the > OpenPGP community is to adapt the hardwired SHA-3 fingerprints. In Which has not even be discussed. Back when the SHA-3 process started we said that we will wait for the outcome of it and only then start working on a a new key format. Whether this will use SHA-3 or SHA-2 needs to to discussed. Given that there is no real world experience with SHA-3, we can't assume anything at that point. And if we want to do go for a new key format I am in favor of rechartering the WG than to have the IETF decide on individual I-Ds for such changes. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From openpgp at brainhub.org Fri Dec 14 18:55:46 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Fri, 14 Dec 2012 09:55:46 -0800 Subject: SHA3 IANA registration - method? In-Reply-To: <8738z8anbl.fsf@vigenere.g10code.de> References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <878v92cngu.fsf@vigenere.g10code.de> <50CA0E89.90301@fifthhorseman.net> <50CA3EBB.6060901@brainhub.org> <8738z8anbl.fsf@vigenere.g10code.de> Message-ID: <50CB6822.8000503@brainhub.org> On 12/14/2012 03:24 AM, Werner Koch wrote: > On Thu, 13 Dec 2012 21:46, openpgp at brainhub.org said: > >> fingerprints in the same spec, this makes things easier. The issue in >> my mind is that OpenPFP fingerprint and SHA-3 may be dependent if the >> OpenPGP community is to adapt the hardwired SHA-3 fingerprints. In > > Which has not even be discussed. Back when the SHA-3 process started we > said that we will wait for the outcome of it and only then start working > on a a new key format. Whether this will use SHA-3 or SHA-2 needs to to > discussed. Given that there is no real world experience with SHA-3, we > can't assume anything at that point. And if we want to do go for a new > key format I am in favor of rechartering the WG than to have the IETF > decide on individual I-Ds for such changes. The new key format is a much broader task. Perhaps I wasn't clear on what motivated my comments on fingerprints. What I meant came as a result of my review of the hash use in RFC 4880, done in the process of writing the SHA3 draft that I sent out (this analysis is summarized in the spec). My focus was of the weakening of security due of the SHA1 and its deprecation by standard bodies. The use of fingerprints in OpenPGP should be viewed as dependent on collision resistance of the hash function, in our case, unfortunately, on the collision resistance of the SHA1 without the path to upgrade the hash algorithm. Ideally, we should plan ahead and have some solution that can be slowly introduced. With this in mind I thought that it would be reasonable to deal with this shorter term problem in fingerprints as a separate task. Rewriting the key format seems like a bigger undertaking and I am not sure that there is much demand for the new key format. In any case, we can wait with new format longer than with SHA-1 deprecation. Thank you. From dkg at fifthhorseman.net Fri Dec 14 19:11:37 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 14 Dec 2012 13:11:37 -0500 Subject: SHA3 IANA registration - method? In-Reply-To: <50CB6822.8000503@brainhub.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <878v92cngu.fsf@vigenere.g10code.de> <50CA0E89.90301@fifthhorseman.net> <50CA3EBB.6060901@brainhub.org> <8738z8anbl.fsf@vigenere.g10code.de> <50CB6822.8000503@brainhub.org> Message-ID: <50CB6BD9.1000202@fifthhorseman.net> On 12/14/2012 12:55 PM, Andrey Jivsov wrote: > The use of fingerprints in OpenPGP > should be viewed as dependent on collision resistance of the hash > function, My recollection from the review and discussion i participated in was that the OpenPGP fingerprint's security was dependent on the preimage resistance of the hash function, not on the collision resistance. If that's correct, OpenPGP should be OK on the fingerprint for a while yet (modulo some organizations that just want to be rid of "old" digest algorithms without understanding the nuances in where they're used). Can you describe an attack that might show how weak collision resistance could compromise the fingerprint? Regards, --dkg From openpgp at brainhub.org Fri Dec 14 19:32:58 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Fri, 14 Dec 2012 10:32:58 -0800 Subject: SHA3 IANA registration - method? In-Reply-To: <50CB6BD9.1000202@fifthhorseman.net> References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <878v92cngu.fsf@vigenere.g10code.de> <50CA0E89.90301@fifthhorseman.net> <50CA3EBB.6060901@brainhub.org> <8738z8anbl.fsf@vigenere.g10code.de> <50CB6822.8000503@brainhub.org> <50CB6BD9.1000202@fifthhorseman.net> Message-ID: <50CB70DA.4030808@brainhub.org> On 12/14/2012 10:11 AM, Daniel Kahn Gillmor wrote: > On 12/14/2012 12:55 PM, Andrey Jivsov wrote: >> The use of fingerprints in OpenPGP >> should be viewed as dependent on collision resistance of the hash >> function, > > My recollection from the review and discussion i participated in was > that the OpenPGP fingerprint's security was dependent on the preimage > resistance of the hash function, not on the collision resistance. > > If that's correct, OpenPGP should be OK on the fingerprint for a while > yet (modulo some organizations that just want to be rid of "old" digest > algorithms without understanding the nuances in where they're used). > > Can you describe an attack that might show how weak collision resistance > could compromise the fingerprint? Here is one scenario. I generate two keys A,B with the same fingerprint. I provide the key A to another party. Another party encrypts a message to me using this key. At some later point that party deletes the key A, but diligently keeps the audit log that states that the fingerprint of the key A was used to encrypt a message to me. After all, the key was initially trusted by its fingerprint, so it seems OK to only save the fingerprint. From this point I can claim repudiation (aka an alibi), stating that the sender has never properly encrypted the message to me that I could have ever read. Here is my key (B) with the same fingerprint that matches the one that the server has but this key doesn't decrypt the message. From mail_kb at yahoo.com Fri Dec 14 20:50:02 2012 From: mail_kb at yahoo.com (KB Sriram) Date: Fri, 14 Dec 2012 11:50:02 -0800 (PST) Subject: Import manipulated public key, gpg 1.4.11 corrupts database [1445] Message-ID: <1355514602.51381.YahooMailNeo@web125806.mail.ne1.yahoo.com> A quick ping to the list about?https://bugs.g10code.com/gnupg/issue1455?(filed about a week back.) The summary is that one can craft a public key that causes gpg --import to corrupt its pubring.gpg database, at which point most subsequent gpg operations (including --delete-key) fail. Also, just running gpg without importing it (specifically: "gpg thebadkey.gpg") shows no errors and an apparently valid key. It's at least a nuisance as the database has to be restored manually from pubring.pgp~, and I also don't know whether other tools that use gpg in the background expose an obvious way to restore the database. (Might there be additional complications if such keys were published via keyservers?) At any rate, thought I'd point to this issue in the mailing list as well, in case it is a real problem (and my apologies if someone has already looked at it and just not updated the status -- it says 'unread' at the moment.) Best regards, -kb From mailinglisten at hauke-laging.de Fri Dec 14 22:53:15 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 14 Dec 2012 22:53:15 +0100 Subject: SHA3 IANA registration - method? In-Reply-To: <50CB70DA.4030808@brainhub.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50CB6BD9.1000202@fifthhorseman.net> <50CB70DA.4030808@brainhub.org> Message-ID: <3035659.KHhMZOD6SR@inno> Am Fr 14.12.2012, 10:32:58 schrieb Andrey Jivsov: > I generate two keys A,B with the same fingerprint. And how are you going to do that? It's not enough to have two values with the same hash. These values (one is trivial) have to form valid key parameters. Otherwise you are not even capable of creating a valid self signature. The attack against X.509 certificates is easier as the hash refers to the whole certificate. Much more data to play with. > I provide the key A > to another party. Another party encrypts a message to me using this key. > > At some later point that party deletes the key A So does the other party? > Here is my key (B) with the same fingerprint that > matches the one that the server has but this key doesn't decrypt the > message. This only works if 1) no-one (including the keyservers) has a copy of the key left 2) the key material is formally correct 3) the key material is not bullshit (something that no software would create) So assuming a possible collision for SHA-1, how many collisions do you need to meet (2) and (3)? Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From openpgp at brainhub.org Sat Dec 15 02:32:16 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Fri, 14 Dec 2012 17:32:16 -0800 Subject: SHA3 IANA registration - method? In-Reply-To: <3035659.KHhMZOD6SR@inno> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50CB6BD9.1000202@fifthhorseman.net> <50CB70DA.4030808@brainhub.org> <3035659.KHhMZOD6SR@inno> Message-ID: <50CBD320.9090706@brainhub.org> On 12/14/2012 01:53 PM, Hauke Laging wrote: > Am Fr 14.12.2012, 10:32:58 schrieb Andrey Jivsov: > >> I generate two keys A,B with the same fingerprint. > > And how are you going to do that? It's not enough to have two values with the > same hash. These values (one is trivial) have to form valid key parameters. > Otherwise you are not even capable of creating a valid self signature. The > attack against X.509 certificates is easier as the hash refers to the whole > certificate. Much more data to play with. > I answered the question: "Can you describe an attack that might show how weak collision resistance could compromise the fingerprint?" How practical this attack is a separate question and it requires much deeper analysts. It would depend on the ability to find collisions by choosing primes, dates, header sizes, selected by the attacker. Remember that we start from 80bit security by birthday bounds even when we simply randomly generate keys (for a perfect 160 bit hash function). By the same token collision for ASCII documents is also not as easy as for arbitrary binary data. Same for colliding ISO images (with the intent is to create malicious code). BTW, it's common to have a separate encryption-only subkey that doesn't need to sign anything. > >> I provide the key A >> to another party. Another party encrypts a message to me using this key. >> >> At some later point that party deletes the key A > > So does the other party? Do you mean the owner? Correct, the owner who generated keys A and B removes the incriminating key A. He will be claiming that he never had the key A. The key A need to disappear from caches. A and B in my description can be subkeys. > > >> Here is my key (B) with the same fingerprint that >> matches the one that the server has but this key doesn't decrypt the >> message. > > This only works if > > 1) no-one (including the keyservers) has a copy of the key left If you can keep everything that you signed (or hashed), you don't depend on collision resistance. The OpenPGP ecosystem uses fingerprints as a shortcut for keys quite extensively. > 2) the key material is formally correct > 3) the key material is not bullshit (something that no software would create) Yes, indeed, you have to produce the colliding pre-images that are appear valid to software tests. This is true for any attack on the collision resistance. Does every OpenPGP software test validity of every public keys? > So assuming a possible collision for SHA-1, how many collisions do you need to > meet (2) and (3)? Now let's ask ourselves: given what I said, would you be able to convince jurors about non-repudiation nature of a protocol that uses SHA-1 fingerprints? Would you feel better if it was, say, truncated P-256 or Keccak? Regardless of practicality of the attacks, at some point OpenPGP fingerprints will start to be flagged by a black box audit based on the answer to "Do you use SHA-1 in applications that depend on collision resistance?". What do I personally hope for here? A think a solution that introduces a hardcoded Keccak fingerprint in the scope of RFC 4880 would be ideal, IMO. This assumes very slow adoption of this new alternative method. Thank you. From wk at gnupg.org Sat Dec 15 10:32:14 2012 From: wk at gnupg.org (Werner Koch) Date: Sat, 15 Dec 2012 10:32:14 +0100 Subject: SHA3 IANA registration - method? In-Reply-To: <50CB70DA.4030808@brainhub.org> (Andrey Jivsov's message of "Fri, 14 Dec 2012 10:32:58 -0800") References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <878v92cngu.fsf@vigenere.g10code.de> <50CA0E89.90301@fifthhorseman.net> <50CA3EBB.6060901@brainhub.org> <8738z8anbl.fsf@vigenere.g10code.de> <50CB6822.8000503@brainhub.org> <50CB6BD9.1000202@fifthhorseman.net> <50CB70DA.4030808@brainhub.org> Message-ID: <87d2yb7ja9.fsf@vigenere.g10code.de> On Fri, 14 Dec 2012 19:32, openpgp at brainhub.org said: > From this point I can claim repudiation (aka an alibi), stating that > the sender has never properly encrypted the message to me that I could > have ever read. Here is my key (B) with the same fingerprint that The non-repudiation capability of an enryption system is hard to implement and to deploy. I am not sure whether OpenPGP may claim to support it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Dec 15 11:29:44 2012 From: wk at gnupg.org (Werner Koch) Date: Sat, 15 Dec 2012 11:29:44 +0100 Subject: [PATCH] Fix potential heap corruption in "gpg -v --version" In-Reply-To: <20121213200114.GA3751@altlinux.org> (Dmitry V. Levin's message of "Fri, 14 Dec 2012 00:01:14 +0400") References: <20121026221247.GA18127@altlinux.org> <87d303c19b.fsf@vigenere.g10code.de> <20121027200724.GA26481@altlinux.org> <87hapc8e7m.fsf@vigenere.g10code.de> <20121213200114.GA3751@altlinux.org> Message-ID: <874njn7gmf.fsf@vigenere.g10code.de> On Thu, 13 Dec 2012 21:01, ldv at altlinux.org said: > Is there any progress with the fix? Thanks for reminding. I just pushed a patch for 1.4. 2.0 and master will follow. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christian at quelltextlich.at Sat Dec 15 15:03:01 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sat, 15 Dec 2012 15:03:01 +0100 Subject: Fingerprint algorithm and SHA-1 usage [was: Re: SHA3 IANA registration - method?] In-Reply-To: <50CBD320.9090706@brainhub.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50CB6BD9.1000202@fifthhorseman.net> <50CB70DA.4030808@brainhub.org> <3035659.KHhMZOD6SR@inno> <50CBD320.9090706@brainhub.org> Message-ID: <20121215140301.GA5409@quelltextlich.at> Hi Andrey, On Fri, Dec 14, 2012 at 05:32:16PM -0800, Andrey Jivsov wrote: > The OpenPGP ecosystem uses fingerprints as a > shortcut for keys quite extensively. for whatever "OpenPGP ecosystem" means to you :-) IIRC, in RFC 4880 the fingerprint is used as "a shortcut for keys" only once [1] -- and the corresponding subpacket is not even mandatory. I would not call that "quite extensively". Part of the SHA-1 fingerprint also makes up the key id. But that can even less be expected to be unique. And it's useful only as sieve for keys (to limit the keys you have to check) than a unique handle to a key. So for whatever software or practice [2] you employ that mistakes fingerprints for unique key identifiers, fix that software or practice -- it's not the flaw of RFC 4880. Indeed SHA-1 /fingerprints/ are not a problem. As they are effectively not used in RFC 4880, it's up to us?the users and software developers?if we use them or what we use them for. We can switch at will [3]. The problem is rather SHA-1 than fingerprints. And OpenPGP also uses SHA-1 for other things than fingerprints as well. RFC 4880 forces SHA-1 usage also in * ? 5.5.3 Secret-Key Packet Formats (usage 254) * ? 5.14 Modification Detection Code Packet Fortunately, SHA-1 in those packets does not do much harm. But it shows that, we do not get rid of SHA-1 by only changing the OpenPGP fingerprint algorithm. Furthermore, eight other packet types allow to set the used hash algorithm. But as SHA-1 is the only mandatory hashing algorithm, we may resort to using it, when trying to provide maximal interoperability within RFC 4880. So if we want to avoid SHA-1 (and I am all for it), we'd rather change "Let's see how to change the fingerprint algorithm." to "Let's avoid SHA-1" . And it's actually easy. > What do I personally hope for here? A think a solution that introduces > a hardcoded Keccak fingerprint in the scope of RFC 4880 would be ideal, I tend do disagree. As said above switching the fingerprint algorithms, does not eliminate SHA-1 from OpenPGP. But even if. Forcing the fingerprint algorithm allows for effortless interoperability, but it limits the users' freedom to avoid using algorithms within the specification's borders. Even worse: as soon as the chosen algorithm is broken (for whatever value of broken), dependent applications are probably affected/broken as well and they cannot switch away quickly. We'd end up being in the same situation as now -- only having traded SHA-1 by whatever algorithm we'd settle on. Best regards, Christian [1] "Revocation Key" subpackets. http://tools.ietf.org/rfcmarkup?doc=4880#section-5.2.3.15 And the key owner can decide for her-/himself whether she/he wants to add "Revocation Key" packets. [2] Yes, that includes typical key signing parties. [3] Shameless plug: You can for example allow others to avoid SHA-1 at key-signing parties, by adding additional (non-standard) SHA-512 fingerprints to your paper slips: http://openpgp.quelltextlich.at/slip.html?key=8421F11C&format=pdf&variant=SHA512,A4R,sparse as described here http://openpgp.quelltextlich.at/slip.html?query=0x8421F11C#faq-additional-digests -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From openpgp at brainhub.org Mon Dec 17 08:28:13 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Sun, 16 Dec 2012 23:28:13 -0800 Subject: SHA3 IANA registration - method? In-Reply-To: <87d2yb7ja9.fsf@vigenere.g10code.de> References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <878v92cngu.fsf@vigenere.g10code.de> <50CA0E89.90301@fifthhorseman.net> <50CA3EBB.6060901@brainhub.org> <8738z8anbl.fsf@vigenere.g10code.de> <50CB6822.8000503@brainhub.org> <50CB6BD9.1000202@fifthhorseman.net> <50CB70DA.4030808@brainhub.org> <87d2yb7ja9.fsf@vigenere.g10code.de> Message-ID: <50CEC98D.8000107@brainhub.org> On 12/15/2012 01:32 AM, Werner Koch wrote: > On Fri, 14 Dec 2012 19:32, openpgp at brainhub.org said: > >> From this point I can claim repudiation (aka an alibi), stating that >> the sender has never properly encrypted the message to me that I could >> have ever read. Here is my key (B) with the same fingerprint that > The non-repudiation capability of an enryption system is hard to > implement and to deploy. I am not sure whether OpenPGP may claim to > support it. How about this signature repudiation: At some point I generated two keys with colliding fingerprints. I post the fingerprint of one key and the key itself on the website. I keep my second key for tough times ahead. At some point I sign a document, but get in troubles because of this signature and want to deny the signature. I quickly update the key file on the website. The key file was not cached by the search engines (by luck or my forward planning). It could be due to my luck because the key was in a directory that was excluded per my /robots.txt file. Fingerprint, however, was not (it was in the indexed html folder). Now my denial of the signature looks convincing: the fingerprint is correct and is exactly the one that was on my page at the alleged time of signing, but the signature doesn't verify. I hire 3d party experts to record the current state of things and will rely on their statement for the repudiation. ( Of course the accuser forgot to cache my old key. ) From dkg at fifthhorseman.net Mon Dec 17 15:23:44 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 17 Dec 2012 09:23:44 -0500 Subject: SHA3 IANA registration - method? In-Reply-To: <50CEC98D.8000107@brainhub.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <878v92cngu.fsf@vigenere.g10code.de> <50CA0E89.90301@fifthhorseman.net> <50CA3EBB.6060901@brainhub.org> <8738z8anbl.fsf@vigenere.g10code.de> <50CB6822.8000503@brainhub.org> <50CB6BD9.1000202@fifthhorseman.net> <50CB70DA.4030808@brainhub.org> <87d2yb7ja9.fsf@vigenere.g10code.de> <50CEC98D.8000107@brainhub.org> Message-ID: <50CF2AF0.7060407@fifthhorseman.net> On 12/17/2012 02:28 AM, Andrey Jivsov wrote: > Now my denial of the signature looks convincing: the fingerprint is > correct and is exactly the one that was on my page at the alleged time > of signing, but the signature doesn't verify. I hire 3d party experts to > record the current state of things and will rely on their statement for > the repudiation. > > ( Of course the accuser forgot to cache my old key. ) I'm unconvinced of this as a realistic threat. For one thing, all OpenPGP implementations i've seen cache keys by default. For another thing, if all the stars are aligned as you suggest, then all i need to do to repudiate it is simply remove the key in the first place. No key, no verification. So if we are to consider this a vulnerability, i don't think it is a problem that is solved by a more-collision-resistant fingerprint. So i'm still left with the sense that OpenPGP's key fingerprint mechanism is reliant on resistance to a pre-image attack, and is *not* concerned with its collision resistance. --dkg From openpgp at brainhub.org Mon Dec 17 21:22:11 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Mon, 17 Dec 2012 12:22:11 -0800 Subject: SHA3 IANA registration - method? In-Reply-To: <50CF2AF0.7060407@fifthhorseman.net> References: <20121212104620.GA35659@redoubt.spodhuis.org> <589B3D14-528A-4BB0-B59A-C3A280F0D797@jabberwocky.com> <50C8F274.2050701@brainhub.org> <878v92cngu.fsf@vigenere.g10code.de> <50CA0E89.90301@fifthhorseman.net> <50CA3EBB.6060901@brainhub.org> <8738z8anbl.fsf@vigenere.g10code.de> <50CB6822.8000503@brainhub.org> <50CB6BD9.1000202@fifthhorseman.net> <50CB70DA.4030808@brainhub.org> <87d2yb7ja9.fsf@vigenere.g10code.de> <50CEC98D.8000107@brainhub.org> <50CF2AF0.7060407@fifthhorseman.net> Message-ID: <50CF7EF3.1070600@brainhub.org> On 12/17/2012 06:23 AM, Daniel Kahn Gillmor wrote: > On 12/17/2012 02:28 AM, Andrey Jivsov wrote: >> Now my denial of the signature looks convincing: the fingerprint is >> correct and is exactly the one that was on my page at the alleged time >> of signing, but the signature doesn't verify. I hire 3d party experts to >> record the current state of things and will rely on their statement for >> the repudiation. >> >> ( Of course the accuser forgot to cache my old key. ) > > I'm unconvinced of this as a realistic threat. For one thing, all > OpenPGP implementations i've seen cache keys by default. The products that work as mail gateways can work with millions of user keys. These discovered keys are not cached indefinitely (I know one such a product). This is different from end-user products/usage model. > > For another thing, if all the stars are aligned as you suggest, then all > i need to do to repudiate it is simply remove the key in the first > place. No key, no verification. > > So if we are to consider this a vulnerability, i don't think it is a > problem that is solved by a more-collision-resistant fingerprint. > If we can count on removing the keys, the collision resistance has no opportunity to play out. Here we are discussing the issue from the somewhat academic point of view. The question is what additional problems creep in when fingerprints are not collision resistant. I don't think one has a convincing story in front of the court saying that he lost the key pair. > So i'm still left with the sense that OpenPGP's key fingerprint > mechanism is reliant on resistance to a pre-image attack, and is *not* > concerned with its collision resistance. Without special wording anywhere about weaknesses of fingerprints, OpenPGP fingerprints can be used in protocols that depend on collision resistance, as well as in protocols that don't. From mailinglisten at hauke-laging.de Mon Dec 17 22:57:58 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 17 Dec 2012 22:57:58 +0100 Subject: SHA3 IANA registration - method? In-Reply-To: <50CEC98D.8000107@brainhub.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <87d2yb7ja9.fsf@vigenere.g10code.de> <50CEC98D.8000107@brainhub.org> Message-ID: <4599875.rlaQdxBocv@inno> Am So 16.12.2012, 23:28:13 schrieb Andrey Jivsov: > ( Of course the accuser forgot to cache my old key. ) And how is he supposed to check the signature without having the key? Who would accuse anyone of anything without even being able to make a signature verification for himself? Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From openpgp at brainhub.org Mon Dec 17 23:05:32 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Mon, 17 Dec 2012 14:05:32 -0800 Subject: SHA3 IANA registration - method? In-Reply-To: <4599875.rlaQdxBocv@inno> References: <20121212104620.GA35659@redoubt.spodhuis.org> <87d2yb7ja9.fsf@vigenere.g10code.de> <50CEC98D.8000107@brainhub.org> <4599875.rlaQdxBocv@inno> Message-ID: <50CF972C.5080403@brainhub.org> On 12/17/2012 01:57 PM, Hauke Laging wrote: > Am So 16.12.2012, 23:28:13 schrieb Andrey Jivsov: > >> ( Of course the accuser forgot to cache my old key. ) > > And how is he supposed to check the signature without having the key? Who > would accuse anyone of anything without even being able to make a signature > verification for himself? > > > Hauke My description includes "I quickly update the key file on the website". That refers to the update with the second key with colliding fingerprint. From hans at guardianproject.info Mon Dec 17 23:12:13 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 17 Dec 2012 17:12:13 -0500 Subject: remaining gnupg changes for Android support In-Reply-To: <87vcc69bjt.fsf@vigenere.g10code.de> References: <87ip9a7v78.fsf@gnupg.org> <87ehjy7uo4.fsf@gnupg.org> <50C9DA8D.8000208@guardianproject.info> <87vcc69bjt.fsf@vigenere.g10code.de> Message-ID: <50CF98BD.4070400@guardianproject.info> On 12/13/2012 11:11 AM, Werner Koch wrote: > On Thu, 13 Dec 2012 14:39, abel at guardianproject.info said: > >> This commit works! Sorry for the huge delay, I applied it months ago and >> forgot to let you know. > > I forgot it too; I had this branch only on my laptop. > >> Could we get it merged? > > Done. 6177fb3. > > BTW, I merged the internal Git repo and the public one. Thus there > should be no more delay. > > > Salam-Shalom, > > Werner Ok, I updated the gnupg-for-android build to use the latest gnupg HEAD of master and removed my patch. The whole thing built, which is great news! That means nothing needs to be patched anymore to build for Android. Abel, could you try your pinentry stuff? .hc From openpgp at brainhub.org Mon Dec 17 23:16:21 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Mon, 17 Dec 2012 14:16:21 -0800 Subject: Fingerprint algorithm and SHA-1 usage [was: Re: SHA3 IANA registration - method?] In-Reply-To: <20121215140301.GA5409@quelltextlich.at> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50CB6BD9.1000202@fifthhorseman.net> <50CB70DA.4030808@brainhub.org> <3035659.KHhMZOD6SR@inno> <50CBD320.9090706@brainhub.org> <20121215140301.GA5409@quelltextlich.at> Message-ID: <50CF99B5.5040707@brainhub.org> On 12/15/2012 06:03 AM, Christian Aistleitner wrote: > Hi Andrey, > > On Fri, Dec 14, 2012 at 05:32:16PM -0800, Andrey Jivsov wrote: >> The OpenPGP ecosystem uses fingerprints as a >> shortcut for keys quite extensively. > > for whatever "OpenPGP ecosystem" means to you :-) > > IIRC, in RFC 4880 the fingerprint is used as "a shortcut for keys" > only once [1] -- and the corresponding subpacket is not even > mandatory. > I would not call that "quite extensively". > > Part of the SHA-1 fingerprint also makes up the key id. But that can > even less be expected to be unique. And it's useful only as sieve for > keys (to limit the keys you have to check) than a unique handle to a > key. > > So for whatever software or practice [2] you employ that mistakes > fingerprints for unique key identifiers, fix that software or > practice -- it's not the flaw of RFC 4880. > > > Indeed SHA-1 /fingerprints/ are not a problem. As they are effectively > not used in RFC 4880, it's up to us?the users and software > developers?if we use them or what we use them for. We can switch at > will [3]. > > > The problem is rather SHA-1 than fingerprints. And OpenPGP also uses > SHA-1 for other things than fingerprints as well. RFC 4880 forces > SHA-1 usage also in > * ? 5.5.3 Secret-Key Packet Formats (usage 254) > * ? 5.14 Modification Detection Code Packet > > Fortunately, SHA-1 in those packets does not do much harm. But it shows > that, we do not get rid of SHA-1 by only changing the OpenPGP > fingerprint algorithm. > > Furthermore, eight other packet types allow to set the used hash > algorithm. But as SHA-1 is the only mandatory hashing algorithm, we > may resort to using it, when trying to provide maximal > interoperability within RFC 4880. > > So if we want to avoid SHA-1 (and I am all for it), we'd rather change > "Let's see how to change the fingerprint algorithm." > to > "Let's avoid SHA-1" > . And it's actually easy. > > > >> What do I personally hope for here? A think a solution that introduces >> a hardcoded Keccak fingerprint in the scope of RFC 4880 would be ideal, > > I tend do disagree. > > As said above switching the fingerprint algorithms, does not > eliminate SHA-1 from OpenPGP. > > But even if. Forcing the fingerprint algorithm allows for effortless > interoperability, but it limits the users' freedom to avoid using > algorithms within the specification's borders. > > Even worse: as soon as the chosen algorithm is broken (for whatever > value of broken), dependent applications are probably affected/broken > as well and they cannot switch away quickly. > > We'd end up being in the same situation as now -- only having traded > SHA-1 by whatever algorithm we'd settle on. > > > Best regards, > Christian > > > [1] "Revocation Key" subpackets. > http://tools.ietf.org/rfcmarkup?doc=4880#section-5.2.3.15 > > And the key owner can decide for her-/himself whether she/he wants to add > "Revocation Key" packets. > > [2] Yes, that includes typical key signing parties. > > [3] Shameless plug: You can for example allow others to avoid SHA-1 at > key-signing parties, by adding additional (non-standard) SHA-512 > fingerprints to your paper slips: > http://openpgp.quelltextlich.at/slip.html?key=8421F11C&format=pdf&variant=SHA512,A4R,sparse > as described here > http://openpgp.quelltextlich.at/slip.html?query=0x8421F11C#faq-additional-digests > > > If I understand your proposal correctly, you are changing the hardwired SHA-1 fingerprint to SHA-512 without metadata/agility. I also favor this path (I was proposing to use Keccak for this to be future-proof, but this is the same general idea). Some work need to be done to take care of interoperability issues as far as when I see the fingerprint referenced, how do I calculate it (SHA-1 or using the new method)? I was not proposing to get rid of SHA-1 anywhere else, only in the single found place where we depend on collision resistance. The NIST SP 800 107 singles out SHA-1 for collision resistance usage. It's prohibiting the use of SHA-1 for digital signatures by the end of next year. With this in mind I am hoping for some (slow) process to update the fingerprints in OpenPGP. AFAIK, that's the only task that has some degree of urgency. Thank you. From mailinglisten at hauke-laging.de Mon Dec 17 23:20:12 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 17 Dec 2012 23:20:12 +0100 Subject: SHA3 IANA registration - method? In-Reply-To: <50CF972C.5080403@brainhub.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <4599875.rlaQdxBocv@inno> <50CF972C.5080403@brainhub.org> Message-ID: <1534234.5QBUm8ahIh@inno> Am Mo 17.12.2012, 14:05:32 schrieb Andrey Jivsov: > > And how is he supposed to check the signature without having the key? Who > > would accuse anyone of anything without even being able to make a > > signature > > verification for himself? > My description includes "I quickly update the key file on the website". > That refers to the update with the second key with colliding fingerprint. Sure but what difference does that make? The new key does not verify the signature. I think it boils down to the point that anyone who wants to make claims about a signature but does not store the respective public key is just plain stupid. This is not a technical problem. Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From openpgp at brainhub.org Tue Dec 18 00:21:08 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Mon, 17 Dec 2012 15:21:08 -0800 Subject: SHA3 IANA registration - method? In-Reply-To: <1534234.5QBUm8ahIh@inno> References: <20121212104620.GA35659@redoubt.spodhuis.org> <4599875.rlaQdxBocv@inno> <50CF972C.5080403@brainhub.org> <1534234.5QBUm8ahIh@inno> Message-ID: <50CFA8E4.2060502@brainhub.org> On 12/17/2012 02:20 PM, Hauke Laging wrote: > Am Mo 17.12.2012, 14:05:32 schrieb Andrey Jivsov: > >>> And how is he supposed to check the signature without having the key? Who >>> would accuse anyone of anything without even being able to make a >>> signature >>> verification for himself? > >> My description includes "I quickly update the key file on the website". >> That refers to the update with the second key with colliding fingerprint. > > Sure but what difference does that make? The new key does not verify the > signature. > > I think it boils down to the point that anyone who wants to make claims about > a signature but does not store the respective public key is just plain stupid. > This is not a technical problem. OpenPGP signed messages contain only a reference to the key as keyID. It's a truncated fingerprint. The key will need to be retrieved based on this set of bytes. There are OpenPGP-based systems that retrieve keys from key servers automatically and verify signatures in the automated way. For these systems fingerprints are important elements of the whole system. Please keep in mind that this thread is about fingerprints. If an OpenPGP system doesn't rely that much on the the fingerprint-to-key link, then whatever we are discussing here is irrelevant to these system. That's not to say that there is no problem with fingerprints. RFC 4880 doesn't warn users that "you cannot rely on fingerprints for security and MUST cache keys for full repudiation". I don't think it should. I think it's much easier to fix the fingerprints and continue to view them as ideal hashes of keys. From dkg at fifthhorseman.net Tue Dec 18 00:44:35 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 17 Dec 2012 18:44:35 -0500 Subject: SHA3 IANA registration - method? In-Reply-To: <50CFA8E4.2060502@brainhub.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <4599875.rlaQdxBocv@inno> <50CF972C.5080403@brainhub.org> <1534234.5QBUm8ahIh@inno> <50CFA8E4.2060502@brainhub.org> Message-ID: <50CFAE63.2020106@fifthhorseman.net> On 12/17/2012 06:21 PM, Andrey Jivsov wrote: > That's not to say that there is no problem with fingerprints. RFC 4880 > doesn't warn users that "you cannot rely on fingerprints for security > and MUST cache keys for full repudiation". I don't think it should. I > think it's much easier to fix the fingerprints and continue to view them > as ideal hashes of keys. https://tools.ietf.org/html/rfc4880#page-72 : >> Note that it is possible for there to be collisions of Key IDs -- two >> different keys with the same Key ID. Note that there is a much >> smaller, but still non-zero, probability that two different keys have >> the same fingerprint. This seems to strongly imply the arguments you suggest are lacking above. I can't find anywhere in RFC 4880 that encourages people to throw away copies of keys that they have used for validation and expect to be able to find them again. I really don't think the scenario you've described amounts to a serious vulnerability, let alone one related to the collision-resistance of the fingerprinting mechanism. --dkg From openpgp at brainhub.org Tue Dec 18 01:02:11 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Mon, 17 Dec 2012 16:02:11 -0800 Subject: SHA3 IANA registration - method? In-Reply-To: <50CFAE63.2020106@fifthhorseman.net> References: <20121212104620.GA35659@redoubt.spodhuis.org> <4599875.rlaQdxBocv@inno> <50CF972C.5080403@brainhub.org> <1534234.5QBUm8ahIh@inno> <50CFA8E4.2060502@brainhub.org> <50CFAE63.2020106@fifthhorseman.net> Message-ID: <50CFB283.7090108@brainhub.org> On 12/17/2012 03:44 PM, Daniel Kahn Gillmor wrote: > On 12/17/2012 06:21 PM, Andrey Jivsov wrote: >> That's not to say that there is no problem with fingerprints. RFC 4880 >> doesn't warn users that "you cannot rely on fingerprints for security >> and MUST cache keys for full repudiation". I don't think it should. I >> think it's much easier to fix the fingerprints and continue to view them >> as ideal hashes of keys. > > https://tools.ietf.org/html/rfc4880#page-72 : > >>> Note that it is possible for there to be collisions of Key IDs -- two >>> different keys with the same Key ID. Note that there is a much >>> smaller, but still non-zero, probability that two different keys have >>> the same fingerprint. > > This seems to strongly imply the arguments you suggest are lacking > above. I can't find anywhere in RFC 4880 that encourages people to > throw away copies of keys that they have used for validation and expect > to be able to find them again. > > I really don't think the scenario you've described amounts to a serious > vulnerability, let alone one related to the collision-resistance of the > fingerprinting mechanism. The quote you provided talks about keyID. The collision it talks about is an unavoidable collision due to the limited length of the keyID, which is 8 bytes. The collision here happens with ~ 1/2^32 probability and it will not be helped by a stronger fingerprint that uses SHA-512, for example. Fingerprints are 160 bits. If you talk to application developers with some knowledge of security, you are almost certain to see a surprise that OpenPGP fingerprints (not keyIDs) may not be assumed to be collision free and one SHOULD cache/log actual keys. From dkg at fifthhorseman.net Tue Dec 18 02:01:50 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 17 Dec 2012 20:01:50 -0500 Subject: SHA3 IANA registration - method? In-Reply-To: <50CFB283.7090108@brainhub.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <4599875.rlaQdxBocv@inno> <50CF972C.5080403@brainhub.org> <1534234.5QBUm8ahIh@inno> <50CFA8E4.2060502@brainhub.org> <50CFAE63.2020106@fifthhorseman.net> <50CFB283.7090108@brainhub.org> Message-ID: <50CFC07E.60909@fifthhorseman.net> On 12/17/2012 07:02 PM, Andrey Jivsov wrote: > On 12/17/2012 03:44 PM, Daniel Kahn Gillmor wrote: >> https://tools.ietf.org/html/rfc4880#page-72 : >> >>>> Note that it is possible for there to be collisions of Key IDs -- two >>>> different keys with the same Key ID. Note that there is a much >>>> smaller, but still non-zero, probability that two different keys have >>>> the same fingerprint. > The quote you provided talks about keyID. It starts by talking about the key ID (64 bits, not 32 bits, fwiw -- see section 3.3), and it concludes by talking about the fingerprint. Regards, --dkg From dshaw at jabberwocky.com Tue Dec 18 06:19:02 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 18 Dec 2012 00:19:02 -0500 Subject: Bugs 1446 and 1447 (SRV and SSL) Message-ID: <926005D5-4E72-4CB9-8BE5-49342F63B144@jabberwocky.com> Hi folks, I have fixes in for bugs 1446 (not following the port from the SRV) and 1447 (not presenting the right SNI and Host header after following a SRV) on the 2.0 branch. If anyone would like to give them a whirl, I'd appreciate it. The cases are: * No curl at all (i.e. configure --without-libcurl): should use the port given in the SRV, and the Host header should be that of the SRV itself, rather than the chosen target given within the SRV. * Built with curl before 7.21.3: No SRV support. * Built with curl at or after 7.21.3: Same as the no-curl case, except it works with hkps as well, and passes the appropriate SNI (which like the Host header, is that of the SRV itself, rather than the chosen target given with the SRV). David From wk at gnupg.org Tue Dec 18 13:45:36 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Dec 2012 13:45:36 +0100 Subject: Search keys on a keyserver with GPGME In-Reply-To: (=?utf-8?Q?=22Jos=C3=A9?= Carlos de Campos"'s message of "Thu, 13 Dec 2012 16:03:38 +0000") References: Message-ID: <87sj731qbz.fsf@vigenere.g10code.de> On Thu, 13 Dec 2012 17:03, zecapistolas at gmail.com said: > How can I do this, how can I make a search on a keyserver using GPGME? I suggest to compare your code to gpgme/tests/run-keylist.c - I just checked that it works. Take care: GnuPG master might not work right now. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From brande at heag.ch Tue Dec 18 13:39:54 2012 From: brande at heag.ch (Erwin Brandenberger) Date: Tue, 18 Dec 2012 13:39:54 +0100 Subject: Windows: MiniDumpWriteDump entry point missing Message-ID: <50D0641A.6060205@heag.ch> I'm writing a 32bit application with libgcrypt 1.5.0 for Windows Vista 64bit. After compiling the library with mingw32 I tested the DLL in Vista. But right after starting the binary I got the error popup with message: libgcrypt-11.dll can't find entry point "MiniDumpWriteDump". What is the problem ? How can I solve it ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Dec 18 18:36:02 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Dec 2012 18:36:02 +0100 Subject: Windows: MiniDumpWriteDump entry point missing In-Reply-To: <50D0641A.6060205@heag.ch> (Erwin Brandenberger's message of "Tue, 18 Dec 2012 13:39:54 +0100") References: <50D0641A.6060205@heag.ch> Message-ID: <87fw331cvx.fsf@vigenere.g10code.de> On Tue, 18 Dec 2012 13:39, brande at heag.ch said: > After compiling the library with mingw32 I tested the DLL in Vista. I assume you did a native build. This is not supported. You must use a cross-compiler. With the tarball release a "./autogen.sh --build-w32" does everything for you. You may also use the DLL included in the latest Gpg4win. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From openpgp at brainhub.org Tue Dec 18 18:42:46 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Tue, 18 Dec 2012 09:42:46 -0800 Subject: SHA3 IANA registration - method? In-Reply-To: <50CFC07E.60909@fifthhorseman.net> References: <20121212104620.GA35659@redoubt.spodhuis.org> <4599875.rlaQdxBocv@inno> <50CF972C.5080403@brainhub.org> <1534234.5QBUm8ahIh@inno> <50CFA8E4.2060502@brainhub.org> <50CFAE63.2020106@fifthhorseman.net> <50CFB283.7090108@brainhub.org> <50CFC07E.60909@fifthhorseman.net> Message-ID: <50D0AB16.5020505@brainhub.org> On 12/17/2012 05:01 PM, Daniel Kahn Gillmor wrote: > On 12/17/2012 07:02 PM, Andrey Jivsov wrote: >> On 12/17/2012 03:44 PM, Daniel Kahn Gillmor wrote: >>> https://tools.ietf.org/html/rfc4880#page-72 : >>> >>>>> Note that it is possible for there to be collisions of Key IDs -- two >>>>> different keys with the same Key ID. Note that there is a much >>>>> smaller, but still non-zero, probability that two different keys have >>>>> the same fingerprint. > >> The quote you provided talks about keyID. > > It starts by talking about the key ID (64 bits, not 32 bits, fwiw -- see > section 3.3), and it concludes by talking about the fingerprint. > > Regards, > > --dkg > I was referring to the fact that in a group of keys about 2^32 will likely have a pair of colliding 8 byte keyIDs. If a message or a 3d party signature references one of these keys, we have a collision. OK, there is a language about fingerprint, but it will have 1/2^80 probability of a collision, not something to worry about. Commonly used UUIDs will have the probability of 1/2^64, for comparison. Thus, that last line about fingerprints should not be taken as a practical consideration. These types of collisions were mentioned in a context of a hash function that is viewed as a random hash function. KeyIDs are simply the ending of the fingerprint. It's quite easy today to produce two keys with colliding keyIDs simply by random key generation. However, these 2 keys will have different fingerprints. The expectation is that it's safe to log these fingerprints in the audit log. So, while it was not safe to rely on uniqueness of the keyID, it was expected that the remedy to this is to use the fingerprints. Well, not anymore if SHA-1 continues to deteriorate. From christian at quelltextlich.at Tue Dec 18 18:51:37 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Tue, 18 Dec 2012 18:51:37 +0100 Subject: [PATCH] Show 'public key already present' warning only in verbose mode Message-ID: <20121218175137.GA31370@quelltextlich.at> * g10/pkclist.c (find_and_check_key): Show 'public key already present' warning only in verbose mode. (build_pk_list): Ditto. --- g10/pkclist.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/g10/pkclist.c b/g10/pkclist.c index f805da8..baa15ab 100644 --- a/g10/pkclist.c +++ b/g10/pkclist.c @@ -837,7 +837,10 @@ find_and_check_key (ctrl_t ctrl, const char *name, unsigned int use, list. */ if (!key_present_in_pk_list (*pk_list_addr, pk)) { - log_info (_("%s: skipped: public key already present\n"), name); + if (opt.verbose) + { + log_info (_("%s: skipped: public key already present\n"), name); + } free_public_key (pk); } else @@ -945,8 +948,11 @@ build_pk_list (ctrl_t ctrl, if (key_present_in_pk_list(pk_list, pk) == 0) { free_public_key (pk); pk = NULL; - log_info (_("%s: skipped: public key already present\n"), - rov->d); + if (opt.verbose) + { + log_info (_("%s: skipped: public key already present\n"), + rov->d); + } } else { -- 1.7.8.6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Tue Dec 18 20:12:46 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Dec 2012 20:12:46 +0100 Subject: [PATCH] Show 'public key already present' warning only in verbose mode In-Reply-To: <20121218175137.GA31370@quelltextlich.at> (Christian Aistleitner's message of "Tue, 18 Dec 2012 18:51:37 +0100") References: <20121218175137.GA31370@quelltextlich.at> Message-ID: <87vcbzyy1d.fsf@vigenere.g10code.de> On Tue, 18 Dec 2012 18:51, christian at quelltextlich.at said: > * g10/pkclist.c (find_and_check_key): Show 'public key already present' > warning only in verbose mode. Why do you want this? The only annoying case I know is that if you encrypt to yourself, it will show this message due to the encrypt-to config option. The fix would be to show the message not in this case. In all other cases I consider this message useful. Not showing it with --quiet would be fine with me. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christian at quelltextlich.at Tue Dec 18 20:52:50 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Tue, 18 Dec 2012 20:52:50 +0100 Subject: Fingerprint algorithm and SHA-1 usage [was: Re: SHA3 IANA registration - method?] In-Reply-To: <50CF99B5.5040707@brainhub.org> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50CB6BD9.1000202@fifthhorseman.net> <50CB70DA.4030808@brainhub.org> <3035659.KHhMZOD6SR@inno> <50CBD320.9090706@brainhub.org> <20121215140301.GA5409@quelltextlich.at> <50CF99B5.5040707@brainhub.org> Message-ID: <20121218195250.GA22901@quelltextlich.at> Hi Andrey, On Mon, Dec 17, 2012 at 02:16:21PM -0800, Andrey Jivsov wrote: > On 12/15/2012 06:03 AM, Christian Aistleitner wrote: > > [3] Shameless plug: You can for example allow others to avoid SHA-1 at > > key-signing parties, by adding additional (non-standard) SHA-512 > > fingerprints to your paper slips: > > http://openpgp.quelltextlich.at/slip.html?key=8421F11C&format=pdf&variant=SHA512,A4R,sparse > > as described here > > http://openpgp.quelltextlich.at/slip.html?query=0x8421F11C#faq-additional-digests > > If I understand your proposal correctly, you are changing the hardwired > SHA-1 fingerprint to SHA-512 without metadata/agility. And I am not suggesting to trade hardwired SHA-1 for hardwired SHA-512. I'd be against doing this. Best regards, Christian P.S.: The paper slips generated by above's service do contain metadata: The additional SHA-512 part contains a link to the patch on how to verify the non-standard fingerprint. Those non-standard SHA-512 fingerprints serve two purposes: * It allows SHA-1 averse people to participate in current key-signing parties. * It shows people what checking a SHA-512 hash may amount to. Thereby it invites for discussions about fingerprints and concepts on how to exchange keys. And --- *surprise* :-) --- it seems hexadecimal encoded 512-bit hashes are beyond what most people want to compare by hand. But additionally putting a 2D Barcode encoded hash on the slip may do the trick. -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From openpgp at brainhub.org Tue Dec 18 21:01:32 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Tue, 18 Dec 2012 12:01:32 -0800 Subject: Fingerprint algorithm and SHA-1 usage [was: Re: SHA3 IANA registration - method?] In-Reply-To: <20121218195250.GA22901@quelltextlich.at> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50CB6BD9.1000202@fifthhorseman.net> <50CB70DA.4030808@brainhub.org> <3035659.KHhMZOD6SR@inno> <50CBD320.9090706@brainhub.org> <20121215140301.GA5409@quelltextlich.at> <50CF99B5.5040707@brainhub.org> <20121218195250.GA22901@quelltextlich.at> Message-ID: <50D0CB9C.10102@brainhub.org> On 12/18/2012 11:52 AM, Christian Aistleitner wrote: > Hi Andrey, > > On Mon, Dec 17, 2012 at 02:16:21PM -0800, Andrey Jivsov wrote: >> On 12/15/2012 06:03 AM, Christian Aistleitner wrote: >>> [3] Shameless plug: You can for example allow others to avoid SHA-1 at >>> key-signing parties, by adding additional (non-standard) SHA-512 >>> fingerprints to your paper slips: >>> http://openpgp.quelltextlich.at/slip.html?key=8421F11C&format=pdf&variant=SHA512,A4R,sparse >>> as described here >>> http://openpgp.quelltextlich.at/slip.html?query=0x8421F11C#faq-additional-digests >> >> If I understand your proposal correctly, you are changing the hardwired >> SHA-1 fingerprint to SHA-512 without metadata/agility. > > And I am not suggesting to trade hardwired SHA-1 for hardwired > SHA-512. I'd be against doing this. > > Best regards, > Christian > > > P.S.: The paper slips generated by above's service do contain metadata: > The additional SHA-512 part contains a link to the patch on how to > verify the non-standard fingerprint. > > Those non-standard SHA-512 fingerprints serve two purposes: > * It allows SHA-1 averse people to participate in current key-signing > parties. > * It shows people what checking a SHA-512 hash may amount to. Thereby > it invites for discussions about fingerprints and concepts on how to > exchange keys. And --- *surprise* :-) --- it seems hexadecimal > encoded 512-bit hashes are beyond what most people want to compare > by hand. But additionally putting a 2D Barcode encoded hash on the > slip may do the trick. One things that stands out here: I would consider truncating the SHA-512 hash output used as fingerprint to 160 bits or a bit more. 80 bit of security seems OK for the fingerprinting. We have a problem with SHA-1, not the 160 bit output. From christian at quelltextlich.at Tue Dec 18 21:19:25 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Tue, 18 Dec 2012 21:19:25 +0100 Subject: [PATCH] Show 'public key already present' warning only in verbose mode In-Reply-To: <87vcbzyy1d.fsf@vigenere.g10code.de> References: <20121218175137.GA31370@quelltextlich.at> <87vcbzyy1d.fsf@vigenere.g10code.de> Message-ID: <20121218201925.GA26593@quelltextlich.at> Hi Werner, On Tue, Dec 18, 2012 at 08:12:46PM +0100, Werner Koch wrote: > On Tue, 18 Dec 2012 18:51, christian at quelltextlich.at said: > > * g10/pkclist.c (find_and_check_key): Show 'public key already present' > > warning only in verbose mode. > > Why do you want this? Recently, there has been a complaint on the gnupg-user list about this warning [1] and he/she even found that you suggested to only show it in verbose mode back in 2001 [2]. Only he/she did not seem to know how to do this. So, I followed your suggestion and made it dependent on verbose mode :-) > Not showing it with --quiet would be fine with me. So be it. See follow up message. Best regards, Christian [1] http://lists.gnupg.org/pipermail/gnupg-users/2012-December/045813.html [2] http://lists.gnupg.org/pipermail/gnupg-users/2001-May/008354.html -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From christian at quelltextlich.at Tue Dec 18 21:22:47 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Tue, 18 Dec 2012 21:22:47 +0100 Subject: [PATCH] Do not show 'public key already present' warning in quiet mode In-Reply-To: <20121218201925.GA26593@quelltextlich.at> References: <20121218175137.GA31370@quelltextlich.at> <87vcbzyy1d.fsf@vigenere.g10code.de> <20121218201925.GA26593@quelltextlich.at> Message-ID: <20121218202247.GB26593@quelltextlich.at> * g10/pkclist.c (find_and_check_key): Do not show 'public key already present' warning in quiet mode (build_pk_list): Ditto. --- g10/pkclist.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/g10/pkclist.c b/g10/pkclist.c index f805da8..04e5400 100644 --- a/g10/pkclist.c +++ b/g10/pkclist.c @@ -837,7 +837,10 @@ find_and_check_key (ctrl_t ctrl, const char *name, unsigned int use, list. */ if (!key_present_in_pk_list (*pk_list_addr, pk)) { - log_info (_("%s: skipped: public key already present\n"), name); + if (!opt.quiet) + { + log_info (_("%s: skipped: public key already present\n"), name); + } free_public_key (pk); } else @@ -945,8 +948,11 @@ build_pk_list (ctrl_t ctrl, if (key_present_in_pk_list(pk_list, pk) == 0) { free_public_key (pk); pk = NULL; - log_info (_("%s: skipped: public key already present\n"), - rov->d); + if (!opt.quiet) + { + log_info (_("%s: skipped: public key already present\n"), + rov->d); + } } else { -- 1.7.8.6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Tue Dec 18 21:59:25 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Dec 2012 21:59:25 +0100 Subject: [PATCH] Show 'public key already present' warning only in verbose mode In-Reply-To: <20121218201925.GA26593@quelltextlich.at> (Christian Aistleitner's message of "Tue, 18 Dec 2012 21:19:25 +0100") References: <20121218175137.GA31370@quelltextlich.at> <87vcbzyy1d.fsf@vigenere.g10code.de> <20121218201925.GA26593@quelltextlich.at> Message-ID: <87mwxbyt3m.fsf@vigenere.g10code.de> On Tue, 18 Dec 2012 21:19, christian at quelltextlich.at said: > Recently, there has been a complaint on the gnupg-user list about this > warning [1] and he/she even found that you suggested to only show it > in verbose mode back in 2001 [2]. I can't remember ;-) > So be it. See follow up message. Please let me hack it myself. We still have this stupid copyright assignment requirement. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Dec 18 22:02:08 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Dec 2012 22:02:08 +0100 Subject: Fingerprint algorithm and SHA-1 usage In-Reply-To: <20121218195250.GA22901@quelltextlich.at> (Christian Aistleitner's message of "Tue, 18 Dec 2012 20:52:50 +0100") References: <20121212104620.GA35659@redoubt.spodhuis.org> <50CB6BD9.1000202@fifthhorseman.net> <50CB70DA.4030808@brainhub.org> <3035659.KHhMZOD6SR@inno> <50CBD320.9090706@brainhub.org> <20121215140301.GA5409@quelltextlich.at> <50CF99B5.5040707@brainhub.org> <20121218195250.GA22901@quelltextlich.at> Message-ID: <87ip7zysz3.fsf@vigenere.g10code.de> On Tue, 18 Dec 2012 20:52, christian at quelltextlich.at said: > * It shows people what checking a SHA-512 hash may amount to. Thereby :-) > by hand. But additionally putting a 2D Barcode encoded hash on the > slip may do the trick. And add lots of code which can be used to subvert the whole process. SHA-384 being the weakest link? I doubt it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christian at quelltextlich.at Wed Dec 19 11:02:27 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Wed, 19 Dec 2012 11:02:27 +0100 Subject: Fingerprint algorithm and SHA-1 usage In-Reply-To: <87ip7zysz3.fsf@vigenere.g10code.de> References: <20121212104620.GA35659@redoubt.spodhuis.org> <50CB6BD9.1000202@fifthhorseman.net> <50CB70DA.4030808@brainhub.org> <3035659.KHhMZOD6SR@inno> <50CBD320.9090706@brainhub.org> <20121215140301.GA5409@quelltextlich.at> <50CF99B5.5040707@brainhub.org> <20121218195250.GA22901@quelltextlich.at> <87ip7zysz3.fsf@vigenere.g10code.de> Message-ID: <20121219100226.GA1463@quelltextlich.at> Hi Werner, On Tue, Dec 18, 2012 at 10:02:08PM +0100, Werner Koch wrote: > On Tue, 18 Dec 2012 20:52, christian at quelltextlich.at said: > > by hand. But additionally putting a 2D Barcode encoded hash on the > > slip may do the trick. > > And add lots of code which can be used to subvert the whole process. > SHA-384 being the weakest link? I doubt it. So do I. The weakest link is us humans. I'd be glad if more people would start to check more than only the first and last byte of the SHA-1 hash to assert that two hashes match. Humans are notoriously bad at comparing data piece by piece. Machines are better at it. So once we exchanged the data by meeting in the real world, why should we not delegate the comparison to machines? Not only sloppy^Wtoo busy people would benefit. But yes, that'd mean using further code. As people typically use 3rd party tools like caff anyways, I am not yet convinced that this an unsolvable problem. Percepted transparency of the process is more of an issue here. People tend to think that the hexadecimal encoded hash actually /is/ the one and only pure hash, while e.g.: a 2D-barcode encoded hash is some obscure, bad thing. But once one explains to them that both the hexadecimal encoding and also the 2D-barcode encoding are isomorphic encodings of the same 512-bit hash, this perception changes a bit. Indeed, none of the two encodings is more or less obscure than the other. It's just that humans favour one of the isomorphic encodings for comparisons, while machines favour the other. So why not add both of them and let the recipient decide, how to verify it? Best regards, Christian P.S.: Obviously, 2D-barcodes are not the one and only solution. Most 2D-barcode variants are encumbered by patent issues for a start. Nevertheless, they seem most viable to me for now. If anyone can provide more input or propose different solutions, I'd definitely love to hear them. -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From pgut001 at cs.auckland.ac.nz Wed Dec 19 12:22:09 2012 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 20 Dec 2012 00:22:09 +1300 Subject: Fingerprint algorithm and SHA-1 usage In-Reply-To: <20121219100226.GA1463@quelltextlich.at> Message-ID: Christian Aistleitner writes: >So do I. The weakest link is us humans. I'd be glad if more people would >start to check more than only the first and last byte of the SHA-1 hash to >assert that two hashes match. For more on this could I recommend "Do Users Verify SSH Keys?", https://www.usenix.org/publications/login/august-2011-volume-36-number-4/do-users-verify-ssh-keys. (And no, it's not a deliberate invocation of Betteridge's Law). Peter. From wk at gnupg.org Wed Dec 19 16:06:17 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 19 Dec 2012 16:06:17 +0100 Subject: [PATCH] Do not show 'public key already present' warning in quiet mode In-Reply-To: <20121218202247.GB26593@quelltextlich.at> (Christian Aistleitner's message of "Tue, 18 Dec 2012 21:22:47 +0100") References: <20121218175137.GA31370@quelltextlich.at> <87vcbzyy1d.fsf@vigenere.g10code.de> <20121218201925.GA26593@quelltextlich.at> <20121218202247.GB26593@quelltextlich.at> Message-ID: <87licuxes6.fsf@vigenere.g10code.de> On Tue, 18 Dec 2012 21:22, christian at quelltextlich.at said: > * g10/pkclist.c (find_and_check_key): Do not show 'public key already > present' warning in quiet mode Nearly identical change pushed to all branches. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 20 08:41:40 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Dec 2012 08:41:40 +0100 Subject: gitstats.gnupg.org Message-ID: <87sj71uq4r.fsf@vigenere.g10code.de> Hi, Subject says all. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 20 21:20:32 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Dec 2012 21:20:32 +0100 Subject: [Announce] GnuPG 1.4.13 released Message-ID: <87d2y4tqzz.fsf@vigenere.g10code.de> Hello! 15 years after the first release we are now pleased to announce the availability of a new stable GnuPG-1 release: Version 1.4.13. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility, smartcard support and is compliant with the OpenPGP Internet standard as described by RFC-4880. Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build, and also better portable to ancient platforms. In contrast to GnuPG-2 (e.g version 2.0.19) it comes with no support for S/MIME, Secure Shell, or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict. What's New =========== * Add support for the old cipher algorithm IDEA. * Minor bug fixes. * Small changes to better cope with future OpenPGP and GnuPG features. Getting the Software ==================== First of all, decide whether you really need GnuPG version 1.4.x - most users are better off with the modern GnuPG 2.0.x version. Then follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.13 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.13.tar.bz2 (3599k) gnupg-1.4.13.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.13.tar.gz (4966k) gnupg-1.4.13.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.12-1.4.13.diff.bz2 (284k) A patch file to upgrade a 1.4.12 GnuPG source tree. This patch does not include updates of the language files. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.13.exe (1557k) gnupg-w32cli-1.4.13.exe.sig GnuPG compiled for Microsoft Windows and OpenPGP signature. This is a command line only version; the source files are the same as given above. Note, that this is a minimal installer and unless you are just in need for the gpg binary, you are better off using the full featured installer at http://www.gpg4win.org . 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 trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.13.tar.bz2 you would use this command: gpg --verify gnupg-1.4.13.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com | gpg --import or using a keyserver like gpg --recv-key 4F25E3B6 The distribution key 1CE0C630 is signed by the well known keys 1E42B367. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.13.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.12.tar.bz2 and check that the output matches the first line from the following list: 17a75c54d292bd0923f0a1817a1b02ded37d1de1 gnupg-1.4.13.tar.bz2 9f2696f3b61cb771053db599e884952c80d2a6e7 gnupg-1.4.13.tar.gz ba200314de0e6e4fc507a16da96261f22e3b0874 gnupg-1.4.12-1.4.13.diff.bz2 852666756ae96dee667eccdd619689c18d662b4a gnupg-w32cli-1.4.13.exe Internationalization ==================== GnuPG comes with support for 29 languages. The Chinese (Simple and Traditional), Czech, Danish, Dutch, French, German, Norwegian, Polish, Romanian, Russian, Spanish, Swedish, Ukrainian, and Turkish translations are close to be complete. Support ======= A listing with commercial support offers for GnuPG is available at: http://www.gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software take up a most of their resources. To allow them continue their work they ask to either purchase a support contract, engage them for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, donating money, spreading the word, or answering questions on the mailing lists. Happy Hacking, The GnuPG Team (David, Werner and the other contributors) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 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 bernhard at intevation.de Fri Dec 21 12:30:43 2012 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 21 Dec 2012 12:30:43 +0100 Subject: A wiki for GnuPG and related topics? Message-ID: <201212211230.48404.bernhard@intevation.de> Hi friends of Free Software crypto, we do need a better plattform to document how this all works together in a central place. GnuPG has a wonderful technical documentation and being involved with www.gpg4win.org and www.gpg4kde.org I have contributed my part of making the necessary knowledge more accessible. Still I have seen numerous installations where setup or basic administration issues were faulty, resulting in bad user experiences. And they are even unfortunate because the technology of GnuPG would have allowed to configure and use it in a better way. It mainly is lack of knowledge. To give one example I recently saw Kontact on OpenSuse 12.2 where they stil are unable to start a gnupg-agent by default. Simple thing that worsens the experience a lot. Where do I document the solution for all packagers of GNU systems, like Debian, Redhat, Ubuntu? Now I also want to plan for interesting features and development topics for Gpg4win, together with the community. The mailing is good, but often not canonical. So my idea to solve is would be a wiki. It takes a bit to maintain, spam fighting and keeping things together, but we could do it. What do you think? Best Regards, Bernhard ps.: I offline for days to come until January. pps.: If everybody agrees that running a Wiki is cool and we get some people willing to help, maybe I am offering to host one from Intevaion. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From openpgp at brainhub.org Fri Dec 21 20:32:28 2012 From: openpgp at brainhub.org (Andrey Jivsov) Date: Fri, 21 Dec 2012 11:32:28 -0800 Subject: Fingerprint algorithm and SHA-1 usage In-Reply-To: References: Message-ID: <50D4B94C.3000501@brainhub.org> To summarize, I wonder were do we stand on this issue? I am not sure which one / more of the following represents a consensus on this list. I would appreciate your feedback. * don't change anything regarding the fingerprint usage in OpenPGP * if there is a proposal for new fingerprint, we will look into it * the Keccak in OpenPGP spec should definitely not include any proposal for the new fingerprint * any other thoughts / options / timelines? Thank you. From nicholas.cole at gmail.com Sat Dec 22 13:39:43 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sat, 22 Dec 2012 12:39:43 +0000 Subject: Fingerprint algorithm and SHA-1 usage In-Reply-To: References: <50D4B94C.3000501@brainhub.org> Message-ID: On Sat, Dec 22, 2012 at 12:30 PM, Nicholas Cole wrote: > As far as I can see, and based solely on listening to experts on this > list, there is no pressing technical reason to change - but for PR > reasons, I think I would be happier if some sensible new fingerprint > were agreed. > > But I do NOT favour a solution that will burden users with having to > check needlessly[*] long fingerprints, or carry around barcode > scanners and the like! > > Best wishes, > > N. > [*] for real-world, non-paranoid, "pretty good" privacy. Just writing the above made me wonder, though. Perhaps we could tolerate longer fingerprints if they were presented in (eg.) Base 32 rather than in Hex. Perhaps any new proposal should consider that. N. From nicholas.cole at gmail.com Sat Dec 22 13:30:21 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sat, 22 Dec 2012 12:30:21 +0000 Subject: Fingerprint algorithm and SHA-1 usage In-Reply-To: <50D4B94C.3000501@brainhub.org> References: <50D4B94C.3000501@brainhub.org> Message-ID: On Fri, Dec 21, 2012 at 7:32 PM, Andrey Jivsov wrote: > To summarize, I wonder were do we stand on this issue? Just from an interested, user's perspective: > I am not sure which one / more of the following represents a consensus on > this list. I would appreciate your feedback. > * don't change anything regarding the fingerprint usage in OpenPGP SHA-1 fingerprints have served quite well. Collisions are (highly) unlikely, the fingerprint is still short enough to fit on a business card, be checked by a human etc. But there are hints of attacks coming, and furthermore if standards bodies are going to start being suspicious about SHA-1, then some kind of change is probably a good idea. > * if there is a proposal for new fingerprint, we will look into it I'm not sure there has been a clear proposal. But in terms of everyday usage: > * the Keccak in OpenPGP spec should definitely not include any proposal for > the new fingerprint Which version? SHA3-224 seems to me to be the limit of what you could get onto a business card with any ease. Would that provide enough collision-resistence for the next 15 years or so? > * any other thoughts / options / timelines? I don't think I favour (from a user perspective) a huge plethora of new types of fingerprint. Allowing implementations to generate fingerprints using arbitrary hash functions just seems like a potential source of confusion. On the other hand, perhaps building two fingerprints into the new standard, SHA-2-224 and SHA-3-224 might be a way forward and provide some protection against any change in attacks. As far as I can see, and based solely on listening to experts on this list, there is no pressing technical reason to change - but for PR reasons, I think I would be happier if some sensible new fingerprint were agreed. But I do NOT favour a solution that will burden users with having to check needlessly[*] long fingerprints, or carry around barcode scanners and the like! Best wishes, N. [*] for real-world, non-paranoid, "pretty good" privacy. From sms at antinode.info Sat Dec 22 16:17:50 2012 From: sms at antinode.info (Steven M. Schweda) Date: Sat, 22 Dec 2012 09:17:50 -0600 (CST) Subject: GnuPG 1.4.13 v. VMS Message-ID: <12122209175014_20200E91@antinode.info> I haven't tested much, but a build on VMS (Alpha) seemed to go through with little difficulty. I did run into one minor problem, which was my fault, because I forgot to tell you about one more change which I wanted in config.h.in. I haven't worked up a real patch, because I don't actually use config.h.in directly, but it's the addition of two lines: [...] /* Please note that the string version must not contain more than one character because the using code assumes strlen()==1 */ #ifdef HAVE_DOSISH_SYSTEM # define DIRSEP_C '\\' # define EXTSEP_C '.' # define DIRSEP_S "\\" # define EXTSEP_S "." # define PATHSEP_C ';' # define PATHSEP_S ";" #else # define DIRSEP_C '/' # define EXTSEP_C '.' # define EXTSEP_C2 '-' <------ # define DIRSEP_S "/" # define EXTSEP_S "." # define EXTSEP_S2 "-" <------ # define PATHSEP_C ':' # define PATHSEP_S ":" #endif [...] These macros are used only in the VMS-specific code, so they could be made conditional (#ifdef __VMS) or placed in the VMS-conditional block just below that. (Or I could define them in the VMS-specific code, but it seemed reasonable to keep all these definitions together.) If you could slip these things into the main code stream (one way or another), then you'd save me a couple of minutes when 1.4.14 appears. (It's almost worth the extra work.) Feel free to change the names, if desired. Other than that one problem, all I needed to do was rip out some now-obsolete special handling for idea.c, fix a couple of old bugs in the VMS builders, and run through the usual manual editing of a config.h_vms. Pretty painless. ALP $ gpg --version gpg (GnuPG) 1.4.13a Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /SYS$LOGIN/gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Thanks again. ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From eric at debian.org Mon Dec 31 23:41:48 2012 From: eric at debian.org (Eric Dorland) Date: Mon, 31 Dec 2012 17:41:48 -0500 Subject: [PATCH] Fix some spelling errors picked up by lintian. Message-ID: <20121231224148.GA1990@gambit> --- doc/dirmngr.texi | 4 ++-- doc/gpg-agent.texi | 18 +++++++++--------- doc/gpg.texi | 27 ++++++++++++++------------- doc/gpgsm.texi | 14 +++++++------- doc/scdaemon.texi | 6 +++--- doc/tools.texi | 14 +++++++------- 6 files changed, 42 insertions(+), 41 deletions(-) diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi index e626487..5243dd0 100644 --- a/doc/dirmngr.texi +++ b/doc/dirmngr.texi @@ -299,8 +299,8 @@ Obviously this will lead to problems if the password has orginally been encoded as Latin-1. There is no other solution here than to put such a password in the binary encoding into the file (i.e. non-ascii characters won't show up readable). at footnote{The @command{gpgconf} tool might be -helpful for frontends as it allows to edit this configuration file using -percent escaped strings.} +helpful for frontends as it allows one to edit this configuration file +using percent escaped strings.} @item --ldaptimeout @var{secs} diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi index dcd96fb..63f7be0 100644 --- a/doc/gpg-agent.texi +++ b/doc/gpg-agent.texi @@ -53,10 +53,10 @@ independently from any protocol. It is used as a backend for utilities. @ifset gpgtwoone -The agent is usualy started on demand by @command{gpg}, @command{gpgsm}, - at command{gpgconf} or @command{gpg-connect-agent}. Thus there is no -reason to start it manually. In case you want to use the included -Secure Shell Agent you may start the agent using: +The agent is usually started on demand by @command{gpg}, + at command{gpgsm}, @command{gpgconf} or @command{gpg-connect-agent}. +Thus there is no reason to start it manually. In case you want to use +the included Secure Shell Agent you may start the agent using: @example gpg-connect-agent /bye @@ -122,7 +122,7 @@ output of the @code{tty} command. For W32 systems this option is not required. Please make sure that a proper pinentry program has been installed -under the default filename (which is system dependant) or use the +under the default filename (which is system dependent) or use the option @option{pinentry-program} to specify the full name of that program. It is often useful to install a symbolic link from the actual used pinentry (e.g. @file{/usr/bin/pinentry-gtk}) to the expected @@ -577,8 +577,8 @@ agent. By default they may all be found in the current home directory lines are ignored. To mark a key as trusted you need to enter its fingerprint followed by a space and a capital letter @code{S}. Colons may optionally be used to separate the bytes of a fingerprint; this - allows to cut and paste the fingerprint from a key listing output. If - the line is prefixed with a @code{!} the key is explicitly marked as + allows one to cut and paste the fingerprint from a key listing output. + If the line is prefixed with a @code{!} the key is explicitly marked as not trusted. Here is an example where two keys are marked as ultimately trusted @@ -980,8 +980,8 @@ Here is an example session: This is used to create a new keypair and store the secret key inside the active PSE --- which is in most cases a Soft-PSE. An not yet defined -option allows to choose the storage location. To get the secret key out -of the PSE, a special export tool has to be used. +option allows one to choose the storage location. To get the secret key +out of the PSE, a special export tool has to be used. @example @ifset gpgtwoone diff --git a/doc/gpg.texi b/doc/gpg.texi index d679000..abc3c40 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -1232,9 +1232,9 @@ Use @code{file} to access the smartcard reader. The current default is @ifset gpgone @item --disable-ccid @opindex disable-ccid -Disable the integrated support for CCID compliant readers. This -allows to fall back to one of the other drivers even if the internal -CCID driver can handle the reader. Note, that CCID support is only +Disable the integrated support for CCID compliant readers. This allows +one to fall back to one of the other drivers even if the internal CCID +driver can handle the reader. Note, that CCID support is only available if libusb was available at build time. @end ifset @@ -1463,8 +1463,8 @@ mechanisms, in the order they are to be tried: may be used here to query that particular keyserver. @item local - Locate the key using the local keyrings. This mechanism allows to - select the order a local key lookup is done. Thus using + Locate the key using the local keyrings. This mechanism allows one + to select the order a local key lookup is done. Thus using @samp{--auto-key-locate local} is identical to @option{--no-auto-key-locate}. @@ -1872,13 +1872,13 @@ Use @var{name} as the key to sign with. Note that this option overrides @opindex try-secret-key For hidden recipients GPG needs to know the keys to use for trial decryption. The key set with @option{--default-key} is always tried -first, but this is often not sufficient. This option allows to set more -keys to be used for trial decryption. Although any valid user-id -specification may be used for @var{name} it makes sense to use at least -the long keyid to avoid ambiguities. Note that gpg-agent might pop up a -pinentry for a lot keys to do the trial decryption. If you want to stop -all further trial decryption you may use close-window button instead of -the cancel button. +first, but this is often not sufficient. This option allows one to +set more keys to be used for trial decryption. Although any valid +user-id specification may be used for @var{name} it makes sense to use +at least the long keyid to avoid ambiguities. Note that gpg-agent +might pop up a pinentry for a lot keys to do the trial decryption. If +you want to stop all further trial decryption you may use close-window +button instead of the cancel button. @end ifset @item --try-all-secrets @@ -2475,7 +2475,8 @@ to display the message. This option overrides @option{--set-filename}. @itemx --no-use-embedded-filename @opindex use-embedded-filename Try to create a file with a name as embedded in the data. This can be -a dangerous option as it allows to overwrite files. Defaults to no. +a dangerous option as it allows one to overwrite files. Defaults to +no. @item --cipher-algo @code{name} @opindex cipher-algo diff --git a/doc/gpgsm.texi b/doc/gpgsm.texi index bdb0378..136bbf8 100644 --- a/doc/gpgsm.texi +++ b/doc/gpgsm.texi @@ -611,15 +611,15 @@ interoperability problems. @item --extra-digest-algo @var{name} @opindex extra-digest-algo -Sometimes signatures are broken in that they announce a different digest -algorithm than actually used. @command{gpgsm} uses a one-pass data -processing model and thus needs to rely on the announced digest +Sometimes signatures are broken in that they announce a different +digest algorithm than actually used. @command{gpgsm} uses a one-pass +data processing model and thus needs to rely on the announced digest algorithms to properly hash the data. As a workaround this option may be used to tell gpg to also hash the data using the algorithm - at var{name}; this slows processing down a little bit but allows to verify -such broken signatures. If @command{gpgsm} prints an error like -``digest algo 8 has not been enabled'' you may want to try this option, -with @samp{SHA256} for @var{name}. + at var{name}; this slows processing down a little bit but allows one to +verify such broken signatures. If @command{gpgsm} prints an error +like ``digest algo 8 has not been enabled'' you may want to try this +option, with @samp{SHA256} for @var{name}. @item --faked-system-time @var{epoch} diff --git a/doc/scdaemon.texi b/doc/scdaemon.texi index 200fed8..f91d312 100644 --- a/doc/scdaemon.texi +++ b/doc/scdaemon.texi @@ -254,9 +254,9 @@ deprecated; it may be removed in future releases. @item --disable-ccid @opindex disable-ccid Disable the integrated support for CCID compliant readers. This -allows to fall back to one of the other drivers even if the internal -CCID driver can handle the reader. Note, that CCID support is only -available if libusb was available at build time. +allows one to fall back to one of the other drivers even if the +internal CCID driver can handle the reader. Note, that CCID support +is only available if libusb was available at build time. @item --reader-port @var{number_or_string} @opindex reader-port diff --git a/doc/tools.texi b/doc/tools.texi index be1233b..74bf81c 100644 --- a/doc/tools.texi +++ b/doc/tools.texi @@ -235,7 +235,7 @@ commit the changes. @command{gpgconf} provides the backend of a configuration editor. The configuration editor would usually be a graphical user interface -program, that allows to display the current options, their default +program, that allows one to display the current options, their default values, and allows the user to make changes to the options. These changes can then be made active with @command{gpgconf} again. Such a program that uses @command{gpgconf} in this way will be called GUI @@ -972,12 +972,12 @@ no feature to change the global option file through @command{gpgconf}. @mansect description This script is a wrapper around @command{gpgconf} to run it with the command @code{--apply-defaults} for all real users with an existing -GnuPG home directory. Admins might want to use this script to update he -GnuPG configuration files for all users after - at file{/etc/gnupg/gpgconf.conf} has been changed. This allows to enforce -certain policies for all users. Note, that this is not a bulletproof of -forcing a user to use certain options. A user may always directly edit -the configuration files and bypass gpgconf. +GnuPG home directory. Admins might want to use this script to update +he GnuPG configuration files for all users after + at file{/etc/gnupg/gpgconf.conf} has been changed. This allows one to +enforce certain policies for all users. Note, that this is not a +bulletproof of forcing a user to use certain options. A user may +always directly edit the configuration files and bypass gpgconf. @noindent @command{applygnupgdefaults} is invoked by root as: -- 1.7.10.4 -- Eric Dorland ICQ: #61138586, Jabber: hooty at jabber.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: