From wk at gnupg.org Tue Oct 1 14:27:00 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 01 Oct 2013 14:27:00 +0200 Subject: ECC and smartcards In-Reply-To: <1380173248.3247.8.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 26 Sep 2013 14:27:28 +0900") References: <1326243062.2015.1.camel@latx1.gniibe.org> <1360911825.12360.1.camel@cfw2.gniibe.org> <87ehghpwk9.fsf@vigenere.g10code.de> <1360937901.1886.2.camel@latx1.gniibe.org> <87y5epoa54.fsf@vigenere.g10code.de> <1361163668.3183.9.camel@cfw2.gniibe.org> <1380173248.3247.8.camel@cfw2.gniibe.org> Message-ID: <87k3hx9nxn.fsf@vigenere.g10code.de> On Thu, 26 Sep 2013 07:27, gniibe at fsij.org said: > Since then, I did some part of ECDSA in GnuPG 2.1.x. I tested it with > Gnuk development version for authentication. I have more and more doubts that using ECDSA by default in GnuPG is the Right Thing. Although I don't think that the NIST curves have been selected for possible future algorithm break or a chance for broken implementations, we can't be sure about it and many people will probably not trust them for non-technical reasons. Thus a released 2.1.0 will likely use Bernstein et al.'s curves by default. Given that it is unlikely that we will find an implementation of Curve25519 in a proprietary smartcard any time soon, I am bit lost on what do do with ECC and smartcards. Given that Gnuk would actually benefit from a fast software implementable curve, it might be a good idea to take the first step and do just that. Ed22519 is now implemented in Libgcrypt and a next step could be to squeeze it into the RFC-6637 format (using non-compressed points) and make it the default ECC signing algorithm. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ott at mirix.org Tue Oct 1 20:09:25 2013 From: ott at mirix.org (Matthias-Christian Ott) Date: Tue, 01 Oct 2013 20:09:25 +0200 Subject: ECC and smartcards In-Reply-To: <87k3hx9nxn.fsf@vigenere.g10code.de> References: <1326243062.2015.1.camel@latx1.gniibe.org> <1360911825.12360.1.camel@cfw2.gniibe.org> <87ehghpwk9.fsf@vigenere.g10code.de> <1360937901.1886.2.camel@latx1.gniibe.org> <87y5epoa54.fsf@vigenere.g10code.de> <1361163668.3183.9.camel@cfw2.gniibe.org> <1380173248.3247.8.camel@cfw2.gniibe.org> <87k3hx9nxn.fsf@vigenere.g10code.de> Message-ID: <524B0FD5.2040300@mirix.org> On 10/01/13 14:27, Werner Koch wrote: > I have more and more doubts that using ECDSA by default in GnuPG is the > Right Thing. Although I don't think that the NIST curves have been > selected for possible future algorithm break or a chance for broken > implementations, we can't be sure about it and many people will probably > not trust them for non-technical reasons. Thus a released 2.1.0 will > likely use Bernstein et al.'s curves by default. And thus limiting the security to "128 bits". > Given that it is unlikely that we will find an implementation of > Curve25519 in a proprietary smartcard any time soon, I am bit lost on > what do do with ECC and smartcards. The NXP Java Cards I bough some time ago (contact me if someone wants one) allow you to specify the curve parameters (untested). So it seems that you could use the Brainpool curves on these cards. At least their PRNG seed is a "nothing up my sleeve numbers". But if you worry about backdoors, I can imagine that the smartcards have probably have hidden functionality to extract keys from them or contain other intentional attack vectors or bugdoors in the hardware or operating system. Regards, Matthias-Christian From openpgp at brainhub.org Tue Oct 1 20:56:21 2013 From: openpgp at brainhub.org (Andrey Jivsov) Date: Tue, 01 Oct 2013 11:56:21 -0700 Subject: ECC and smartcards In-Reply-To: <87k3hx9nxn.fsf@vigenere.g10code.de> References: <1326243062.2015.1.camel@latx1.gniibe.org> <1360911825.12360.1.camel@cfw2.gniibe.org> <87ehghpwk9.fsf@vigenere.g10code.de> <1360937901.1886.2.camel@latx1.gniibe.org> <87y5epoa54.fsf@vigenere.g10code.de> <1361163668.3183.9.camel@cfw2.gniibe.org> <1380173248.3247.8.camel@cfw2.gniibe.org> <87k3hx9nxn.fsf@vigenere.g10code.de> Message-ID: <524B1AD5.2000806@brainhub.org> The main issue arising from this is interoperability. IMO any other curve as a standard curve for digital signastures will split already thin ecosystem of ECC to the degree that it's insignificant. Users will continue to use RSA/DSA keys as a result. Note that the situation regarding encryption is more forgiving. It's only with signatures when we need the widest interoperability base, because when I create a message or a key, I don't typically know who my verifies are. SuiteB curves are basically Neil Koblitz, a no-NSA-friend, curves with parameters a,b following standard rules, but which method of choice is unpublished. People would want to see curves generated as some sort of hash output, but if the hash is SHA, some of them will remain unconvinced. The bet against SuiteB weakness is that: 1) NSA knows about a (fundamental?) flaw in ECC 2) NSA is convinced that nobody will discover it, so that the US government data protection at TOP SECRET level is not at risk 3) the alternatives (i.e. Edwards curves) don't have this flaw and don't have other flaws related to special structure of the new curves 4) SHA2 algorithm is secure This thread is started about ECDSA, so + 5) you are worrying about NSA forging OpenPGP signatures (as opposed to breaking encryption) Also, many people are thinking that entire ECC is flawed, so + 6) RSA, DSA is stronger. My approach at this point is wait and see. In the calm 8 years between SuiteB announcement until NSA revelations ECC got some traction, but far from universal adoption. It's hard to see Edwards curves (or any other ECC curve) having much success (unless you have a closed system and don't care about anybody else, or an online protocol). On 10/01/2013 05:27 AM, Werner Koch wrote: > On Thu, 26 Sep 2013 07:27, gniibe at fsij.org said: > >> Since then, I did some part of ECDSA in GnuPG 2.1.x. I tested it with >> Gnuk development version for authentication. > > I have more and more doubts that using ECDSA by default in GnuPG is the > Right Thing. Although I don't think that the NIST curves have been > selected for possible future algorithm break or a chance for broken > implementations, we can't be sure about it and many people will probably > not trust them for non-technical reasons. Thus a released 2.1.0 will > likely use Bernstein et al.'s curves by default. > > Given that it is unlikely that we will find an implementation of > Curve25519 in a proprietary smartcard any time soon, I am bit lost on > what do do with ECC and smartcards. Given that Gnuk would actually > benefit from a fast software implementable curve, it might be a good > idea to take the first step and do just that. Ed22519 is now > implemented in Libgcrypt and a next step could be to squeeze it into the > RFC-6637 format (using non-compressed points) and make it the default > ECC signing algorithm. > > > Shalom-Salam, > > Werner > From ott at mirix.org Wed Oct 2 21:54:12 2013 From: ott at mirix.org (Matthias-Christian Ott) Date: Wed, 02 Oct 2013 21:54:12 +0200 Subject: True RNG and GnuPG / libgcrypt In-Reply-To: <1380163559.3247.5.camel@cfw2.gniibe.org> References: <1377157444.3419.8.camel@cfw2.gniibe.org> <1378092424.3168.5.camel@cfw2.gniibe.org> <5230B97E.2080408@mirix.org> <1380163559.3247.5.camel@cfw2.gniibe.org> Message-ID: <524C79E4.9020303@mirix.org> On 09/26/13 04:45, NIIBE Yutaka wrote: > For me, it will be simple and solid if we can use the output of an RNG > device directly, for key generation operation of GnuPG, given the > condition where such an RNG device has best quality. > > I mean, it would be good to have an interface which allows using RNG > device directly (even if /dev/random is available). That is a bad idea. How much ?true randomness? per bit does NeuG generate? If this is less than 1.0, you could weaken security. For example with (non-deterministic) DSA you could leak parts of the private key, if the attacker can predict partially predict the output of the random number generator with a model of the device. So you can't simply read 128 bit of output from the random number generator, use it directly as the key and assume that your key provides ?128 bit security?. You probably have to read a lot more and then compress the data with a hash function. >From what I've read about measuring the quality of randomness sources you have to test raw output of the random number generator (according to the website NeuG's output is biased and needs post-processing) and the output random number generator should significantly differ after each restart. AIS 31 is often cited in the context. Unfortunately I don't understand statistics involved, so you have to do the research yourself. For example with ring oscillator based random number generators which were believed to be simple and ?secure? (the VIA Padlock RNG is based on ring oscillators [1]), there have been publications recently that question to what extent the output of those generators is ?truly random? and to what extent it is deterministic. I guess what I want to say is the following: Measuring the quality of random number generators is not as easy as running the Diehard or NIST tests on the output and assuming that the output is ?truly random? just because it passes the tests. If you want to use the output of the random number generator directly you should somehow ?know? how much ?true randomness? per bit of output it yields. Feeding the output of the random number generator into /dev/random has the advantage that it gets mixed with other sources of randomness and that there is a single implementation that can be peer-reviewed. Probably there are better attacks than predicting the output of NeuG and xkcd 538 right, so this discussion doesn't matter in practice. Regards, Matthias-Christian [1] http://www.via.com.tw/en/downloads/whitepapers/initiatives/padlock/evaluation_padlock_rng.pdf From cswiger at mac.com Thu Oct 3 00:49:21 2013 From: cswiger at mac.com (Charles Swiger) Date: Wed, 02 Oct 2013 15:49:21 -0700 Subject: True RNG and GnuPG / libgcrypt In-Reply-To: <524C79E4.9020303@mirix.org> References: <1377157444.3419.8.camel@cfw2.gniibe.org> <1378092424.3168.5.camel@cfw2.gniibe.org> <5230B97E.2080408@mirix.org> <1380163559.3247.5.camel@cfw2.gniibe.org> <524C79E4.9020303@mirix.org> Message-ID: <3DCD67A3-F340-48EB-B2C2-B9025AF7B3AE@mac.com> Hi-- On Oct 2, 2013, at 12:54 PM, Matthias-Christian Ott wrote: > On 09/26/13 04:45, NIIBE Yutaka wrote: >> For me, it will be simple and solid if we can use the output of an RNG >> device directly, for key generation operation of GnuPG, given the >> condition where such an RNG device has best quality. >> >> I mean, it would be good to have an interface which allows using RNG >> device directly (even if /dev/random is available). > > That is a bad idea. How much ?true randomness? per bit does NeuG > generate? If this is less than 1.0, you could weaken security. For > example with (non-deterministic) DSA you could leak parts of the private > key, if the attacker can predict partially predict the output of the > random number generator with a model of the device. So you can't simply > read 128 bit of output from the random number generator, use it directly > as the key and assume that your key provides ?128 bit security?. You > probably have to read a lot more and then compress the data with a hash > function. Indeed, putting a hopefully-strong (but maybe not) RNG or PRNG behind a hash function like AES-256 is the notion which algorithms like Yarrow and Fortuna use, and which FreeBSD and MacOS X in turn use for our /dev/random devices: http://en.wikipedia.org/wiki/Yarrow_algorithm http://en.wikipedia.org/wiki/Fortuna_%28PRNG%29 It might be nice to accurately know whether a platform provides a trustworthy and genuinely random /dev/random, but there is no reason preventing GnuPG / libcrypt from doing Fortuna in userspace (aside spending some extra memory and CPU resources) so that it doesn't have to trust the quality of /dev/random. Regards, -- -Chuck From beebe at math.utah.edu Thu Oct 3 01:30:28 2013 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Wed, 2 Oct 2013 17:30:28 -0600 (MDT) Subject: [gnupg-devel] Re: True RNG and GnuPG / libgcrypt Message-ID: Matthias-Christian Ott responds on Wed, 02 Oct 2013 21:54:12 +0200 to an earlier question about possible direct-access to random-number-producing devices: >> ... >> If you want to use the output of the random number generator directly >> you should somehow know how much true randomness per bit of output it >> yields. Feeding the output of the random number generator into >> /dev/random has the advantage that it gets mixed with other sources of >> randomness and that there is a single implementation that can be >> peer-reviewed. >> ... That is definitely good advice. However, it is important to remember a distinction between the /dev/urandom and /dev/random device interfaces available on some flavors of Unix: Both produce random streams of bits, but /dev/urandom generally continues to produce output for every read, whereas /dev/random may block until the interface believes that enough additional entropy has been collected to produce more random bits. That means that reading /dev/random makes you susceptible to denial-of-service attacks that could be as simple as this: dd ibs=10240 count=1 < /dev/urandom > /dev/null I just tried that on one of my GNU/Linux servers and had the process hang for tens of seconds; changing it to read from /dev/urandom instead produced 10KB of data in 2 msec. I then increased the count from 1 to 10240, and pulled from /dev/urandom 100MB of random data in 6 to 20 seconds on a half-dozen different servers. If you have a single-user single-process machine, you might be immune to such attacks, but change either, or both, qualifiers "single-" to "multi-", and you could be a victim, even if the other consumer(s) of random bits from /dev/random are just trying to get data for their own use, rather than intentionally trying to deny YOU access to the device. If you are concerned about possible bias from a random-number generating device, here is an old technique that can fix it: Assume that the device is biased, but that the bias is CONSTANT. Then, it produces a 0-bit with probability p, and a 1-bit with probability 1 - p. Take two successive bits, and look at the four possible outcomes: 0 0 prob. = p * p = p^2 0 1 prob. = p(1 - p) 1 0 prob. = (1 - p)p = p(1 - p) 1 1 prob. = (1 - p)^2 The cases 0 0 and 1 1 have different probabilities (unless p = 1/2, but that is not possible because we said the generator is biased), so discard pairs of identical bits. The cases 0 1 and 1 0 have equal probability, so choose the second bit of each input pair where the two bits differ, and otherwise read a second pair of bits and retry. Assemble the chosen bits into an output stream. That stream contains 0 and 1 bits, each with equal probability. If p is near 1/2, then you consume about 8 bits for every 2 bits output, so your efficiency is only 0.25, and you have additional software overhead of working at the bit-level with shifting and counting, instead of at the higher level of random bytes and words. As p tends to either 0 or 1, the efficiency tends to 0. Of course, there could still be a problem, if the generator perversely gets stuck in a mode where it produces, perhaps only for certain time intervals, long sequences of alternating bits: 0 1 0 1 0 1 ....: your resampling according to the above algorithm then produces either 0 0 0 0 ... or 1 1 1 1 ..., sequences that are probably not what you expected. Issues like that are why random-number device drivers try to mix things up further, by arranging for multiple input sources, periodic remixing of those sources, hashing or other digital-signature algorithms, and so on. For more on that general problem, see the extensive bibliography of more than 3500 publications on generating, testing, and sampling of pseudorandom numbers at http://www.math.utah.edu/pub/tex/bib/prng.bib http://www.math.utah.edu/pub/tex/bib/prng.html The two URLs look almost identical in a browser, but the second has live hyperlinks, and the first is needed by BibTeX and associated bibliographic software. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From ekleog at gmail.com Thu Oct 3 13:55:33 2013 From: ekleog at gmail.com (Leo Gaspard) Date: Thu, 3 Oct 2013 13:55:33 +0200 Subject: True RNG and GnuPG / libgcrypt In-Reply-To: <3DCD67A3-F340-48EB-B2C2-B9025AF7B3AE@mac.com> References: <1377157444.3419.8.camel@cfw2.gniibe.org> <1378092424.3168.5.camel@cfw2.gniibe.org> <5230B97E.2080408@mirix.org> <1380163559.3247.5.camel@cfw2.gniibe.org> <524C79E4.9020303@mirix.org> <3DCD67A3-F340-48EB-B2C2-B9025AF7B3AE@mac.com> Message-ID: <20131003115533.GA29459@leortable> On Wed, Oct 02, 2013 at 03:49:21PM -0700, Charles Swiger wrote: > Indeed, putting a hopefully-strong (but maybe not) RNG or PRNG behind a hash > function like AES-256 is the notion which algorithms like Yarrow and Fortuna > use, and which FreeBSD and MacOS X in turn use for our /dev/random devices: > > http://en.wikipedia.org/wiki/Yarrow_algorithm > http://en.wikipedia.org/wiki/Fortuna_%28PRNG%29 > > It might be nice to accurately know whether a platform provides a trustworthy > and genuinely random /dev/random, but there is no reason preventing GnuPG / > libcrypt from doing Fortuna in userspace (aside spending some extra > memory and CPU resources) so that it doesn't have to trust the quality > of /dev/random. Knowing that /dev/random is directly OS-managed, distrusting it is directly like distrusting the OS. (Assuming the OS claims it has a secure randomness compressor.) And, once you do not trust your own OS, you can trust absolutely no program running on it. Thus you are not able to trust GnuPG, if you run it on your not-trusted OS. So I believe implementing a fortuna "generator" in GnuPG is not the most urgent improvement to be made -- though I know nothing of GnuPG's current most-wanted improvements. Cheers, Leo From cswiger at mac.com Thu Oct 3 20:10:10 2013 From: cswiger at mac.com (Charles Swiger) Date: Thu, 03 Oct 2013 11:10:10 -0700 Subject: True RNG and GnuPG / libgcrypt In-Reply-To: <20131003114730.GQ18701@leortable> References: <1377157444.3419.8.camel@cfw2.gniibe.org> <1378092424.3168.5.camel@cfw2.gniibe.org> <5230B97E.2080408@mirix.org> <1380163559.3247.5.camel@cfw2.gniibe.org> <524C79E4.9020303@mirix.org> <3DCD67A3-F340-48EB-B2C2-B9025AF7B3AE@mac.com> <20131003114730.GQ18701@leortable> Message-ID: Hi-- On Oct 3, 2013, at 4:47 AM, Leo Gaspard wrote: >> It might be nice to accurately know whether a platform provides a trustworthy >> and genuinely random /dev/random, but there is no reason preventing GnuPG / >> libcrypt from doing Fortuna in userspace (aside spending some extra >> memory and CPU resources) so that it doesn't have to trust the quality >> of /dev/random. > > Knowing that /dev/random is directly OS-managed, distrusting it is directly like > distrusting the OS. (Assuming the OS claims it has a secure randomness > compressor.) > > And, once you do not trust your own OS, you can trust absolutely no program > running on it. Thus you are not able to trust GnuPG, if you run it on your > not-trusted OS. Yes, that's true as far as it goes: if the OS has been maliciously compromised, then no program running on it can be considered secure or trustworthy. However, please also note that bugs or flaws in what was believed to be a good implementation of /dev/random, OpenSSL's rand, etc can lead to weak crypto. A recent case-in-point was the Android SecureRandom issue affecting Bitcoin and possibly other apps, which was due to OpenSSL not being properly initialized: http://android-developers.blogspot.co.uk/2013/08/some-securerandom-thoughts.html > So I believe implementing a fortuna "generator" in GnuPG is not the most urgent > improvement to be made -- though I know nothing of GnuPG's current most-wanted > improvements. I seem to recall interest in supporting GnuPG on Android, so it would seem worthwhile to make sure that GnuPG is properly seeding OpenSSL and/or libgcrypt. My own quick check of libgcrypt sources suggests that it will treat Android as a Linux flavor and try to seed its CSPRNG from /dev/random. Regards, -- -Chuck From ott at mirix.org Thu Oct 3 20:27:15 2013 From: ott at mirix.org (Matthias-Christian Ott) Date: Thu, 03 Oct 2013 20:27:15 +0200 Subject: [gnupg-devel] Re: True RNG and GnuPG / libgcrypt In-Reply-To: References: Message-ID: <524DB703.4040908@mirix.org> On 10/03/13 01:30, Nelson H. F. Beebe wrote: > Matthias-Christian Ott responds on Wed, 02 Oct 2013 > 21:54:12 +0200 to an earlier question about possible direct-access > to random-number-producing devices: > >>> ... >>> If you want to use the output of the random number generator directly >>> you should somehow know how much true randomness per bit of output it >>> yields. Feeding the output of the random number generator into >>> /dev/random has the advantage that it gets mixed with other sources of >>> randomness and that there is a single implementation that can be >>> peer-reviewed. >>> ... > > That is definitely good advice. > > However, it is important to remember a distinction between the > /dev/urandom and /dev/random device interfaces available on some > flavors of Unix: > > Both produce random streams of bits, but /dev/urandom > generally continues to produce output for every read, whereas > /dev/random may block until the interface believes that enough > additional entropy has been collected to produce more random > bits. FreeBSD doesn't distinguish them for example. I think the semantics of /dev/random are supposed to be the following: Cryptography often needs ?true randomness? for key generation and other operations. /dev/random uses an entropy estimator to only output ?true randomness? from different sources to a requesting application. The application can be sure that if it needs n bits ?true randomness? it will get it. This leaves two questions: What to do when /dev/random is an alias for /dev/urandom, i.e. what should software do that needs n bit randomness for cryptography? Does entropy estimation work? What if some proprietary device produces lower amounts than the entropy estimator assumes? Especially as an application developer who just needs n bits of ?true randomness? these are hard questions. Do you for example really need 128 bits or a 64 bits that are ?stretched? to 128 bits enough? Are realistic attacks possible if you got less than n bits of ?true randomness?? For NeuG this also leaves the question: How to estimate how much ?true randomness? is in NeuG's output (on Linux you have to do this when you feed data to /dev/random via the RNDADDENTROPY ioctl or you weaken the security of software that depends on the entropy estimator of /dev/random)? > That means that reading /dev/random makes you susceptible to > denial-of-service attacks that could be as simple as this: > > dd ibs=10240 count=1 < /dev/urandom > /dev/null I think what you meant here is: dd ibs=10240 count=1 < /dev/random > /dev/null > I just tried that on one of my GNU/Linux servers and had the process > hang for tens of seconds; changing it to read from /dev/urandom > instead produced 10KB of data in 2 msec. I then increased the count > from 1 to 10240, and pulled from /dev/urandom 100MB of random data in > 6 to 20 seconds on a half-dozen different servers. > If you have a single-user single-process machine, you might be immune > to such attacks, but change either, or both, qualifiers "single-" to > "multi-", and you could be a victim, even if the other consumer(s) of > random bits from /dev/random are just trying to get data for their own > use, rather than intentionally trying to deny YOU access to the > device. That sounds to be a tough problem and probably involves resource limits and process priorities. Regards, Matthias-Christian From ekleog at gmail.com Thu Oct 3 22:11:59 2013 From: ekleog at gmail.com (Leo Gaspard) Date: Thu, 3 Oct 2013 22:11:59 +0200 Subject: True RNG and GnuPG / libgcrypt In-Reply-To: References: <1377157444.3419.8.camel@cfw2.gniibe.org> <1378092424.3168.5.camel@cfw2.gniibe.org> <5230B97E.2080408@mirix.org> <1380163559.3247.5.camel@cfw2.gniibe.org> <524C79E4.9020303@mirix.org> <3DCD67A3-F340-48EB-B2C2-B9025AF7B3AE@mac.com> <20131003114730.GQ18701@leortable> Message-ID: <20131003201159.GB29459@leortable> Hi, On Thu, Oct 03, 2013 at 11:10:10AM -0700, Charles Swiger wrote: > On Oct 3, 2013, at 4:47 AM, Leo Gaspard wrote: > > Knowing that /dev/random is directly OS-managed, distrusting it is directly like > > distrusting the OS. (Assuming the OS claims it has a secure randomness > > compressor.) > > > > And, once you do not trust your own OS, you can trust absolutely no program > > running on it. Thus you are not able to trust GnuPG, if you run it on your > > not-trusted OS. > > Yes, that's true as far as it goes: if the OS has been maliciously compromised, > then no program running on it can be considered secure or trustworthy. > > However, please also note that bugs or flaws in what was believed to be a good > implementation of /dev/random, OpenSSL's rand, etc can lead to weak crypto. > A recent case-in-point was the Android SecureRandom issue affecting Bitcoin and > possibly other apps, which was due to OpenSSL not being properly initialized: > > http://android-developers.blogspot.co.uk/2013/08/some-securerandom-thoughts.html In this case, wouldn't re-reading and triple-checking that these randomness-generating algorithms are indeed "random" be a better effort for the whole crypto community ? This way, each and every application can benefit from the work made on /dev/random. What's more, adding yet another random number generator means yet another randomness library to be checked for bugs. > > So I believe implementing a fortuna "generator" in GnuPG is not the most urgent > > improvement to be made -- though I know nothing of GnuPG's current most-wanted > > improvements. > > I seem to recall interest in supporting GnuPG on Android, so it would seem worthwhile > to make sure that GnuPG is properly seeding OpenSSL and/or libgcrypt. My own quick > check of libgcrypt sources suggests that it will treat Android as a Linux flavor > and try to seed its CSPRNG from /dev/random. In this case, wouldn't developing a general algorithm for randomness accumulation and then proposing it to android for inclusion be a better idea than just sticking it in gnupg ? This way, all applications can take advantage of the new randomness accumulation algorithm. And maybe would it even be possible to re-use GNU/Linux's /dev/random generator. However, not knowing much about development on android, I am not to be trusted with ideas. BTW, reading the first few paragraphs of the article you linked, seeding the PRNG from /dev/random *is* actually the thing to do, as the issue with android would be (if I understood) that it does not properly seed its PRNG. Regards, Leo From cswiger at mac.com Thu Oct 3 22:56:44 2013 From: cswiger at mac.com (Charles Swiger) Date: Thu, 03 Oct 2013 13:56:44 -0700 Subject: True RNG and GnuPG / libgcrypt In-Reply-To: <20131003201159.GB29459@leortable> References: <1377157444.3419.8.camel@cfw2.gniibe.org> <1378092424.3168.5.camel@cfw2.gniibe.org> <5230B97E.2080408@mirix.org> <1380163559.3247.5.camel@cfw2.gniibe.org> <524C79E4.9020303@mirix.org> <3DCD67A3-F340-48EB-B2C2-B9025AF7B3AE@mac.com> <20131003114730.GQ18701@leortable> <20131003201159.GB29459@leortable> Message-ID: <432FC483-1D93-4CC3-9574-7DA69800668E@mac.com> Hi-- On Oct 3, 2013, at 1:11 PM, Leo Gaspard wrote: >> However, please also note that bugs or flaws in what was believed to be a good >> implementation of /dev/random, OpenSSL's rand, etc can lead to weak crypto. >> A recent case-in-point was the Android SecureRandom issue affecting Bitcoin and >> possibly other apps, which was due to OpenSSL not being properly initialized: >> >> http://android-developers.blogspot.co.uk/2013/08/some-securerandom-thoughts.html > > In this case, wouldn't re-reading and triple-checking that these > randomness-generating algorithms are indeed "random" be a better effort for the > whole crypto community ? This way, each and every application can benefit from > the work made on /dev/random. Yes, that's likely why Ferguson, Kelsey, & Schneier released Yarrow (and I believe Fortuna as well) under open, royalty-free license terms. However, a user running GnuPG on an existing version of whatever OS isn't going to suddenly obtain a better /dev/random unless the OS vendor releases a patch or update. And the user gets that update installed; OpenSSL, libgcrypt, Java's crypto stuff, etc is updated and told to use /dev/random for seeding rather than using a default static seed initialization; and so forth up through the application stack. >>> So I believe implementing a fortuna "generator" in GnuPG is not the most urgent >>> improvement to be made -- though I know nothing of GnuPG's current most-wanted >>> improvements. >> >> I seem to recall interest in supporting GnuPG on Android, so it would seem worthwhile >> to make sure that GnuPG is properly seeding OpenSSL and/or libgcrypt. My own quick >> check of libgcrypt sources suggests that it will treat Android as a Linux flavor >> and try to seed its CSPRNG from /dev/random. > > In this case, wouldn't developing a general algorithm for randomness > accumulation and then proposing it to android for inclusion be a better idea > than just sticking it in gnupg ? > > This way, all applications can take advantage of the new randomness accumulation > algorithm. And maybe would it even be possible to re-use GNU/Linux's /dev/random > generator. Someone has already done the work of porting Fortuna to Linux 2.6.x here: http://jlcooke.ca/random/ > However, not knowing much about development on android, I am not to be trusted > with ideas. That's OK-- the Google folks lurking some ~5 miles to the west in Mountain View, CA will do what they feel is best for the Android platform. :-) > BTW, reading the first few paragraphs of the article you linked, seeding the > PRNG from /dev/random *is* actually the thing to do, as the issue with android > would be (if I understood) that it does not properly seed its PRNG. Yes, that's my impression as well. Of course, it also means that you need to trust that /dev/random provides high-quality random numbers. Regards, -- -Chuck From wk at gnupg.org Fri Oct 4 13:39:37 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Oct 2013 13:39:37 +0200 Subject: Checking key server response against the request parameters In-Reply-To: <20130915212250.GM21970@zirkel.wertarbyte.de> (Stefan Tomanek's message of "Sun, 15 Sep 2013 23:22:50 +0200") References: <20130913064854.GZ21970@zirkel.wertarbyte.de> <20130915212250.GM21970@zirkel.wertarbyte.de> Message-ID: <8761td5kp2.fsf@vigenere.g10code.de> On Sun, 15 Sep 2013 23:22, tomanek at internet-sicherheit.de said: > I just noticed that gnupg will even import secret keys from any keyserver > response if the key data is prefixed with "BEGIN PGP PUBLIC KEY DATA". That is correct. It will do so even for keys retrieved via DNS. I have a pretty simple patch against this in the queue. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Oct 5 10:46:39 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Oct 2013 10:46:39 +0200 Subject: [Announce] [security fix] GnuPG 2.0.22 released Message-ID: <87eh803y1c.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.22. This is a *security fix* release and all users are advised to updated to this version. See below for the impact of the problem. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.14) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPLv3+). GnuPG-2 works best on GNU/Linux and *BSD systems but is also available for other Unices, Microsoft Windows and Mac OS X. What's New in 2.0.22 ==================== * Fixed possible infinite recursion in the compressed packet parser. [CVE-2013-4402] * Improved support for some card readers. * Prepared building with the forthcoming Libgcrypt 1.6. * Protect against rogue keyservers sending secret keys. Impact of the security problem ============================== Special crafted input data may be used to cause a denial of service against GPG (GnuPG's OpenPGP part) and some other OpenPGP implementations. All systems using GPG to process incoming data are affected. Taylor R. Campbell invented a neat trick to generate OpenPGP packages to force GPG to recursively parse certain parts of OpenPGP messages ad infinitum. As a workaround a tight "ulimit -v" setting may be used to mitigate the problem. Sample input data to trigger this problem has not yet been seen in the wild. Details of the attack will eventually be published by its inventor. A fixed release of the GnuPG 1.4 series has also been released. An updated vesion of gpg4win will be released next week. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.22 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . 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 FTP server and its mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.22.tar.bz2 (4200k) gnupg-2.0.22.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.20-2.0.22.diff.bz2 (39k) A patch file to upgrade a 2.0.20 GnuPG source tree. This patch does not include updates of the language files. Note, that we don't distribute gzip compressed tarballs for GnuPG-2. 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-2.0.22.tar.bz2 you would use this command: gpg --verify gnupg-2.0.22.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 or using a keyserver like gpg --keyserver keys.gnupg.net --recv-key 4F25E3B6 The distribution key 4F25E3B6 is signed by the well known key 1E42B367. 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-2.0.22.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.22.tar.bz2 and check that the output matches the first line from the following list: 9ba9ee288e9bf813e0f1e25cbe06b58d3072d8b8 gnupg-2.0.22.tar.bz2 6cc51b14ed652fe7eadae25ec7cdaa6f63377525 gnupg-2.0.21-2.0.22.diff.bz2 Documentation ============= The file gnupg.info has the complete user manual of the system. Separate man pages are included as well; however they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Almost all mail clients support GnuPG-2. Mutt users may want to use the configure option "--enable-gpgme" during build time and put a "set use_crypt_gpgme" in ~/.muttrc to enable S/MIME support along with the reworked OpenPGP support. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . We also have a dedicated service directory at: 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 takes up most of their resources. To allow him to continue this work he kindly asks to either purchase a support contract, engage g10 Code 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, administering the servers, spreading the word, or answering questions on the mailing lists. Happy Hacking, The GnuPG Team -- 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 wk at gnupg.org Sat Oct 5 10:56:32 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Oct 2013 10:56:32 +0200 Subject: [Announce] [security fix] GnuPG 1.4.15 released Message-ID: <877gds3xkv.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-1 release: Version 1.4.15. This is a *security fix* release and all users are advised to updated to this version. See below for the impact of the problem. 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.22) 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 =========== * Fixed possible infinite recursion in the compressed packet parser. [CVE-2013-4402] * Protect against rogue keyservers sending secret keys. * Use 2048 bit also as default for batch key generation. * Minor bug fixes. Impact of the security problem ============================== Special crafted input data may be used to cause a denial of service against GPG (GnuPG's OpenPGP part) and some other OpenPGP implementations. All systems using GPG to process incoming data are affected. Taylor R. Campbell invented a neat trick to generate OpenPGP packages to force GPG to recursively parse certain parts of OpenPGP messages ad infinitum. As a workaround a tight "ulimit -v" setting may be used to mitigate the problem. Sample input data to trigger this problem has not yet been seen in the wild. Details of the attack will eventually be published by its inventor. A fixed release of the GnuPG 2.0 series has also been released. 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.15 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.15.tar.bz2 (3569k) gnupg-1.4.15.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.15.tar.gz (4948k) gnupg-1.4.15.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.14-1.4.15.diff.bz2 (37k) A patch file to upgrade a 1.4.14 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.15.exe (1568k) gnupg-w32cli-1.4.15.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 . An updated version of gpg4win is scheduled for next week. 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.15.tar.bz2 you would use this command: gpg --verify gnupg-1.4.15.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 4F25E3B6 is signed by the well known key 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.14.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.15.tar.bz2 and check that the output matches the first line from the following list: 63ebf0ab375150903c65738070e4105200197fd4 gnupg-1.4.15.tar.bz2 2881c8174c15bb86ecf2e879cb7ca22c91fbcf93 gnupg-1.4.15.tar.gz 0e3a593da55be0fb9a556513ce034e13677e5ebc gnupg-1.4.14-1.4.15.diff.bz2 1adda83f3eda5a2ac6d362c294e31fbb529a03e4 gnupg-w32cli-1.4.15.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 -- 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 wk at gnupg.org Sat Oct 5 11:19:26 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Oct 2013 11:19:26 +0200 Subject: Patches for 2.0.21 Message-ID: <87txgw2hy9.fsf@vigenere.g10code.de> Hi! unfortunately the git server is currently down. Security teams who want to use a minimal fix, I attach the two relevant patches (2.0 version) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-Fix-bug-with-deeply-nested-compressed-packets.patch Type: text/x-diff Size: 5189 bytes Desc: GnuPG 2.0 patch 1 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-gpg-Limit-the-nesting-level-of-I-O-filters.patch Type: text/x-diff Size: 8084 bytes Desc: GnuPG 2.0 patch 2 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: From wk at gnupg.org Sat Oct 5 11:23:55 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Oct 2013 11:23:55 +0200 Subject: GnuPG 1.4.14 patches Message-ID: <87pprk2hqs.fsf@vigenere.g10code.de> Hi! unfortunately the git server is currently down. Security teams who want to use a minimal fix, may use these patches. (1.4 version) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-Fix-bug-with-deeply-nested-compressed-packets.patch Type: text/x-diff Size: 5193 bytes Desc: GnuPG 2.0 patch 1 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-gpg-Limit-the-nesting-level-of-I-O-filters.patch Type: text/x-diff Size: 9830 bytes Desc: GnuPG 2.0 patch 2 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: From tomanek at internet-sicherheit.de Sat Oct 5 12:34:30 2013 From: tomanek at internet-sicherheit.de (Stefan Tomanek) Date: Sat, 5 Oct 2013 12:34:30 +0200 Subject: Checking key server response against the request parameters In-Reply-To: <8761td5kp2.fsf@vigenere.g10code.de> References: <20130913064854.GZ21970@zirkel.wertarbyte.de> <20130915212250.GM21970@zirkel.wertarbyte.de> <8761td5kp2.fsf@vigenere.g10code.de> Message-ID: <20131005103430.GD6981@zirkel.wertarbyte.de> Hello, Dies schrieb Werner Koch (wk at gnupg.org): > > I just noticed that gnupg will even import secret keys from any keyserver > > response if the key data is prefixed with "BEGIN PGP PUBLIC KEY DATA". > > That is correct. It will do so even for keys retrieved via DNS. I have > a pretty simple patch against this in the queue. With that sorted out, did you find the time to look over my patch regarding the matching of keyserver responses to their request parameters? Sincerly Stefan Tomanek -- if(is) - Institut f?r Internet-Sicherheit Westf?lische Hochschule, Gelsenkirchen OpenPGP-Schl?sselkennung: 0x2788CD17B78FEAFA OpenPGP-Fingerabdruck: 15F9 00BF BA9B 685D 15D0 266C 2788 CD17 B78F EAFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: Digital signature URL: From lrn1986 at gmail.com Mon Oct 7 22:35:37 2013 From: lrn1986 at gmail.com (LRN) Date: Tue, 08 Oct 2013 00:35:37 +0400 Subject: Does gitweb work for everyone? Message-ID: <52531B19.4040404@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is it just me, or [1] is broken? [1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=shortlog;h=refs/heads/master - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJSUxsYAAoJEOs4Jb6SI2CwNxkIAKO218uwI51cGJKNWOuWHpwB SlQmYt61022BcopAL1kJw5Hcaa0vVGGU2w5BSZGRBE8swYxqXwdrccIQK1ccXUrx O1sWpQRGSNXP/IV4aXfoGW6blbrtsD7wjgJh0/6hopU+acx57rxSV/owuSD9+2G7 KsyJmPFt/F2IcvX1R1CItNGvWxPGWRr3lOnb0jGMIOxtD6C3UJm3FrCi7Jf93wCH 2RruD2V4qQTbqyjJLG52XuPOec39JB5JggnjI6+pRo2+5cCokc5PNeO+niTK/3eQ Scd8JlMs625iDYksw/otesTrn81l+SitMczneHrOsrRwclo/Dqv/8KcvyjTD+KY= =VK0S -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Tue Oct 8 06:33:52 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 08 Oct 2013 00:33:52 -0400 Subject: Does gitweb work for everyone? In-Reply-To: <52531B19.4040404@gmail.com> References: <52531B19.4040404@gmail.com> Message-ID: <52538B30.6020906@fifthhorseman.net> On 10/07/2013 04:35 PM, LRN wrote: > Is it just me, or [1] is broken? > > [1] > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=shortlog;h=refs/heads/master http://lists.gnutls.org/pipermail/gnupg-devel/2013-October/027995.html says: >> unfortunately the git server is currently down. Werner is aware of the problem, and has said he hopes to get the machine back up soon. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From gnupg-devel at spodhuis.org Tue Oct 8 07:42:52 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Tue, 8 Oct 2013 01:42:52 -0400 Subject: Does gitweb work for everyone? In-Reply-To: <52531B19.4040404@gmail.com> References: <52531B19.4040404@gmail.com> Message-ID: <20131008054252.GA16987@redoubt.spodhuis.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 2013-10-08 at 00:35 +0400, LRN wrote: > Is it just me, or [1] is broken? > > [1] > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=shortlog;h=refs/heads/master As already noted, it's a known issue. In the meantime: I sync some git mirrors daily, including some GnuPG.org repos; shows the last update to the repo was on October 2nd (the gnupg.org git fetches started failing on Saturday). (The update process also tars up the before/after status of the git status links, so if there's major damage, I can roll back.) It looks like the latest commits to the branches in my mirror are to fix the security issue per the patches. Oh, and is there too. - -Phil -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlJTm1MACgkQQDBDFTkDY3/xugCffsra0KufYeS0FI7rKd7JOC0f 3EoAn1Y2DANBxrq0DyQkT0Hi8dLQoEzp =QMeN -----END PGP SIGNATURE----- From xantares09 at hotmail.com Tue Oct 8 11:22:59 2013 From: xantares09 at hotmail.com (xantares 09) Date: Tue, 8 Oct 2013 09:22:59 +0000 Subject: libgcrypt parallel install bug Message-ID: Hi, I think there is a bug in libgcrypt with parallel make install target in case of a mingw build. The rule for installing libgcrypt.def assumes $(DESTDIR)$(libdir) has been previously created, in src/Makefile.in @HAVE_W32_SYSTEM_TRUE at install-def-file: @HAVE_W32_SYSTEM_TRUE@ $(INSTALL) $(srcdir)/libgcrypt.def $(DESTDIR)$(libdir)/libgcrypt.def It should test and call MKDIR_P if necessary on $(DESTDIR)$(libdir), or the rule could depend on install-libLTLIBRARIES target, which creates libdir. x. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Oct 8 13:29:56 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Oct 2013 13:29:56 +0200 Subject: Does gitweb work for everyone? In-Reply-To: <20131008054252.GA16987@redoubt.spodhuis.org> (Phil Pennock's message of "Tue, 8 Oct 2013 01:42:52 -0400") References: <52531B19.4040404@gmail.com> <20131008054252.GA16987@redoubt.spodhuis.org> Message-ID: <8761t8yp8r.fsf@vigenere.g10code.de> On Tue, 8 Oct 2013 07:42, gnupg-devel at spodhuis.org said: > It looks like the latest commits to the branches in my mirror are to fix > the security issue per the patches. The latest commits for 1.4. and 2.0 have the release tags. I did this on Friday and the server started to fail on early Saturday morning. GnuPG master should be at 7c5d290. I still waiting for the new machine and don't want to move the repo temporary to another box; after all it is a DVCS. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Oct 8 13:31:14 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Oct 2013 13:31:14 +0200 Subject: libgcrypt parallel install bug In-Reply-To: (xantares's message of "Tue, 8 Oct 2013 09:22:59 +0000") References: Message-ID: <871u3wyp6l.fsf@vigenere.g10code.de> On Tue, 8 Oct 2013 11:22, xantares09 at hotmail.com said: > It should test and call MKDIR_P if necessary on $(DESTDIR)$(libdir), or the rule could depend on install-libLTLIBRARIES target, which creates libdir. Right. I'll fix that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Oct 9 21:28:42 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Oct 2013 21:28:42 +0200 Subject: git.gnupg.org back online Message-ID: <871u3uw8et.fsf@vigenere.g10code.de> Hi, I migrated the git server to a new box. This is a VM sponsored by OpenIT. This should better protect against hardware failures stopping the git service for longer periods. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From xantares09 at hotmail.com Mon Oct 14 10:17:23 2013 From: xantares09 at hotmail.com (xantares 09) Date: Mon, 14 Oct 2013 08:17:23 +0000 Subject: libgcrypt parallel install bug In-Reply-To: <871u3wyp6l.fsf@vigenere.g10code.de> References: , <871u3wyp6l.fsf@vigenere.g10code.de> Message-ID: > From: wk at gnupg.org > To: xantares09 at hotmail.com > CC: gnupg-devel at gnupg.org > Subject: Re: libgcrypt parallel install bug > Date: Tue, 8 Oct 2013 13:31:14 +0200 > > On Tue, 8 Oct 2013 11:22, xantares09 at hotmail.com said: > > > It should test and call MKDIR_P if necessary on $(DESTDIR)$(libdir), or the rule could depend on install-libLTLIBRARIES target, which creates libdir. > > Right. I'll fix that. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > Hi, Or we can simply do "install -D" in src/Makefile.am: install-def-file: $(INSTALL) -D $(srcdir)/libgcrypt.def $(DESTDIR)$(libdir)/libgcrypt.def Regard, x. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Oct 15 13:16:45 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 15 Oct 2013 13:16:45 +0200 Subject: ECC and smartcards In-Reply-To: <524B1AD5.2000806@brainhub.org> (Andrey Jivsov's message of "Tue, 01 Oct 2013 11:56:21 -0700") References: <1326243062.2015.1.camel@latx1.gniibe.org> <1360911825.12360.1.camel@cfw2.gniibe.org> <87ehghpwk9.fsf@vigenere.g10code.de> <1360937901.1886.2.camel@latx1.gniibe.org> <87y5epoa54.fsf@vigenere.g10code.de> <1361163668.3183.9.camel@cfw2.gniibe.org> <1380173248.3247.8.camel@cfw2.gniibe.org> <87k3hx9nxn.fsf@vigenere.g10code.de> <524B1AD5.2000806@brainhub.org> Message-ID: <87d2n6okbm.fsf@vigenere.g10code.de> On Tue, 1 Oct 2013 20:56, openpgp at brainhub.org said: > IMO any other curve as a standard curve for digital signastures will > split already thin ecosystem of ECC to the degree that it's > insignificant. Users will continue to use RSA/DSA keys as a result. I don't know of any released OpenPGP implementation with support for ECC. Well, there is a GnuPG beta and some people are already using it. However, before ECC support can actually be declared stable we need to get a real release out. Even then, the generation of ECC keys will only be available in --expert mode for, say, a year before it can be declared mainstream. We need this delay so that a large installation base of ECC enabled GnuPGs is available. > SuiteB curves are basically Neil Koblitz, a no-NSA-friend, curves with > parameters a,b following standard rules, but which method of choice is > unpublished. Right - this raises a lot of suspicion and did that for many years. In Europe the Brainpool curves are strongly preferred over the NIST curves. Maybe because they have been developed without hiding the way they have been generated - maybe out of other reasons. We don't know. Thus I consider it better to step aside the issue and use what is currently considered the best choice. > 1) NSA knows about a (fundamental?) flaw in ECC > 2) NSA is convinced that nobody will discover it, so that the US > government data protection at TOP SECRET level is not at risk > 3) the alternatives (i.e. Edwards curves) don't have this flaw and > don't have other flaws related to special structure of the new curves > 4) SHA2 algorithm is secure This has all been discussed elsewhere and despite that nobody has an idea on how the NSA may have subverted the curves, it is better to avoid them if technically possible. We are lucky enough that there are no deployed OpenPG ECC keys and thus there is still time for a change. > 5) you are worrying about NSA forging OpenPGP signatures (as opposed > to breaking encryption) Signatures are often more important than encryption. All the OpenPGP security relies on digital signatures. This it is good target for an active attack. > Also, many people are thinking that entire ECC is flawed, so + > 6) RSA, DSA is stronger. Some people are righly thinking that all software is flawed. > far from universal adoption. It's hard to see Edwards curves (or any > other ECC curve) having much success (unless you have a closed system > and don't care about anybody else, or an online protocol). Two weeks ago I had the opportunity to chat with PRZ about this topic. He agrees that ECC will be the future and that we should use the Bernstein curves for PGP. For Silent Circle they can't use 25519 because the security margin is less than of the currently used P-384. Thus they are waiting for DJB to finish the development a 400+ bit curve. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Wed Oct 16 03:05:14 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 16 Oct 2013 10:05:14 +0900 Subject: scd: pinpad input improvements Message-ID: <1381885514.3175.4.camel@cfw2.gniibe.org> For the issue 1549, I commit and pushed my changes for scd/apdu.c. The bug was introduced by me when I added PINMIN/PINMAX handling and I forgot to remove old code (which should have removed). https://bugs.g10code.com/gnupg/issue1549 Also, I created a wiki page at: http://wiki.gnupg.org/CardReader/PinpadInput If people have other card readers, please add information. -- From tomanek at internet-sicherheit.de Sun Oct 20 14:53:23 2013 From: tomanek at internet-sicherheit.de (Stefan Tomanek) Date: Sun, 20 Oct 2013 14:53:23 +0200 Subject: [PATCH v4] filter and verify keyserver responses Message-ID: <20131020125323.GT17429@zirkel.wertarbyte.de> This changes introduces import functions that apply a constraining filter to imported keys. These filters can verify the fingerprints of the keys returned before importing them into the keyring, ensuring that the keys fetched from the keyserver are in fact those selected by the user beforehand. It also prevents the accidental import of secret keys through key server responses. --- g10/import.c | 47 ++++++++++++++++++++++++++++++++--------------- g10/keyserver.c | 48 ++++++++++++++++++++++++++++++++++++++++++++---- g10/main.h | 4 +++- 3 files changed, 79 insertions(+), 20 deletions(-) diff --git a/g10/import.c b/g10/import.c index 441dcca..cd93f12 100644 --- a/g10/import.c +++ b/g10/import.c @@ -59,14 +59,17 @@ struct stats_s { static int import( IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options ); + unsigned char **fpr,size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ); static int read_block( IOBUF a, PACKET **pending_pkt, KBNODE *ret_root ); static void revocation_present(KBNODE keyblock); static int import_one(const char *fname, KBNODE keyblock,struct stats_s *stats, unsigned char **fpr,size_t *fpr_len, - unsigned int options,int from_sk); + unsigned int options,int from_sk, + import_filter filter, void *filter_arg); static int import_secret_one( const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options); + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg ); static int import_revoke_cert( const char *fname, KBNODE node, struct stats_s *stats); static int chk_self_sigs( const char *fname, KBNODE keyblock, @@ -163,7 +166,8 @@ import_release_stats_handle (void *p) static int import_keys_internal( IOBUF inp, char **fnames, int nnames, void *stats_handle, unsigned char **fpr, size_t *fpr_len, - unsigned int options ) + unsigned int options, + import_filter filter, void *filter_arg ) { int i, rc = 0; struct stats_s *stats = stats_handle; @@ -172,7 +176,7 @@ import_keys_internal( IOBUF inp, char **fnames, int nnames, stats = import_new_stats_handle (); if (inp) { - rc = import( inp, "[stream]", stats, fpr, fpr_len, options); + rc = import( inp, "[stream]", stats, fpr, fpr_len, options, filter, filter_arg); } else { int once = (!fnames && !nnames); @@ -192,7 +196,7 @@ import_keys_internal( IOBUF inp, char **fnames, int nnames, log_error(_("can't open `%s': %s\n"), fname, strerror(errno) ); else { - rc = import( inp2, fname, stats, fpr, fpr_len, options ); + rc = import( inp2, fname, stats, fpr, fpr_len, options, NULL, NULL ); iobuf_close(inp2); /* Must invalidate that ugly cache to actually close it. */ iobuf_ioctl (NULL, 2, 0, (char*)fname); @@ -223,19 +227,21 @@ void import_keys( char **fnames, int nnames, void *stats_handle, unsigned int options ) { - import_keys_internal(NULL,fnames,nnames,stats_handle,NULL,NULL,options); + import_keys_internal(NULL,fnames,nnames,stats_handle,NULL,NULL,options,NULL,NULL); } int import_keys_stream( IOBUF inp, void *stats_handle, - unsigned char **fpr, size_t *fpr_len,unsigned int options ) + unsigned char **fpr, size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ) { - return import_keys_internal(inp,NULL,0,stats_handle,fpr,fpr_len,options); + return import_keys_internal(inp,NULL,0,stats_handle,fpr,fpr_len,options,filter,filter_arg); } static int import( IOBUF inp, const char* fname,struct stats_s *stats, - unsigned char **fpr,size_t *fpr_len,unsigned int options ) + unsigned char **fpr,size_t *fpr_len,unsigned int options, + import_filter filter, void *filter_arg ) { PACKET *pending_pkt = NULL; KBNODE keyblock = NULL; @@ -252,9 +258,10 @@ import( IOBUF inp, const char* fname,struct stats_s *stats, while( !(rc = read_block( inp, &pending_pkt, &keyblock) )) { if( keyblock->pkt->pkttype == PKT_PUBLIC_KEY ) - rc = import_one( fname, keyblock, stats, fpr, fpr_len, options, 0); + rc = import_one( fname, keyblock, stats, fpr, fpr_len, options, 0, + filter, filter_arg); else if( keyblock->pkt->pkttype == PKT_SECRET_KEY ) - rc = import_secret_one( fname, keyblock, stats, options ); + rc = import_secret_one( fname, keyblock, stats, options, filter, filter_arg ); else if( keyblock->pkt->pkttype == PKT_SIGNATURE && keyblock->pkt->pkt.signature->sig_class == 0x20 ) rc = import_revoke_cert( fname, keyblock, stats ); @@ -738,7 +745,7 @@ check_prefs(KBNODE keyblock) static int import_one( const char *fname, KBNODE keyblock, struct stats_s *stats, unsigned char **fpr,size_t *fpr_len,unsigned int options, - int from_sk ) + int from_sk, import_filter filter, void *filter_arg) { PKT_public_key *pk; PKT_public_key *pk_orig; @@ -778,6 +785,10 @@ import_one( const char *fname, KBNODE keyblock, struct stats_s *stats, return 0; } + if (filter && filter(pk, NULL, filter_arg)) { + log_error( _("key %s: rejected by import filter\n"), keystr_from_pk(pk)); + return 0; + } if (opt.interactive) { if(is_status_enabled()) print_import_check (pk, uidnode->pkt->pkt.user_id); @@ -1146,7 +1157,8 @@ sec_to_pub_keyblock(KBNODE sec_keyblock) */ static int import_secret_one( const char *fname, KBNODE keyblock, - struct stats_s *stats, unsigned int options) + struct stats_s *stats, unsigned int options, + import_filter filter, void *filter_arg ) { PKT_secret_key *sk; KBNODE node, uidnode; @@ -1162,6 +1174,11 @@ import_secret_one( const char *fname, KBNODE keyblock, keyid_from_sk( sk, keyid ); uidnode = find_next_kbnode( keyblock, PKT_USER_ID ); + if (filter && filter(NULL, sk, filter_arg)) { + log_error( _("secret key %s: rejected by import filter\n"), keystr_from_sk(sk)); + return 0; + } + if( opt.verbose ) { log_info( "sec %4u%c/%s %s ", @@ -1241,7 +1258,7 @@ import_secret_one( const char *fname, KBNODE keyblock, if(pub_keyblock) { import_one(fname,pub_keyblock,stats, - NULL,NULL,opt.import_options,1); + NULL,NULL,opt.import_options,1,NULL,NULL); release_kbnode(pub_keyblock); } } diff --git a/g10/keyserver.c b/g10/keyserver.c index 3cef647..eaf44bc 100644 --- a/g10/keyserver.c +++ b/g10/keyserver.c @@ -971,6 +971,46 @@ direct_uri_map(const char *scheme,unsigned int is_direct) #define KEYSERVER_ARGS_KEEP " -o \"%O\" \"%I\"" #define KEYSERVER_ARGS_NOKEEP " -o \"%o\" \"%i\"" +static int +keyserver_retrieval_filter(PKT_public_key *pk, PKT_secret_key *sk, void *arg) +{ + KEYDB_SEARCH_DESC *desc = arg; + u32 keyid[2]; + byte fpr[MAX_FINGERPRINT_LEN]; + size_t fpr_len = 0; + + /* we definitely do not want to import secret keys! */ + if (sk) { + return 1; + } + + fingerprint_from_pk(pk, fpr, &fpr_len); + keyid_from_pk(pk, keyid); + + /* compare requested and returned fingerprints if available */ + if (desc->mode == KEYDB_SEARCH_MODE_FPR20) { + if (fpr_len != 20 || memcmp(fpr, desc->u.fpr, 20)) { + return 1; + } + } + else if (desc->mode == KEYDB_SEARCH_MODE_FPR16) { + if (fpr_len != 16 || memcmp(fpr, desc->u.fpr, 16)) { + return 1; + } + } + else if (desc->mode == KEYDB_SEARCH_MODE_LONG_KID) { + if (memcmp(keyid, desc->u.kid, sizeof(keyid))) { + return 1; + } + } + else if (desc->mode == KEYDB_SEARCH_MODE_SHORT_KID) { + if (memcmp(&keyid[1], &desc->u.kid[1], 1)) { + return 1; + } + } + return 0; +} + static int keyserver_spawn(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, int count,int *prog,unsigned char **fpr,size_t *fpr_len, @@ -1520,9 +1560,9 @@ keyserver_spawn(enum ks_action action,STRLIST list,KEYDB_SEARCH_DESC *desc, keyserver. Keyservers should never accept or send them but we better protect against rogue keyservers. */ - import_keys_stream (spawn->fromchild, stats_handle, fpr, fpr_len, - (opt.keyserver_options.import_options - | IMPORT_NO_SECKEY)); + import_keys_stream(spawn->fromchild,stats_handle,fpr,fpr_len, + (opt.keyserver_options.import_options | IMPORT_NO_SECKEY), + &keyserver_retrieval_filter, desc); import_print_stats(stats_handle); import_release_stats_handle(stats_handle); @@ -2055,7 +2095,7 @@ keyserver_import_cert(const char *name,unsigned char **fpr,size_t *fpr_len) rc=import_keys_stream (key, NULL, fpr, fpr_len, (opt.keyserver_options.import_options - | IMPORT_NO_SECKEY)); + | IMPORT_NO_SECKEY), NULL, NULL); opt.no_armor=armor_status; diff --git a/g10/main.h b/g10/main.h index eadac1f..73a5529 100644 --- a/g10/main.h +++ b/g10/main.h @@ -207,11 +207,13 @@ MPI encode_md_value( PKT_public_key *pk, PKT_secret_key *sk, MD_HANDLE md, int hash_algo ); /*-- import.c --*/ +typedef int (*import_filter)(PKT_public_key *pk, PKT_secret_key *sk, void *arg); int parse_import_options(char *str,unsigned int *options,int noisy); void import_keys( char **fnames, int nnames, void *stats_hd, unsigned int options ); int import_keys_stream( IOBUF inp,void *stats_hd,unsigned char **fpr, - size_t *fpr_len,unsigned int options ); + size_t *fpr_len,unsigned int options, + import_filter constr, void *filter_arg); void *import_new_stats_handle (void); void import_release_stats_handle (void *p); void import_print_stats (void *hd); -- 1.7.10.4 From wolters.mar at googlemail.com Wed Oct 23 13:50:55 2013 From: wolters.mar at googlemail.com (Martin Wolters) Date: Wed, 23 Oct 2013 13:50:55 +0200 Subject: gpg4win pinentry ignores pinpad Message-ID: <5267B81F.3050806@gmail.com> Hi, I already posted this problem to gnupg-users, but after some inves- tigation, I consider this list to be more appropriate. I use a SPR332, which should be supported by gpg4win 2.2.1, but the pinpad is not used. check_pcsc_pinpad() returns SW_NOT_SUPPORTED and pinentry then prompts me to enter the PIN with my keyboard. I tried to patch the function to always return affirmative, to test wether the bug is in the detection of the reader, but I couldn't get the source to build on Ubuntu nor Debian. Both times the preprocessor complained about not being able to locate windows.h when compiling adns-1.4-g10-3. Adding -I/usr/i586-mingw32msvc/include to CFLAGS didn't solve the problem and my knowledge of the GNU build system leaves me there. That directory is in the default search path for mingw32, though. Just running #include through the preprocessor works as ex- pected. scdaemon.exe seems to be distributed without symbols, so I didn't have much success by attaching a debugger, either. My last measure was re- placing the constant SW_NOT_SUPPORTED (0x00006a81) for 0x00000000 in the binary directly, but it occurred several times and replacing them all would probably just have broken the binary. What do I need to do to get the program to build? Are there any other spots to look for information about how that bug occurs and to fix it? I copied the log from scdaemon I already posted in gnupg-users to the end of this mail. Hoping for help, Martin scdaemon[15820]: chan_00000138 -> OK GNU Privacy Guard's Smartcard server ready scdaemon[15820]: chan_00000138 <- GETINFO socket_name scdaemon[15820]: chan_00000138 -> D C:UsersasdfAppDataRoaminggnupgS.scdaemon scdaemon[15820]: chan_00000138 -> OK scdaemon[15820]: chan_00000138 <- OPTION event-signal=f8 scdaemon[15820]: chan_00000138 -> OK scdaemon[15820]: chan_00000138 <- SERIALNO openpgp 2013-10-22 19:53:07 scdaemon[15820] reader slot 0: active protocol: T1 2013-10-22 19:53:07 scdaemon[15820] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 A4 00 0C 02 3F 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=6B00 datalen=0 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 A4 04 00 06 D2 76 00 01 24 01 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=0 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=4F lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 4F 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=16 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 2013-10-22 19:53:07 scdaemon[15820] AID: D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 5F 52 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=10 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 00 31 C5 73 C0 01 40 05 90 00 2013-10-22 19:53:07 scdaemon[15820] Historical Bytes: 00 31 C5 73 C0 01 40 05 90 00 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 C4 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=7 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 00 20 20 20 03 00 03 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 6E 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=217 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 10 00 00 20 00 C2 06 01 10 00 00 20 00 C3 06 01 10 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C CC 19 5D 23 92 34 85 8F E0 25 31 DB A9 F0 CC F3 EA 7E F1 4F 79 C0 D2 34 6E 04 09 AB 89 B5 ED 10 8D 1F 92 D2 4A E6 0B AF 7A F7 D8 1C 32 87 D5 E3 D5 A0 F1 BA 75 29 9B 20 95 6A 3C EC C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 52 5D 88 A3 52 5D 88 A3 52 5D 88 A3 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=5E lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 5E 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=0 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 2013-10-22 19:53:07 scdaemon[15820] Version-2 ......: yes 2013-10-22 19:53:07 scdaemon[15820] Get-Challenge ..: yes (2048 bytes max) 2013-10-22 19:53:07 scdaemon[15820] Key-Import .....: yes 2013-10-22 19:53:07 scdaemon[15820] Change-Force-PW1: yes 2013-10-22 19:53:07 scdaemon[15820] Private-DOs ....: yes 2013-10-22 19:53:07 scdaemon[15820] Algo-Attr-Change: yes 2013-10-22 19:53:07 scdaemon[15820] SM-Support .....: no 2013-10-22 19:53:07 scdaemon[15820] Max-Cert3-Len ..: 2048 2013-10-22 19:53:07 scdaemon[15820] Max-Cmd-Data ...: 2048 2013-10-22 19:53:07 scdaemon[15820] Max-Rsp-Data ...: 2048 2013-10-22 19:53:07 scdaemon[15820] Cmd-Chaining ...: no 2013-10-22 19:53:07 scdaemon[15820] Ext-Lc-Le ......: yes 2013-10-22 19:53:07 scdaemon[15820] Status Indicator: 05 2013-10-22 19:53:07 scdaemon[15820] GnuPG-No-Sync ..: no 2013-10-22 19:53:07 scdaemon[15820] GnuPG-Def-PW2 ..: no 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 6E 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=217 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 10 00 00 20 00 C2 06 01 10 00 00 20 00 C3 06 01 10 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C CC 19 5D 23 92 34 85 8F E0 25 31 DB A9 F0 CC F3 EA 7E F1 4F 79 C0 D2 34 6E 04 09 AB 89 B5 ED 10 8D 1F 92 D2 4A E6 0B AF 7A F7 D8 1C 32 87 D5 E3 D5 A0 F1 BA 75 29 9B 20 95 6A 3C EC C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 52 5D 88 A3 52 5D 88 A3 52 5D 88 A3 2013-10-22 19:53:07 scdaemon[15820] Key-Attr-sign ..: RSA, n=4096, e=32, fmt=std 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 6E 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=217 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 10 00 00 20 00 C2 06 01 10 00 00 20 00 C3 06 01 10 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C CC 19 5D 23 92 34 85 8F E0 25 31 DB A9 F0 CC F3 EA 7E F1 4F 79 C0 D2 34 6E 04 09 AB 89 B5 ED 10 8D 1F 92 D2 4A E6 0B AF 7A F7 D8 1C 32 87 D5 E3 D5 A0 F1 BA 75 29 9B 20 95 6A 3C EC C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 52 5D 88 A3 52 5D 88 A3 52 5D 88 A3 2013-10-22 19:53:07 scdaemon[15820] Key-Attr-encr ..: RSA, n=4096, e=32, fmt=std 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 6E 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=217 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 10 00 00 20 00 C2 06 01 10 00 00 20 00 C3 06 01 10 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C CC 19 5D 23 92 34 85 8F E0 25 31 DB A9 F0 CC F3 EA 7E F1 4F 79 C0 D2 34 6E 04 09 AB 89 B5 ED 10 8D 1F 92 D2 4A E6 0B AF 7A F7 D8 1C 32 87 D5 E3 D5 A0 F1 BA 75 29 9B 20 95 6A 3C EC C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 52 5D 88 A3 52 5D 88 A3 52 5D 88 A3 2013-10-22 19:53:07 scdaemon[15820] Key-Attr-auth ..: RSA, n=4096, e=32, fmt=std 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=5E lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 5E 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=0 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 2013-10-22 19:53:07 scdaemon[15820] DO `Login Data': 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=5F p2=50 lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 5F 50 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=0 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 2013-10-22 19:53:07 scdaemon[15820] DO `URL': `' 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 5F 52 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=10 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 00 31 C5 73 C0 01 40 05 90 00 2013-10-22 19:53:07 scdaemon[15820] DO `Historical Bytes': 00 31 C5 73 C0 01 40 05 90 00 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=65 lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 65 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=26 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 5B 0F 57 6F 6C 74 65 72 73 3C 3C 4D 61 72 74 69 6E 5F 2D 02 64 65 5F 35 01 31 2013-10-22 19:53:07 scdaemon[15820] DO `Cardholder Related Data': 5B 0F 57 6F 6C 74 65 72 73 3C 3C 4D 61 72 74 69 6E 5F 2D 02 64 65 5F 35 01 31 2013-10-22 19:53:07 scdaemon[15820] DO `Name': `Wolters< S SERIALNO D2760001240102000005000004890000 0 scdaemon[15820]: chan_00000138 -> OK 2013-10-22 19:53:08 scdaemon[15820] updating slot 0 status: 0x0000->0x0007 (0->1) 2013-10-22 19:53:08 scdaemon[15820] triggering event f8 (000000F8) for client -1 scdaemon[15820]: chan_00000138 <- SERIALNO openpgp scdaemon[15820]: chan_00000138 -> S SERIALNO D2760001240102000005000004890000 0 scdaemon[15820]: chan_00000138 -> OK scdaemon[15820]: chan_00000138 <- SETDATA 0D9E9F4BABF6EB5726CF901C6019C866912290C9162F6B9569A3BF354A01DB8850CA74E9FCE8541F799F5E4B744C69C7BE67347782BE5BA3F6FD83AF7FF9AF88BA2DC0E1A1C91BFF5D68A1C772FF955BC6359FEBE2C37EE9978111C39E78A9C24FCA4347D5208F64BF2BE5CCD71BF4BCDAA0057FA06D37405D238CF3C9BC085254D6ED534DC0407B3035C10F897F75E8096C3CD0E2FBDCF5D7106C9DEB5626C82B40689C3E6C17CE4EAE8F49BA479AE9F6103448DAD452BC8A6DA849E6FC172A522262DE3E9421112BCA60C924063E1994EA9B6D808C118CB423548F8430421163166052ED3ED4DBF5F104F94D9C6D3A486B6B30F114F745CFABAAFBAEB09D857E7136F038165D9FF829B297B626F791421119AD311B5B5E74F22066D80129BFE3BB4A07ECE75175FB63B073240FE0D3BA1043AD84599761DD9600D0E5ABA667E51DD32B83B908846B01C28A10B5CD9740D7514D83F657C3C954BFE7C2D53C832940E4490A6509E4C1592333872BC71ED6D2C6814DF6ED4E2C7A56C93DF159807D1829DA531DEE5AB35D6F536919584F099C6D32E16BCD9740F8E91C4612F60DE050A6A4BF95CEC9A0D277BACECE4511118ABD2059F15695A23B7124846A6831D49EC57FA3DFA907406F60B6BD37078E817E108069C88264A18C22AF scdaemon[15820]: chan_00000138 -> OK scdaemon[15820]: chan_00000138 <- SETDATA --append B9EE67BE9D48AF9E285BB25C391C83E4E96251D9D41AB372D61498B75A907E6C0059250B scdaemon[15820]: chan_00000138 -> OK scdaemon[15820]: chan_00000138 <- PKDECRYPT D2760001240102000005000004890000/79C0D2346E0409AB89B5ED108D1F92D24AE60BAF 2013-10-22 19:53:08 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-22 19:53:08 scdaemon[15820] DBG: PCSC_data: 00 CA 00 6E 00 2013-10-22 19:53:08 scdaemon[15820] DBG: response: sw=9000 datalen=217 2013-10-22 19:53:08 scdaemon[15820] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 10 00 00 20 00 C2 06 01 10 00 00 20 00 C3 06 01 10 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C CC 19 5D 23 92 34 85 8F E0 25 31 DB A9 F0 CC F3 EA 7E F1 4F 79 C0 D2 34 6E 04 09 AB 89 B5 ED 10 8D 1F 92 D2 4A E6 0B AF 7A F7 D8 1C 32 87 D5 E3 D5 A0 F1 BA 75 29 9B 20 95 6A 3C EC C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 52 5D 88 A3 52 5D 88 A3 52 5D 88 A3 2013-10-22 19:53:08 scdaemon[15820] DBG: check_pcsc_pinpad: command=20, r=27265 2013-10-22 19:53:08 scdaemon[15820] DBG: asking for PIN '||Bitte die PIN eingeben' scdaemon[15820]: chan_00000138 -> INQUIRE NEEDPIN ||Bitte die PIN eingeben scdaemon[15820]: chan_00000138 <- [ 44 20 PI NP IN PI NP IN 00 00 00 00 00 00 00 00 ...(76 byte(s) skipped) ] scdaemon[15820]: chan_00000138 <- END 2013-10-22 19:53:12 scdaemon[15820] DBG: send apdu: c=00 i=20 p1=00 p2=82 lc=6 le=-1 em=0 2013-10-22 19:53:12 scdaemon[15820] DBG: PCSC_data: 00 20 00 82 06 PI NP IN PI NP IN 2013-10-22 19:53:12 scdaemon[15820] DBG: response: sw=9000 datalen=0 2013-10-22 19:53:12 scdaemon[15820] DBG: dump: 2013-10-22 19:53:12 scdaemon[15820] DBG: send apdu: c=00 i=2A p1=80 p2=86 lc=513 le=2048 em=1 2013-10-22 19:53:12 scdaemon[15820] DBG: PCSC_data: 00 2A 80 86 00 02 01 00 0D 9E 9F 4B AB F6 EB 57 26 CF 90 1C 60 19 C8 66 91 22 90 C9 16 2F 6B 95 69 A3 BF 35 4A 01 DB 88 50 CA 74 E9 FC E8 54 1F 79 9F 5E 4B 74 4C 69 C7 BE 67 34 77 82 BE 5B A3 F6 FD 83 AF 7F F9 AF 88 BA 2D C0 E1 A1 C9 1B FF 5D 68 A1 C7 72 FF 95 5B C6 35 9F EB E2 C3 7E E9 97 81 11 C3 9E 78 A9 C2 4F CA 43 47 D5 20 8F 64 BF 2B E5 CC D7 1B F4 BC DA A0 05 7F A0 6D 37 40 5D 23 8C F3 C9 BC 08 52 54 D6 ED 53 4D C0 40 7B 30 35 C1 0F 89 7F 75 E8 09 6C 3C D0 E2 FB DC F5 D7 10 6C 9D EB 56 26 C8 2B 40 68 9C 3E 6C 17 CE 4E AE 8F 49 BA 47 9A E9 F6 10 34 48 DA D4 52 BC 8A 6D A8 49 E6 FC 17 2A 52 22 62 DE 3E 94 21 11 2B CA 60 C9 24 06 3E 19 94 EA 9B 6D 80 8C 11 8C B4 23 54 8F 84 30 42 11 63 16 60 52 ED 3E D4 DB F5 F1 04 F9 4D 9C 6D 3A 48 6B 6B 30 F1 14 F7 45 CF AB AA FB AE B0 9D 85 7E 71 36 F0 38 16 5D 9F F8 29 B2 97 B6 26 F7 91 42 11 19 AD 31 1B 5B 5E 74 F2 20 66 D8 01 29 BF E3 BB 4A 07 EC E7 51 75 FB 63 B0 73 24 0F E0 D3 BA 10 43 AD 84 59 97 61 DD 96 00 D0 E5 AB A6 67 E5 1D D3 2B 83 B9 08 84 6B 01 C2 8A 10 B5 CD 97 40 D7 51 4D 83 F6 57 C3 C9 54 BF E7 C2 D5 3C 83 29 40 E4 49 0A 65 09 E4 C1 59 23 33 87 2B C7 1E D6 D2 C6 81 4D F6 ED 4E 2C 7A 56 C9 3D F1 59 80 7D 18 29 DA 53 1D EE 5A B3 5D 6F 53 69 19 58 4F 09 9C 6D 32 E1 6B CD 97 40 F8 E9 1C 46 12 F6 0D E0 50 A6 A4 BF 95 CE C9 A0 D2 77 BA CE CE 45 11 11 8A BD 20 59 F1 56 95 A2 3B 71 24 84 6A 68 31 D4 9E C5 7F A3 DF A9 07 40 6F 60 B6 BD 37 07 8E 81 7E 10 80 69 C8 82 64 A1 8C 22 AF B9 EE 67 BE 9D 48 AF 9E 28 5B B2 5C 39 1C 83 E4 E9 62 51 D9 D4 1A B3 72 D6 14 98 B7 5A 90 7E 6C 00 59 25 0B 08 00 2013-10-22 19:53:15 scdaemon[15820] DBG: response: sw=9000 datalen=35 2013-10-22 19:53:15 scdaemon[15820] DBG: dump: 09 2A F3 4A 7E 82 3B 0E E9 80 2A 11 69 1F CF 2D 27 85 AF FA 4C 31 A3 0E 5D 72 58 B3 85 38 2F FF 5A 0D 7A 2013-10-22 19:53:15 scdaemon[15820] operation decipher result: Erfolg scdaemon[15820]: chan_00000138 -> [ 44 20 09 2a f3 4a 7e 82 3b 0e e9 80 2a 11 69 1f ...(23 byte(s) skipped) ] scdaemon[15820]: chan_00000138 -> OK scdaemon[15820]: chan_00000138 <- RESTART scdaemon[15820]: chan_00000138 -> OK From mailinglisten at hauke-laging.de Thu Oct 24 03:44:50 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 24 Oct 2013 03:44:50 +0200 Subject: add a request for advocating crypto to the crypto tools Message-ID: <1524185.Rkb8MydCvq@inno.berlin.laging.de> Hello, due to its rather little visibility for the average user this affects GnuPG less than its GUIs (the mail clients in particular). It may well be used in the GnuPG documentation (man, info, www). But I assume that many GUI (or more general: crypto tool) developers are on these lists. We need everyone we can get for help in advocating the usage of crypto tools. Currently probably even most crypto users are not aware of the opportunities they have for doing that (even at nearly no effort). Thus I suggest that the crypto tools get somewhere (configuration windows) a link to a page which tells them. I created a page in the KDE userbase wiki (which has the advantage that it is going to be translated) for this purpose (based on my German page http://www.openpgp-schulungen.de/fuer/unterstuetzer/): http://userbase.kde.org/Concepts/OpenPGP_Help_Spread And I have created according wishlist entries (PLEASE feel free to vote for them ;-) ) in the bug tracker for KMail and KGpg: https://bugs.kde.org/show_bug.cgi?id=326476 (KMail) https://bugs.kde.org/show_bug.cgi?id=326477 (KGpg) This may not just raise the interest in crypto but also the donations for the tools. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From gniibe at fsij.org Thu Oct 24 04:01:24 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 24 Oct 2013 11:01:24 +0900 Subject: gpg4win pinentry ignores pinpad In-Reply-To: <5267B81F.3050806@gmail.com> References: <5267B81F.3050806@gmail.com> Message-ID: <1382580084.4526.1.camel@cfw2.gniibe.org> On 2013-10-23 at 13:50 +0200, Martin Wolters wrote: > I use a SPR332, which should be supported by gpg4win 2.2.1, but the > pinpad is not used. check_pcsc_pinpad() returns SW_NOT_SUPPORTED and > pinentry then prompts me to enter the PIN with my keyboard. I can't answer to your build problem (I don't have knowledge). I only answer to your pinpad problem. I don't know if we have any experience with SPR332. By the way, this month, I created a Wiki page for pinpad input, so that it helps users: http://wiki.gnupg.org/CardReader/PinpadInput In that page, I am gathering information about readers which support pinpad input. Well, let me explain scdaemon. The scdaemon works like this: (1) When opening the connection (open_pcsc_reader), it calls pcsc_vendor_specific_init to get vendor specific information, specifically, information for pinpad input. (1-1) It calls conrol_pcsc with CM_IOCTL_GET_FEATURE_REQUEST. Here, reader_table[slot].pcsc.verify_ioctl (and others) is filled, if the reader supports FEATURE_VERIFY_PIN_DIRECT. (1-2) It calls conrol_pcsc with GET_TLV_PROPERTIES. (2) When apdu_check_pinpad is called, it calls check_pcsc_pinpad to check if the reader support pinpad input. When reader_table[slot].pcsc.verify_ioctl is filled it returns 0 (success). It seems for me that you've tried to circumvent the checking of (2), but the real issue is (1-1). > scdaemon[15820]: chan_00000138 -> OK GNU Privacy Guard's Smartcard > server ready > scdaemon[15820]: chan_00000138 <- GETINFO socket_name > scdaemon[15820]: chan_00000138 -> D > C:UsersasdfAppDataRoaminggnupgS.scdaemon > scdaemon[15820]: chan_00000138 -> OK > scdaemon[15820]: chan_00000138 <- OPTION event-signal=f8 > scdaemon[15820]: chan_00000138 -> OK > scdaemon[15820]: chan_00000138 <- SERIALNO openpgp Here, we don't see any log (for the step (1-1)). If it fails for CM_IOCTL_GET_FEATURE_REQUEST, we might see something like: pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: ... Or else, we should see: feature: code=??, len=??, v=?? We don't see any log... It means that the call got success, but it returned empty information. In this situation, pinpad input doesn't work. [...] > 2013-10-22 19:53:08 scdaemon[15820] DBG: check_pcsc_pinpad: command=20, > r=27265 This is at (2). Well, I found an article in OpenSC mailng list: http://opensc.1086184.n5.nabble.com/Pinpad-support-for-SCM-Microsystems-Inc-SPRx32-USB-Smart-Card-Reader-td5270.html Could you check your firmware version? -- From wolters.mar at googlemail.com Thu Oct 24 22:05:51 2013 From: wolters.mar at googlemail.com (Martin Wolters) Date: Thu, 24 Oct 2013 22:05:51 +0200 Subject: gpg4win pinentry ignores pinpad In-Reply-To: <52697584.3080305@gmail.com> References: <52697584.3080305@gmail.com> Message-ID: <52697D9F.5040505@gmail.com> Am 24.10.2013 04:01, schrieb NIIBE Yutaka: > [...] > Well, let me explain scdaemon. The scdaemon works like this: Thank you very much, it was helpful indeed. > [...] > Here, we don't see any log (for the step (1-1)). > > If it fails for CM_IOCTL_GET_FEATURE_REQUEST, we might see something > like: > > pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: ... > > Or else, we should see: > > feature: code=??, len=??, v=?? > > We don't see any log... It means that the call got success, but it > returned empty information. In this situation, pinpad input doesn't > work. I just tried again and checked the log. The function you refer to generates the following messages at the very beginning: > 2013-10-24 21:07:55 scdaemon[8936] detected reader `SCM Microsystems Inc. SPRx32 USB Smart Card Reader 0' > 2013-10-24 21:07:55 scdaemon[8936] pcsc_control failed: invalid PC/SC error code (0x6) > 2013-10-24 21:07:55 scdaemon[8936] pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 65547 > 2013-10-24 21:07:55 scdaemon[8936] reader slot 0: not connected > scdaemon[8936]: chan_00000140 -> OK GNU Privacy Guard's Smartcard server ready The return constant has the symbol SW_HOST_GENERAL_ERROR, before anyone looks it up in hope of finding something useful. The error code of pcsc_control() is Invalid Handle (0x06), forwarded from SCardControl() in the Windows Smartcard API, indicating reader_table[slot].pcsc.card contains an invalid value. Being unable to attach a debugger proves disadvantageous again. Can anybody supply me with a binary of scdaemon that doesn't have the symbols stripped? > [...] > Could you check your firmware version? It is 6.01 Thank you for your extensive response. Sorry I couldn't answer sooner. Have a good time, Martin From gniibe at fsij.org Fri Oct 25 02:47:47 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 25 Oct 2013 09:47:47 +0900 Subject: gpg4win pinentry ignores pinpad In-Reply-To: <52697D9F.5040505@gmail.com> References: <52697584.3080305@gmail.com> <52697D9F.5040505@gmail.com> Message-ID: <1382662067.3180.2.camel@cfw2.gniibe.org> On 2013-10-24 at 22:05 +0200, Martin Wolters wrote: > looks it up in hope of finding something useful. The error code of > pcsc_control() is Invalid Handle (0x06), forwarded from SCardControl() > in the Windows Smartcard API, indicating reader_table[slot].pcsc.card > contains an invalid value. Err... I understand. This is a bug. There are two implementations for PC/SC access by GnuPG, depending on the flag NEED_PCSC_WRAPPER. On Windows, *_direct version is used. (While I tested mainly on GNU/Linux, where *_wrapper version is used.) For *_direct version, we should not call pcsc_vendor_specific_init from open_pcsc_reader_direct, as it is *not* yet connected to card, or else, as you saw, it just returned error. We should call pcsc_vendor_specific_init from connect_pcsc_card, even though it's not card specific (but reader specific). This is due to PC/SC API where the distinction of reader and card is not good. It would be clear if we have API to control reader, but currently, we need to control reader through the API of card control (thus, after connecting card). Here's a patch. I will commit this soon. Well, then, you're going back to your original question of building GnuPG on Windows. Sorry, I don't have knowledge. You'd better to ask to gpg4win-devel list. Thank you for your bug report. diff --git a/scd/apdu.c b/scd/apdu.c index 58f6075..0351e00 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -1508,6 +1508,8 @@ connect_pcsc_card (int slot) pcsc_dword_t readerlen, atrlen; long card_state, card_protocol; + pcsc_vendor_specific_init (slot); + atrlen = DIM (reader_table[0].atr); readerlen = sizeof reader -1 ; err = pcsc_status (reader_table[slot].pcsc.card, @@ -1929,7 +1931,6 @@ open_pcsc_reader_direct (const char *portstr) reader_table[slot].send_apdu_reader = pcsc_send_apdu; reader_table[slot].dump_status_reader = dump_pcsc_reader_status; - pcsc_vendor_specific_init (slot); dump_reader_status (slot); return slot; } -- From aheinecke at intevation.de Fri Oct 25 10:25:51 2013 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 25 Oct 2013 10:25:51 +0200 Subject: gpg4win pinentry ignores pinpad In-Reply-To: <5267B81F.3050806@gmail.com> References: <5267B81F.3050806@gmail.com> Message-ID: <201310251025.56656.aheinecke@intevation.de> Hi, On Wednesday 23 October 2013 13:50:55 Martin Wolters wrote: > What do I need to do to get the program to build? Are there any other > spots to look for information about how that bug occurs and to fix it? > I copied the log from scdaemon I already posted in gnupg-users to the > end of this mail. I'm taking over the building for Windows questions ;) There is a conveniance option in all the gnupg packages: ./autogen.sh --build-w32 This will automatically configure your build so that it places the windows binaries under ~/w32root and looks for dependencies in that place. (Take a look at the autogen.sh script if you want to know how you can modify this) On debian wheezy / ubuntu: apt-get install mingw-w64-i686 Then get libgpg-error sources and run: ./autogen.sh && ./autogen.sh --build-w32 && make && make install Repeat for all dependencies you need for gnupg. And it should work. You can also use the gpg4win scripts to build it but I guess if you only want to hack gnupg this is overkill. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Fri Oct 25 17:16:00 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 25 Oct 2013 11:16:00 -0400 Subject: @ifset gpgtwoone macro not working in gpg.texi? Message-ID: <877gd1fkjz.fsf@alice.fifthhorseman.net> I don't think @ifset gpgtwoone is being evaluated properly in gpg.texi (though i don't know why). I'm using debian, and have both gpg (1.4.15) and gpg2 (2.0.22) installed. gpg(1) says: --try-secret-key name For hidden recipients GPG needs to know the keys to use for trial decryption. The key set with --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 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. But the argument doesn't work in these versions: 0 dkg at alice:~$ gpg --try-secret-key 'Daniel Kahn Gillmor ' < tmp/x.gpg gpg: Invalid option "--try-secret-key" 2 dkg at alice:~$ gpg2 --try-secret-key 'Daniel Kahn Gillmor ' < tmp/x.gpg gpg: invalid option "--try-secret-key" 2 dkg at alice:~$ Looking in the source, i see that the documentation is supposed to be wrapped in an "@ifset gpgtwoone" in doc/gpg.texi. The same is true for --with-keygrip -- it shows up in the manpage output. Interestingly, "@ifclear gpgtwoone" is also evaluating to true, because the export-secret-subkeys documentation contains the reference to --simple-sk-checksum: --export-secret-subkeys Same as --export, but exports the secret keys instead. This is normally not very useful and a security risk. The second form of the command has the special property to render the secret part of the primary key useless; this is a GNU extension to OpenPGP and other implementations can not be expected to successfully import such a key. See the option --simple-sk-checksum if you want to import such an exported key with an older OpenPGP implementation. Any ideas what might be going wrong in the documentation generation process? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From wk at gnupg.org Fri Oct 25 18:31:44 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Oct 2013 18:31:44 +0200 Subject: @ifset gpgtwoone macro not working in gpg.texi? In-Reply-To: <877gd1fkjz.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 25 Oct 2013 11:16:00 -0400") References: <877gd1fkjz.fsf@alice.fifthhorseman.net> Message-ID: <87txg5z4zz.fsf@vigenere.g10code.de> On Fri, 25 Oct 2013 17:16, dkg at fifthhorseman.net said: > Looking in the source, i see that the documentation is supposed to be > wrapped in an "@ifset gpgtwoone" in doc/gpg.texi. The same is true for > --with-keygrip -- it shows up in the manpage output. You hit a bug in yat2m.c: /* The only define we understand is -D gpgone. Thus we need a simple boolean to track it. */ static int gpgone_defined; This it does not know about any other defines. Patches to properly support -D are welcome. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Oct 25 20:54:05 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Oct 2013 20:54:05 +0200 Subject: @ifset gpgtwoone macro not working in gpg.texi? In-Reply-To: <87txg5z4zz.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 25 Oct 2013 18:31:44 +0200") References: <877gd1fkjz.fsf@alice.fifthhorseman.net> <87txg5z4zz.fsf@vigenere.g10code.de> Message-ID: <878uxhyyeq.fsf@vigenere.g10code.de> On Fri, 25 Oct 2013 18:31, wk at gnupg.org said: > This it does not know about any other defines. Patches to properly > support -D are welcome. Never mind; I already started to fix it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wolters.mar at googlemail.com Sat Oct 26 00:10:05 2013 From: wolters.mar at googlemail.com (Martin Wolters) Date: Sat, 26 Oct 2013 00:10:05 +0200 Subject: gpg4win pinentry ignores pinpad In-Reply-To: <201310251025.56656.aheinecke@intevation.de> References: <5267B81F.3050806@gmail.com> <201310251025.56656.aheinecke@intevation.de> Message-ID: <526AEC3D.2080400@gmail.com> Am 25.10.2013 10:25, schrieb Andre Heinecke: > I'm taking over the building for Windows questions ;) > > There is a conveniance option in all the gnupg packages: [...] > Repeat for all dependencies you need for gnupg. > > And it should work. Ok, I misinterpreted the documentation and thought, I only needed to do that once for the complete package. It was quite an oddyssey and with little reward, but I got a working scdaemon.exe. To do that, I had to patch npth-0.91. I am not sure if the bug is in scdaemon, because it crashed on dereferenced NULL pointers, but I found validating them couldn't hurt, so I changed the library. Also, there was a bug in the build system. The patch is here: https://chelloveck.vellocet.net/etc/npth-0.91.patch CC to wk at gnupg.org as I reckon he's the maintainer. I needed to make a minor modification in scd to get it to build. The function pcsc_vendor_specific_init was called before being declared. The fix is trivial. So after an evening worth of work, I ran my new scdaemon.exe, only to see it fail again. Log: https://chelloveck.vellocet.net/etc/scd.log Have a good time, Martin From gniibe at fsij.org Sat Oct 26 04:15:23 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 26 Oct 2013 11:15:23 +0900 Subject: gpg4win pinentry ignores pinpad In-Reply-To: <526AEC3D.2080400@gmail.com> References: <5267B81F.3050806@gmail.com> <201310251025.56656.aheinecke@intevation.de> <526AEC3D.2080400@gmail.com> Message-ID: <1382753723.3839.0.camel@latx1.gniibe.org> On 2013-10-26 at 00:10 +0200, Martin Wolters wrote: > So after an evening worth of work, I ran my new scdaemon.exe, only to > see it fail again. Log: > > https://chelloveck.vellocet.net/etc/scd.log Thanks a lot for your time. The return code 0x1 looks fatal. I think that I found same problem in the OpenSC mailing list in 2009. It's about SCARD_CTL_CODE. I think that following change of SCARD_CTL_CODE in OpenSC is worth a try: https://github.com/OpenSC/OpenSC/commit/cd6adb4e269db0549b0f442660c27693918758d8 -- From wolters.mar at googlemail.com Sat Oct 26 06:18:02 2013 From: wolters.mar at googlemail.com (Martin Wolters) Date: Sat, 26 Oct 2013 06:18:02 +0200 Subject: gpg4win pinentry ignores pinpad In-Reply-To: <1382753723.3839.0.camel@latx1.gniibe.org> References: <5267B81F.3050806@gmail.com> <201310251025.56656.aheinecke@intevation.de> <526AEC3D.2080400@gmail.com> <1382753723.3839.0.camel@latx1.gniibe.org> Message-ID: <526B427A.1030108@gmail.com> Am 26.10.2013 04:15, schrieb NIIBE Yutaka: > I think that following change of SCARD_CTL_CODE in OpenSC is worth a > try: > > https://github.com/OpenSC/OpenSC/commit/cd6adb4e269db0549b0f442660c27693918758d8 > Tried that, and it worked. Kind of. scdaemon gets the features but then fails later when calling npth_eselect. WaitForMultipleObjects returns WAIT_TIMEOUT (npth.c:1876) with the timeout being 500msecs. It then dies in npth.c:1977 by NULL pointer dereference. I might add that I am having trouble building the whole gnupg from git and only replaced scdaemon.exe and libnpth-0.dll. Maybe there are pieces missing that are needed for everything to work. Linking dirmngr failed with an undefined reference to _getaddrinfo and _getnameinfo, which are both part of libws2_32. The linker is called with -lws2_32 but doesn't seem to care. Have a good time, Martin From wk at gnupg.org Sat Oct 26 11:01:16 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 26 Oct 2013 11:01:16 +0200 Subject: gpg4win pinentry ignores pinpad In-Reply-To: <526AEC3D.2080400@gmail.com> (Martin Wolters's message of "Sat, 26 Oct 2013 00:10:05 +0200") References: <5267B81F.3050806@gmail.com> <201310251025.56656.aheinecke@intevation.de> <526AEC3D.2080400@gmail.com> Message-ID: <87wql0xv6r.fsf@vigenere.g10code.de> On Sat, 26 Oct 2013 00:10, wolters.mar at googlemail.com said: > https://chelloveck.vellocet.net/etc/npth-0.91.patch Well, the current master (2.1) has not yet been ported to Windows. Some stuff might work but I never did any real tests. I have a couple of patches for npth sitting in my private repo; some of yours are new. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Oct 28 07:26:07 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Oct 2013 07:26:07 +0100 Subject: @ifset gpgtwoone macro not working in gpg.texi? In-Reply-To: <877gd1fkjz.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 25 Oct 2013 11:16:00 -0400") References: <877gd1fkjz.fsf@alice.fifthhorseman.net> Message-ID: <87fvrlx668.fsf@vigenere.g10code.de> On Fri, 25 Oct 2013 17:16, dkg at fifthhorseman.net said: > I don't think @ifset gpgtwoone is being evaluated properly in gpg.texi > (though i don't know why). I'm using debian, and have both gpg (1.4.15) > and gpg2 (2.0.22) installed. Fixed in master with commit a15c35f. This should apply cleany to all other branches because we maintain yat2m.c only in master. There will be a another 1.4 release this year, thus I don't think there is a need for distros to include a patch. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Mon Oct 28 07:59:29 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 28 Oct 2013 02:59:29 -0400 Subject: @ifset gpgtwoone macro not working in gpg.texi? In-Reply-To: <87fvrlx668.fsf@vigenere.g10code.de> References: <877gd1fkjz.fsf@alice.fifthhorseman.net> <87fvrlx668.fsf@vigenere.g10code.de> Message-ID: <526E0B51.4020903@fifthhorseman.net> On 10/28/2013 02:26 AM, Werner Koch wrote: > Fixed in master with commit a15c35f. This should apply cleany to all > other branches because we maintain yat2m.c only in master. There will > be a another 1.4 release this year, thus I don't think there is a need > for distros to include a patch. thanks for the fix, Werner. --dkg From gniibe at fsij.org Tue Oct 29 01:13:32 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 29 Oct 2013 09:13:32 +0900 Subject: gpg4win pinentry ignores pinpad In-Reply-To: <526B427A.1030108@gmail.com> References: <5267B81F.3050806@gmail.com> <201310251025.56656.aheinecke@intevation.de> <526AEC3D.2080400@gmail.com> <1382753723.3839.0.camel@latx1.gniibe.org> <526B427A.1030108@gmail.com> Message-ID: <1383005612.3479.0.camel@cfw2.gniibe.org> On 2013-10-26 at 06:18 +0200, Martin Wolters wrote: > Am 26.10.2013 04:15, schrieb NIIBE Yutaka: > > I think that following change of SCARD_CTL_CODE in OpenSC is worth a > > try: > > > > https://github.com/OpenSC/OpenSC/commit/cd6adb4e269db0549b0f442660c27693918758d8 > > > > Tried that, and it worked. Kind of. scdaemon gets the features but then > fails later when calling npth_eselect. WaitForMultipleObjects returns > WAIT_TIMEOUT (npth.c:1876) with the timeout being 500msecs. It then > dies in npth.c:1977 by NULL pointer dereference. Thanks for your testing. I applied the change to GnuPG to both (STABLE-BRANCH-2-0 and master). --