From gcrypt at dstoecker.de Fri Sep 1 08:37:51 2006 From: gcrypt at dstoecker.de (Dirk Stoecker) Date: Fri Sep 1 08:36:25 2006 Subject: Cleanup patch In-Reply-To: <878xl644nc.fsf@wheatstone.g10code.de> References: <878xl644nc.fsf@wheatstone.g10code.de> Message-ID: On Wed, 30 Aug 2006, Werner Koch wrote: > > Well, I ask myself why I did that work when I'm totally ignored again. > > I have not come around to reply. My reply would anyay be the usual: After a month? In this really high-traffic mailinglist? > We need legal papers for such patches. It might or might not be a Quoting from the mail I send the patch with: : The patches are fully public domain with no legal restrictions of any : form. > trivial patch but all together it would lead to extra work to check > whether this and possible future patches are trivial. Thus I can't > accept them. You wont get any future patches from me. > I will also need to check the patch which is time consuming. Well, finding the bugs and quirks yourself is not? So my internal patch file will grow with every update of libgcrypt (e.g. implementing SEED added new build errors) and libgcrypt will keep its bugs. Ciao -- http://www.dstoecker.de/ (PGP key available) From wk at gnupg.org Sun Sep 3 20:12:38 2006 From: wk at gnupg.org (Werner Koch) Date: Sun Sep 3 20:16:29 2006 Subject: Cleanup patch In-Reply-To: (Dirk Stoecker's message of "Fri, 1 Sep 2006 08:37:51 +0200 (CEST)") References: <878xl644nc.fsf@wheatstone.g10code.de> Message-ID: <8764g4n7jd.fsf@wheatstone.g10code.de> On Fri, 1 Sep 2006 08:37, Dirk Stoecker said: > Quoting from the mail I send the patch with: > : The patches are fully public domain with no legal restrictions of any > : form. I have said this more timse than I am willing to count. We need legal papers, really. See: http://www.gnu.org/copyleft/why-assign.html . > Well, finding the bugs and quirks yourself is not? So my > internal patch file will grow with every update of libgcrypt (e.g. I you don't want to sign a CA it is best to report the problems instead of lettung us come up with our own fix. And well, stuff like +#ifdef HAVE_CONFIG_H #include +#endif is not very helpful. config.h is not an optional file in Libgcrypt. Further it makes it very hard to figure things we should really fix, like the trailing comman in an enum which is only allowed by c99. Salam-Shalom, Werner p.s. Some times I even look into mails on Sundays ;-) From ekarttun at cs.helsinki.fi Tue Sep 12 16:44:31 2006 From: ekarttun at cs.helsinki.fi (Einar Karttunen) Date: Tue Sep 12 17:55:31 2006 Subject: gcry_pk_decrypt and leading zeros in the decrypted output Message-ID: <20060912144430.GA14685@localdomain> Hello gcry_pk_decrypt creates an s-exp of the decryption result. If passed something like "(enc-val(flags)(rsa (a%m)))" it returns "(value plaintext)". Now if the data is encoded as EME-PKCS1-v1_5 it has a leading zero byte. Libgcrypt seems to want to delete that when I use gcry_sexp_nth_data (and also with gcry_sexp_nth_mpi). It seems very unsafe to assume that there was a leading zero byte that got deleted by libgcrypt as many programs using libgcrypt seem to do. What is the correct way to get the value from the decryption result sexp while preserving any possible leading zero bytes? - Einar Karttunen From wk at gnupg.org Wed Sep 13 11:53:41 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Sep 13 11:56:34 2006 Subject: gcry_pk_decrypt and leading zeros in the decrypted output In-Reply-To: <20060912144430.GA14685@localdomain> (Einar Karttunen's message of "Tue, 12 Sep 2006 17:44:31 +0300") References: <20060912144430.GA14685@localdomain> Message-ID: <871wqgytwa.fsf@wheatstone.g10code.de> On Tue, 12 Sep 2006 16:44, Einar Karttunen said: > a leading zero byte. Libgcrypt seems to want to delete that > when I use gcry_sexp_nth_data (and also with gcry_sexp_nth_mpi). Internally these are all MPIs. Thus it makes no difference what function you use to retrieve it. > It seems very unsafe to assume that there was a leading zero > byte that got deleted by libgcrypt as many programs using Why do you think it is unsafe? Leading zeroes of numbers are meanigless in computations. When computing m = c^d mod n there won't be a leading zero. We need to invent it. The reason pkcs#1 requires the leading zero is to state that this is a non-negative number and less than n. > What is the correct way to get the value from the decryption result > sexp while preserving any possible leading zero bytes? You don't need the leading zero. Take a normalized MPI and check that it is not negative (the latter is always true for our rsa implementation). Salam-Shalom, Werner From jas at extundo.com Thu Sep 14 18:28:25 2006 From: jas at extundo.com (Simon Josefsson) Date: Thu Sep 14 19:51:44 2006 Subject: Build problems in libgpg-error 1.4 Message-ID: <87venqwgye.fsf@latte.josefsson.org> Hi! Cross-compiling libgpg-error using mingw fails: make[2]: Entering directory `/home/jas/libgpg-error-1.4/tests' ... if i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -g -O2 -MT t-syserror.o -MD -MP -MF ".deps/t-syserror.Tpo" -c -o t-syserror.o t-syserror.c; \ then mv -f ".deps/t-syserror.Tpo" ".deps/t-syserror.Po"; else rm -f ".deps/t-syserror.Tpo"; exit 1; fi /bin/sh ../libtool --tag=CC --mode=link i586-mingw32msvc-gcc -g -O2 -o t-syserror.exe t-syserror.o ../src/libgpg-error.la i586-mingw32msvc-gcc -g -O2 -o .libs/t-syserror.exe t-syserror.o ../src/.libs/libgpg-error.dll.a -Wl,--rpath -Wl,/usr/local/libt-syserror.o: In function `main':/home/jas/libgpg-error-1.4/tests/t-syserror.c:54: undefined reference to `_gpg_err_code_from_syserror' :/home/jas/libgpg-error-1.4/tests/t-syserror.c:69: undefined reference to `_gpg_err_code_from_syserror' collect2: ld returned 1 exit status make[2]: *** [t-syserror.exe] Error 1 make[2]: Leaving directory `/home/jas/libgpg-error-1.4/tests' The problem appear to be a missing export, adding: gpg_err_code_from_syserror @7 to src/gpg-error.def make it work again. Thanks, Simon From wk at gnupg.org Mon Sep 18 19:13:30 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Sep 18 19:16:34 2006 Subject: Build problems in libgpg-error 1.4 In-Reply-To: <87venqwgye.fsf@latte.josefsson.org> (Simon Josefsson's message of "Thu, 14 Sep 2006 18:28:25 +0200") References: <87venqwgye.fsf@latte.josefsson.org> Message-ID: <873bapcd39.fsf@wheatstone.g10code.de> On Thu, 14 Sep 2006 18:28, Simon Josefsson said: > The problem appear to be a missing export, adding: > > gpg_err_code_from_syserror @7 > > to src/gpg-error.def make it work again. Thanks. Time to think about extending make distcheck to include the pretty common w32 case. Shalom-Salam, Werner From spizamme at hotmail.com Tue Sep 19 04:35:26 2006 From: spizamme at hotmail.com (jitspoe) Date: Sun Oct 1 16:27:41 2006 Subject: RSA Key Gen: Fast in Test App, Slow in Real App. Message-ID: <6380989.post@talk.nabble.com> I made a test app to test RSA key generation and whatnot using gcrypt directly. Generating a 128bit key pair is almost instant in the test app. It takes less than a second. When I try using it in my real application (a game), however, it takes several seconds to generate the key. The libraries and function calls are identical. Any idea what the causes for the speed differences are? I'm using Visual Studio 7.0 on Windows XP. I'm not using secure memory or multithreading. -- View this message in context: http://www.nabble.com/RSA-Key-Gen%3A-Fast-in-Test-App%2C-Slow-in-Real-App.-tf2296684.html#a6380989 Sent from the GnuPG - Libgcrypt - Dev mailing list archive at Nabble.com.