From vanenkj at gmail.com Thu Dec 3 07:34:43 2009 From: vanenkj at gmail.com (John Van Enk) Date: Thu, 3 Dec 2009 01:34:43 -0500 Subject: Bug in cipher/ac.c Message-ID: Hello List, I'm trying to write some Haskell bindings for libgcrypt. I tripped over a bug in the eme_pkcs_v1_5_encode function. Even though you shouldn't, the library segfaults when using a key size of less than 11 bytes in length. Note the conditional below. By changing the if to "if (k < 11 || m_n > k - 11)", the function properly responds with GPG_ERR_TOO_SHORT rather than segfaulting. 2239 /* Figure out key length in bytes. */ 2240 k = options->key_size / 8; 2241 2242 if (m_n > k - 11) 2243 { 2244 /* Key is too short for message. */ 2245 err = gcry_error (GPG_ERR_TOO_SHORT); 2246 goto out; 2247 } Now, I may have just done something silly in my example program which would cause this not to happen, but this seems like a good check to add. Also, this is my first post. I'm sorry if I've broken list some etiquette. My example program is posted here: http://gist.github.com/247935 Thanks for your time. /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergi at calcurco.cat Tue Dec 8 11:48:34 2009 From: sergi at calcurco.cat (=?ISO-8859-1?Q?Sergi_Blanch_i_Torn=E9?=) Date: Tue, 8 Dec 2009 11:48:34 +0100 Subject: new contributor? In-Reply-To: References: Message-ID: <80e2a3c40912080248x70b9d213hbf6ca62656bc3b4d@mail.gmail.com> Hi Fr?d?ric, I thing this thread is better to have it in the gcrypt list. Can I ask you for some help in the elliptic curve encryption? The implementation of the future standart [1] is giving me some implementations headaches. Also the mathematical primitives over the finite fields can be optimized because in elliptic curves we use a shorter field, but we call them many more times. About how to manage your contribution, I am not the good one to answer you. As far as I know, you there are some types of agreements that can help in how will be your contribution. Finally, only say good luck and book some time to develop! /Sergi. [1] http://tools.ietf.org/html/draft-jivsov-openpgp-ecc-03 2009/12/6 Fr?d?ric Yhuel : > Hello, > > I recently graduate from Grenoble university (France), where I > attended a M Sc in Mathematics and Cryptology. I would like to > contribute to GNU PG project, and one of my former teacher told me you > may need help for the ECDSA test. If it is the case, or if you need > help somewhere else, please let me know. I will do my best to be > useful and to not get (too much) in the way. > > BR, > Fr?d?ric Yhuel > > PS I've tried to subscribe to gcrypt-devel mailing list, but it seems > that the sever doesn't accept gmail addresses. > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From ametzler at downhill.at.eu.org Tue Dec 8 17:40:09 2009 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Tue, 8 Dec 2009 17:40:09 +0100 Subject: libgcrypt tries to use SPARC32 assembly code on SPARC64 Message-ID: <20091208164009.GC3218@downhill.g.la> Hello, this is http://bugs.debian.org/560028 reported by Aurelien Jarno. Patch still applies on SVN head. cu andreas ----- Forwarded message from Aurelien Jarno ----- From: Aurelien Jarno Subject: Bug#560028: libgcrypt11: try to use SPARC32 assembly code on SPARC64 Package: libgcrypt11 Version: 1.4.1-1 Severity: normal Tags: patch User: debian-sparc at lists.debian.org Usertags: sparc64 libgcrypt11 fails to build on sparc64, as it tries to mix SPARC32 assembly code on SPARC64. The patch below fixes the problem. --- libgcrypt11-1.4.4.orig/mpi/config.links +++ libgcrypt11-1.4.4/mpi/config.links @@ -138,11 +138,10 @@ mpi_extra_modules="udiv-qrnnd" ;; sparc64-*-linux-gnu) - # An extra rule because we have an report for this one only. - # Should be compared against the next GMP version - echo '/* configured for sparc64-*-linux-gnu */' >>./mpi/asm-syntax.h - path="sparc32v8 sparc32" - mpi_extra_modules="udiv" + # There are no sparc64 assembler modules that work on GNU/Linux, + # so use the generic C functions. + echo '/* No working assembler modules available */' >>./mpi/asm-syntax.h + path="" ;; sparc64-sun-solaris2*) # Got a report that udiv is missing, so we try this one -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'unstable') Architecture: sparc64 Kernel: Linux 2.6.26-2-sparc64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ----- End forwarded message ----- From wk at gnupg.org Wed Dec 9 11:12:46 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Dec 2009 11:12:46 +0100 Subject: AES-Wrap Message-ID: <873a3ksbfl.fsf@vigenere.g10code.de> Hi! I just finished an implementation of the AES-Wrap algorithm as specified in rfc3394 and a similar NIST spec. It is implemented as a new cipher mode so that the algorithm may optionally be used with any 128 bit block cipher. Example encryption code: gcry_error_t err; gcry_cipher_hd_t hd; unsigned char outbuf[32+8]; size_t outbuflen; int i; err = gcry_cipher_open (&hd, GCRY_CIPHER_AES128, GCRY_CIPHER_MODE_AESWRAP, 0); if (err) { fail ("gcrypt_cipher_open failed: %s\n", gpg_strerror (err)); return; } err = gcry_cipher_setkey (hd, kek, 128/8); if (err) { fail ("grcy_cipher_setkey failed: %s\n", gpg_strerror (err)); return; } outbuflen = datalen + 8; if (outbuflen > sizeof outbuf) err = gpg_error (GPG_ERR_INTERNAL); else err = gcry_cipher_encrypt (hd, outbuf, outbuflen, data, datalen); if (err) { fail ("grcy_cipher_encrypt failed: %s\n", gpg_strerror (err)); return; } fprintf (stderr, "Ciphertext:"); for (i = 0; i < outbuflen; i++) fprintf (stderr, " %02x", outbuf[i]); putc ('\n', stderr); decryption is similar: ... create handle and set key ... outbuflen = datalen - 8; if (outbuflen > sizeof outbuf) err = gpg_error (GPG_ERR_INTERNAL); else err = gcry_cipher_decrypt (hd, outbuf, outbuflen, data, datalen); if (err) { fail ("grcy_cipher_decrypt failed: %s\n", gpg_strerror (err)); return; } fprintf (stderr, "Plaintext:"); for (i = 0; i < outbuflen; i++) fprintf (stderr, " %02x", outbuf[i]); putc ('\n', stderr); Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 9 15:37:47 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Dec 2009 15:37:47 +0100 Subject: libgcrypt tries to use SPARC32 assembly code on SPARC64 In-Reply-To: <20091208164009.GC3218@downhill.g.la> References: <20091208164009.GC3218@downhill.g.la> Message-ID: <87r5r4qklg.fsf@vigenere.g10code.de> > this is http://bugs.debian.org/560028 reported by Aurelien Jarno. > Patch still applies on SVN head. Thanks. I applied to to all versions as weel as to GnuPG 1.4. Thus --disable-asm is not anymore needed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From yhuelf at gmail.com Thu Dec 10 11:30:27 2009 From: yhuelf at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBZaHVlbA==?=) Date: Thu, 10 Dec 2009 11:30:27 +0100 Subject: elliptic curves Message-ID: Hi Sergi, > By now I am writing (slowly, really slowly) the code for the 'ecc in openpgp', the aeswrap is done and I was my biggest headache. Now test the KDF, and the rest should work easily. So, you want me to test the KDF? What I don't understand, is that when I "svn log" ecc.c, the latest modification is january 2009. I have mailed Werner Koch, as you told me, about how I could manage my contribution. I'm waiting for his answer. -- Frederic From wk at gnupg.org Thu Dec 10 14:11:09 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Dec 2009 14:11:09 +0100 Subject: elliptic curves In-Reply-To: References: Message-ID: <87k4wvq8ia.fsf@vigenere.g10code.de> On Thu, 10 Dec 2009 11:30:27 +0100, Fr?d?ric Yhuel wrote: > So, you want me to test the KDF? What I don't understand, is that when > I "svn log" ecc.c, the latest modification is january 2009. Sergi sent me a patch which I have not integrated because it does not yet work. To help out I implemented the AESWRAP mode. Sergie: Please resent a cleaned up pacth to the list. > I have mailed Werner Koch, as you told me, about how I could manage my > contribution. I'm waiting for his answer. Here we go: Please be prepared to sign a copyright assignment to the FSF. While we are working this out may already work on the code. I'll review patches and integrate them. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From yhuelf at gmail.com Thu Dec 10 18:37:45 2009 From: yhuelf at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBZaHVlbA==?=) Date: Thu, 10 Dec 2009 18:37:45 +0100 Subject: elliptic curves In-Reply-To: <87k4wvq8ia.fsf@vigenere.g10code.de> References: <87k4wvq8ia.fsf@vigenere.g10code.de> Message-ID: On Thu, Dec 10, 2009 at 2:11 PM, Werner Koch wrote: > On Thu, 10 Dec 2009 11:30:27 +0100, Fr?d?ric Yhuel wrote: > >> So, you want me to test the KDF? What I don't understand, is that when >> I "svn log" ecc.c, the latest modification is january 2009. > > Sergi sent me a patch which I have not integrated because it does not > yet work. ?To help out I implemented the AESWRAP mode. ?Sergie: Please > resent a cleaned up pacth to the list. > >> I have mailed Werner Koch, as you told me, about how I could manage my >> contribution. I'm waiting for his answer. > > Here we go: Please be prepared to sign a copyright assignment to the > FSF. ?While we are working this out may already work on the code. > I'll review patches and integrate them. > > > Salam-Shalom, > > ? Werner > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > > OK, it's quite clear. Thank you Werner. If I've understood well, you've e-mailed the FSF, and they're going to send me a paper to sign. From wk at gnupg.org Fri Dec 11 17:48:02 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 11 Dec 2009 17:48:02 +0100 Subject: Libgcrypt 1.4.5 released Message-ID: <87bpi5qwxp.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.4.5. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.4.5: * Fixed minor memory leak in DSA key generation. * No more switching to FIPS mode if /proc/version is not readable. * Fixed a sigill during Padlock detection on old CPUs. * Fixed a hang on some W2000 machines. * Boosted SHA-512 performance by 30% on ia32 boxes and gcc 4.3; SHA-256 went up by 25%. Source code is hosted at the GnuPG FTP server and its mirrors as listed at . On the primary server the source file and its digital signature is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.5.tar.bz2 (1121k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.5.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.5.tar.gz (1386k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.5.tar.gz.sig Alternativley you may upgrade version 1.4.4 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.4-1.4.5.diff.bz2 (93k) The SHA-1 checksums are: ef7ecbd3a03a7978094366bcd1257b3654608d28 libgcrypt-1.4.5.tar.bz2 8d83a60ca55f2ea40b5d5bc99463905b7a1dcb56 libgcrypt-1.4.5.tar.gz 5307e361da5232cd771c300adddc69e57f0e366d libgcrypt-1.4.4-1.4.5.diff.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. Note that this version is from the stable branch; the current development version is available at . Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [2], order extensions or support or more general by donating money to the Free Software movement (e.g. ). Commercial support contracts for Libgcrypt are available [3], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company, is currently funding Libgcrypt development. We are always looking for interesting development projects. Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See . [2] Note that copyright assignments to the FSF are required. [3] See the service directory at . -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sergi at calcurco.cat Fri Dec 11 18:18:20 2009 From: sergi at calcurco.cat (=?ISO-8859-1?Q?Sergi_Blanch_i_Torn=E9?=) Date: Fri, 11 Dec 2009 18:18:20 +0100 Subject: elliptic curves In-Reply-To: <87k4wvq8ia.fsf@vigenere.g10code.de> References: <87k4wvq8ia.fsf@vigenere.g10code.de> Message-ID: <80e2a3c40912110918m2a54dc16o2a3ace3214d85bc2@mail.gmail.com> On Thu, Dec 10, 2009 at 2:11 PM, Werner Koch wrote: > Sergi sent me a patch which I have not integrated because it does not > yet work. ?To help out I implemented the AESWRAP mode. ?Sergie: Please > resent a cleaned up pacth to the list. I have to clean and sync my mirror to the main svn, do some test, and share. If everything goes in the good direction, soon we shall has this available. (note that I'm not promising for a concrete day ;) ) /Sergi. From hoyt6 at llnl.gov Wed Dec 16 20:34:06 2009 From: hoyt6 at llnl.gov (Hoyt, David) Date: Wed, 16 Dec 2009 11:34:06 -0800 Subject: gcrypt windows build Message-ID: When I compile on Windows XP using MinGW and GCC 4.4.1, and run the tests (make check), I get a bunch of failures: FAIL: version.exe FAIL: t-mpi-bit.exe FAIL: prime.exe FAIL: register.exe FAIL: ac.exe FAIL: ac-schemes.exe FAIL: ac-data.exe FAIL: basic.exe FAIL: mpitests.exe FAIL: tsexp.exe FAIL: keygen.exe FAIL: pubkey.exe FAIL: hmac.exe FAIL: keygrip.exe FAIL: fips186-dsa.exe FAIL: benchmark.exe ======================================== 16 of 16 tests failed Please report to bug-libgcrypt at gnupg.org ======================================== The libraries build just fine - no problems there. When I run the programs I don't see any output at all. Any thoughts? I appreciate any help anyone can provide. From wk at gnupg.org Thu Dec 17 09:01:35 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Dec 2009 09:01:35 +0100 Subject: gcrypt windows build In-Reply-To: References: Message-ID: <876386rpuo.fsf@vigenere.g10code.de> On Wed, 16 Dec 2009 11:34:06 -0800, Hoyt, David wrote: > > When I compile on Windows XP using MinGW and GCC 4.4.1, and run the tests (make check), I get a bunch of failures: We only support cross-builds from a POSIX platform. If you try to build it on the traget platform it may or may not work. > The libraries build just fine - no problems there. When I run the programs I don't see any output at all. Any thoughts? I appreciate any help anyone can provide. You mean the test program? They return an exit code; some of them accept an option like cd tests ./basic --verbose Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ametzler at downhill.at.eu.org Thu Dec 17 19:00:00 2009 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Thu, 17 Dec 2009 19:00:00 +0100 Subject: libgcrypt11/mips(el): FTBFS with gcc-4.4 Message-ID: <20091217180000.GA3567@downhill.g.la> Hello, this is . Debian/unstable has recently switched to gcc-4.4. This seems to have caused a build-failure for libgcrypt. cu andreas ----- Forwarded message from Aurelien Jarno ----- From: Aurelien Jarno Message-ID: <20091217133201.16090.92884.reportbug at mipsel.aurel32.net> Date: Thu, 17 Dec 2009 14:32:01 +0100 Subject: Bug#561475: libgcrypt11/mips(el): FTBFS with gcc-4.4 Package: libgcrypt11 Version: 1.4.1-1 Severity: serious Tags: patch Justification: fails to build from source mpfr fails to build on mips(el) with gcc-4.4. A full build log can be found here: https://buildd.debian.org/fetch.cgi?pkg=libgcrypt11&arch=mipsel&ver=1.4.5-1&stamp=1260977092&file=log&as=raw This is due to a change in GCC 4.4, the h asm constraint is not supported anymore on mips. For more details please have a look at: http://gcc.gnu.org/gcc-4.4/changes.html The patch below fixes the problem by implementing the solution recommended by the previous web page. With it libgcrypt11 builds successfully. --- libgcrypt11-1.4.5.orig/mpi/longlong.h +++ libgcrypt11-1.4.5/mpi/longlong.h @@ -714,7 +714,15 @@ extern USItype __udiv_qrnnd (); ************** MIPS ***************** ***************************************/ #if defined (__mips__) && W_TYPE_SIZE == 32 -#if __GNUC__ > 2 || __GNUC_MINOR__ >= 7 +#if (__GNUC__ >= 5) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) +#define umul_ppmm(w1, w0, u, v) \ + do { \ + UDItype _r; \ + _r = (UDItype) u * v; \ + (w1) = _r >> 32; \ + (w0) = (USItype) _r; \ + } while (0) +#elif __GNUC__ > 2 || __GNUC_MINOR__ >= 7 #define umul_ppmm(w1, w0, u, v) \ __asm__ ("multu %2,%3" \ : "=l" ((USItype)(w0)), \ @@ -739,7 +747,16 @@ extern USItype __udiv_qrnnd (); ************** MIPS/64 ************** ***************************************/ #if (defined (__mips) && __mips >= 3) && W_TYPE_SIZE == 64 -#if __GNUC__ > 2 || __GNUC_MINOR__ >= 7 +#if (__GNUC__ >= 5) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) +typedef unsigned int UTItype __attribute__ ((mode (TI))); +#define umul_ppmm(w1, w0, u, v) \ + do { \ + UTItype _r; \ + _r = (UTItype) u * v; \ + (w1) = _r >> 64; \ + (w0) = (UDItype) _r; \ + } while (0) +#elif __GNUC__ > 2 || __GNUC_MINOR__ >= 7 #define umul_ppmm(w1, w0, u, v) \ __asm__ ("dmultu %2,%3" \ : "=l" ((UDItype)(w0)), \ -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: mipsel (mips64) Kernel: Linux 2.6.26-2-5kc-malta Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash From hoyt6 at llnl.gov Thu Dec 17 20:06:53 2009 From: hoyt6 at llnl.gov (Hoyt, David) Date: Thu, 17 Dec 2009 11:06:53 -0800 Subject: gcrypt windows build In-Reply-To: <876386rpuo.fsf@vigenere.g10code.de> References: <876386rpuo.fsf@vigenere.g10code.de> Message-ID: > We only support cross-builds from a POSIX platform. If you try to build it on the traget platform it may or may not work. How do you test a cross-compiled library? How do you run your test programs to validate your cross-compiled libraries are working correctly? Do you have any tips on how I could get the test programs working? > You mean the test program? They return an exit code; some of them > accept an option like > > cd tests > ./basic --verbose > I was running the generated executables (e.g. ./basic.exe --verbose), not the associated scripts (./basic) and even with --verbose, I was getting no output at all. Thanks for helping me out - it's appreciated. From simon at josefsson.org Thu Dec 17 21:57:03 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 17 Dec 2009 21:57:03 +0100 Subject: gcrypt windows build In-Reply-To: (David Hoyt's message of "Thu, 17 Dec 2009 11:06:53 -0800") References: <876386rpuo.fsf@vigenere.g10code.de> Message-ID: <87ws0lmi8w.fsf@mocca.josefsson.org> "Hoyt, David" writes: >> We only support cross-builds from a POSIX platform. If you try to build it on the traget platform it may or may not work. > > How do you test a cross-compiled library? How do you run your test > programs to validate your cross-compiled libraries are working > correctly? Do you have any tips on how I could get the test programs > working? Use wine. Just install MinGW and Wine under Linux, and then build libgcrypt like this: ./configure --host=i586-mingw32msvc --build=i686-pc-linux-gnu It will invoke the self-tests automatically, if you have the binfmt-support package installed. If you want a makefile that does everything, check out . /Simon From hoyt6 at llnl.gov Fri Dec 18 01:29:51 2009 From: hoyt6 at llnl.gov (Hoyt, David) Date: Thu, 17 Dec 2009 16:29:51 -0800 Subject: gcrypt windows build In-Reply-To: <87ws0lmi8w.fsf@mocca.josefsson.org> References: <876386rpuo.fsf@vigenere.g10code.de> <87ws0lmi8w.fsf@mocca.josefsson.org> Message-ID: > If you want a makefile that does everything, check out > . What version of gcc do you use (in the mingw toolchain)? From simon at josefsson.org Fri Dec 18 07:20:36 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 18 Dec 2009 07:20:36 +0100 Subject: gcrypt windows build In-Reply-To: (David Hoyt's message of "Thu, 17 Dec 2009 16:29:51 -0800") References: <876386rpuo.fsf@vigenere.g10code.de> <87ws0lmi8w.fsf@mocca.josefsson.org> Message-ID: <87y6l0kdl7.fsf@mocca.josefsson.org> "Hoyt, David" writes: >> If you want a makefile that does everything, check out >> . > > What version of gcc do you use (in the mingw toolchain)? I'm using the 'mingw32' package from debian, which appears to be gcc 4.2 based. http://packages.qa.debian.org/m/mingw32.html /Simon From wk at gnupg.org Fri Dec 18 14:55:15 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Dec 2009 14:55:15 +0100 Subject: gcrypt windows build In-Reply-To: <87y6l0kdl7.fsf@mocca.josefsson.org> References: <876386rpuo.fsf@vigenere.g10code.de> <87ws0lmi8w.fsf@mocca.josefsson.org> <87y6l0kdl7.fsf@mocca.josefsson.org> Message-ID: <87vdg4qtdo.fsf@vigenere.g10code.de> On Fri, 18 Dec 2009 07:20:36 +0100, Simon Josefsson wrote: > > "Hoyt, David" writes: > > >> If you want a makefile that does everything, check out > >> . > > > > What version of gcc do you use (in the mingw toolchain)? > > I'm using the 'mingw32' package from debian, which appears to be gcc 4.2 > based. http://packages.qa.debian.org/m/mingw32.html Take care: The mingw packages in Debian are broken: as GNU make. We are using Debian GNU/Linux (Lenny); due to a little bug in the mingw32 compiler it is highly suggested to put a line deb http://apt.intevation.org lenny/mingw . into /etc/apt/sources and update the mingw packages. they replaced the snprintf and introduced a bug. IIRC, "%lu" requires an "unsigned long long" arg and not an "unsigned long". The result is that the stack is messed up and you get all kinds of strange error. At one point it took us many hours of debugging until we realized that some parts of a system were build with the broken mingw runtime. The fix is trivial but still hasn't made it into Debian. I think libgcrypt does not use printf with "%lu" but that may depend on the version. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Fri Dec 18 16:23:34 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 18 Dec 2009 16:23:34 +0100 Subject: gcrypt windows build In-Reply-To: <87vdg4qtdo.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 18 Dec 2009 14:55:15 +0100") References: <876386rpuo.fsf@vigenere.g10code.de> <87ws0lmi8w.fsf@mocca.josefsson.org> <87y6l0kdl7.fsf@mocca.josefsson.org> <87vdg4qtdo.fsf@vigenere.g10code.de> Message-ID: <87hbro487d.fsf@mocca.josefsson.org> Werner Koch writes: > On Fri, 18 Dec 2009 07:20:36 +0100, Simon Josefsson wrote: >> >> "Hoyt, David" writes: >> >> >> If you want a makefile that does everything, check out >> >> . >> > >> > What version of gcc do you use (in the mingw toolchain)? >> >> I'm using the 'mingw32' package from debian, which appears to be gcc 4.2 >> based. http://packages.qa.debian.org/m/mingw32.html > > Take care: The mingw packages in Debian are broken: > > as GNU make. We are using Debian GNU/Linux (Lenny); due to a little > bug in the mingw32 compiler it is highly suggested to put a line > deb http://apt.intevation.org lenny/mingw . > into /etc/apt/sources and update the mingw packages. > > they replaced the snprintf and introduced a bug. IIRC, "%lu" requires > an "unsigned long long" arg and not an "unsigned long". The result is > that the stack is messed up and you get all kinds of strange error. > At one point it took us many hours of debugging until we realized that > some parts of a system were build with the broken mingw runtime. The > fix is trivial but still hasn't made it into Debian. > > I think libgcrypt does not use printf with "%lu" but that may depend > on the version. Interesting! I believe I was able to reproduce the problem, now reported too: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561599 /Simon From wk at gnupg.org Sat Dec 19 13:57:06 2009 From: wk at gnupg.org (Werner Koch) Date: Sat, 19 Dec 2009 13:57:06 +0100 Subject: gcrypt windows build In-Reply-To: <87hbro487d.fsf@mocca.josefsson.org> References: <876386rpuo.fsf@vigenere.g10code.de> <87ws0lmi8w.fsf@mocca.josefsson.org> <87y6l0kdl7.fsf@mocca.josefsson.org> <87vdg4qtdo.fsf@vigenere.g10code.de> <87hbro487d.fsf@mocca.josefsson.org> Message-ID: <87skb7qfz1.fsf@vigenere.g10code.de> On Fri, 18 Dec 2009 16:23:34 +0100, Simon Josefsson wrote: > Interesting! I believe I was able to reproduce the problem, now > reported too: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561599 There is another bug report as weel. Hwoever I can't remember the number. FWIW, here is a little test program: #include main () { unsigned long foo = 42; char buf[50]; snprintf (buf, sizeof buf, "->%lu<-", 42); if (strcmp (buf, "->42<-")) { fputs ("snprintf is broken\n", stderr); return 1; } else { fputs ("snprintf is okay\n", stderr); } return 0; } Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Sat Dec 19 19:52:55 2009 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 19 Dec 2009 19:52:55 +0100 Subject: gcrypt windows build In-Reply-To: <87skb7qfz1.fsf@vigenere.g10code.de> (Werner Koch's message of "Sat, 19 Dec 2009 13:57:06 +0100") References: <876386rpuo.fsf@vigenere.g10code.de> <87ws0lmi8w.fsf@mocca.josefsson.org> <87y6l0kdl7.fsf@mocca.josefsson.org> <87vdg4qtdo.fsf@vigenere.g10code.de> <87hbro487d.fsf@mocca.josefsson.org> <87skb7qfz1.fsf@vigenere.g10code.de> Message-ID: <878wcyssmw.fsf@mocca.josefsson.org> Werner Koch writes: > On Fri, 18 Dec 2009 16:23:34 +0100, Simon Josefsson wrote: >> Interesting! I believe I was able to reproduce the problem, now >> reported too: >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561599 > > There is another bug report as weel. Hwoever I can't remember the > number. It is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452977 -- my bug was a duplicate of that one. > FWIW, here is a little test program: Looks like the same error. /Simon From sergi at calcurco.cat Sun Dec 27 22:01:48 2009 From: sergi at calcurco.cat (Sergi Blanch i =?iso-8859-1?q?Torn=E9?=) Date: Sun, 27 Dec 2009 22:01:48 +0100 Subject: ecc.c data structures Message-ID: <200912272201.49031.sergi@calcurco.cat> Hi, I have a design doubt following the "ECC in OpenPGP"[1] draft that I like to discuss. I like the current internal structs: 'ECC_secret_key' and 'ECC_public_key'. They have the elliptic curve (as 'elliptic_curve_t'), the public key (as 'mpi_point_t') and, if it's the case, the secret key (as 'gcry_mpi_t'). Not all the data from the draft can be stored in this structs as they are. The low level hash and symmetric algorithms ID has to be stored, but other information like the curve OID and the fingerprint also is need for KDF (Key Derivation Function) First of all, how can be better to be structured? Would I define something like ECC_param_t and put it in the 'ECC_{secret,public}_key' structs? Or can be more elegant to have this in the struct of the context mpi_ec_t? This params are only necessary for encrypt, and this may disturb in this proposed places. The second issue I have now is the fingerprint I mention. I don't know how can I have this information in side a libgcrypt module. The kdf algorithm uses this data, but from where this has to be written I don't know who to access it. By now this. More issues will come soon... Thanks. /Sergi. [1]: http://sites.google.com/site/brainhub/pgp From wk at gnupg.org Mon Dec 28 11:09:56 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Dec 2009 11:09:56 +0100 Subject: ecc.c data structures In-Reply-To: <200912272201.49031.sergi@calcurco.cat> References: <200912272201.49031.sergi@calcurco.cat> Message-ID: <874onbquiz.fsf@vigenere.g10code.de> On Sun, 27 Dec 2009 22:01:48 +0100, Sergi Blanch i Torn? wrote: > Not all the data from the draft can be stored in this structs as they are. The > low level hash and symmetric algorithms ID has to be stored, but other > information like the curve OID and the fingerprint also is need for KDF (Key > Derivation Function) With the draft you probably mean the OpenPGP ECC draft. This is not relevant for Libgcrypt. Libgcrypt has and should not have an idea of a concrete crypto protocol. What Libgcrypt provides are cryptographic building blocks and not protocol implementations. > The second issue I have now is the fingerprint I mention. I don't know how can > I have this information in side a libgcrypt module. The kdf algorithm uses Libgcrypt does not know what a fingerprint is. This is a GnuPG thing. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sergi at calcurco.cat Mon Dec 28 12:03:25 2009 From: sergi at calcurco.cat (Sergi Blanch i =?utf-8?q?Torn=C3=A9?=) Date: Mon, 28 Dec 2009 12:03:25 +0100 Subject: ecc.c data structures In-Reply-To: <874onbquiz.fsf@vigenere.g10code.de> References: <200912272201.49031.sergi@calcurco.cat> <874onbquiz.fsf@vigenere.g10code.de> Message-ID: <200912281203.26580.sergi@calcurco.cat> On Monday 28 December 2009 11:09:56 am Werner Koch wrote: > With the draft you probably mean the OpenPGP ECC draft. > > This is not relevant for Libgcrypt. Libgcrypt has and should not have > an idea of a concrete crypto protocol. What Libgcrypt provides are > cryptographic building blocks and not protocol implementations. yes, current draft http://tools.ietf.org/id/draft-jivsov-openpgp-ecc-04.txt The algorithm makes a hash using a key derivation function (KDF, section 7) using a counter, the x coordinate of the share point and a concatenation that includes the receiver fingerprint: Param = curve_OID_len || curve_OID || public_key_alg_ID || 01 || KDF_hash_ID || AES_alg_ID for AESKeyWrap || "AnonymousSender" || recipient_fingerprint I don't know how to find the last element of this concatenation. Sooner or later this KDF has to live out of the ecc module like the aeswrap does. /Sergi. From wk at gnupg.org Mon Dec 28 13:56:48 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Dec 2009 13:56:48 +0100 Subject: ecc.c data structures In-Reply-To: <200912281203.26580.sergi@calcurco.cat> References: <200912272201.49031.sergi@calcurco.cat> <874onbquiz.fsf@vigenere.g10code.de> <200912281203.26580.sergi@calcurco.cat> Message-ID: <871vifqmsv.fsf@vigenere.g10code.de> On Mon, 28 Dec 2009 12:03:25 +0100, Sergi Blanch i Torn? wrote: > Param = curve_OID_len || curve_OID || public_key_alg_ID || > 01 || KDF_hash_ID || AES_alg_ID for AESKeyWrap || > "AnonymousSender" || recipient_fingerprint > > I don't know how to find the last element of this concatenation. That is all in GnuPG. fingerprint_from_pk (). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sergi at calcurco.cat Mon Dec 28 14:13:47 2009 From: sergi at calcurco.cat (Sergi Blanch i =?utf-8?q?Torn=C3=A9?=) Date: Mon, 28 Dec 2009 14:13:47 +0100 Subject: ecc.c data structures In-Reply-To: <871vifqmsv.fsf@vigenere.g10code.de> References: <200912272201.49031.sergi@calcurco.cat> <200912281203.26580.sergi@calcurco.cat> <871vifqmsv.fsf@vigenere.g10code.de> Message-ID: <200912281413.48006.sergi@calcurco.cat> On Monday 28 December 2009 01:56:48 pm you wrote: > On Mon, 28 Dec 2009 12:03:25 +0100, Sergi Blanch i Torn? wrote: > > Param = curve_OID_len || curve_OID || public_key_alg_ID || > > 01 || KDF_hash_ID || AES_alg_ID for AESKeyWrap || > > "AnonymousSender" || recipient_fingerprint > > That is all in GnuPG. fingerprint_from_pk (). First idea that comes to my mean now is to use gnupg as a lib in the kdf (in the ecc module by now, wherever in the future), but this gives me a crossed dependency that can be an issue. GnuPG uses libgcrypt as crypto and mathematics library, isn't it? But I cannot see clearly that can be accepted in libgcrypt that it uses GnuPG as a lib. About the other question I made. What about the structs? Can be good to extend the mpi_ec_ctx_s with the data that is used in some places? or it's better to have a third struct specific for encrypt algorithm? /sergi. From kmagnum at gmail.com Mon Dec 28 16:00:11 2009 From: kmagnum at gmail.com (Karl Magdsick) Date: Mon, 28 Dec 2009 10:00:11 -0500 Subject: ecc.c data structures In-Reply-To: <200912281413.48006.sergi@calcurco.cat> References: <200912272201.49031.sergi@calcurco.cat> <200912281203.26580.sergi@calcurco.cat> <871vifqmsv.fsf@vigenere.g10code.de> <200912281413.48006.sergi@calcurco.cat> Message-ID: On Mon, Dec 28, 2009 at 8:13 AM, Sergi Blanch i Torn? wrote: > On Monday 28 December 2009 01:56:48 pm you wrote: > > On Mon, 28 Dec 2009 12:03:25 +0100, Sergi Blanch i Torn? wrote: > > > Param = curve_OID_len || curve_OID || public_key_alg_ID || > > > 01 || KDF_hash_ID || AES_alg_ID for AESKeyWrap || > > > "AnonymousSender" || recipient_fingerprint > > > > That is all in GnuPG. fingerprint_from_pk (). > > First idea that comes to my mean now is to use gnupg as a lib in the kdf > (in > the ecc module by now, wherever in the future), but this gives me a crossed > dependency that can be an issue. > Not having looked at the code in question, can't you just inject the dependency by having the libgcrypt function take a function pointer to a fingerprinting function as one of its arguments? This unfortunately means libgcrypt has to have some vague notion about the fingerprint, but perhaps the semantics can be kept sufficiently general to mitigate the ugliness of forcing a higher-level concept down into libgcypt. Cheers, -Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Dec 28 18:10:41 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Dec 2009 18:10:41 +0100 Subject: ecc.c data structures In-Reply-To: <200912281413.48006.sergi@calcurco.cat> References: <200912272201.49031.sergi@calcurco.cat> <200912281203.26580.sergi@calcurco.cat> <871vifqmsv.fsf@vigenere.g10code.de> <200912281413.48006.sergi@calcurco.cat> Message-ID: <87y6knowha.fsf@vigenere.g10code.de> On Mon, 28 Dec 2009 14:13:47 +0100, Sergi Blanch i Torn? wrote: > First idea that comes to my mean now is to use gnupg as a lib in the kdf (in > the ecc module by now, wherever in the future), but this gives me a crossed > dependency that can be an issue. My point is that the entire OpenPGP ECC stuff does not belong into Libgcrypt. The GnuPG specific code needs to be implemented in GnuPG, proper. Only the bare DH ECC code belongs into Libgcrypt. > GnuPG uses libgcrypt as crypto and mathematics library, isn't it? But I cannot > see clearly that can be accepted in libgcrypt that it uses GnuPG as a lib. Sorry, I can't parse this. > About the other question I made. What about the structs? Can be good to extend > the mpi_ec_ctx_s with the data that is used in some places? or it's better to > have a third struct specific for encrypt algorithm? Internal structures are internal structures and thus can be changed as needed. I have not looked at the details, though. However, a fingerprint does not belong into Libgcrypt because it is protocol specific. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From marco.maggi-ipsu at poste.it Wed Dec 30 10:41:04 2009 From: marco.maggi-ipsu at poste.it (Marco Maggi) Date: Wed, 30 Dec 2009 10:41:04 +0100 Subject: gcry_pk_algo_info usage? Message-ID: <87iqboiytr.fsf@rapitore.luna> Ciao, I think the documentation of gcry_pk_algo_info is messed up in release 1.4.5; I may be confused, but reading the source code looks like there is no implementation at all: gcry_error_t gcry_pk_algo_info (int algo, int what, void *buffer, size_t *nbytes) { if (!fips_is_operational ()) return gpg_error (fips_not_operational ()); return _gcry_pk_algo_info (algo, what, buffer, nbytes); } #define gcry_pk_algo_info _gcry_pk_algo_info Can someone modify the following program so that it prints something meaningful (anything will do)? #include #include #include int main (int argc, const char *const argv[]) { /* gcry_control(GCRYCTL_FORCE_FIPS_MODE, 0); */ gcry_check_version(GCRYPT_VERSION); printf("%d\n", gcry_pk_algo_info(GCRY_AC_RSA, GCRYCTL_TEST_ALGO, NULL, NULL)); exit(EXIT_SUCCESS); } TIA P.S. It seems there are no archives for this list, so I cannot find if I (or someone) already asked for this a couple of ages ago (it may be, though). :-/ -- Marco Maggi From ametzler at downhill.at.eu.org Wed Dec 30 11:29:12 2009 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Wed, 30 Dec 2009 11:29:12 +0100 Subject: gcry_pk_algo_info usage? References: <87iqboiytr.fsf@rapitore.luna> Message-ID: Marco Maggi wrote: [...] > P.S. It seems there are no archives for this list, so I > cannot find if I (or someone) already asked for this a > couple of ages ago (it may be, though). :-/ http://news.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel 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' From marco.maggi-ipsu at poste.it Wed Dec 30 20:22:26 2009 From: marco.maggi-ipsu at poste.it (Marco Maggi) Date: Wed, 30 Dec 2009 20:22:26 +0100 Subject: gcry_pk_algo_info usage? References: <87iqboiytr.fsf@rapitore.luna> Message-ID: <87aax0i7wt.fsf@rapitore.luna> I have written: > I think the documentation of gcry_pk_algo_info is messed > up in release 1.4.5; I may be confused, but reading the > source code looks like there is no implementation at all: Found the implementation in "cipher/pubkey.c". :-/ -- Marco Maggi From wk at gnupg.org Thu Dec 31 16:03:06 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 Dec 2009 16:03:06 +0100 Subject: gcry_pk_algo_info usage? In-Reply-To: References: <87iqboiytr.fsf@rapitore.luna> Message-ID: <87tyv7p4np.fsf@vigenere.g10code.de> > http://news.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel And of course here: http://lists.gnupg.org/pipermail/gcrypt-devel/ -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.