From mabrand at mabrand.nl Mon Jun 3 12:46:10 2013 From: mabrand at mabrand.nl (Mark Brand) Date: Mon, 03 Jun 2013 12:46:10 +0200 Subject: [PATCH] avoid accidental inclusion of old winsock.h Message-ID: <3281725.hl7lWlDiKa@hitch> >From 956504b76dc429de2459322bf799534a1171d953 Mon Sep 17 00:00:00 2001 From: Mark Brand Date: Mon, 3 Jun 2013 11:24:12 +0200 Subject: [PATCH] avoid accidental inclusion of old winsock.h /src/gcrypt.h.in:# include implicitly includes windows.h. Avoid including windows.h explicitly before winsock2.h, to avoid implicit inclusion of conflicting winsock.h from windows.h. diff --git a/random/rndw32.c b/random/rndw32.c index f8a83b6..d6c8e34 100644 --- a/random/rndw32.c +++ b/random/rndw32.c @@ -78,7 +78,6 @@ #include #endif -#include #include "types.h" diff --git a/src/ath.h b/src/ath.h index 6ffa928..e52da11 100644 --- a/src/ath.h +++ b/src/ath.h @@ -23,7 +23,6 @@ #include #ifdef _WIN32 -# include #else /* !_WIN32 */ # ifdef HAVE_SYS_SELECT_H # include diff --git a/tests/benchmark.c b/tests/benchmark.c index 61badd5..8a9ceee 100644 --- a/tests/benchmark.c +++ b/tests/benchmark.c @@ -25,7 +25,6 @@ #include #include #ifdef _WIN32 -#include #else #include #endif -- 1.8.1.4 From jussi.kivilinna at iki.fi Mon Jun 10 10:22:06 2013 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Mon, 10 Jun 2013 11:22:06 +0300 Subject: New amd64 implementations... Message-ID: <51B58CAE.7090603@iki.fi> Hello, I have pushed new optimized implementations to 'cipher-amd64-optimizations' branch at 'git.gnupg.org/libgcrypt.git'. These changes include: - AMD64 implementation of blowfish + with 4-way parallel implementation for CBC/CFB/CTR-decryption and CTR-encryption. - AMD64 implementation of AES - AMD64 implementation of twofish + with 3-way parallel implementations - Detection for new AVX2 instruction set - 16-way parallel implementation for Serpent using AVX2 - 32-way parallel implementation for Camellia using AVX2 and AES-NI - Generic optimization for _gcry_burn_stack -Jussi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 730 bytes Desc: OpenPGP digital signature URL: From rick at openfortress.nl Sat Jun 15 08:44:29 2013 From: rick at openfortress.nl (Rick van Rein (OpenFortress)) Date: Sat, 15 Jun 2013 08:44:29 +0200 Subject: What is a "key grip"? Message-ID: Hello, I'm having trouble understanding the concept of a "key grip", and I cannot find it documented anywhere. I'd like to generate keys in a GnuPG-friendly manner, making them available through an SCD mechanism. As I understand it, it's a handle for the private key -- meaning it's not external stuff, but still useful to do well in a key store. It's a hex-denoted form of a binary key identifier, right? I wonder if it should be derivable by GnuPG to a certain value (and if so, what is the calculation?) or if it is merely a value produced by the underlying SCD. In the latter case, I am confused that it is assumed to be 20 binary bytes long. In short, if I store a public key and want it to be GnuPG-friendly, what should I use as the keygrip? For instance, do I write down an S-expression and determine it's SHA-1 and use it as the binary handle to the key? Thanks, -Rick From wk at gnupg.org Sat Jun 15 22:27:21 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 15 Jun 2013 22:27:21 +0200 Subject: What is a "key grip"? In-Reply-To: (Rick van Rein's message of "Sat, 15 Jun 2013 08:44:29 +0200") References: Message-ID: <87obb7unkm.fsf@vigenere.g10code.de> On Sat, 15 Jun 2013 08:44, rick at openfortress.nl said: > I'm having trouble understanding the concept of a "key grip", and I > cannot find it documented anywhere. I'd like to generate keys in a You find the description in Libgcrypt: -- Function: unsigned char * gcry_pk_get_keygrip (gcry_sexp_t KEY, unsigned char *ARRAY) Return the so called "keygrip" which is the SHA-1 hash of the public key parameters expressed in a way depended on the algorithm. ARRAY must either provide space for 20 bytes or be `NULL'. In the latter case a newly allocated array of that size is returned. On success a pointer to the newly allocated space or to ARRAY is returned. `NULL' is returned to indicate an error which is most likely an unknown algorithm or one where a "keygrip" has not yet been defined. The function accepts public or secret keys in KEY. It is a protocol independent way to identify a public key. pkcs#15 has a similar concept but the exact details for the Keygrip are defined by Libgcrypt. > As I understand it, it's a handle for the private key -- meaning it's > not external stuff, but still useful to do well in a key store. It's > a hex-denoted form It is used for the public key. How it is formatted is not defined. > I wonder if it should be derivable by GnuPG to a certain value (and if so, what is the calculation?) or if it is merely a value produced by the underlying SCD. In the latter case, I am confused that it is assumed to be 20 binary bytes long. gpg2 --with-keygrip -k KEYID > In short, if I store a public key and want it to be GnuPG-friendly, what should I use as the keygrip? For instance, do I write down an S-expression and determine it's SHA-1 and use it as the binary handle to the key? You need to call the above Libgcrypt function (or your own implementation of it). gcry_pk_get_keygrip takes an S-expression, but that is just a part of the API and is not needed to define the keygrip. If you look at libgcrypt/cipher/rsa.c you will find how we compute it for RSA: /* Compute a keygrip. MD is the hash context which we are going to update. KEYPARAM is an S-expression with the key parameters, this is usually a public key but may also be a secret key. An example of such an S-expression is: (rsa (n #00B...#) (e #010001#)) PKCS-15 says that for RSA only the modulus should be hashed - however, it is not clear whether this is meant to use the raw bytes (assuming this is an unsigned integer) or whether the DER required 0 should be prefixed. We hash the raw bytes. */ In short for RSA the keygrip is the SHA-1 value of the modulus given as the unsigned integer with leading zero bytes removed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From teichm at in.tum.de Tue Jun 18 08:38:08 2013 From: teichm at in.tum.de (teichm) Date: Tue, 18 Jun 2013 08:38:08 +0200 Subject: Assertion crash in collectd 5.2.1 / libgcrypt 1.5.2 Message-ID: <6f72d96a18d8b76eeff4aa77ca1dd621@mail.fs.tum.de> Heyho, On our collectd 5.2.1 from the Debian Package 5.2.1-1 we encountered an assertion crash from libgcrypt11 1.5.2-1 that occurs aproximately once a day on random conditions. I do not know, if collectd is using libgcrypt wrong or if it is a bug in libgcrypt. It seems, ath_install was called with the first argument beeing NULL. At least i have no other explanation of why this codepath would be reachable. Since i am also working on my Bachelor's thesis at the moment in which I am developing Monkey, a new automated bug reporting system, i generated a report for your convenience: https://gnunet.org/monkey/examples/collectd-01/scrutinizer.html If you are interested in the Debugging System, you can find more information on: https://gnunet.org/monkey/ Also i have a survey (or rather ?experiment?) running, in which you will get three different crash reports (stack trace, stack trace + *life gdb session* on a core dump and of course one generated from Monkey) and try to find the respective bug. You can participate here: https://gnunet.org/monkey/survey/index.php/943594?lang=en --Markus From testtest_2005 at ukr.net Wed Jun 19 19:24:05 2013 From: testtest_2005 at ukr.net (Vasiliy) Date: Wed, 19 Jun 2013 19:24:05 +0200 Subject: Fwd: New amd64 implementations? In-Reply-To: References: Message-ID: I forgot to mention a platform: it is Cygwin 64-bit. It is my understanding, it may need a different set of instructions. From testtest_2005 at ukr.net Wed Jun 19 18:45:49 2013 From: testtest_2005 at ukr.net (Vasiliy) Date: Wed, 19 Jun 2013 18:45:49 +0200 Subject: New amd64 implementations? Message-ID: I've just tried to compile cast5-amd64.S, and it does not, however, it does compile with -m32 option. Are you sure you've pushed up the 64-bit code?... $ gcc -m64 -DHAVE_CONFIG_H -I. -I/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher -I.. -I../src -I/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/src -ggdb -march=native -mtune=native -Ofast -fomit-frame-pointer -pipe -fdebug-prefix-map=/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/build=/usr/src/debug/libgcrypt-1.6.0-1 -fdebug-prefix-map=/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0=/usr/src/debug/libgcrypt-1.6.0-1 -MT cast5-amd64.lo -MD -MP -MF .deps/cast5-amd64.Tpo -c /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S -DDLL_EXPORT -DPIC -o .libs/cast5-amd64.o /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S: Assembler messages: /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:183: Warning: .type pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:183: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:219: Warning: .size pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:219: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:223: Warning: .type pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:223: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:259: Warning: .size pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:259: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:362: Warning: .type pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:362: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:387: Warning: .size pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:387: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:390: Warning: .type pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:390: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:417: Warning: .size pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:417: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:421: Warning: .type pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:421: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:475: Warning: .size pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:475: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:479: Warning: .type pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:479: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:529: Warning: .size pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:529: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:533: Warning: .type pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:533: Error: junk at end of line, first unrecognized character is `_' /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:584: Warning: .size pseudo-op used outside of .def/.endef ignored. /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:584: Error: junk at end of line, first unrecognized character is `_' From jussi.kivilinna at iki.fi Thu Jun 20 01:15:07 2013 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Thu, 20 Jun 2013 02:15:07 +0300 Subject: Fwd: New amd64 implementations? In-Reply-To: References: Message-ID: <51C23B7B.1000802@iki.fi> On 19.06.2013 20:24, Vasiliy wrote: > I forgot to mention a platform: it is Cygwin 64-bit. It is my > understanding, it may need a different set of instructions. > Ok. These implementations need additional checks for different platforms. I'll look in to it next week. -Jussi > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > From jussi.kivilinna at iki.fi Thu Jun 20 14:14:28 2013 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Thu, 20 Jun 2013 15:14:28 +0300 Subject: New amd64 implementations? In-Reply-To: References: Message-ID: <51C2F224.7000609@iki.fi> Hello, I have attached patch that is for the cipher-amd64-optimizations branch. It disables AMD64 assembly implementations if platform assembler is found to be incompatible with those implementations. Adding cygwin64/mingw64 support for these optimizations would require some extra work to handle the different calling convention and I don't have licence for 64-bit Windows, so I cannot easily do this work. -Jussi On 19.06.2013 19:45, Vasiliy wrote: > I've just tried to compile cast5-amd64.S, and it does not, however, it > does compile with -m32 option. Are you sure you've pushed up the > 64-bit code?... > > $ gcc -m64 -DHAVE_CONFIG_H -I. > -I/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher > -I.. -I../src -I/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/src > -ggdb -march=native -mtune=native -Ofast -fomit-frame-pointer -pipe > -fdebug-prefix-map=/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/build=/usr/src/debug/libgcrypt-1.6.0-1 > -fdebug-prefix-map=/usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0=/usr/src/debug/libgcrypt-1.6.0-1 > -MT cast5-amd64.lo -MD -MP -MF .deps/cast5-amd64.Tpo -c > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S > -DDLL_EXPORT -DPIC -o .libs/cast5-amd64.o > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S: > Assembler messages: > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:183: > Warning: .type pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:183: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:219: > Warning: .size pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:219: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:223: > Warning: .type pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:223: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:259: > Warning: .size pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:259: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:362: > Warning: .type pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:362: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:387: > Warning: .size pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:387: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:390: > Warning: .type pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:390: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:417: > Warning: .size pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:417: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:421: > Warning: .type pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:421: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:475: > Warning: .size pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:475: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:479: > Warning: .type pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:479: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:529: > Warning: .size pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:529: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:533: > Warning: .type pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:533: > Error: junk at end of line, first unrecognized character is `_' > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:584: > Warning: .size pseudo-op used outside of .def/.endef ignored. > /usr/src/64bit/release/libGCrypt/libgcrypt-1.6.0-1/src/libgcrypt-1.6.0/cipher/cast5-amd64.S:584: > Error: junk at end of line, first unrecognized character is `_' > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: 06-add-check-for-assembler-compatibility.patch Type: text/x-patch Size: 9584 bytes Desc: not available URL: From testtest_2005 at ukr.net Thu Jun 20 14:26:54 2013 From: testtest_2005 at ukr.net (Vasiliy) Date: Thu, 20 Jun 2013 14:26:54 +0200 Subject: New amd64 implementations? In-Reply-To: <51C2F224.7000609@iki.fi> References: <51C2F224.7000609@iki.fi> Message-ID: Thank you, Jussi. If me could be of any help, you're welcome. Meanwhile, it's possible to test a 64-bit assembler code yet on 32-bit Windows with Cygwin (aka 32-bit), with bundled cross compiler 'x86_64-pc-cygwin-gcc' or by feeding '-m64' option to a 32-bit 'gcc'. Kind regards, Vasiliy On Thu, Jun 20, 2013 at 2:14 PM, Jussi Kivilinna wrote: > Hello, > > I have attached patch that is for the cipher-amd64-optimizations branch. It disables AMD64 > assembly implementations if platform assembler is found to be incompatible with those > implementations. > > Adding cygwin64/mingw64 support for these optimizations would require some extra work to > handle the different calling convention and I don't have licence for 64-bit Windows, so > I cannot easily do this work. > > -Jussi > > On 19.06.2013 19:45, Vasiliy wrote: From testtest_2005 at ukr.net Thu Jun 20 19:47:01 2013 From: testtest_2005 at ukr.net (Vasiliy) Date: Thu, 20 Jun 2013 19:47:01 +0200 Subject: Fwd: gpgsm with elliptic curve algo (Re: SHAxxxWithECDSA) Message-ID: Could it be possible to know, how the following error has been handled?: It appears while importing Thawte certificates bundle. Seiji Ariga ariga at khaotic.net Thu May 17 15:40:47 CEST 2012 Hi. On Thu, 17 May 2012 10:26:20 +0200, Werner Koch wrote, > > libgcrypt does not support, say, SHA384WithECDSA (*1) ? (OID is > > 1.2.840.10045.4.3.3) > Please try adding this OID to libgcrypt/cipher/sha512.c, > oid_spec_sha384. gpgpsm stopped showing "unknown hash algorithm". :-) Now it's producing different error. ---- $ gpgsm --debug-level guru --status-fd 1 --import cert.pem gpgsm: enabled debug flags: x509 mpi crypto memory cache memstat hashing assuan gpgsm: DBG: signature value: 28 37 3A 73 69 67 2D 76 61 6C 28 35 3A 65 63 64 73 61 28 31 3A 72 34 38 3A 66 21 0C 18 26 60 5A 38 7B 56 42 E0 A7 FC 36 84 51 91 20 2C 76 4D 43 3D C4 1D 84 23 D0 AC D6 7C 35 06 CE CD 69 BD 90 0D DB 6C 48 42 1D 0E AA 42 29 28 31 3A 73 34 39 3A 00 9C 3D 48 39 23 39 58 1A 15 12 59 6A 9E EF D5 59 B2 1D 52 2C 99 71 CD C7 29 DF 1B 2A 61 7B 71 D1 DE F3 C0 E5 0D 3A 4A AA 2D A7 D8 86 2A DD 2E 10 29 29 28 34 3A 68 61 73 68 36 3A 73 68 61 33 38 34 29 29 gpgsm: DBG: encoded hash: 28 AC 5A D9 30 27 8C BD 27 6E ED 75 21 4D BA 04 EC 8B 1E 19 E6 3E 30 32 4F A1 BD A0 E9 E8 3B F8 E0 78 6E B8 79 2B E4 A7 5B 20 A6 93 B9 F6 21 EF gpgsm: DBG: gcry_pk_verify: Conflicting use gpgsm: self-signed certificate has a BAD signature: Conflicting use gpgsm: DBG: BEGIN Certificate `self-signing cert': gpgsm: DBG: serial: 2F80FE238C0E220F486712289187ACB3 gpgsm: DBG: notBefore: 2007-11-05 00:00:00 gpgsm: DBG: notAfter: 2038-01-18 23:59:59 gpgsm: DBG: issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G4,OU=(c) 2007 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US gpgsm: DBG: subject: CN=VeriSign Class 3 Public Primary Certification Authority - G4,OU=(c) 2007 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US gpgsm: DBG: hash algo: 1.2.840.10045.4.3.3 gpgsm: DBG: SHA1 Fingerprint: 22:D5:D8:DF:8F:02:31:D1:8D:F7:9D:B7:CF:8A:2D:64:C9:3F:6C:3A gpgsm: DBG: END Certificate gpgsm: basic certificate checks failed - not imported [GNUPG:] IMPORT_PROBLEM 1 22D5D8DF8F0231D18DF79DB7CF8A2D64C93F6C3A gpgsm: total number processed: 1 gpgsm: not imported: 1 [GNUPG:] IMPORT_RES 1 0 0 0 0 0 0 0 0 0 0 0 0 1 random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 0/16384 bytes in 0 blocks ---- I guess this is because gcry_pk_verify() fails due to "pubkey algo ECDH != signature algo ECDSA" in gpgsm_check_cert_sig(). src/gcrypt.h ---- enum gcry_pk_algos { [...] GCRY_PK_ECDSA = 301, GCRY_PK_ECDH = 302 }; ---- // Seiji Ariga From testtest_2005 at ukr.net Thu Jun 20 21:05:13 2013 From: testtest_2005 at ukr.net (Vasiliy) Date: Thu, 20 Jun 2013 21:05:13 +0200 Subject: FYI: Thawte and Siemens unsupported inquiries Message-ID: Source: https://www.siemens.com/corp/en/index/digital_id.htm and Thawte bundled certificates, plus one not found in there. gpgsm --call-dirmngr loadcrl $HOME/ThawtePersonalFreemailIssuingCA.crl ... gpgsm: unsupported inquiry 'ISTRUSTED E61883AE84CAC1C1CD52ADE8E9252B45A64FB7E2' ... Siemens CRL's: gpgsm: unsupported inquiry 'SENDCERT_SKI From jussi.kivilinna at iki.fi Tue Jun 25 07:47:15 2013 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Tue, 25 Jun 2013 08:47:15 +0300 Subject: New amd64 implementations? In-Reply-To: References: <51C2F224.7000609@iki.fi> Message-ID: <51C92EE3.1060401@iki.fi> On 20.06.2013 15:26, Vasiliy wrote: > Thank you, Jussi. > > If me could be of any help, you're welcome. Meanwhile, it's possible > to test a 64-bit assembler code yet on 32-bit Windows with Cygwin (aka > 32-bit), with bundled cross compiler 'x86_64-pc-cygwin-gcc' or by > feeding '-m64' option to a 32-bit 'gcc'. I managed to get mingw64 build of libgcrypt to work on linux. To point that even 'make check' works, thanks to wine. Basically I added the autogen.sh mingw64 changes that appeared in libgpg-error and worked my way through all the issues that rose (added MS ABI => SysV ABI wrapper code for mpi&cipher assembly code, and pile of other changes). -Jussi > > Kind regards, > Vasiliy > > On Thu, Jun 20, 2013 at 2:14 PM, Jussi Kivilinna wrote: >> Hello, >> >> I have attached patch that is for the cipher-amd64-optimizations branch. It disables AMD64 >> assembly implementations if platform assembler is found to be incompatible with those >> implementations. >> >> Adding cygwin64/mingw64 support for these optimizations would require some extra work to >> handle the different calling convention and I don't have licence for 64-bit Windows, so >> I cannot easily do this work. >> >> -Jussi >> >> On 19.06.2013 19:45, Vasiliy wrote: > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > From jussi.kivilinna at iki.fi Tue Jun 25 07:48:26 2013 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Tue, 25 Jun 2013 08:48:26 +0300 Subject: New amd64 implementations... In-Reply-To: <51B58CAE.7090603@iki.fi> References: <51B58CAE.7090603@iki.fi> Message-ID: <51C92F2A.6020704@iki.fi> On 10.06.2013 11:22, Jussi Kivilinna wrote: > Hello, > > I have pushed new optimized implementations to 'cipher-amd64-optimizations' branch at 'git.gnupg.org/libgcrypt.git'. It is ok, if I push 'cipher-amd64-optimizations' to master? -Jussi > > These changes include: > - AMD64 implementation of blowfish > + with 4-way parallel implementation for CBC/CFB/CTR-decryption and CTR-encryption. > - AMD64 implementation of AES > - AMD64 implementation of twofish > + with 3-way parallel implementations > - Detection for new AVX2 instruction set > - 16-way parallel implementation for Serpent using AVX2 > - 32-way parallel implementation for Camellia using AVX2 and AES-NI > - Generic optimization for _gcry_burn_stack > > -Jussi > > > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > From wk at gnupg.org Tue Jun 25 10:04:56 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Jun 2013 10:04:56 +0200 Subject: New amd64 implementations? In-Reply-To: <51C92EE3.1060401@iki.fi> (Jussi Kivilinna's message of "Tue, 25 Jun 2013 08:47:15 +0300") References: <51C2F224.7000609@iki.fi> <51C92EE3.1060401@iki.fi> Message-ID: <87r4fqmx93.fsf@vigenere.g10code.de> On Tue, 25 Jun 2013 07:47, jussi.kivilinna at iki.fi said: > Basically I added the autogen.sh mingw64 changes that appeared in libgpg-error and That is the right way. Remember not to use any build done for w64. The RNG has not been checked for correctness - in fact it is unlikely that it is okay. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jun 25 10:16:47 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Jun 2013 10:16:47 +0200 Subject: New amd64 implementations... In-Reply-To: <51C92F2A.6020704@iki.fi> (Jussi Kivilinna's message of "Tue, 25 Jun 2013 08:48:26 +0300") References: <51B58CAE.7090603@iki.fi> <51C92F2A.6020704@iki.fi> Message-ID: <87mwqemwpc.fsf@vigenere.g10code.de> On Tue, 25 Jun 2013 07:48, jussi.kivilinna at iki.fi said: > It is ok, if I push 'cipher-amd64-optimizations' to master? Please do that. More people will test it this way. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jussi.kivilinna at iki.fi Wed Jun 26 12:38:24 2013 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Wed, 26 Jun 2013 13:38:24 +0300 Subject: New amd64 implementations? In-Reply-To: <87r4fqmx93.fsf@vigenere.g10code.de> References: <51C2F224.7000609@iki.fi> <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de> Message-ID: <51CAC4A0.4090304@iki.fi> On 25.06.2013 11:04, Werner Koch wrote: > On Tue, 25 Jun 2013 07:47, jussi.kivilinna at iki.fi said: > >> Basically I added the autogen.sh mingw64 changes that appeared in libgpg-error and > > That is the right way. Is it ok, if I make new branch for mingw64 support work? > > Remember not to use any build done for w64. The RNG has not been > checked for correctness - in fact it is unlikely that it is okay. What kind of problems should be checked for? Microsoft appears to have made transition from WIN32 to WIN64 easy; the size of 'long' remains at 4 bytes and type sizes in Win API appear to remain mostly the same with exception of pointer types (HANDLE, HWIN, etc) and pointer sized integers. Some API functions appear to be changed, most notably GetProcessWorkingSetSize which now takes two SIZE_T* arguments, instead of two DWORD*. -Jussi > > > Shalom-Salam, > > Werner > From funman at videolan.org Wed Jun 26 17:52:27 2013 From: funman at videolan.org (=?ISO-8859-1?Q?Rafa=EBl_Carr=E9?=) Date: Wed, 26 Jun 2013 17:52:27 +0200 Subject: New amd64 implementations? In-Reply-To: <51CAC4A0.4090304@iki.fi> References: <51C2F224.7000609@iki.fi> <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de> <51CAC4A0.4090304@iki.fi> Message-ID: <51CB0E3B.7090304@videolan.org> Hello, Le 26/06/2013 12:38, Jussi Kivilinna a ?crit : > Is it ok, if I make new branch for mingw64 support work? Small nitpicking here, the name is "mingw-w64". Thanks, From wk at gnupg.org Wed Jun 26 19:15:34 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Jun 2013 19:15:34 +0200 Subject: New amd64 implementations? In-Reply-To: <51CAC4A0.4090304@iki.fi> (Jussi Kivilinna's message of "Wed, 26 Jun 2013 13:38:24 +0300") References: <51C2F224.7000609@iki.fi> <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de> <51CAC4A0.4090304@iki.fi> Message-ID: <87bo6sg5e1.fsf@vigenere.g10code.de> On Wed, 26 Jun 2013 12:38, jussi.kivilinna at iki.fi said: > Is it ok, if I make new branch for mingw64 support work? No, that is not needed. > Microsoft appears to have made transition from WIN32 to WIN64 easy; the size of 'long' remains at 4 bytes and type sizes in Win API appear to remain mostly the same with exception of pointer > types (HANDLE, HWIN, etc) and pointer sized integers. We need to reevaluate the entire rndw32.c. In fact a rndw64.c should be written. All other things will be simple to fix. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jussi.kivilinna at iki.fi Wed Jun 26 20:24:03 2013 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Wed, 26 Jun 2013 21:24:03 +0300 Subject: New amd64 implementations? In-Reply-To: <51CB0E3B.7090304@videolan.org> References: <51C2F224.7000609@iki.fi> <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de> <51CAC4A0.4090304@iki.fi> <51CB0E3B.7090304@videolan.org> Message-ID: <51CB31C3.9000105@iki.fi> On 26.06.2013 18:52, Rafa?l Carr? wrote: > Hello, > > Le 26/06/2013 12:38, Jussi Kivilinna a ?crit : > >> Is it ok, if I make new branch for mingw64 support work? > > Small nitpicking here, the name is "mingw-w64". Ah, ok. -Jussi > > Thanks, > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel > From wk at gnupg.org Wed Jun 26 22:57:24 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Jun 2013 22:57:24 +0200 Subject: New amd64 implementations? In-Reply-To: <51CB0E3B.7090304@videolan.org> (=?utf-8?Q?=22Rafa=C3=ABl_Car?= =?utf-8?Q?r=C3=A9=22's?= message of "Wed, 26 Jun 2013 17:52:27 +0200") References: <51C2F224.7000609@iki.fi> <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de> <51CAC4A0.4090304@iki.fi> <51CB0E3B.7090304@videolan.org> Message-ID: <877ghgfv4b.fsf@vigenere.g10code.de> On Wed, 26 Jun 2013 17:52, funman at videolan.org said: > Small nitpicking here, the name is "mingw-w64". Which however conflicts with the CPU-VENDOR-OS triplet ;-). A 64 bit Windows is a still a Win32 based Windows NT OS where only the CPU is different. Thus it should be something amd64-mingw-w32 or x86_64-mingw-winnt and the former Alpha version would have had a alpha-mingw-w32 triplet. I have understood why this 4th variant of the mingw toolchain uses a name which so easy leads to misunderstandings. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From funman at videolan.org Wed Jun 26 23:10:59 2013 From: funman at videolan.org (=?ISO-8859-1?Q?Rafa=EBl_Carr=E9?=) Date: Wed, 26 Jun 2013 23:10:59 +0200 Subject: New amd64 implementations? In-Reply-To: <877ghgfv4b.fsf@vigenere.g10code.de> References: <51C2F224.7000609@iki.fi> <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de> <51CAC4A0.4090304@iki.fi> <51CB0E3B.7090304@videolan.org> <877ghgfv4b.fsf@vigenere.g10code.de> Message-ID: <51CB58E3.3070404@videolan.org> Le 26/06/2013 22:57, Werner Koch a ?crit : > On Wed, 26 Jun 2013 17:52, funman at videolan.org said: > >> Small nitpicking here, the name is "mingw-w64". > > Which however conflicts with the CPU-VENDOR-OS triplet ;-). A 64 bit > Windows is a still a Win32 based Windows NT OS where only the CPU is > different. Thus it should be something amd64-mingw-w32 or > x86_64-mingw-winnt and the former Alpha version would have had a > alpha-mingw-w32 triplet. The gcc triplet is actually x86_64-w64-mingw32, although the project name for headers/libraries is mingw-w64. (See http://mingw-w64.sourceforge.net/) > I have understood why this 4th variant of the mingw toolchain uses a > name which so easy leads to misunderstandings. Indeed it's very confusing :) > Salam-Shalom, > > Werner From jussi.kivilinna at iki.fi Thu Jun 27 16:33:12 2013 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Thu, 27 Jun 2013 17:33:12 +0300 Subject: New amd64 implementations? In-Reply-To: <87bo6sg5e1.fsf@vigenere.g10code.de> References: <51C2F224.7000609@iki.fi> <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de> <51CAC4A0.4090304@iki.fi> <87bo6sg5e1.fsf@vigenere.g10code.de> Message-ID: <51CC4D28.7060204@iki.fi> On 26.06.2013 20:15, Werner Koch wrote: > On Wed, 26 Jun 2013 12:38, jussi.kivilinna at iki.fi said: > >> Is it ok, if I make new branch for mingw64 support work? > > No, that is not needed. > >> Microsoft appears to have made transition from WIN32 to WIN64 easy; the size of 'long' remains at 4 bytes and type sizes in Win API appear to remain mostly the same with exception of pointer >> types (HANDLE, HWIN, etc) and pointer sized integers. > > We need to reevaluate the entire rndw32.c. In fact a rndw64.c should be > written. All other things will be simple to fix. > Would it make sense to re-evaluate rndw32.c for current Windows versions (32/64bit) and drop support for Windows versions that have reached end of life? As I understand it, the CryptGenRandom function is supported by all current Windows and is the '/dev/urandom' of WIN32. -Jussi > > Shalom-Salam, > > Werner > From wk at gnupg.org Thu Jun 27 20:21:57 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 27 Jun 2013 20:21:57 +0200 Subject: New amd64 implementations? In-Reply-To: <51CC4D28.7060204@iki.fi> (Jussi Kivilinna's message of "Thu, 27 Jun 2013 17:33:12 +0300") References: <51C2F224.7000609@iki.fi> <51C92EE3.1060401@iki.fi> <87r4fqmx93.fsf@vigenere.g10code.de> <51CAC4A0.4090304@iki.fi> <87bo6sg5e1.fsf@vigenere.g10code.de> <51CC4D28.7060204@iki.fi> Message-ID: <87vc4zct2y.fsf@vigenere.g10code.de> On Thu, 27 Jun 2013 16:33, jussi.kivilinna at iki.fi said: > Would it make sense to re-evaluate rndw32.c for current Windows versions (32/64bit) and drop support for Windows versions that have reached end of life? Better don't touch it ;-) IIRC, I already remove some old code. > As I understand it, the CryptGenRandom function is supported by all current Windows and is the '/dev/urandom' of WIN32. I wouldn't trust CryptGenRandom. It is used only as one entropy source. What should really be done is to compare the changes Peter did in Cryptlib and port them back to Libgcrypt. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From testtest_2005 at ukr.net Fri Jun 28 21:20:53 2013 From: testtest_2005 at ukr.net (Vasiliy) Date: Fri, 28 Jun 2013 21:20:53 +0200 Subject: 64-bit: some compilation warnings (gcc 4.8.1, Cygwin64) Message-ID: typos (apdu.c, pcsc-wrapper.c): unsinged -> unsigned also: /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c: In function ?pcsc_send_apdu_direct?: /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1046:35: warning: unused parameter ?pininfo? [-Wunused-parameter] pininfo_t *pininfo) ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c: In function ?connect_pcsc_card?: /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1491:26: warning: passing argument 4 of ?pcsc_status? from incompatible pointer type [enabled by default] reader_table[slot].atr, &atrlen); ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1491:26: note: expected ?pcsc_dword_t *? but argument is of type ?long int *? /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1491:26: warning: passing argument 5 of ?pcsc_status? from incompatible pointer type [enabled by default] /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1491:26: note: expected ?pcsc_dword_t *? but argument is of type ?long int *? /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1494:20: warning: format ?%lu? expects argument of type ?long unsigned int?, but argument 4 has type ?pcsc_dword_t? [-Wformat=] pcsc_error_string (err), err, readerlen); ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c: In function ?open_pcsc_reader_direct?: /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/apdu.c:1681:25: warning: variable ?listlen? set but not used [-Wunused-but-set-variable] pcsc_dword_t nreader, listlen; ^ ... /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/app-nks.c: In function ?do_change_pin?: /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/app-nks.c:1250:9: warning: ?pwid? may be used uninitialized in this function [-Wmaybe-uninitialized] err = iso7816_change_reference_data (app->slot, pwid, ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/app-nks.c: In function ?do_check_pin?: /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/scd/app-nks.c:1279:3: warning: ?pwid? may be used uninitialized in this function [-Wmaybe-uninitialized] return verify_pin (app, pwid, desc, pincb, pincb_arg); ^ ... /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/g13/mount.c: In function ?g13_mount_container?: /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/g13/mount.c:161:10: warning: ?headerlen? may be used uninitialized in this function [-Wmaybe-uninitialized] msglen = headerlen - 32; ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/g13/mount.c:142:10: note: ?headerlen? was declared here size_t headerlen, msglen; ^ ... /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c: In function ?pid_suffix_callback?: /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:542:3: warning: passing argument 1 of ?pthread_getspecific? makes pointer from integer without a cast [enabled by default] value.aptr = npth_getspecific (my_tlskey_current_fd); ^ In file included from /usr/include/npth.h:61:0, from /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:43: /usr/include/pthread.h:145:7: note: expected ?pthread_key_t? but argument is of type ?int? void *pthread_getspecific (pthread_key_t); ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c: In function ?main?: /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:651:3: warning: passing argument 1 of ?pthread_key_create? from incompatible pointer type [enabled by default] if (npth_key_create (&my_tlskey_current_fd, NULL) == 0) ^ In file included from /usr/include/npth.h:61:0, from /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:43: /usr/include/pthread.h:147:5: note: expected ?struct __pthread_key_t **? but argument is of type ?int *? int pthread_key_create (pthread_key_t *, void (*)(void *)); ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:652:5: warning: passing argument 1 of ?pthread_setspecific? makes pointer from integer without a cast [enabled by default] if (npth_setspecific (my_tlskey_current_fd, NULL) == 0) ^ In file included from /usr/include/npth.h:61:0, from /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:43: /usr/include/pthread.h:202:5: note: expected ?pthread_key_t? but argument is of type ?int? int pthread_setspecific (pthread_key_t, const void *); ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c: In function ?start_connection_thread?: /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:1714:3: warning: passing argument 1 of ?pthread_setspecific? makes pointer from integer without a cast [enabled by default] npth_setspecific (my_tlskey_current_fd, argval.aptr); ^ In file included from /usr/include/npth.h:61:0, from /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:43: /usr/include/pthread.h:202:5: note: expected ?pthread_key_t? but argument is of type ?int? int pthread_setspecific (pthread_key_t, const void *); ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:1729:3: warning: passing argument 1 of ?pthread_setspecific? makes pointer from integer without a cast [enabled by default] npth_setspecific (my_tlskey_current_fd, argval.aptr); ^ In file included from /usr/include/npth.h:61:0, from /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/dirmngr/dirmngr.c:43: /usr/include/pthread.h:202:5: note: expected ?pthread_key_t? but argument is of type ?int? int pthread_setspecific (pthread_key_t, const void *); ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/tools/gpgkey2ssh.c: In function ?main?: /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/tools/gpgkey2ssh.c:148:11: warning: ?fields[3]? may be used uninitialized in this function [-Wmaybe-uninitialized] err = gcry_mpi_scan (&mpi, GCRYMPI_FMT_HEX, fields[3], 0, NULL); ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/tools/gpgkey2ssh.c:85:13: note: ?fields[3]? was declared here char *fields[6]; ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/tools/gpgkey2ssh.c:141:9: warning: ?fields[1]? may be used uninitialized in this function [-Wmaybe-uninitialized] i = atoi (fields[1]); ^ /usr/src/64bit/release/gnupg/gnupg-2.1.0beta4-1/src/gnupg-2.1.0beta4/tools/gpgkey2ssh.c:85:13: note: ?fields[1]? was declared here char *fields[6]; ^ From testtest_2005 at ukr.net Sat Jun 29 09:37:04 2013 From: testtest_2005 at ukr.net (Vasiliy) Date: Sat, 29 Jun 2013 09:37:04 +0200 Subject: could not create a keypair / sign a single file Message-ID: Dear GNUPG Team, I couldn't get a detachable signature with the existing/imported key which doesn't make a use of CRL's, neither could I create a new keypair with the latest gpgsm and libraries built on my 64-bit machine. What am I doing wrong? Best regards, Vasiliy $ gpgsm --detach-sign --disable-crl-checks --verbose libgcrypt-1.6.0.tar.bz2 > libgcrypt-1.6.0.tar.bz2.sig gpgsm: NOTE: THIS IS A DEVELOPMENT VERSION! gpgsm: It is only intended for test purposes and should NOT be gpgsm: used in a production environment or with production keys! gpgsm: enabled debug flags: assuan gpgsm: certificate is good gpgsm: root certificate is good gpgsm: no running gpg-agent - starting '/usr/bin/gpg-agent' gpgsm: waiting for the agent to come up ... (5s) gpgsm: waiting for the agent to come up ... (4s) gpgsm: DBG: chan_4 <- OK Pleased to meet you, process 9724 gpgsm: connection to agent established gpgsm: DBG: chan_4 -> RESET gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION ttyname=/dev/pty5 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION ttytype=xterm gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION display=:0.0 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION xauthority=~/.Xauthority gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION lc-ctype=en_US.UTF-8 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION lc-messages=en_US.UTF-8 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION allow-pinentry-notify gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> ISTRUSTED FB7EAD4851BE76AF04486BA4738A744BFB50DE86 gpgsm: DBG: chan_4 <- ERR 67108961 Line too long gpgsm: checking the trust list failed: Line too long gpgsm: validation model used: shell gpgsm: error creating signature: Line too long secmem usage: 0/65536 bytes in 0 blocks ... configure: checking for libraries checking for gpg-error-config... (cached) /usr/bin/gpg-error-config checking for GPG Error - version >= 1.11... yes (1.12-beta6) checking for libgcrypt-config... (cached) /usr/bin/libgcrypt-config checking for LIBGCRYPT - version >= 1.5.0... yes (1.6.0-beta145) checking LIBGCRYPT API version... okay checking for libassuan-config... (cached) /usr/bin/libassuan-config checking for LIBASSUAN - version >= 2.1.0... yes (2.1.0) checking LIBASSUAN API version... okay checking for ksba-config... (cached) /usr/bin/ksba-config checking for KSBA - version >= 1.2.0... yes (1.3.1-beta3) checking KSBA API version... okay checking for usb_bulk_write in -lusb... (cached) no checking for usb_create_match... (cached) no checking for library containing dlopen... (cached) none required checking for encfs... (cached) /usr/bin/encfs checking for fusermount... (cached) /usr/bin/fusermount checking for openpty in -lutil... (cached) yes checking for shred... (cached) /usr/bin/shred checking for npth-config... (cached) /usr/bin/npth-config checking for NPTH - version >= 0.91... yes (0.91) checking NPTH API version... okay ... checking for iconv declaration... (cached) extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); ... GnuPG v2.1.0-beta220 has been configured as follows: Revision: 82c25e6 (33474) Platform: Cygwin (x86_64-unknown-cygwin) OpenPGP: yes S/MIME: yes Agent: yes Smartcard: yes (without internal CCID driver) G13: yes Dirmngr: yes Gpgtar: yes Protect tool: (default) LDAP wrapper: (default) Default agent: (default) Default pinentry: /usr/bin/pinentry-gtk-2 Default scdaemon: (default) Default dirmngr: (default) Use standard socket: yes Dirmngr auto start: yes ... $ gpgsm --gen-key --verbose gpgsm (GnuPG) 2.1.0-beta220; Copyright (C) 2012 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpgsm: NOTE: THIS IS A DEVELOPMENT VERSION! gpgsm: It is only intended for test purposes and should NOT be gpgsm: used in a production environment or with production keys! gpgsm: enabled debug flags: assuan Please select what kind of key you want: (1) RSA (2) Existing key (3) Existing key from card Your selection? 1 What keysize do you want? (2048) 1024 Requested keysize is 1024 bits Possible actions for a RSA key: (1) sign, encrypt (2) sign (3) encrypt Your selection? 1 Enter the X.509 subject name: 'NAME' Enter email addresses (end with an empty line): > Enter DNS names (optional; end with an empty line): > Enter URIs (optional; end with an empty line): > Create self-signed certificate? (y/N) Y These parameters are used: Key-Type: RSA Key-Length: 1024 Key-Usage: sign, encrypt Serial: random Name-DN: 'NAME' Proceed with creation? (y/N) Y Now creating self-signed certificate. This may take a while ... gpgsm: no running gpg-agent - starting '/usr/bin/gpg-agent' gpgsm: waiting for the agent to come up ... (5s) gpgsm: waiting for the agent to come up ... (4s) gpgsm: DBG: chan_4 <- OK Pleased to meet you, process 29624 gpgsm: connection to agent established gpgsm: DBG: chan_4 -> RESET gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION ttyname=/dev/pty5 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION ttytype=xterm gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION display=:0.0 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION xauthority=~/.Xauthority gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION lc-ctype=en_US.UTF-8 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION lc-messages=en_US.UTF-8 gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> OPTION allow-pinentry-notify gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> RESET gpgsm: DBG: chan_4 <- OK gpgsm: DBG: chan_4 -> GENKEY gpgsm: DBG: chan_4 <- S INQUIRE_MAXLEN 1024 gpgsm: DBG: chan_4 <- INQUIRE KEYPARAM gpgsm: DBG: chan_4 -> D (6:genkey(3:rsa(5:nbits4:1024))) gpgsm: DBG: chan_4 -> END gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 14648 gpgsm: DBG: chan_4 -> END gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 8752 gpgsm: DBG: chan_4 -> END gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 33476 gpgsm: DBG: chan_4 -> END gpgsm: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 9628 gpgsm: DBG: chan_4 -> END gpgsm: DBG: chan_4 <- S CACHE_NONCE C2E4CD8509DED213BFC75CC4 gpgsm: DBG: chan_4 <- [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(168 byte(s) skipped) ] gpgsm: DBG: chan_4 <- OK gpgsm: error setting the subject's name: Not implemented gpgsm: error creating certificate request: Not implemented secmem usage: 0/65536 bytes in 0 blocks From ametzler at downhill.at.eu.org Sun Jun 30 19:27:28 2013 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 30 Jun 2013 19:27:28 +0200 Subject: No secmem support on kfreebsd-amd64 Message-ID: <20130630172728.GA3233@downhill.g.la> Hello, it looks like secmem support is broken on kfreebsd-amd64 (gcrypt 1.5.2): ---------------------- (sid_kfreebsd-amd64-dchroot)ametzler at falla:~/GCR$ gcc -O2 -o minimal-gcrypt -lgcrypt minimal-gcrypt.c && ./minimal-gcrypt minimal-gcrypt: minimal-gcrypt.c:16: main: Assertion `! err' failed. Aborted ---------------------- cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: minimal-gcrypt.c Type: text/x-csrc Size: 406 bytes Desc: not available URL: From wk at gnupg.org Sun Jun 30 23:46:55 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 30 Jun 2013 23:46:55 +0200 Subject: could not create a keypair / sign a single file In-Reply-To: (Vasiliy's message of "Sat, 29 Jun 2013 09:37:04 +0200") References: Message-ID: <8761wvb7ao.fsf@vigenere.g10code.de> On Sat, 29 Jun 2013 09:37, testtest_2005 at ukr.net said: > gpgsm: DBG: chan_4 -> ISTRUSTED FB7EAD4851BE76AF04486BA4738A744BFB50DE86 > gpgsm: DBG: chan_4 <- ERR 67108961 Line too long > gpgsm: checking the trust list failed: Line too long Please check ~/.gnupg.trustlist.txt. A line is longer that 255 bytes. You will find the above fingerprint there - what is special with that line? Did you edit it manually, has it been added by GnuPG, or was it created by Kleopatra or another tool? > gpgsm: error setting the subject's name: Not implemented > gpgsm: error creating certificate request: Not implemented You libksba is too old. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.