From freebsd-listen at fabiankeil.de Sat Nov 2 14:16:00 2013 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Sat, 2 Nov 2013 14:16:00 +0100 Subject: Missing g10_errstr() equivalent in gpgme Message-ID: <03b7abfa.0f7beda4@fabiankeil.de> I occasionally get mails that aren't encrypted with one of my own public keys, but using keys that don't belong to me. In this case, claws-mail currently merely notes: "couldn't decrypt: Decryption failed" This is the result of this code excerpt from src/plugins/pgpcore/sgpgme.c | gpgme_data_t sgpgme_decrypt_verify(gpgme_data_t cipher, gpgme_verify_result_t *status, gpgme_ctx_t ctx) | { | [...] | if (gpgme_get_protocol(ctx) == GPGME_PROTOCOL_OpenPGP) { | err = gpgme_op_decrypt_verify(ctx, cipher, plain); | if (err != GPG_ERR_NO_ERROR) { | debug_print("can't decrypt (%s)\n", gpgme_strerror(err)); | privacy_set_error("%s", gpgme_strerror(err)); | gpgmegtk_free_passphrase(); | gpgme_data_release(plain); | return NULL; | } Therefore one has to manually use gpg to figure out the cause of the problem: fk at r500 ~ $gpg --decrypt encrypted-message gpg: encrypted with RSA key, ID [...] gpg: encrypted with RSA key, ID [...] gpg: decryption failed: secret key not available As this is tedious, I'd like to modify claws-mail to provide similar details and am missing something like gnupg's g10_errstr() in gpgme. I'd prefer not to copy&paste it from gnupg into claws-mail's pgp module. Any suggestions? Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From duncan at p2vpro.com Sat Nov 2 20:00:04 2013 From: duncan at p2vpro.com (p2vpro IMAP) Date: Sat, 2 Nov 2013 19:00:04 +0000 Subject: Compiling on Maverick Message-ID: Hi all, looking for some help with installing GnuPG on an iMac running Maverick (10.9 (13A603)) Started working on the pre-reqs and got to libgcrypt-1.5.3 configured as follows: Libgcrypt v1.5.3 has been configured as follows: Revision: a3eabcb (41962) Platform: Darwin (x86_64-apple-darwin13.0.0) Enabled cipher algorithms: arcfour blowfish cast5 des aes twofish serpent rfc2268 seed camellia idea Enabled digest algorithms: crc md4 md5 rmd160 sha1 sha256 sha512 tiger whirlpool Enabled pubkey algorithms: dsa elgamal rsa ecc Random number generator: default Using linux capabilities: no Try using Padlock crypto: yes Try using AES-NI crypto: yes A ?make? gets as far as: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -g -O2 -MT mpih-mul1-asm.lo -MD -MP -MF .deps/mpih-mul1-asm.Tpo -c mpih-mul1-asm.S -fno-common -DPIC -o .libs/mpih-mul1-asm.o mpih-mul1-asm.S:43:9: error: invalid alignment value .align 1<<(5) ^ make[2]: *** [mpih-mul1-asm.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Any suggestions? From kristian.fiskerstrand at sumptuouscapital.com Sat Nov 2 20:58:05 2013 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sat, 02 Nov 2013 20:58:05 +0100 Subject: Compiling on Maverick In-Reply-To: References: Message-ID: <5275594D.6050705@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/02/2013 08:00 PM, p2vpro IMAP wrote: > Hi all, looking for some help with installing GnuPG on an iMac > running Maverick (10.9 (13A603)) > ... > Any suggestions? _______________________________________________ Without looking into your issue in particular I would recommend looking into https://gpgtools.org/ and as such macgpg which has a git repository at https://github.com/GPGTools/MacGPG2 . - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Testis unus, testis nullus A single witness is no witness -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSdVlIAAoJEAt/i2Dj7frjf4oQAKbjr5cDj6tu3lrP1Lwq/Uyi xobAHDIdksaGskVlfxGhoHZMEHRtWw7/FpayzSM7mRkXQ/MyQzX0u707MdO+8ypP jBUkGWwKXXmibBVaMXeTcoy5g8dzotrIWVygZGYtXIy9hGRyzCE+nNSKhKjGVwfV a1pufwLQP55f7dY4yy1/zkikEixm5EVlFXRlAF+9I7XfCISUjD3nIvBRzImbXXjL I8f+vBZlNPRksYK3bMZ43h/FOgzVr/oDxq7yV9xzbxGomaRX+bkDMcpw9iMuUZKq vXjQEzCR5MSWAhv39ijPtGhAYZOsI4JIsFzpfyXGtUZjW+zqhpQk9060qlX4pOnq D1ej6Mkh5UhkviENS135oqmUg0s3KapAjLBCJtu2heW3y6102kK9nB8c5fyxZbNX H/VUiVJkX/B+KBmgvr1cfLIna1T/nL15gprXsyqJLcUZWVOWpRlK34PwGtU6gfgs ZkCsDZVjYUY3+e+x6sTycDg0EJU6f08V4CrapH4CtHP3NVtGwgB5kTEVG4QNx09C ZSPm969VIr1Czf8Nhsonz4+uHIKr4wXQLVSiQ06R5F0F6M+kH9oCzAgvbO4K2K5V yrd2NjDhHOb13jlw7dqbFOC4bojvXemMz6V83FFKnd7N951nsEmWAe92RkiSnk2p iJfnVkmIqQYo8GNptj4+ =N9rk -----END PGP SIGNATURE----- From christoph_murauer at yahoo.de Sat Nov 2 21:56:56 2013 From: christoph_murauer at yahoo.de (Christoph Roland Murauer) Date: Sat, 2 Nov 2013 21:56:56 +0100 Subject: Compiling on Maverick In-Reply-To: References: Message-ID: <53DC1C20-BC16-4FEC-99CA-E1BBD732116F@yahoo.de> Hy ! Depends on the rest of your build system like CFLAGS and so on. Run make clean and add --disable-asm to ./configure. Apple has changed many things in Xcode 5 (gcc / llvm). As inspiration you could look at https://github.com/mxcl/homebrew/blob/master/Library/Formula/libgcrypt.rb. C. M. Am 02.11.2013 um 20:00 schrieb p2vpro IMAP : > Hi all, looking for some help with installing GnuPG on an iMac running Maverick (10.9 (13A603)) > > Started working on the pre-reqs and got to libgcrypt-1.5.3 configured as follows: > > Libgcrypt v1.5.3 has been configured as follows: > > Revision: a3eabcb (41962) > Platform: Darwin (x86_64-apple-darwin13.0.0) > Enabled cipher algorithms: arcfour blowfish cast5 des aes twofish serpent rfc2268 seed camellia idea > Enabled digest algorithms: crc md4 md5 rmd160 sha1 sha256 sha512 tiger whirlpool > Enabled pubkey algorithms: dsa elgamal rsa ecc > Random number generator: default > Using linux capabilities: no > Try using Padlock crypto: yes > Try using AES-NI crypto: yes > > A ?make? gets as far as: > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -g -O2 -MT mpih-mul1-asm.lo -MD -MP -MF .deps/mpih-mul1-asm.Tpo -c mpih-mul1-asm.S -fno-common -DPIC -o .libs/mpih-mul1-asm.o > mpih-mul1-asm.S:43:9: error: invalid alignment value > .align 1<<(5) > ^ > make[2]: *** [mpih-mul1-asm.lo] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > Any suggestions? > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan at p2vpro.com Sun Nov 3 18:13:47 2013 From: duncan at p2vpro.com (duncan at p2vpro.com) Date: Sun, 3 Nov 2013 17:13:47 +0000 Subject: Compiling on Maverick In-Reply-To: <53DC1C20-BC16-4FEC-99CA-E1BBD732116F@yahoo.de> References: <53DC1C20-BC16-4FEC-99CA-E1BBD732116F@yahoo.de> Message-ID: <66D1242B-1EE4-4F7B-8B2B-0076E7A7F091@p2vpro.com> Good suggestion, thanks. That?s enabled me to finish libgcrypt. Onwards and upwards to the next pre-req (libassuan). What would the iPad generation make of it all? Duncan P.S. Here are timings from the iMac (2.7Ghz Core i5, 8G, OS X 10.9): PASS: version PASS: t-mpi-bit PASS: prime PASS: register PASS: ac PASS: ac-schemes PASS: ac-data PASS: basic PASS: mpitests PASS: tsexp PASS: keygen PASS: pubkey PASS: hmac PASS: keygrip PASS: fips186-dsa PASS: aeswrap PASS: curves PASS: t-kdf PASS: pkcs1v2 PASS: random MD5 0ms 10ms 20ms 0ms 0ms SHA1 10ms 0ms 20ms 10ms 0ms RIPEMD160 0ms 10ms 20ms 10ms 0ms TIGER192 10ms 0ms 30ms 10ms 0ms SHA256 10ms 10ms 30ms 10ms 0ms SHA384 10ms 10ms 30ms 10ms 0ms SHA512 10ms 10ms 30ms 10ms 0ms SHA224 10ms 10ms 30ms 10ms 0ms MD4 10ms 0ms 20ms 0ms 0ms CRC32 10ms 0ms 10ms 0ms 10ms CRC32RFC1510 0ms 0ms 10ms 10ms 0ms CRC24RFC2440 10ms 10ms 20ms 20ms 10ms WHIRLPOOL 10ms 20ms 30ms 10ms 20ms TIGER 0ms 10ms 30ms 0ms 10ms TIGER2 0ms 10ms 30ms 0ms 10ms ECB/Stream CBC CFB OFB CTR --------------- --------------- --------------- --------------- --------------- IDEA 10ms 20ms 20ms 30ms 20ms 20ms 20ms 20ms 20ms 20ms 3DES 50ms 40ms 50ms 40ms 50ms 40ms 50ms 40ms 50ms 50ms CAST5 20ms 10ms 20ms 10ms 20ms 10ms 20ms 10ms 20ms 20ms BLOWFISH 20ms 10ms 20ms 10ms 20ms 10ms 20ms 10ms 20ms 20ms AES 10ms 0ms 10ms 10ms 0ms 10ms 10ms 10ms 0ms 10ms AES192 10ms 10ms 10ms 0ms 10ms 10ms 10ms 10ms 10ms 10ms AES256 0ms 10ms 10ms 10ms 10ms 10ms 10ms 10ms 10ms 10ms TWOFISH 10ms 10ms 10ms 10ms 10ms 10ms 10ms 10ms 10ms 10ms ARCFOUR 0ms 10ms DES 20ms 10ms 30ms 20ms 20ms 20ms 20ms 20ms 20ms 30ms TWOFISH128 0ms 10ms 10ms 20ms 10ms 10ms 10ms 10ms 10ms 10ms SERPENT128 20ms 10ms 20ms 20ms 20ms 10ms 20ms 20ms 20ms 20ms SERPENT192 20ms 10ms 20ms 20ms 10ms 20ms 20ms 20ms 20ms 20ms SERPENT256 20ms 10ms 20ms 20ms 10ms 20ms 20ms 20ms 20ms 20ms RFC2268_40 20ms 10ms 20ms 10ms 20ms 20ms 20ms 20ms 20ms 20ms SEED 10ms 20ms 20ms 20ms 10ms 20ms 20ms 20ms 20ms 20ms CAMELLIA128 20ms 30ms 20ms 30ms 20ms 30ms 20ms 30ms 30ms 30ms CAMELLIA192 20ms 30ms 30ms 30ms 20ms 30ms 30ms 30ms 30ms 30ms CAMELLIA256 30ms 20ms 30ms 30ms 30ms 20ms 30ms 30ms 30ms 30ms Algorithm generate 100*sign 100*verify ------------------------------------------------ RSA 1024 bit 40ms 170ms 10ms RSA 2048 bit 280ms 1030ms 20ms RSA 3072 bit 840ms 3000ms 30ms RSA 4096 bit 3590ms 6690ms 50ms DSA 1024/160 - 90ms 90ms DSA 2048/224 - 380ms 350ms DSA 3072/256 - 870ms 770ms ECDSA 192 bit 10ms 210ms 350ms ECDSA 224 bit 20ms 320ms 610ms ECDSA 256 bit 10ms 280ms 520ms ECDSA 384 bit 30ms 600ms 1130ms ECDSA 521 bit 50ms 1360ms 2580ms powm 0ms 20ms 60ms random 0ms 10ms PASS: benchmark =================== All 21 tests passed =================== make[1]: Nothing to be done for `check-am'. On 2 Nov 2013, at 20:56, Christoph Roland Murauer wrote: > Hy ! > > Depends on the rest of your build system like CFLAGS and so on. Run make clean and add --disable-asm to ./configure. Apple has changed many things in Xcode 5 (gcc / llvm). As inspiration you could look at https://github.com/mxcl/homebrew/blob/master/Library/Formula/libgcrypt.rb. > > C. M. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph_murauer at yahoo.de Sun Nov 3 20:31:44 2013 From: christoph_murauer at yahoo.de (Christoph Roland Murauer) Date: Sun, 3 Nov 2013 20:31:44 +0100 Subject: Compiling on Maverick In-Reply-To: <66D1242B-1EE4-4F7B-8B2B-0076E7A7F091@p2vpro.com> References: <53DC1C20-BC16-4FEC-99CA-E1BBD732116F@yahoo.de> <66D1242B-1EE4-4F7B-8B2B-0076E7A7F091@p2vpro.com> Message-ID: Hy ! Good to hear that the build of libgcrypt worked. Any problems with libassuan ? Do I need to understand the question about the iPad generation ? C. M. P.S. Mavericks is very slow in some things (i7 quad core 2,7 GHz and HT). Am 03.11.2013 um 18:13 schrieb "duncan at p2vpro.com" : > Good suggestion, thanks. That?s enabled me to finish libgcrypt. Onwards and upwards to the next pre-req (libassuan). > > What would the iPad generation make of it all? > > Duncan > > P.S. Here are timings from the iMac (2.7Ghz Core i5, 8G, OS X 10.9): > > PASS: version > PASS: t-mpi-bit > PASS: prime > PASS: register > PASS: ac > PASS: ac-schemes > PASS: ac-data > PASS: basic > PASS: mpitests > PASS: tsexp > PASS: keygen > PASS: pubkey > PASS: hmac > PASS: keygrip > PASS: fips186-dsa > PASS: aeswrap > PASS: curves > PASS: t-kdf > PASS: pkcs1v2 > PASS: random > MD5 0ms 10ms 20ms 0ms 0ms > SHA1 10ms 0ms 20ms 10ms 0ms > RIPEMD160 0ms 10ms 20ms 10ms 0ms > TIGER192 10ms 0ms 30ms 10ms 0ms > SHA256 10ms 10ms 30ms 10ms 0ms > SHA384 10ms 10ms 30ms 10ms 0ms > SHA512 10ms 10ms 30ms 10ms 0ms > SHA224 10ms 10ms 30ms 10ms 0ms > MD4 10ms 0ms 20ms 0ms 0ms > CRC32 10ms 0ms 10ms 0ms 10ms > CRC32RFC1510 0ms 0ms 10ms 10ms 0ms > CRC24RFC2440 10ms 10ms 20ms 20ms 10ms > WHIRLPOOL 10ms 20ms 30ms 10ms 20ms > TIGER 0ms 10ms 30ms 0ms 10ms > TIGER2 0ms 10ms 30ms 0ms 10ms > > ECB/Stream CBC CFB OFB CTR > --------------- --------------- --------------- --------------- --------------- > IDEA 10ms 20ms 20ms 30ms 20ms 20ms 20ms 20ms 20ms 20ms > 3DES 50ms 40ms 50ms 40ms 50ms 40ms 50ms 40ms 50ms 50ms > CAST5 20ms 10ms 20ms 10ms 20ms 10ms 20ms 10ms 20ms 20ms > BLOWFISH 20ms 10ms 20ms 10ms 20ms 10ms 20ms 10ms 20ms 20ms > AES 10ms 0ms 10ms 10ms 0ms 10ms 10ms 10ms 0ms 10ms > AES192 10ms 10ms 10ms 0ms 10ms 10ms 10ms 10ms 10ms 10ms > AES256 0ms 10ms 10ms 10ms 10ms 10ms 10ms 10ms 10ms 10ms > TWOFISH 10ms 10ms 10ms 10ms 10ms 10ms 10ms 10ms 10ms 10ms > ARCFOUR 0ms 10ms > DES 20ms 10ms 30ms 20ms 20ms 20ms 20ms 20ms 20ms 30ms > TWOFISH128 0ms 10ms 10ms 20ms 10ms 10ms 10ms 10ms 10ms 10ms > SERPENT128 20ms 10ms 20ms 20ms 20ms 10ms 20ms 20ms 20ms 20ms > SERPENT192 20ms 10ms 20ms 20ms 10ms 20ms 20ms 20ms 20ms 20ms > SERPENT256 20ms 10ms 20ms 20ms 10ms 20ms 20ms 20ms 20ms 20ms > RFC2268_40 20ms 10ms 20ms 10ms 20ms 20ms 20ms 20ms 20ms 20ms > SEED 10ms 20ms 20ms 20ms 10ms 20ms 20ms 20ms 20ms 20ms > CAMELLIA128 20ms 30ms 20ms 30ms 20ms 30ms 20ms 30ms 30ms 30ms > CAMELLIA192 20ms 30ms 30ms 30ms 20ms 30ms 30ms 30ms 30ms 30ms > CAMELLIA256 30ms 20ms 30ms 30ms 30ms 20ms 30ms 30ms 30ms 30ms > > Algorithm generate 100*sign 100*verify > ------------------------------------------------ > RSA 1024 bit 40ms 170ms 10ms > RSA 2048 bit 280ms 1030ms 20ms > RSA 3072 bit 840ms 3000ms 30ms > RSA 4096 bit 3590ms 6690ms 50ms > DSA 1024/160 - 90ms 90ms > DSA 2048/224 - 380ms 350ms > DSA 3072/256 - 870ms 770ms > ECDSA 192 bit 10ms 210ms 350ms > ECDSA 224 bit 20ms 320ms 610ms > ECDSA 256 bit 10ms 280ms 520ms > ECDSA 384 bit 30ms 600ms 1130ms > ECDSA 521 bit 50ms 1360ms 2580ms > > powm 0ms 20ms 60ms > > random 0ms 10ms > PASS: benchmark > =================== > All 21 tests passed > =================== > make[1]: Nothing to be done for `check-am'. > > On 2 Nov 2013, at 20:56, Christoph Roland Murauer wrote: > >> Hy ! >> >> Depends on the rest of your build system like CFLAGS and so on. Run make clean and add --disable-asm to ./configure. Apple has changed many things in Xcode 5 (gcc / llvm). As inspiration you could look at https://github.com/mxcl/homebrew/blob/master/Library/Formula/libgcrypt.rb. >> >> C. M. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Nov 4 09:22:49 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Nov 2013 09:22:49 +0100 Subject: [Announce] Details on the GnuPG 1.4.15 and 2.0.22 release In-Reply-To: <877gds3xkv.fsf@vigenere.g10code.de> (Werner Koch's message of "Sat, 05 Oct 2013 10:56:32 +0200") References: <877gds3xkv.fsf@vigenere.g10code.de> Message-ID: <87fvrck23q.fsf@vigenere.g10code.de> Hi! Taylor asked me to forward this background info: On Sat, 5 Oct 2013 10:56, wk at gnupg.org said: > not yet been seen in the wild. Details of the attack will eventually > be published by its inventor. The zlib compression language that OpenPGP uses is powerful enough to express an OpenPGP compression quine -- that is, an OpenPGP compressed data packet that decompresses to itself -- causing infinite nesting of OpenPGP packets. Source code to generate such a quine is at . When fed the quine, older versions of GnuPG would blow the stack and crash. GnuPG 1.4.15 and GnuPG 2.0.22 avoid this by setting a small constant bound on the depth of packet nesting. (This is similar to Tavis Ormandy's IPcomp compression quine, reported in CVE-2011-1547, which I didn't know about at the time I made the OpenPGP compression quine. Both of us had read Russ Cox's article on zlib compression quines: .) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From duncan at p2vpro.com Mon Nov 4 21:23:11 2013 From: duncan at p2vpro.com (duncan at p2vpro.com) Date: Mon, 4 Nov 2013 20:23:11 +0000 Subject: Compiling on Maverick In-Reply-To: References: <53DC1C20-BC16-4FEC-99CA-E1BBD732116F@yahoo.de> <66D1242B-1EE4-4F7B-8B2B-0076E7A7F091@p2vpro.com> Message-ID: <193DD671-2C79-4E8D-8ED2-10D87062277F@p2vpro.com> C.M. - no problems with the other dependencies but a configure and make of the main target gnupg-2.0.22 failed with the output below. However, I can see there is a workaround for most of these errors here http://lists.gnupg.org/pipermail/gnupg-users/2013-October/047795.html The "iPad generation" was a rhetorical question :-) Duncan In file included from ./stdint.h:66: /usr/include/inttypes.h:238:10: error: unknown type name 'intmax_t' extern intmax_t imaxabs(intmax_t j); ^ /usr/include/inttypes.h:238:27: error: unknown type name 'intmax_t' extern intmax_t imaxabs(intmax_t j); ^ /usr/include/inttypes.h:242:9: error: unknown type name 'intmax_t' intmax_t quot; ^ /usr/include/inttypes.h:243:9: error: unknown type name 'intmax_t' intmax_t rem; ^ /usr/include/inttypes.h:246:28: error: unknown type name 'intmax_t' extern imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom); ^ /usr/include/inttypes.h:246:44: error: unknown type name 'intmax_t' extern imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom); ^ /usr/include/inttypes.h:249:10: error: unknown type name 'intmax_t' extern intmax_t strtoimax(const char * restrict nptr, char ** restrict endptr, int base); ^ /usr/include/inttypes.h:250:10: error: unknown type name 'uintmax_t'; did you mean 'uintptr_t'? extern uintmax_t strtoumax(const char * restrict nptr, char ** restrict endptr, int base); ^ /usr/include/sys/_types/_uintptr_t.h:30:24: note: 'uintptr_t' declared here typedef unsigned long uintptr_t; ^ In file included from allocsa.c:21: In file included from ./allocsa.h:23: In file included from /usr/include/stdlib.h:65: In file included from /usr/include/sys/wait.h:110: In file included from /usr/include/sys/resource.h:72: In file included from ./stdint.h:66: /usr/include/inttypes.h:255:10: error: unknown type name 'intmax_t' extern intmax_t wcstoimax(const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base); ^ /usr/include/inttypes.h:256:10: error: unknown type name 'uintmax_t'; did you mean 'uintptr_t'? extern uintmax_t wcstoumax(const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base); ^ /usr/include/sys/_types/_uintptr_t.h:30:24: note: 'uintptr_t' declared here typedef unsigned long uintptr_t; On 3 Nov 2013, at 19:31, Christoph Roland Murauer wrote: > Hy ! > > Good to hear that the build of libgcrypt worked. Any problems with libassuan ? > > Do I need to understand the question about the iPad generation ? > > C. M. > > P.S. Mavericks is very slow in some things (i7 quad core 2,7 GHz and HT). > > Am 03.11.2013 um 18:13 schrieb "duncan at p2vpro.com" : > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.schwier.ml at cardcontact.de Wed Nov 6 14:02:29 2013 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Wed, 06 Nov 2013 14:02:29 +0100 Subject: Support for SmartCard-HSM Message-ID: <527A3DE5.8050702@cardcontact.de> Dear GnuPG developers, we're currently evaluating the feasibility to add support for the SmartCard-HSM [1] to GnuPG/scdaemon. So far we've been able to set up the development environment and start to work on the scdaemon driver for the card. Apparently scdaemon has support for the OpenPGP card and some other card types. However gpg with --card-status and --card-edit seems to only support the OpenPGP card. Is it true, that other card types can only be used for gpgsm ? Kind regards, Andreas Schwier [1] http://www.cardcontact.de/products/sc-hsm.html From wk at gnupg.org Thu Nov 7 15:28:55 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Nov 2013 15:28:55 +0100 Subject: Support for SmartCard-HSM In-Reply-To: <527A3DE5.8050702@cardcontact.de> (Andreas Schwier's message of "Wed, 06 Nov 2013 14:02:29 +0100") References: <527A3DE5.8050702@cardcontact.de> Message-ID: <87txfo5lqw.fsf@vigenere.g10code.de> On Wed, 6 Nov 2013 14:02, andreas.schwier.ml at cardcontact.de said: > types. However gpg with --card-status and --card-edit seems to only > support the OpenPGP card. Right. If you want to use a smartcard with GnuPG the card needs to be compliant to the OpenPGP card spec. We don't want to support a bunch of incompatible cards in gpg. However, with 2.1 you should be able to convince gpg to work with arbitrary cards as long as they are supported by scdaemon. However, "gpg --card-status" et al won't work which such cards. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From andreas.schwier.ml at cardcontact.de Thu Nov 7 15:50:24 2013 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Thu, 07 Nov 2013 15:50:24 +0100 Subject: Support for SmartCard-HSM In-Reply-To: <87txfo5lqw.fsf@vigenere.g10code.de> References: <527A3DE5.8050702@cardcontact.de> <87txfo5lqw.fsf@vigenere.g10code.de> Message-ID: <527BA8B0.3010800@cardcontact.de> O.K. then it's probably easier to allow our customers to load one of the available OpenPGP JavaCard applets onto their device. So far I've found three different implementations [1] http://sourceforge.net/projects/javacardopenpgp/ [2] https://github.com/FluffyKaon/OpenPGP-Card [3] http://sourceforge.net/projects/jopenpgpcard/ Do you happen to know which one works best with GnuPG ? Andreas On 11/07/2013 03:28 PM, Werner Koch wrote: > On Wed, 6 Nov 2013 14:02, andreas.schwier.ml at cardcontact.de said: > >> types. However gpg with --card-status and --card-edit seems to only >> support the OpenPGP card. > > Right. If you want to use a smartcard with GnuPG the card needs to be > compliant to the OpenPGP card spec. We don't want to support a bunch of > incompatible cards in gpg. However, with 2.1 you should be able to > convince gpg to work with arbitrary cards as long as they are supported > by scdaemon. However, "gpg --card-status" et al won't work which such > cards. > > > Shalom-Salam, > > Werner > From dominik at heidler.eu Sat Nov 9 22:32:40 2013 From: dominik at heidler.eu (Dominik Heidler) Date: Sat, 9 Nov 2013 22:32:40 +0100 Subject: [PATCH] gpg: enable key-to-card upload for cert-only keys Message-ID: <1384032760-7126-1-git-send-email-dominik@heidler.eu> From: Dominik Heidler * g10/card-util.c (card_store_subkey): allow PUBKEY_USAGE_CERT -- GnuPG-bug-id: 1548 Signed-off-by: Dominik Heidler --- g10/card-util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/g10/card-util.c b/g10/card-util.c index add8eed..642843d 100644 --- a/g10/card-util.c +++ b/g10/card-util.c @@ -1569,7 +1569,7 @@ card_store_subkey (KBNODE node, int use) goto leave; } - allow_keyno[0] = (!use || (use & (PUBKEY_USAGE_SIG))); + allow_keyno[0] = (!use || (use & (PUBKEY_USAGE_SIG|PUBKEY_USAGE_CERT))); allow_keyno[1] = (!use || (use & (PUBKEY_USAGE_ENC))); allow_keyno[2] = (!use || (use & (PUBKEY_USAGE_SIG|PUBKEY_USAGE_AUTH))); -- 1.8.4.2 From cryptostick at privacyfoundation.de Sun Nov 10 12:11:32 2013 From: cryptostick at privacyfoundation.de (Crypto Stick) Date: Sun, 10 Nov 2013 12:11:32 +0100 Subject: Support for SmartCard-HSM In-Reply-To: <527BA8B0.3010800@cardcontact.de> References: <527A3DE5.8050702@cardcontact.de> <87txfo5lqw.fsf@vigenere.g10code.de> <527BA8B0.3010800@cardcontact.de> Message-ID: <527F69E4.3030404@privacyfoundation.de> Implementations [1] and [3] aren't ready for prime time. Instead you may want to focus on [2]. Regards, Jan Am 07.11.2013 15:50, schrieb Andreas Schwier: > O.K. then it's probably easier to allow our customers to load one of the > available OpenPGP JavaCard applets onto their device. > > So far I've found three different implementations > > [1] http://sourceforge.net/projects/javacardopenpgp/ > [2] https://github.com/FluffyKaon/OpenPGP-Card > [3] http://sourceforge.net/projects/jopenpgpcard/ > > Do you happen to know which one works best with GnuPG ? > > Andreas > > > On 11/07/2013 03:28 PM, Werner Koch wrote: >> On Wed, 6 Nov 2013 14:02, andreas.schwier.ml at cardcontact.de said: >> >>> types. However gpg with --card-status and --card-edit seems to only >>> support the OpenPGP card. >> >> Right. If you want to use a smartcard with GnuPG the card needs to be >> compliant to the OpenPGP card spec. We don't want to support a bunch of >> incompatible cards in gpg. However, with 2.1 you should be able to >> convince gpg to work with arbitrary cards as long as they are supported >> by scdaemon. However, "gpg --card-status" et al won't work which such >> cards. >> >> >> Shalom-Salam, >> >> Werner >> > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From martin at martinpaljak.net Sun Nov 10 13:45:04 2013 From: martin at martinpaljak.net (Martin Paljak) Date: Sun, 10 Nov 2013 14:45:04 +0200 Subject: Support for SmartCard-HSM In-Reply-To: <527F69E4.3030404@privacyfoundation.de> References: <527A3DE5.8050702@cardcontact.de> <87txfo5lqw.fsf@vigenere.g10code.de> <527BA8B0.3010800@cardcontact.de> <527F69E4.3030404@privacyfoundation.de> Message-ID: Hello, Care to elaborate why? -- Martin +372 515 6495 On Sun, Nov 10, 2013 at 1:11 PM, Crypto Stick wrote: > Implementations [1] and [3] aren't ready for prime time. Instead you may > want to focus on [2]. > > Regards, > Jan > > Am 07.11.2013 15:50, schrieb Andreas Schwier: >> O.K. then it's probably easier to allow our customers to load one of the >> available OpenPGP JavaCard applets onto their device. >> >> So far I've found three different implementations >> >> [1] http://sourceforge.net/projects/javacardopenpgp/ >> [2] https://github.com/FluffyKaon/OpenPGP-Card >> [3] http://sourceforge.net/projects/jopenpgpcard/ >> >> Do you happen to know which one works best with GnuPG ? >> >> Andreas >> >> >> On 11/07/2013 03:28 PM, Werner Koch wrote: >>> On Wed, 6 Nov 2013 14:02, andreas.schwier.ml at cardcontact.de said: >>> >>>> types. However gpg with --card-status and --card-edit seems to only >>>> support the OpenPGP card. >>> >>> Right. If you want to use a smartcard with GnuPG the card needs to be >>> compliant to the OpenPGP card spec. We don't want to support a bunch of >>> incompatible cards in gpg. However, with 2.1 you should be able to >>> convince gpg to work with arbitrary cards as long as they are supported >>> by scdaemon. However, "gpg --card-status" et al won't work which such >>> cards. >>> >>> >>> Shalom-Salam, >>> >>> Werner >>> >> >> >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel >> > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From gniibe at fsij.org Mon Nov 11 08:53:38 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 11 Nov 2013 16:53:38 +0900 Subject: scd: pinpad input improvements In-Reply-To: <1381885514.3175.4.camel@cfw2.gniibe.org> References: <1381885514.3175.4.camel@cfw2.gniibe.org> Message-ID: <1384156418.5473.2.camel@cfw2.gniibe.org> On 2013-10-16 at 10:05 +0900, NIIBE Yutaka wrote: > 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 I pushed another fix today. It was applied both to stable and master. -- From gniibe at fsij.org Mon Nov 11 09:06:49 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 11 Nov 2013 17:06:49 +0900 Subject: NeuG 1.0 and its standalone device Message-ID: <1384157209.5473.4.camel@cfw2.gniibe.org> Today is 11-11 (or still 11-10 for different time zones), and we celebrate zero and one. NeuG 1.0 was released. NeuG is an implementation of True Random Number Generator based on quantization error of ADC of STM32F103. Original intention of NeuG development was using it as a part of Gnuk, but we also have standalone USB CDC-ACM version now. You can get random stream from /dev/ttyACM0. Standalone version is useful to feed entropy to /dev/random on GNU/Linux. Its generation speed is around 70KB/sec. The output has been tested NIST STS 2.1.1, Dieharder 3.31.1, TestU01 1.2.3 and PractRand 0.90. Highlights are: * Upgrade of Chopstx (the thread library) Now, we use Chopstx 0.03. * Stabilize the upgrade process For firmware upgrade, it has been unstable somehow and it has been recommended not to access its stream (/dev/ttyACM0) before running neug_upgrade.py. This bug was fixed in 1.0, and it's more stable. * Add support of Fraucheky Fraucheky is a GPL container which makes sure to deliver GPL to users. It is only for Japan domestic, but I started to sell NeuG standalone device as a kind of outreach program for spreading idea of cryptography and concept of a product which respects users' computing freedom. http://www.gniibe.org/shop/buy-neug-on-fst-01 (in Japanese) Here are some links for NeuG, Gnuk and FST-01 (the hardware). NeuG (under Gnuk Repository): http://gitorious.org/gnuk/neug Gnuk News: http://www.fsij.org/gnuk/ FST-01 introduction: http://www.seeedstudio.com/wiki/index.php?title=FST-01 FST-01 Q&A site: http://no-passwd.net/askbot/questions/ Japanese Documentation for FST-01 and Gnuk Token: http://no-passwd.net/fst-01-gnuk-handbook/index.html Enjoy, -- From libgcrypt at edrusb.is-a-geek.org Mon Nov 11 18:52:57 2013 From: libgcrypt at edrusb.is-a-geek.org (Denis Corbin) Date: Mon, 11 Nov 2013 18:52:57 +0100 Subject: sha1 hash using libgcrypt different from what returns sha1sum Message-ID: <20131111175258.B2868140A04@edrusb.is-a-geek.org> Hi, first, I hope that I do not sent my questions to the wrong mailing-list. I maintain the dar (aka Disk ARchive) backup software that generates sha1 or md5 sums of files it generates using libgcrypt. Recently a user reported a hash failure on a large file when using sha1sum against the hash generated by dar, while at the same time the generated archive was not corrupted. I could reproduce this problem but only using large files (larger than 200 GB and could not clearly find a threshold below which the problem never exists and above which it always occurs). dar is a somehow large C++ program thus I've extracted the pertinent code into a more simple C program for easier review and criticism about the way dar calls libgcrypt. This C code (hashsum.c [1]) also reproduces the problem. I have re-read the libgcrypt documentation and could not find anything wrong... but it's still possible I've missed something... To avoid generating large testing files and to reduce execution time of the tests the make_sparse_file.c program ([1]) let generate a so called sparse file (if the underlying filesystem supports it). Note that using dd to create a real plain equivalent file leads to the same difference of hash for large files. Note also that if the generated file for testing contains a long series of byte set to zero, the problem also occurs for more random data pattern (like slice generated by dar). The system used is Debian wheezy, on 64 bits AMD host: libgcrypt version based on 1.5.0 (with probable Debian patches) sha1sum (GNU coreutils) 8.13 md5sum (GNU coreutils) 8.13 Using libgcrypt 1.5.3 gives the same result. Well I wonder whether this is due to wrong usage of libgcrypt in dar or here hashsum.c? Or is it a bug in libgcrypt or in sha1sum and md5sum? Thanks for any help, Regards, Denis Corbin. [1] source code and test results are available for download at: http://dar.linux.free.fr/libgcrypt-tests.tar.gz (~ 3 KB) From yumkam at gmail.com Tue Nov 12 00:44:49 2013 From: yumkam at gmail.com (Yuriy Kaminskiy) Date: Tue, 12 Nov 2013 03:44:49 +0400 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: <20131111175258.B2868140A04@edrusb.is-a-geek.org> References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> Message-ID: Denis Corbin wrote: > first, I hope that I do not sent my questions to the wrong mailing-list. > > I maintain the dar (aka Disk ARchive) backup software that generates > sha1 or md5 sums of files it generates using libgcrypt. Recently a user > reported a hash failure on a large file when using sha1sum against the > hash generated by dar, while at the same time the generated archive was > not corrupted. > > I could reproduce this problem but only using large files (larger than > 200 GB and could not clearly find a threshold below which the problem > never exists and above which it always occurs). > > dar is a somehow large C++ program thus I've extracted the pertinent > code into a more simple C program for easier review and criticism about > the way dar calls libgcrypt. This C code (hashsum.c [1]) also reproduces > the problem. I have re-read the libgcrypt documentation and could not > find anything wrong... but it's still possible I've missed something... > > To avoid generating large testing files and to reduce execution time of > the tests the make_sparse_file.c program ([1]) let generate a so called > sparse file (if the underlying filesystem supports it). Note that using > dd to create a real plain equivalent file leads to the same difference > of hash for large files. Note also that if the generated file for > testing contains a long series of byte set to zero, the problem also > occurs for more random data pattern (like slice generated by dar). > > The system used is Debian wheezy, on 64 bits AMD host: > libgcrypt version based on 1.5.0 (with probable Debian patches) > sha1sum (GNU coreutils) 8.13 > md5sum (GNU coreutils) 8.13 > > Using libgcrypt 1.5.3 gives the same result. > > Well I wonder whether this is due to wrong usage of libgcrypt in dar or > here hashsum.c? Or is it a bug in libgcrypt or in sha1sum and md5sum? It looks like gcrypt uses 'u32 nblocks' intermediately to count 64-byte blocks, and then convert it to number of bits appended to last block in sha1_final function. This u32 counter overflows after processing (2**32)*64 bytes (== 2**38 B == 256 GiB). Actually, as number of bytes in final blocks will be added to [effectively] 64-bit variable, those "nblocks wraparound effects" will be visible only with files over (2**38)+63 bytes, very peculiar limit. I strongly believe this is a bug, I have not found any such behavior in standard - only limitation for SHA-1 is 2**64 bits (2**61 bytes). There are exactly same bug with sha256 and md5 implementations (but, curiously, there are *no* similar problem in sha512). I checked git master, it should have same problem. > [1] source code and test results are available for download at: > http://dar.linux.free.fr/libgcrypt-tests.tar.gz (~ 3 KB) From wk at gnupg.org Tue Nov 12 18:34:24 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Nov 2013 18:34:24 +0100 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: (Yuriy Kaminskiy's message of "Tue, 12 Nov 2013 03:44:49 +0400") References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> Message-ID: <87iovx1q3j.fsf@vigenere.g10code.de> On Tue, 12 Nov 2013 00:44, yumkam at gmail.com said: > I strongly believe this is a bug, I have not found any such behavior in standard You are right. This is a limitation of the code which was never hit in practice until now - at least I hope so. The more disturbing fact is that this also affects GPG encrypted files: SHA-1 is used for an MDC to protect the encrtpted messages. If both parties use GPG, this won't be a problem but it is not standard compliant. Now, what shall we do with GPG? - Fix the code and hope that no encrypted files larger than 256GB need decryption? - Fix and print a warning for an MDC mismatch in case the file is too long. - Fix and add an option to use the unfixed SHA-1 code? Takes a lot of time for processing. Anyone tested this with PGP? > There are exactly same bug with sha256 and md5 implementations (but, curiously, > there are *no* similar problem in sha512). SHA-512 uses a 64 bit type for the counter because its implementation requires a 64 bit type anyway. Salam-Shalom, Werner p.s. Funny that Libgcrypt passes the FIPS validation. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Tue Nov 12 20:06:09 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 12 Nov 2013 14:06:09 -0500 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> Message-ID: <165C4CE3-FD2D-44CF-8B47-4B14A2842CBB@jabberwocky.com> On Nov 11, 2013, at 6:44 PM, Yuriy Kaminskiy wrote: > This u32 counter overflows after processing (2**32)*64 bytes (== 2**38 B == 256 > GiB). > Actually, as number of bytes in final blocks will be added to [effectively] > 64-bit variable, those "nblocks wraparound effects" will be visible only with > files over (2**38)+63 bytes, very peculiar limit. > > I strongly believe this is a bug, I have not found any such behavior in standard > - only limitation for SHA-1 is 2**64 bits (2**61 bytes). Nice find! This is a problem. > There are exactly same bug with sha256 and md5 implementations (but, curiously, > there are *no* similar problem in sha512). Yes. SHA-512 (and thus SHA-384) are inherently 64-bit. They don't even build unless the compiler supports 64-bit types. David From dshaw at jabberwocky.com Tue Nov 12 21:46:47 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 12 Nov 2013 15:46:47 -0500 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: <87iovx1q3j.fsf@vigenere.g10code.de> References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> <87iovx1q3j.fsf@vigenere.g10code.de> Message-ID: On Nov 12, 2013, at 12:34 PM, Werner Koch wrote: > On Tue, 12 Nov 2013 00:44, yumkam at gmail.com said: > >> I strongly believe this is a bug, I have not found any such behavior in standard > > You are right. This is a limitation of the code which was never hit in > practice until now - at least I hope so. The more disturbing fact is > that this also affects GPG encrypted files: SHA-1 is used for an MDC to > protect the encrtpted messages. If both parties use GPG, this won't be > a problem but it is not standard compliant. > > Now, what shall we do with GPG? > > - Fix the code and hope that no encrypted files larger than 256GB need > decryption? > > - Fix and print a warning for an MDC mismatch in case the file is too > long. > > - Fix and add an option to use the unfixed SHA-1 code? Takes a lot of > time for processing. I suppose it would be nice to have an option to use the unfixed SHA-1 code to be bug-compatible with earlier versions, but how common is this problem? I'm somewhat surprised that this hasn't come up long before, or possibly it has and people just accepted (or bypassed) the MDC mismatch? Bug compatible is nice, but it's also really nice to not to have to maintain a second known-incorrect version of the algorithms internally. David From yumkam at gmail.com Tue Nov 12 22:17:21 2013 From: yumkam at gmail.com (Yuriy Kaminskiy) Date: Wed, 13 Nov 2013 01:17:21 +0400 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: <87iovx1q3j.fsf@vigenere.g10code.de> References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> <87iovx1q3j.fsf@vigenere.g10code.de> Message-ID: Werner Koch wrote: > On Tue, 12 Nov 2013 00:44, yumkam at gmail.com said: > >> I strongly believe this is a bug, I have not found any such behavior in standard > > You are right. This is a limitation of the code which was never hit in > practice until now - at least I hope so. The more disturbing fact is > that this also affects GPG encrypted files: SHA-1 is used for an MDC to > protect the encrtpted messages. If both parties use GPG, this won't be > a problem but it is not standard compliant. I guess, same apply to signatures? (and it is not only sha1, it's most other hashes [except of sha384 and sha512] too) > Now, what shall we do with GPG? > > - Fix the code and hope that no encrypted files larger than 256GB need > decryption? > > - Fix and print a warning for an MDC mismatch in case the file is too > long. I'd vote for this as quick fix. > - Fix and add an option to use the unfixed SHA-1 code? Takes a lot of > time for processing. Actually, it won't add much time on *processing* - you can produce both versions at nearly same cost as one, only *final method needs to be different to produce both versions (one with counter truncation, one without). (But I guess it will take lot of time on *designing proper API* for such hack; and I'm not sure if it worth it.) (However, while only printing warning feels "acceptable workaround" for MDC, it feels totally wrong for signatures, so I guess in long run, there are no way around it. Fortunately, very few users should be affected.) > Anyone tested this with PGP? > >> There are exactly same bug with sha256 and md5 implementations ... and more: md4, rmd160, tiger. And I'm not sure, but cipher-ccm.c also feels suspicious in this respect (won't it fail after SIZE_T_MAX bytes?). >> (but, curiously, there are *no* similar problem in sha512). > SHA-512 uses a 64 bit type for the counter because its implementation > requires a 64 bit type anyway. Strictly speaking, libgcrypt's sha512 and whirlpool are "broken" too - standard limits message size with 2**128 bits (more for whirlpool), and so libgcrypt sha512 will also fail after about 2**73 + 127 bytes. But I guess, unlike *md*/sha*, it won't become practical problem for some quite time :-). > p.s. > Funny that Libgcrypt passes the FIPS validation. (...And most likely fix will be in the not-yet-validated version faster. "Validation" is nice and good if it is really able to catch all implementation errors (which is, of course, pipedream). If bug was found after validation, re-validation become additional hurdle on the path to employ fix on all affected systems.) From gniibe at fsij.org Wed Nov 13 09:03:41 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 13 Nov 2013 17:03:41 +0900 Subject: scd: pinpad input improvements In-Reply-To: <1384156418.5473.2.camel@cfw2.gniibe.org> References: <1381885514.3175.4.camel@cfw2.gniibe.org> <1384156418.5473.2.camel@cfw2.gniibe.org> Message-ID: <1384329821.3207.13.camel@cfw2.gniibe.org> On 2013-11-11 at 16:53 +0900, NIIBE Yutaka wrote: > On 2013-10-16 at 10:05 +0900, NIIBE Yutaka wrote: > > 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 > > I pushed another fix today. It was applied both to stable and master. ... and more fix. It was applied both to stable and master. -- From wk at gnupg.org Wed Nov 13 09:55:00 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Nov 2013 09:55:00 +0100 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: (Yuriy Kaminskiy's message of "Wed, 13 Nov 2013 01:17:21 +0400") References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> <87iovx1q3j.fsf@vigenere.g10code.de> Message-ID: <87iovwznob.fsf@vigenere.g10code.de> On Tue, 12 Nov 2013 22:17, yumkam at gmail.com said: > I guess, same apply to signatures? (and it is not only sha1, it's most other > hashes [except of sha384 and sha512] too) Yes. > Actually, it won't add much time on *processing* - you can produce both versions > at nearly same cost as one, only *final method needs to be different to produce > both versions (one with counter truncation, one without). > (But I guess it will take lot of time on *designing proper API* for such hack; Right, that is a major problem. For GnuPG-1 this would be easy but GnuPG-2 uses Libgcrypt and adding a bug comatibility interface is not easy. > And I'm not sure, but cipher-ccm.c also feels suspicious in this respect (won't > it fail after SIZE_T_MAX bytes?). We need to look at it. > Strictly speaking, libgcrypt's sha512 and whirlpool are "broken" too - standard > limits message size with 2**128 bits (more for whirlpool), and so libgcrypt > sha512 will also fail after about 2**73 + 127 bytes. But I guess, unlike > *md*/sha*, it won't become practical problem for some quite time :-). I wonder how we could do a regression test or get test vectors in the first place. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Nov 13 09:51:07 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Nov 2013 09:51:07 +0100 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: (David Shaw's message of "Tue, 12 Nov 2013 15:46:47 -0500") References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> <87iovx1q3j.fsf@vigenere.g10code.de> Message-ID: <87mwl8znus.fsf@vigenere.g10code.de> On Tue, 12 Nov 2013 21:46, dshaw at jabberwocky.com said: > Bug compatible is nice, but it's also really nice to not to have to maintain a second known-incorrect version of the algorithms internally. Indeed. We already have too much bug compatibility to old versions. That might still be justified. But for 256GB files it is questionable. If it turns out to be a real problem we could add an option in another version. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Nov 13 15:57:54 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 Nov 2013 09:57:54 -0500 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: <87iovwznob.fsf@vigenere.g10code.de> References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> <87iovx1q3j.fsf@vigenere.g10code.de> <87iovwznob.fsf@vigenere.g10code.de> Message-ID: <52839372.1070703@fifthhorseman.net> On 11/13/2013 03:55 AM, Werner Koch wrote: > I wonder how we could do a regression test or get test vectors in the > first place. If you don't mind burning a lot of CPU, it's pretty easy to generate a test vector from /dev/zero ("pee" is from the moreutils package, but similar results could easily be made from repeated pipelines): 0 dkg at alice:~$ dd if=/dev/zero bs=1G count=257 | \ pee \ "openssl dgst -sha1 | cut -f2 -d' ' | sed s/$/:openssl/" \ "gpg --print-md SHA1 | tr -d ' ' | tr A-F a-f | sed s/$/:gpg/" \ "sha1sum | cut -f1 -d' ' | sed s/$/:binutils/" 257+0 records in 257+0 records out 275951648768 bytes (276 GB) copied, 1866.12 s, 148 MB/s 6938f23e29e7d3dcd100d0ed2df9d6593113718f:openssl 52416101a2ffd51e853aabbfb4e6fc67db066a32:gpg 6938f23e29e7d3dcd100d0ed2df9d6593113718f:binutils 0 dkg at alice:~$ --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 libgcrypt at edrusb.is-a-geek.org Wed Nov 13 16:45:33 2013 From: libgcrypt at edrusb.is-a-geek.org (Denis Corbin) Date: Wed, 13 Nov 2013 16:45:33 +0100 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: <87iovwznob.fsf@vigenere.g10code.de> References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> <87iovx1q3j.fsf@vigenere.g10code.de> <87iovwznob.fsf@vigenere.g10code.de> Message-ID: <20131113154535.5ADB7141339@edrusb.is-a-geek.org> On 13/11/2013 15:57, Daniel Kahn Gillmor wrote: > On 11/13/2013 03:55 AM, Werner Koch wrote: >> I wonder how we could do a regression test or get test vectors in the >> first place. > > If you don't mind burning a lot of CPU, it's pretty easy to generate a > test vector from /dev/zero ("pee" is from the moreutils package, but > similar results could easily be made from repeated pipelines): > > 0 dkg at alice:~$ dd if=/dev/zero bs=1G count=257 | \ > pee \ > "openssl dgst -sha1 | cut -f2 -d' ' | sed s/$/:openssl/" \ > "gpg --print-md SHA1 | tr -d ' ' | tr A-F a-f | sed s/$/:gpg/" \ > "sha1sum | cut -f1 -d' ' | sed s/$/:binutils/" > 257+0 records in > 257+0 records out > 275951648768 bytes (276 GB) copied, 1866.12 s, 148 MB/s > 6938f23e29e7d3dcd100d0ed2df9d6593113718f:openssl > 52416101a2ffd51e853aabbfb4e6fc67db066a32:gpg > 6938f23e29e7d3dcd100d0ed2df9d6593113718f:binutils > 0 dkg at alice:~$ > If you need, you can also use/adapt the test software I've used to reproduce the problem, there is no copyright on it :) Denis Corbin. From wk at gnupg.org Wed Nov 13 20:00:20 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Nov 2013 20:00:20 +0100 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: <52839372.1070703@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 13 Nov 2013 09:57:54 -0500") References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> <87iovx1q3j.fsf@vigenere.g10code.de> <87iovwznob.fsf@vigenere.g10code.de> <52839372.1070703@fifthhorseman.net> Message-ID: <8761rwxh2z.fsf@vigenere.g10code.de> On Wed, 13 Nov 2013 15:57, dkg at fifthhorseman.net said: > If you don't mind burning a lot of CPU, it's pretty easy to generate a > test vector from /dev/zero ("pee" is from the moreutils package, but That is not the problem. The hashing of 256GB takes alone 14 minutes on my box - using the latest optimized code. Nothing you want to do everytime in a regression suite. tools/mk-tdata can easily be changed to emit large non-compressable blocks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Nov 13 22:05:57 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 Nov 2013 16:05:57 -0500 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: <8761rwxh2z.fsf@vigenere.g10code.de> References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> <87iovx1q3j.fsf@vigenere.g10code.de> <87iovwznob.fsf@vigenere.g10code.de> <52839372.1070703@fifthhorseman.net> <8761rwxh2z.fsf@vigenere.g10code.de> Message-ID: <5283E9B5.1020803@fifthhorseman.net> On 11/13/2013 02:00 PM, Werner Koch wrote: > On Wed, 13 Nov 2013 15:57, dkg at fifthhorseman.net said: > >> If you don't mind burning a lot of CPU, it's pretty easy to generate a >> test vector from /dev/zero ("pee" is from the moreutils package, but > > That is not the problem. The hashing of 256GB takes alone 14 minutes on > my box - using the latest optimized code. Nothing you want to do > everytime in a regression suite. yep, agreed, that would be pretty obnoxious for a regression suite. maybe we should consider a separate "extended regression suite" annex for people with CPU to burn? I'm not sure how else to really test this sort of codepath without testing it. Maybe we could save and store intermediate digest state in git and make the test suite load that intermediate state and restart the digest from most-of-the-way-through? that kind of seems like cheating though. > tools/mk-tdata can easily be changed to emit large non-compressable > blocks. hm, I was just offering reasonable and clearly-understood test vectors that are easily available. I'm not sure non-compressability is a characteristic we need care about for a test vectors to avoid a regression into this particular bug. --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 at oneiroi.net Wed Nov 13 22:40:31 2013 From: gnupg at oneiroi.net (Filip M. Nowak) Date: Wed, 13 Nov 2013 22:40:31 +0100 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: <5283E9B5.1020803@fifthhorseman.net> References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> <87iovx1q3j.fsf@vigenere.g10code.de> <87iovwznob.fsf@vigenere.g10code.de> <52839372.1070703@fifthhorseman.net> <8761rwxh2z.fsf@vigenere.g10code.de> <5283E9B5.1020803@fifthhorseman.net> Message-ID: <5283F1CF.4020403@oneiroi.net> Hello, On 13.11.2013 22:05, Daniel Kahn Gillmor wrote: > On 11/13/2013 02:00 PM, Werner Koch wrote: >> On Wed, 13 Nov 2013 15:57, dkg at fifthhorseman.net said: >> >>> If you don't mind burning a lot of CPU, it's pretty easy to generate a >>> test vector from /dev/zero ("pee" is from the moreutils package, but >> >> That is not the problem. The hashing of 256GB takes alone 14 minutes on >> my box - using the latest optimized code. Nothing you want to do >> everytime in a regression suite. > > (...) > > hm, I was just offering reasonable and clearly-understood test vectors > that are easily available. I'm not sure non-compressability is a > characteristic we need care about for a test vectors to avoid a > regression into this particular bug. Apologies for non-technical comment in advance... In case of security-oriented software is quite sane to define software's capability and limitations and back it by tests. Working with bigger volumes of data is real use case and in future will be even more probable. Actually such information could be good add-on to existing FAQ. Cheers, Filip From wk at gnupg.org Thu Nov 14 11:31:52 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Nov 2013 11:31:52 +0100 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: <5283E9B5.1020803@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 13 Nov 2013 16:05:57 -0500") References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> <87iovx1q3j.fsf@vigenere.g10code.de> <87iovwznob.fsf@vigenere.g10code.de> <52839372.1070703@fifthhorseman.net> <8761rwxh2z.fsf@vigenere.g10code.de> <5283E9B5.1020803@fifthhorseman.net> Message-ID: <87ppq3uvdz.fsf@vigenere.g10code.de> On Wed, 13 Nov 2013 22:05, dkg at fifthhorseman.net said: > On 11/13/2013 02:00 PM, Werner Koch wrote: >> On Wed, 13 Nov 2013 15:57, dkg at fifthhorseman.net said: > yep, agreed, that would be pretty obnoxious for a regression suite. > maybe we should consider a separate "extended regression suite" annex > for people with CPU to burn? I'm not sure how else to really test this > sort of codepath without testing it. Could be done with a configure option. Actually we already have such an option for the PKITS tests. > Maybe we could save and store intermediate digest state in git and make > the test suite load that intermediate state and restart the digest from > most-of-the-way-through? that kind of seems like cheating though. Right, that is not a real test. In particular because there is no API for intermediate values. > hm, I was just offering reasonable and clearly-understood test vectors > that are easily available. I'm not sure non-compressability is a > characteristic we need care about for a test vectors to avoid a Weel, we could also use -z 0 to disable compression. Given that it is an algorithm error, we may not need to test the entire gpg output but just the plain hashing (ie. --print-md). Meanwhile I started with a tests program for Libgcrypt and now I only need to wait for test vectors. I am currently using the program below to generate data and run sha1sum on it: ./genhashdata --gigs 256 --bytes -64 | sha1sum ./genhashdata --gigs 256 --bytes -1 | sha1sum ./genhashdata --gigs 256 --bytes 0 | sha1sum ./genhashdata --gigs 256 --bytes 1 | sha1sum Libgcrypt's new hash test program outputs 4 values by taking copies of the hash context and thus not requiring 4 indivudal runs. Example: $ ./hashtest --gigs 1 --verbose sha1 hashtest: 1 GiB hashed hashtest: 1 GiB -64 SHA1 dd636d1d217b368e9cdf02f001580aa7e1e69324 hashtest: 1 GiB -1 SHA1 108e2e62b787deb94d64a7e4c4ec32f6ecb8f876 hashtest: 1 GiB +0 SHA1 ecebf8a78d57368378471ce3d7046702ed865e92 hashtest: 1 GiB +1 SHA1 48544b31ab4b4963f219a8c821081176ba7d1269 Should be done for all algorithms, though. I guess some help running shaXXXX will be needed. Salam-Shalom, Werner /* genhashdata.c - Create data for hash tests * Copyright (C) 2013 g10 Code GmbH * * This file is part of Libgcrypt. * * Libgcrypt is free software; you can redistribute it and/or modify * it under the terms of the GNU Lesser General Public License as * published by the Free Software Foundation; either version 2.1 of * the License, or (at your option) any later version. * * Libgcrypt is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this program; if not, see . */ #include #include #include #include #include #define PGM "genhashdata" static void die (const char *format, ...) { va_list arg_ptr ; fflush (stdout); fprintf (stderr, "%s: ", PGM); va_start (arg_ptr, format ) ; vfprintf (stderr, format, arg_ptr ); va_end(arg_ptr); if (*format && format[strlen(format)-1] != '\n') putc ('\n', stderr); exit (1); } int main (int argc, char **argv) { int last_argc = -1; int gigs = 0; int bytes = 0; char pattern[1024]; int i, g; if (argc) { argc--; argv++; } while (argc && last_argc != argc ) { last_argc = argc; if (!strcmp (*argv, "--")) { argc--; argv++; break; } else if (!strcmp (*argv, "--help")) { fputs ("usage: " PGM " [options]\n" "Options:\n" " --gigs N Emit N GiB of test bytes\n" " --bytes DIFF Stop DIFF bytes earlier or later\n", stdout); exit (0); } else if (!strcmp (*argv, "--gigs")) { argc--; argv++; if (argc) { gigs = atoi (*argv); argc--; argv++; } } else if (!strcmp (*argv, "--bytes")) { argc--; argv++; if (argc) { bytes = atoi (*argv); argc--; argv++; } } else if (!strncmp (*argv, "--", 2)) die ("unknown option '%s'", *argv); } if (gigs < 0 || gigs > 1024*1024) die ("value for --gigs must be in the range 0 to %d", 1024*1024); if (bytes < -1024 || bytes > 1024) die ("value for --bytes must be in the range -1024 to 1024"); if (sizeof pattern != 1024) die ("internal error"); if (argc > 1) die ("arguments are not expected"); memset (pattern, 'a', sizeof pattern); for (g=0; g < gigs; g++) { if (g + 1 == gigs && bytes < 0) { for (i = 0; i < 1024*1023; i++) if (fwrite (pattern, sizeof pattern, 1, stdout) != 1) die ("writing to stdout failed: %s", strerror (errno)); for (i = 0; i < 1023; i++) if (fwrite (pattern, sizeof pattern, 1, stdout) != 1) die ("writing to stdout failed: %s", strerror (errno)); if (fwrite (pattern, sizeof pattern + bytes, 1, stdout) != 1) die ("writing to stdout failed: %s", strerror (errno)); } else { for (i = 0; i < 1024*1024; i++) if (fwrite (pattern, sizeof pattern, 1, stdout) != 1) die ("writing to stdout failed: %s", strerror (errno)); } } if (bytes > 0) if (fwrite (pattern, bytes, 1, stdout) != 1) die ("writing to stdout failed: %s", strerror (errno)); if (fflush (stdout)) die ("writing to stdout failed: %s", strerror (errno)); return 0; } -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lion at lion.leolix.org Thu Nov 14 13:03:47 2013 From: lion at lion.leolix.org (Philipp Schafft) Date: Thu, 14 Nov 2013 13:03:47 +0100 Subject: sha1 hash using libgcrypt different from what returns sha1sum In-Reply-To: References: <20131111175258.B2868140A04@edrusb.is-a-geek.org> <87iovx1q3j.fsf@vigenere.g10code.de> Message-ID: <20131114120352.2E19C7A228@priderock.keep-cool.org> On Tue, 2013-11-12 at 15:46 -0500, David Shaw wrote: > On Nov 12, 2013, at 12:34 PM, Werner Koch wrote: > > > On Tue, 12 Nov 2013 00:44, yumkam at gmail.com said: > > > >> I strongly believe this is a bug, I have not found any such > behavior in standard > > > > You are right. This is a limitation of the code which was never hit > in > > practice until now - at least I hope so. The more disturbing fact > is > > that this also affects GPG encrypted files: SHA-1 is used for an MDC > to > > protect the encrtpted messages. If both parties use GPG, this won't > be > > a problem but it is not standard compliant. > > > > [...] > [...] > I'm somewhat surprised that this hasn't come up long before, or > possibly it has and people just accepted (or bypassed) the MDC > mismatch? As of my understanding it doesn't generate any warning just that the hash that is stored is wrong. So maybe it happend very often but nobody noticed because if it happens on both ends the problem will not show up. I think that there are little pople like me and Yuriy Kaminskiy that will have a closer look into the hashing code and do more testing. So it's hard to find such bugs and then people still need to report it. Most users of most projects I have be involved are just too lazy to report problems (but not to lazy to complain on IRC or somewhere ;). I would also vote for calculating both hashes (of it's really only the finaling) and print an warning in case it matches the hash caluclated with the bad implementation. Maybe rejecting it with --batch or something for rejecting it by default as soon as major operating systems have updated. Thank you for your work and many thanks to Yuriy Kaminskiy for reporting! -- Philipp. (Rah of PH2) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From jrb at expunge.us Thu Nov 21 06:19:42 2013 From: jrb at expunge.us (Jared Baldridge) Date: Thu, 21 Nov 2013 00:19:42 -0500 Subject: Destroyed OpenPGP v2 Card? Message-ID: Due to an unfortunate scripting incident, I seem to have exceeded the maximum number of retries for PW3 on an OpenPGP Card v2 (ATR 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C) with 3 empty key data objects. When attempting to reset the card by sending a TERMINATE DF, I receive 6A 88, Referenced Data Not found. Does TERMINATE DF depend on the key data objects being populated? If so, should I relegate this card to the rubbish bin? It seems most any command sent to the card receives a status of 6A 88. Thanks -jrb -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Nov 21 07:47:05 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 21 Nov 2013 15:47:05 +0900 Subject: Destroyed OpenPGP v2 Card? In-Reply-To: References: Message-ID: <1385016425.3314.6.camel@cfw2.gniibe.org> On 2013-11-21 at 00:19 -0500, Jared Baldridge wrote: > When attempting to reset the card by sending a TERMINATE DF, I receive > 6A 88, Referenced Data Not found. If I understand correctly, it is ACTIVATE FILE (INS=0x44) to recover. I used a Python script for that (SELECT FILE and ACTIVATE FILE). See: http://lists.gnupg.org/pipermail/gnupg-devel/2013-March/027518.html -- From jrb at expunge.us Thu Nov 21 16:53:24 2013 From: jrb at expunge.us (Jared Baldridge) Date: Thu, 21 Nov 2013 10:53:24 -0500 Subject: Destroyed OpenPGP v2 Card? In-Reply-To: <1385016425.3314.6.camel@cfw2.gniibe.org> References: <1385016425.3314.6.camel@cfw2.gniibe.org> Message-ID: INS=0x44 is actually TERMINATE DF. It seems I needed the SELECT FILE (00 A4 04 00 06 D2 76 00 01 24 01 00) prior to sending TERMINATE DF. I'm back up and going with a 3 0 3 pin retry. Thanks for your help! -jrb On Thu, Nov 21, 2013 at 1:47 AM, NIIBE Yutaka wrote: > On 2013-11-21 at 00:19 -0500, Jared Baldridge wrote: > > When attempting to reset the card by sending a TERMINATE DF, I receive > > 6A 88, Referenced Data Not found. > > If I understand correctly, it is ACTIVATE FILE (INS=0x44) to recover. > I used a Python script for that (SELECT FILE and ACTIVATE FILE). See: > > http://lists.gnupg.org/pipermail/gnupg-devel/2013-March/027518.html > -- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Fri Nov 22 02:58:45 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 22 Nov 2013 10:58:45 +0900 Subject: Destroyed OpenPGP v2 Card? In-Reply-To: References: <1385016425.3314.6.camel@cfw2.gniibe.org> Message-ID: <1385085525.3199.3.camel@cfw2.gniibe.org> It's good you recovered your card. :-) Yes, SELECT FILE is needed before ACTIVATE FILE. On 2013-11-21 at 10:53 -0500, Jared Baldridge wrote: > INS=0x44 is actually TERMINATE DF. INS=0x44 is ACTIVATE FILE in ISO/IEC 7816-9. I've just checked corresponding Japanese standard (JIS X6320-9), and ISO/IEC 7816-4:2005 which refers ISO/IEC 7816-9. (I don't have ISO/IEC 7816-9 at hand.) In the OpenPGPcard specification 2.0, it's wrongly described in the table in page 30, but in page 46, ACTIVATE FILE is correctly described as 0x44. -- From achim at pietig.com Fri Nov 22 08:52:24 2013 From: achim at pietig.com (Achim Pietig) Date: Fri, 22 Nov 2013 08:52:24 +0100 Subject: Destroyed OpenPGP v2 Card? In-Reply-To: <1385085525.3199.3.camel@cfw2.gniibe.org> References: <1385016425.3314.6.camel@cfw2.gniibe.org> <1385085525.3199.3.camel@cfw2.gniibe.org> Message-ID: <528F0D38.2020402@pietig.com> Hi, in 7.1 the INS of the commands Terminate and Activate in the table are swapped, thanks for that hint. It will be corrected in the next version. For understandig: The special life cicle management (reset card) is proprietary for the OpenPGP card application, other applications on the same card may have a different behaviour. For that reason the Selection of the application is needed before a Reset. Regards, Achim Am 22.11.2013 02:58, schrieb NIIBE Yutaka: > It's good you recovered your card. :-) Yes, SELECT FILE is needed > before ACTIVATE FILE. > > On 2013-11-21 at 10:53 -0500, Jared Baldridge wrote: >> INS=0x44 is actually TERMINATE DF. > > INS=0x44 is ACTIVATE FILE in ISO/IEC 7816-9. I've just checked > corresponding Japanese standard (JIS X6320-9), and ISO/IEC 7816-4:2005 > which refers ISO/IEC 7816-9. (I don't have ISO/IEC 7816-9 at hand.) > > In the OpenPGPcard specification 2.0, it's wrongly described in the > table in page 30, but in page 46, ACTIVATE FILE is correctly described > as 0x44. > From gpgsm at plaga.de Mon Nov 25 14:55:05 2013 From: gpgsm at plaga.de (Sven Plaga) Date: Mon, 25 Nov 2013 14:55:05 +0100 Subject: gpgsm/smartcard/AES Message-ID: <19af8f320e6d44372e9ad4495fa55f50@prometheus3.straubing.biz> Hi, at my company we are using safesign smartcards for SMIME. Using this smartcard with gpgsm, I've noticed that it is not possible to decrypt AES encrypted E-Mails. With the following patch, it is possible to decrypt the AES message: --- original/gnupg2-2.0.19/sm/decrypt.c 2012-03-27 10:00:38.000000000 +0200 +++ BugReport/gnupg2-2.0.19/sm/decrypt.c 2013-11-25 14:40:34.760667458 +0100 @@ -73,7 +73,7 @@ prepare_decryption (ctrl_t ctrl, const c log_printhex ("pkcs1 encoded session key:", seskey, seskeylen); n=0; - if (seskeylen == 24) + if (1) { /* Smells like a 3-des key. This might happen because a SC has already done the unpacking. */ As the AES-key has a length of 32 bytes, a possible work-around would be the insertion of an additional if-check for seskeylen == 32 -- But I am not sure if there are possible collisions with non-unpacked (see [1]) keys. Is there an easy way to check if the key is already unpacked? Kind Regards Sven Plaga [1] https://github.com/matsuu/gnupg/commit/dc8f3ee42c4bd873ddce57098c23ca5dbd445fff From wk at gnupg.org Mon Nov 25 18:58:13 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Nov 2013 18:58:13 +0100 Subject: gpgsm/smartcard/AES In-Reply-To: <19af8f320e6d44372e9ad4495fa55f50@prometheus3.straubing.biz> (Sven Plaga's message of "Mon, 25 Nov 2013 14:55:05 +0100") References: <19af8f320e6d44372e9ad4495fa55f50@prometheus3.straubing.biz> Message-ID: <87y54cjrd6.fsf@vigenere.g10code.de> On Mon, 25 Nov 2013 14:55, gpgsm at plaga.de said: > As the AES-key has a length of 32 bytes, a possible work-around would > be the insertion of an additional if-check for seskeylen == 32 -- But > I am not sure if there are possible collisions with non-unpacked (see > [1]) keys. I don't like such a hack. There is even a fixme comment for the 3-DES hack. A proper way to implement that is to add specific support for this into gpg-agent and scdaemon. gpgsm would then be able to decide whether this is an unpacked key or not. Granted, trial decyption is possible and thus - aside from side channel attacks - there is no security problem with that. However, a clean solution makes much more sense. What card application are you using? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ido at kernel.org Fri Nov 29 03:24:18 2013 From: ido at kernel.org (Ido Rosen) Date: Thu, 28 Nov 2013 21:24:18 -0500 Subject: generating RSA key sizes > 4096 Message-ID: <20131129022417.GB3349@gmail.com> Currently, several downstream distributions of GnuPG patch the GPG code in their packages to support generating RSA keys larger than 4096 bits large. Mac OS X GPGTools, for example, patched to support generating 8192 bit RSA keys back in October (23rd?), 2010. I've opened a bug issue/ticket #1573 with a patch which addresses this need. Specifically, rather than changing the maximum RSA key size outright, I've created a compile-time flag --enable-max-rsa-key-size=SIZE. [1] When the feature is not used, the current behavior (4096 bit maximum, 32768 byte secmem init size) are retained. When the feature is set to greater than 4096 bit key size, secmem init and the key size in ask_keysize (g10/keygen.c) are modified accordingly. I apologize in advance if I made any mistakes in terms of following the project's coding style or patch submission procedures. Ido -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From wk at gnupg.org Fri Nov 29 11:08:12 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Nov 2013 11:08:12 +0100 Subject: GPGTools GPL compliance (was: generating RSA key sizes > 4096) In-Reply-To: <20131129022417.GB3349@gmail.com> (Ido Rosen's message of "Thu, 28 Nov 2013 21:24:18 -0500") References: <20131129022417.GB3349@gmail.com> Message-ID: <87siufcygj.fsf@vigenere.g10code.de> On Fri, 29 Nov 2013 03:24, ido at kernel.org said: > Currently, several downstream distributions of GnuPG patch the GPG code in > their packages to support generating RSA keys larger than 4096 bits large. > Mac OS X GPGTools, for example, patched to support generating 8192 bit RSA > keys back in October (23rd?), 2010. Really? Of cource they are free to do this but nevertheless this is annoying given that they have asked to be listed as suggested Mac package for GnuPG. I can't help myself but it somehow reminds me of the Debian RNG problem. Now for the actual subject: Checking your website I noticed that some things have changed since gpgtools has been listed at gnupg.org. For example, I can't find a way to get the source code for the distributed installer. There is only a pointer to some github project but no definitive corresponding source. This needs to be fixed immediately! Please actually read the GPL and provide full corresponding source code and all required tools. If you don't know how to do that you may want to checkout the Gpg4win installer to see how this can be achieved. You should add the source code to the server at scnr.is and provide a link to it. This is the easiest way to comply with section 6d unless you have a contractual agreement with github. I'd also appreciate if changes to the code are communicated back so to discuss on how to get your changes upstream. This is how all other major and minor distributions behave. Shalom-Salam, Werner ps. I am sorry if this sounds a bit harsh. I have seen too many abuses of the GPL. Given that fulfilling the requirements of the GPL is in particular for a full free software project easy, I can't understand why it is not being followed. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Fri Nov 29 17:10:59 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 29 Nov 2013 11:10:59 -0500 Subject: generating RSA key sizes > 4096 In-Reply-To: <20131129022417.GB3349@gmail.com> References: <20131129022417.GB3349@gmail.com> Message-ID: <5298BC93.809@sixdemonbag.org> > Currently, several downstream distributions of GnuPG patch the GPG code in > their packages to support generating RSA keys larger than 4096 bits large. Which ones besides GPGTools? The choice of what range of sizes to support is not a trivial one. The overwhelming majority of OpenPGP installations max out at a 4kbit key. Further, there has been no clear message from the cryptographic community that such a large key is in any way useful. NIST believes a 2048-bit key will be secure for 30 years; ENISA recommends a 3072-bit key. Allowing a 4096-bit key allows people to go far beyond all the current recommendations; why should it go further? Additionally, this tends to promote an obsession with key size -- very often at the expense of other important factors. Whether something is protected by 2048-bit RSA or 8192-bit RSA doesn't matter a damn, since no one with two brain cells to rub together will try cryptanalyzing the traffic. They'll resort to other methods instead. So, yeah, I don't see a point for this patch, I'm sorry to say. I have severe doubts as to whether explicitly supporting extraordinarily large keys is something GnuPG needs to do, support, or facilitate. (I am not a GnuPG developer and I have absolutely no say in the final decision, FYI.) From wk at gnupg.org Fri Nov 29 18:46:59 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Nov 2013 18:46:59 +0100 Subject: GPGTools GPL compliance In-Reply-To: (Ido Rosen's message of "Fri, 29 Nov 2013 09:21:09 -0500") References: <20131129022417.GB3349@gmail.com> <87siufcygj.fsf@vigenere.g10code.de> Message-ID: <877gbrcd7w.fsf@vigenere.g10code.de> On Fri, 29 Nov 2013 15:21, irosen at gmail.com said: > I do not have anything to do with GPGTools. I was using them as an > example. Please redirect your comments to them about GPL. I know that and thus the mail header of my mail looked like this: To: team at gpgtools.org Cc: gnupg-devel at gnupg.org BTW, I had to resort to whois to find that mail contact. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christoph_murauer at yahoo.de Fri Nov 29 20:22:17 2013 From: christoph_murauer at yahoo.de (Christoph Roland Murauer) Date: Fri, 29 Nov 2013 20:22:17 +0100 Subject: generating RSA key sizes > 4096 In-Reply-To: <5298BC93.809@sixdemonbag.org> References: <20131129022417.GB3349@gmail.com> <5298BC93.809@sixdemonbag.org> Message-ID: Hello ! As Werner wrote ... the only source code on the GPGTools website is the one from the patched GPG2 version from the GPGTools team and not the one from the GnuPG project (if there is a link or information about it, then I don't found it). I don't know whether they provide the GPG 1 version as in the past in their installer because I don't use their installer / package. You can find more informations on https://gpgtools.org/opensource.html ... build your own opinion aboit it as I did. @Ido : If you like another keysize, simple change the value in g10/keygen.c and build it from source (works also fine on Mac OS X 10.9). But keep the words from Robert in mind. Means, a long key and a good passphrase / mantra for your keyring prevents noone from copying your intire keyrings. @Robert : I would not call it downstream distributions as Ido does. But package managers like Fink, MacPorts and Homebrew provide a switch to change the key size. Homebrew for example builds GPG with a keysize of 4096 KBit by default but you can use a switch (no patch in GnuPG - only a option in the Ruby script of Homebrew) to get 8192 KBit. You are right with the things you wrote about the key size and so on. The problem is, if a project like GPGTools provide bigger keys then people use it (and want it) without to ask about the background (generate a key / analyse a key) and so on ... The Homebrew project never say, that they provide a own GnuPG distribution but they want to make Unix (like) software available for everyone. As Example the installation formular for GnuPG 1 at https://github.com/mxcl/homebrew/blob/master/Library/Formula/gnupg.rb - if the software was built from source, then the source code was fetched from ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.15.tar.bz2. And the command brew home gpg opened the website www.gnupg.org. C. M. Am 29.11.2013 um 17:10 schrieb "Robert J. Hansen" : >> Currently, several downstream distributions of GnuPG patch the GPG code in >> their packages to support generating RSA keys larger than 4096 bits large. > > Which ones besides GPGTools? > > The choice of what range of sizes to support is not a trivial one. The > overwhelming majority of OpenPGP installations max out at a 4kbit key. > > Further, there has been no clear message from the cryptographic > community that such a large key is in any way useful. NIST believes a > 2048-bit key will be secure for 30 years; ENISA recommends a 3072-bit > key. Allowing a 4096-bit key allows people to go far beyond all the > current recommendations; why should it go further? > > Additionally, this tends to promote an obsession with key size -- very > often at the expense of other important factors. Whether something is > protected by 2048-bit RSA or 8192-bit RSA doesn't matter a damn, since > no one with two brain cells to rub together will try cryptanalyzing the > traffic. They'll resort to other methods instead. > > So, yeah, I don't see a point for this patch, I'm sorry to say. I have > severe doubts as to whether explicitly supporting extraordinarily large > keys is something GnuPG needs to do, support, or facilitate. > > (I am not a GnuPG developer and I have absolutely no say in the final > decision, FYI.) > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From lukashaase at gmx.at Sat Nov 30 06:18:57 2013 From: lukashaase at gmx.at (Lukas Haase) Date: Fri, 29 Nov 2013 21:18:57 -0800 Subject: pinentry: How to get key id? Message-ID: Hi, I want to add a small patch to pinentry-win32 which first tries to query the password from a particular source (and only if it cannot be found there, display the passphrase dialog as usual). But for this I need to know the key ID for which the password is queried. But struct pinentry only contains this information in the description field (as it seems). However, the last thing I want to do is pattern matching. Is there a way to find the key id for which the password is queried, e.g. within the pinentry_loop2 or better, the w32_cmd_handler function? Thanks, Luke