From bradh at frogmouth.net Sat Feb 18 02:11:24 2006 From: bradh at frogmouth.net (Brad Hards) Date: Sat Feb 18 02:13:58 2006 Subject: Query on test/basic.c::check_pubkey() Message-ID: <200602181211.29748.bradh@frogmouth.net> In the tests, basic.c has a number of routines, including one that does some checks on public keys. The code (around line 1090 in a current svn checkout) looks like this: for (i = 0; i < sizeof (pubkeys) / sizeof (*pubkeys); i++) if (pubkeys[i].id) check_one_pubkey (i, pubkeys[i]); check_one_pubkey_new (i); Is that what is really intended? That is, is check_one_pubkey_new() only supposed to check the last of pubkeys? Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060218/f581aea4/attachment.pgp From bradh at frogmouth.net Sat Feb 18 03:49:18 2006 From: bradh at frogmouth.net (Brad Hards) Date: Sat Feb 18 05:04:35 2006 Subject: Two key triple DES? In-Reply-To: <87fynpsb8s.fsf@wheatstone.g10code.de> References: <200601141525.12589.bradh@frogmouth.net> <87fynpsb8s.fsf@wheatstone.g10code.de> Message-ID: <200602181349.23385.bradh@frogmouth.net> On Monday 16 January 2006 03:32 am, Werner Koch wrote: > On Sat, 14 Jan 2006 15:25:06 +1100, Brad Hards said: > > Is there an easier way to do two key triple DES in gcrypt than just > > manually duplicating the first key? > > Sorry, no. Do you think it is still important? I know that banking > systems are still using it. [Not sure if I ever answered this, sorry for the delay] It probably isn't that critical, given that it is easy to work around. Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060218/6c7d2f4c/attachment.pgp From bradh at frogmouth.net Sat Feb 18 12:15:13 2006 From: bradh at frogmouth.net (Brad Hards) Date: Sat Feb 18 12:17:59 2006 Subject: [patch] Additional HMAC unit tests Message-ID: <200602182215.20665.bradh@frogmouth.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060218/d810f778/attachment-0001.pgp From eiband at in.tum.de Sun Feb 19 15:47:12 2006 From: eiband at in.tum.de (Daniel Eiband) Date: Sun Feb 19 17:47:58 2006 Subject: cross-compiling to mipsel Message-ID: <43F884F0.3070201@in.tum.de> I hope this mailing list is suitable, because it might be that my probem is due to a libtool bug. I try to cross-compile libgcrypt for a mipsel host in a buildroot like environment. It works fine, except on machines with a host version of libgpg-error installed in /usr/lib/ (libgpg-error was configured with --prefix=/usr, but installed into the $(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib). My configure looks like this: PATH=$(TARGET_TOOLCHAIN_PATH) \ CFLAGS="$(TARGET_CFLAGS)" \ CPPFLAGS="-I$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/include" \ LDFLAGS="-L$(TARGET_TOOLCHAIN_STAGING_DIR)/lib -L$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib" \ ./configure \ --target=$(GNU_TARGET_NAME) \ --host=$(GNU_TARGET_NAME) \ --build=$(GNU_HOST_NAME) \ --program-prefix="" \ --program-suffix="" \ --prefix=/usr \ --sysconfdir=/etc \ --disable-nls \ --disable-largefile \ --enable-shared \ --enable-static \ --disable-rpath \ --disable-asm \ --with-gpg-error-prefix="$(TARGET_TOOLCHAIN_STAGING_DIR)/usr" If there is libgpg-error installed on the build machine, make stops while linking: /bin/sh ../libtool --tag=CC --mode=link mipsel-linux-gcc -Os -W -Wall -pipe -march=4kc -Wa,--trap -Wall -L/var/tmp/ds-0.2/toolchain/gcc-4.0.1-uClibc-0.9.26/mipsel-linux-uclibc/lib -L/var/tmp/ds-0.2/toolchain/gcc-4.0.1-uClibc-0.9.26/mipsel-linux-uclibc/usr/lib -o libgcrypt.la -rpath /usr/lib -Wl,--version-script=./libgcrypt.vers -version-info 13:1:2 libgcrypt_la-misc.lo libgcrypt_la-global.lo libgcrypt_la-sexp.lo libgcrypt_la-stdmem.lo libgcrypt_la-secmem.lo libgcrypt_la-missing-string.lo libgcrypt_la-module.lo libgcrypt_la-ath.lo ../cipher/libcipher.la ../mpi/libmpi.la -lgpg-error -lnsl -lnsl mipsel-linux-gcc -shared .libs/libgcrypt_la-misc.o .libs/libgcrypt_la-global.o .libs/libgcrypt_la-sexp.o .libs/libgcrypt_la-stdmem.o .libs/libgcrypt_la-secmem.o .libs/libgcrypt_la-missing-string.o .libs/libgcrypt_la-module.o .libs/libgcrypt_la-ath.o -Wl,--whole-archive ../cipher/.libs/libcipher.a ../mpi/.libs/libmpi.a -Wl,--no-whole-archive -L/var/tmp/ds-0.2/toolchain/gcc-4.0.1-uClibc-0.9.26/mipsel-linux-uclibc/lib -L/var/tmp/ds-0.2/toolchain/gcc-4.0.1-uClibc-0.9.26/mipsel-linux-uclibc/usr/lib /usr/lib/libgpg-error.so -lnsl -march=4kc -Wl,--version-script=./libgcrypt.vers -Wl,-soname -Wl,libgcrypt.so.11 -o .libs/libgcrypt.so.11.2.1 /usr/lib/libgpg-error.so: could not read symbols: File in wrong format Of course /usr/lib/libgpg-error.so is in wrong format. Is there a way to tell libtool not to use host libraries when cross-compiling? Is this a common libtool issue or a particular libgcrypt problem? Regards, Daniel From gcrypt at dstoecker.de Thu Feb 23 18:08:12 2006 From: gcrypt at dstoecker.de (Dirk Stoecker) Date: Thu Feb 23 18:07:34 2006 Subject: cross-compiling to mipsel In-Reply-To: <43F884F0.3070201@in.tum.de> References: <43F884F0.3070201@in.tum.de> Message-ID: On Sun, 19 Feb 2006, Daniel Eiband wrote: > I hope this mailing list is suitable, because it might be that my probem is > due to a libtool bug. > > I try to cross-compile libgcrypt for a mipsel host in a buildroot like > environment. It works fine, except on machines with a host version of > libgpg-error installed in /usr/lib/ (libgpg-error was configured with > --prefix=/usr, but installed into the > $(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib). > > My configure looks like this: > > PATH=$(TARGET_TOOLCHAIN_PATH) \ > CFLAGS="$(TARGET_CFLAGS)" \ > CPPFLAGS="-I$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/include" \ > LDFLAGS="-L$(TARGET_TOOLCHAIN_STAGING_DIR)/lib > -L$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib" \ > ./configure \ > --target=$(GNU_TARGET_NAME) \ > --host=$(GNU_TARGET_NAME) \ > --build=$(GNU_HOST_NAME) \ > --program-prefix="" \ > --program-suffix="" \ > --prefix=/usr \ > --sysconfdir=/etc \ > --disable-nls \ > --disable-largefile \ > --enable-shared \ > --enable-static \ > --disable-rpath \ > --disable-asm \ > --with-gpg-error-prefix="$(TARGET_TOOLCHAIN_STAGING_DIR)/usr" I had an equal problem. The --with-gpg-error-prefix seems not to work as expected. I used following method after looking in the configure file (assuming libgpg-error is a subdirectory in current dir): export GPG_ERROR_CONFIG=`pwd`/libgpg-error/src/gpg-error-config export CPPFLAGS=-I`pwd` export LDFLAGS=-L`pwd` ln -sf libgpg-error/src/.libs/libgpg-error.a . ln -sf libgpg-error/src/gpg-error.h . In current dir (`pwd`) now are the links to the .a file and the .h file of gpg-error, thats why the include paths point to this. ./configure --with-gpg-error-prefix=dummy ... ... export -n GPG_ERROR_CONFIG export -n CPPFLAGS export -n LDFLAGS I hope I stripped the relevant parts from my script, so you can follow the idea. Ciao -- http://www.dstoecker.de/ (PGP key available) From eiband at in.tum.de Thu Feb 23 19:42:16 2006 From: eiband at in.tum.de (Daniel Eiband) Date: Thu Feb 23 19:41:33 2006 Subject: cross-compiling to mipsel In-Reply-To: References: <43F884F0.3070201@in.tum.de> Message-ID: <200602231942.16527.eiband@in.tum.de> Am Donnerstag 23 Februar 2006 18:08 schrieben Sie: > I had an equal problem. The --with-gpg-error-prefix seems not to work as > expected. I used following method after looking in the configure file > (assuming libgpg-error is a subdirectory in current dir): > > export GPG_ERROR_CONFIG=`pwd`/libgpg-error/src/gpg-error-config > export CPPFLAGS=-I`pwd` > export LDFLAGS=-L`pwd` > ln -sf libgpg-error/src/.libs/libgpg-error.a . > ln -sf libgpg-error/src/gpg-error.h . > > In current dir (`pwd`) now are the links to the .a file and the .h file of > gpg-error, thats why the include paths point to this. > > ./configure --with-gpg-error-prefix=dummy ... --with-gpg-error-prefix is the prefix where you installed gpg-error. It seams like you didn't install it at all. Besides, this is not my problem. Nevertheless, thanks for your reply. Regards, Daniel From gcrypt at dstoecker.de Fri Feb 24 09:09:38 2006 From: gcrypt at dstoecker.de (Dirk Stoecker) Date: Fri Feb 24 09:09:05 2006 Subject: cross-compiling to mipsel In-Reply-To: <200602231942.16527.eiband@in.tum.de> References: <43F884F0.3070201@in.tum.de> <200602231942.16527.eiband@in.tum.de> Message-ID: On Thu, 23 Feb 2006, Daniel Eiband wrote: > Am Donnerstag 23 Februar 2006 18:08 schrieben Sie: > > I had an equal problem. The --with-gpg-error-prefix seems not to work as > > expected. I used following method after looking in the configure file > > (assuming libgpg-error is a subdirectory in current dir): > > > > export GPG_ERROR_CONFIG=`pwd`/libgpg-error/src/gpg-error-config > > export CPPFLAGS=-I`pwd` > > export LDFLAGS=-L`pwd` > > ln -sf libgpg-error/src/.libs/libgpg-error.a . > > ln -sf libgpg-error/src/gpg-error.h . > > > > In current dir (`pwd`) now are the links to the .a file and the .h file of > > gpg-error, thats why the include paths point to this. > > > > ./configure --with-gpg-error-prefix=dummy ... > > --with-gpg-error-prefix is the prefix where you installed gpg-error. It seams It probably should be, but it is not. Read the autogenerated ./configure file to understand why I use the environment variable and set --with-gpg-error-prefix to dummy. It took me some time to understand, why --with-gpg-error-prefix did not work as expected and how to work around. > like you didn't install it at all. Besides, this is not my problem. Excactly. I did not INSTALL it, but compiled a local copy of gpg-error. This is usually what you need for cross compiling also (at least in static mode). In dynamic mode you need to do some path magic to get it to work on you destination system as well. Ciao -- http://www.dstoecker.de/ (PGP key available) From eiband at in.tum.de Fri Feb 24 10:59:39 2006 From: eiband at in.tum.de (Daniel Eiband) Date: Fri Feb 24 10:59:07 2006 Subject: cross-compiling to mipsel In-Reply-To: References: <43F884F0.3070201@in.tum.de> <200602231942.16527.eiband@in.tum.de> Message-ID: <200602241059.39934.eiband@in.tum.de> Am Freitag, 24. Februar 2006 09:09 schrieb Dirk Stoecker: > On Thu, 23 Feb 2006, Daniel Eiband wrote: > > Am Donnerstag 23 Februar 2006 18:08 schrieben Sie: > > > export GPG_ERROR_CONFIG=`pwd`/libgpg-error/src/gpg-error-config > > > export CPPFLAGS=-I`pwd` > > > export LDFLAGS=-L`pwd` > > > ln -sf libgpg-error/src/.libs/libgpg-error.a . > > > ln -sf libgpg-error/src/gpg-error.h . > > > > > > In current dir (`pwd`) now are the links to the .a file and the .h file > > > of gpg-error, thats why the include paths point to this. > > > > > > ./configure --with-gpg-error-prefix=dummy ... > > > > --with-gpg-error-prefix is the prefix where you installed gpg-error. It > > seams > > It probably should be, but it is not. Read the autogenerated ./configure > file to understand why I use the environment variable and set > --with-gpg-error-prefix to dummy. It took me some time to understand, why > --with-gpg-error-prefix did not work as expected and how to work around. I think it works as expected. You are lucky that you only have one header in this case. Otherwise these symlinks would be really annoying. > > like you didn't install it at all. Besides, this is not my problem. > > Excactly. I did not INSTALL it, but compiled a local copy of gpg-error. > This is usually what you need for cross compiling also (at least in static > mode). In dynamic mode you need to do some path magic to get it to work on > you destination system as well. That's why I compile it with the prefix /usr and install it with the prefix $(STAGING_DIR)/usr. Why working around and fixing some behaviour which ./configure is not supposed to do? make install does it for you, just use another prefix while installing. Back to my original problem: If i insert "|| true" here in the libtool done if test "$found" != yes || true; then # deplib doesn't seem to be a libtool library it works just fine, because then -lgpg-error is not substituted by /usr/lib/gpg-error.so. There is another patch from the OpenWRT buildroot necessary to compile the tests: diff -ruN libgcrypt-1.2.1-orig/tests/Makefile.am libgcrypt-1.2.1-1/tests/Makefile.am --- libgcrypt-1.2.1-orig/tests/Makefile.am 2004-03-03 09:08:05.000000000 +0100 +++ libgcrypt-1.2.1-1/tests/Makefile.am 2005-03-15 21:36:49.000000000 +0100 @@ -21,7 +21,7 @@ TESTS = prime register ac basic tsexp keygen pubkey benchmark INCLUDES = -I$(top_srcdir)/src -LDADD = ../src/libgcrypt.la +LDADD = ../src/libgcrypt.la @LTLIBOBJS@ @GPG_ERROR_LIBS@ EXTRA_PROGRAMS = testapi noinst_PROGRAMS = $(TESTS) diff -ruN libgcrypt-1.2.1-orig/tests/Makefile.in libgcrypt-1.2.1-1/tests/Makefile.in --- libgcrypt-1.2.1-orig/tests/Makefile.in 2005-01-05 14:53:23.000000000 +0100 +++ libgcrypt-1.2.1-1/tests/Makefile.in 2005-03-15 21:37:12.000000000 +0100 @@ -258,7 +258,7 @@ target_vendor = @target_vendor@ TESTS = prime register ac basic tsexp keygen pubkey benchmark INCLUDES = -I$(top_srcdir)/src -LDADD = ../src/libgcrypt.la +LDADD = ../src/libgcrypt.la @LTLIBOBJS@ @GPG_ERROR_LIBS@ AM_CFLAGS = @GPG_ERROR_CFLAGS@ all: all-am Regards, Daniel From frederic.roudaut at irisa.fr Fri Feb 24 17:21:53 2006 From: frederic.roudaut at irisa.fr (Frederic Roudaut) Date: Mon Feb 27 10:52:03 2006 Subject: AES-XCBC-MAC-96 [RFC3566] Message-ID: <43FF32A1.3020206@irisa.fr> Hi, is there a way to compute a MAC based on AES-XCBC-MAC-96 [RFC3566] using libgcrypt ? Perhaps I could use AES-CBC-MAC with just a few modification but I am a little confuse about the real differences. Any help will be greatly apppreciated. Best regards, -- Fr?d?ric ROUDAUT IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France Tl: +33 (0) 2 99 84 71 44, Fax: +33 (0) 2 99 84 71 71