From wk at gnupg.org Fri Aug 4 11:40:36 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Aug 4 11:46:39 2006 Subject: bug in gcrypt's bit manipulation routines In-Reply-To: <20060731163314.GA7608@bacardi.dt115.lan> (bpgcrypt@itaparica.org's message of "Mon, 31 Jul 2006 18:33:14 +0200") References: <20060731163314.GA7608@bacardi.dt115.lan> Message-ID: <87mzakn8iz.fsf@wheatstone.g10code.de> On Mon, 31 Jul 2006 18:33, bpgcrypt@itaparica.org said: > 1. The function gcry_mpi_set_bit ommits the (re-)allocation of enough > memory to store an MPI of the needed size. The following code snippet > demonstrates this: Thanks. I fixed it in the development version. Will be ported to stable later. > 2. The routine gcry_mpi_rshift always interpretes the "shift value" N > as (N % 32). This behaviour is commented (a little bit) in > libgcrypt-1.2.2/mpi/generic/mpih-rshift.c > > * Argument constraints: > * 1. 0 < CNT < BITS_PER_MP_LIMB Changed. You may now use any value of N. > 3. HMAC-SHA256 calculation via > > gcry_md_open(&mh, GCRY_MD_SHA256, GCRY_MD_FLAG_HMAC); > > aborts with some "no secure memory allocated" message. This can be > fixed by explicitely doing a > > gcry_control(GCRYCTL_INIT_SECMEM, 1); or if you don't need secure memory: gcry_control (GCRYCTL_DISABLE_SECMEM, 0); The we require this is that a MAC uses a key and that key should be called in the so-called secure memory. I'll add a note to the docs. Salam-Shalom, Werner From bpgcrypt at itaparica.org Sun Aug 6 23:38:32 2006 From: bpgcrypt at itaparica.org (bpgcrypt@itaparica.org) Date: Sun Aug 6 23:37:05 2006 Subject: HMAC and RIJNDAEL192, was: bugs in bit manipulation routines In-Reply-To: <87mzakn8iz.fsf@wheatstone.g10code.de> References: <20060731163314.GA7608@bacardi.dt115.lan> <87mzakn8iz.fsf@wheatstone.g10code.de> Message-ID: <20060806213832.GA5611@bacardi.dt115.lan> On Fri, Aug 04, 2006 at 11:40:36AM +0200, Werner Koch wrote: > On Mon, 31 Jul 2006 18:33, bpgcrypt@itaparica.org said: > > > 3. HMAC-SHA256 calculation via > > > > gcry_md_open(&mh, GCRY_MD_SHA256, GCRY_MD_FLAG_HMAC); > > > > aborts with some "no secure memory allocated" message. This can be > > fixed by explicitely doing a > > > > gcry_control(GCRYCTL_INIT_SECMEM, 1); > > or if you don't need secure memory: > > gcry_control (GCRYCTL_DISABLE_SECMEM, 0); > > The we require this is that a MAC uses a key and that key should be > called in the so-called secure memory. No doubt: securing the HMAC key is a wise idea. But I think it should be unnecessary to call gcry_control() if one is going to ommit the GCRY_MD_FLAG_SECURE flag anyway when initializing the hash function. When reading in my /usr/include/gcrypt.h I found the following: /* The Rijndael algorithm is basically AES, so provide some macros. */ #define GCRY_CIPHER_AES128 GCRY_CIPHER_AES #define GCRY_CIPHER_RIJNDAEL GCRY_CIPHER_AES #define GCRY_CIPHER_RIJNDAEL128 GCRY_CIPHER_AES128 #define GCRY_CIPHER_RIJNDAEL192 GCRY_CIPHER_AES192 #define GCRY_CIPHER_RIJNDAEL256 GCRY_CIPHER_AES256 AES is a block cipher with fixed 128 bit block length and non-fixed key length. RIJNDAEL on the other hand is a block cipher with "any" block length from 128 to 256. In the literature the identifier RIJNDAEL192 usually denotes the RIJNDAEL cipher with 192 bit block length. With the macros above RIJNDAEL192 denotes the cipher with 128 bit block length and 192 bit key. This is confusing and possibly hazardous. I suggest to drop all of the macros except the third one. bp From wk at gnupg.org Mon Aug 7 10:15:05 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 7 10:16:41 2006 Subject: HMAC and RIJNDAEL192, was: bugs in bit manipulation routines In-Reply-To: <20060806213832.GA5611@bacardi.dt115.lan> (bpgcrypt@itaparica.org's message of "Sun, 6 Aug 2006 23:38:32 +0200") References: <20060731163314.GA7608@bacardi.dt115.lan> <87mzakn8iz.fsf@wheatstone.g10code.de> <20060806213832.GA5611@bacardi.dt115.lan> Message-ID: <871wrthshi.fsf@wheatstone.g10code.de> On Sun, 6 Aug 2006 23:38, bpgcrypt@itaparica.org said: > No doubt: securing the HMAC key is a wise idea. But I think it should be > unnecessary to call gcry_control() if one is going to ommit the > GCRY_MD_FLAG_SECURE flag anyway when initializing the hash function. the md_flag_secure puts all internal buffers into secure emeory. This is for example required if you are going to hmac private key material. Storing the hmac key into secure memory is a design issue with no way to change it except for dropping all secure memeory. > AES is a block cipher with fixed 128 bit block length and non-fixed > key length. RIJNDAEL on the other hand is a block cipher with "any" > block length from 128 to 256. In the literature the identifier I recall from the second AES conference that it was presented in the way it is used in libgcrypt. Can't find the proceedngs right now. Anyway ... > length and 192 bit key. This is confusing and possibly hazardous. I > suggest to drop all of the macros except the third one. ... this would be an API change and thus we can't do it. Shalom-Salam, Werner From Frediano.Ziglio at vodafone.com Mon Aug 7 10:38:02 2006 From: Frediano.Ziglio at vodafone.com (ZIGLIO, Frediano, VF-IT) Date: Mon Aug 7 11:55:44 2006 Subject: constification patch Message-ID: Hi, I wrote a similar patch for the same issue some time ago but it seems lost. Perhaps it was too intrusive so I decide to restart again and send the small and very easy changes first. Here you are the patch. The old one include constification for all cipher/md/pubkey lists too. Frediano Ziglio -------------- next part -------------- A non-text attachment was scrubbed... Name: vedi.diff Type: application/octet-stream Size: 16112 bytes Desc: vedi.diff Url : /pipermail/attachments/20060807/a2afcdd1/vedi-0001.obj From gcrypt at dstoecker.de Wed Aug 9 15:18:01 2006 From: gcrypt at dstoecker.de (Dirk Stoecker) Date: Wed Aug 9 16:42:20 2006 Subject: Cleanup patch Message-ID: Hello, I attached a larger cleanup patch for libgcrypt SVN: It contains: - usage of HAVE_CONFIG_H define - Naming of unnamed data field in gcrypt.h to io. --> This is a leftover from older days and not supported by all modern compilers. --> For some compilers this will break source code compatibility in case this field is used (Seems to be very very seldom). Most compilers should only issue a warning. Adding some defines will fix the error, but I would not recommend doing so. - Fixed some build and path problems - Added some free() functions, where they were missing. All these are only cleanups to fix leaks or compiling stage (mainly for Windows outside of Cygwin). The patches are fully public domain with no legal restrictions of any form. Ciao -- http://www.dstoecker.de/ (PGP key available) -------------- next part -------------- A non-text attachment was scrubbed... Name: cleanup.patch Type: text/x-patch Size: 37010 bytes Desc: Url : /pipermail/attachments/20060809/5e73935f/cleanup-0001.bin From cmouse at desteem.org Thu Aug 10 15:18:06 2006 From: cmouse at desteem.org (Aki Tuomi) Date: Thu Aug 10 16:25:41 2006 Subject: Problem with libcrypt API Message-ID: <20060810131806.GC22103@pi.ip.fi> I am making an application that would depend on gcrypt, but I cannot get beyond initial testing phase due cryptic error message "operation is not possible without initialized secure memory" There is nothing in the manual page on how one should get rid of this message. Tested as non-root and as root user. Any instructions, links, references, whatever will be greatly appreciated. Magical version numbers: gcrypt: 1.2.1 gpg-error: 0.7 gcc: 3.4.1 ld: 2.15.92.0.2 20040927 libc: GNU libc 2.3.4 Following source code was used: main.c: -------- #include "config.h" #include #include "gcrypt.h" #define GCRY_CHECK_ERR(func)\ { \ gcry_error_t err; \ err = 0; \ if (( err = func )) { \ eics4_gcry_fail(err); \ } \ } void eics4_gcry_fail (gcry_error_t err) { fprintf (stderr, "Error: %s/%s\n", gcry_strsource (err), gcry_strerror (err)); exit (1); } int main (void) { gcry_ac_handle_t handle; gcry_ac_key_pair_t keypair; gcry_ac_key_spec_rsa_t dsa_spec; gcry_mpi_t *misc_data; gcry_check_version ("1.2.1"); misc_data = NULL; GCRY_CHECK_ERR (gcry_ac_open (&handle, GCRY_AC_DSA, 0)); GCRY_CHECK_ERR (gcry_ac_key_pair_generate (handle, 1024, NULL, &keypair, &misc_data)); return 0; } -------- Following incantation to compile it to binary gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../intl -I../include -DLOCALEDIR=\"/usr/share/locale\" -g -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.c gcc -g -o eics main.o /usr/lib/libgcrypt.so -lnsl /usr/lib/libgpg-error.so If you wonder why there are so many flags... they are caused by GNU automake/libtool system. Aki Tuomi ----- End forwarded message ----- From wk at gnupg.org Thu Aug 10 17:43:28 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 10 17:46:25 2006 Subject: Problem with libcrypt API In-Reply-To: <20060810131806.GC22103@pi.ip.fi> (Aki Tuomi's message of "Thu, 10 Aug 2006 16:18:06 +0300") References: <20060810131806.GC22103@pi.ip.fi> Message-ID: <87r6zo61gf.fsf@wheatstone.g10code.de> On Thu, 10 Aug 2006 15:18, Aki Tuomi said: > Any instructions, links, references, whatever will be greatly > appreciated. Seems we need to answer this in the manual. The following code should do the trick. if (!gcry_check_version (NEED_LIBGCRYPT_VERSION) ) die ("libgcrypt is too old (need %s, have %s)\n", NEED_LIBGCRYPT_VERSION, gcry_check_version (NULL) ); gcry_control (GCRYCTL_DISABLE_SECMEM, 0); gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0); Salam-Shalom, Werner From bradh at frogmouth.net Tue Aug 22 12:54:16 2006 From: bradh at frogmouth.net (Brad Hards) Date: Tue Aug 22 13:38:49 2006 Subject: Problem with test Message-ID: <200608222054.21693.bradh@frogmouth.net> G'day, I've noted a test failure that appears to only occur on one machine. The test failure: t-mpi-bit: test_rshift: rshift by 0 failed t-mpi-bit: test_rshift: rshift by 0 failed t-mpi-bit: test_rshift: rshift by 0 failed t-mpi-bit: test_rshift: rshift by 0 failed FAIL: t-mpi-bit (the other 13 tests pass). System configuration: x86_64, running Linux (Fedora Core 4) gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) (I also tried using gcc32, same result) I don't see this problem on an ia32 box. I can't see how, but possibly it is a 64-bit problem? 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/20060822/03e93778/attachment.pgp From wk at gnupg.org Tue Aug 22 15:41:22 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 22 15:46:35 2006 Subject: Problem with test In-Reply-To: <200608222054.21693.bradh@frogmouth.net> (Brad Hards's message of "Tue, 22 Aug 2006 20:54:16 +1000") References: <200608222054.21693.bradh@frogmouth.net> Message-ID: <877j1028hp.fsf@wheatstone.g10code.de> On Tue, 22 Aug 2006 12:54, Brad Hards said: > I don't see this problem on an ia32 box. I can't see how, but possibly it is a > 64-bit problem? Please run it as: $ cd tests $ ./t-mpi-bit --verbose From bradh at frogmouth.net Wed Aug 23 08:59:05 2006 From: bradh at frogmouth.net (Brad Hards) Date: Wed Aug 23 14:12:35 2006 Subject: Problem with test In-Reply-To: <877j1028hp.fsf@wheatstone.g10code.de> References: <200608222054.21693.bradh@frogmouth.net> <877j1028hp.fsf@wheatstone.g10code.de> Message-ID: <200608231659.10230.bradh@frogmouth.net> On Tuesday 22 August 2006 23:41, Werner Koch wrote: > On Tue, 22 Aug 2006 12:54, Brad Hards said: > > I don't see this problem on an ia32 box. I can't see how, but possibly it > > is a 64-bit problem? > > Please run it as: > > $ cd tests > $ ./t-mpi-bit --verbose Sorry, should have realised that. t-mpi-bit: checking that set_bit does only set one bit t-mpi-bit: r=0000000000000000000000000000000000000000000000000000000000000000000000 t-mpi-bit: checking that set_highbit does only set one bit t-mpi-bit: r=0000000000000000000000000000000000000000000000000000000000000000000000 t-mpi-bit: checking that rshift works as expected (pass 0) t-mpi-bit: got =000110110000111101010011110001001101011011001010000100100111101111111111 t-mpi-bit: want=000110110000111101010011110001001101011011001010000100100111101111101111 t-mpi-bit: test_rshift: rshift by 0 failed t-mpi-bit: checking that rshift works as expected (pass 1) t-mpi-bit: got =100110111000011111000100000011110100111101001000000001000001110010011011 t-mpi-bit: want=100110111000011111000100000011110100111101001000000001000001110000010011 t-mpi-bit: test_rshift: rshift by 0 failed t-mpi-bit: checking that rshift works as expected (pass 2) t-mpi-bit: got =111011000001100010101001111110001011000101010100010011111111010011111110 t-mpi-bit: want=111011000001100010101001111110001011000101010100010011111111010010010110 t-mpi-bit: test_rshift: rshift by 0 failed t-mpi-bit: checking that rshift works as expected (pass 3) t-mpi-bit: got =001001111011001111000100101001000000110101000111000111101101001011111111 t-mpi-bit: want=001001111011001111000100101001000000110101000111000111101101001011011100 t-mpi-bit: test_rshift: rshift by 0 failed t-mpi-bit: checking that rshift works as expected (pass 4) t-mpi-bit: got =101000010101010100010111010001100000111110101001101100011110110011111011 t-mpi-bit: want=101000010101010100010111010001100000111110101001101100011110110001111011 t-mpi-bit: test_rshift: rshift by 0 failed t-mpi-bit: All tests completed. Errors: 5 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060823/267da4da/attachment.pgp From wk at gnupg.org Fri Aug 25 16:34:34 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Aug 25 16:36:44 2006 Subject: Problem with test In-Reply-To: <200608222054.21693.bradh@frogmouth.net> (Brad Hards's message of "Tue, 22 Aug 2006 20:54:16 +1000") References: <200608222054.21693.bradh@frogmouth.net> Message-ID: <87ac5svq85.fsf@wheatstone.g10code.de> On Tue, 22 Aug 2006 12:54, Brad Hards said: > I don't see this problem on an ia32 box. I can't see how, but possibly it is a > 64-bit problem? Please try the patch below (in libgrypt/mpi/). This should fix it. Shalom-Salam, Werner =================================================================== --- mpi-bit.c (revision 1172) +++ mpi-bit.c (working copy) @@ -256,7 +256,17 @@ x->nlimbs = xsize; if ( xsize ) - _gcry_mpih_rshift (x->d, a->d, x->nlimbs, nbits ); + { + if (nbits ) + _gcry_mpih_rshift (x->d, a->d, x->nlimbs, nbits ); + else + { + /* The rshift helper function is not specified for + NBITS==0, thus we do a plain copy here. */ + for (i=0; i < x->nlimbs; i++ ) + x->d[i] = a->d[i]; + } + } } MPN_NORMALIZE (x->d, x->nlimbs); } From bradh at frogmouth.net Sat Aug 26 01:52:56 2006 From: bradh at frogmouth.net (Brad Hards) Date: Sat Aug 26 02:26:34 2006 Subject: Problem with test In-Reply-To: <87ac5svq85.fsf@wheatstone.g10code.de> References: <200608222054.21693.bradh@frogmouth.net> <87ac5svq85.fsf@wheatstone.g10code.de> Message-ID: <200608260953.00525.bradh@frogmouth.net> On Saturday 26 August 2006 00:34, Werner Koch wrote: > --- mpi-bit.c ? (revision 1172) > +++ mpi-bit.c ? (working copy) > @@ -256,7 +256,17 @@ > ? ? ? ?x->nlimbs = xsize; > ? ? ? ? > ? ? ? ?if ( xsize ) > - ? ? ? ?_gcry_mpih_rshift (x->d, a->d, x->nlimbs, nbits ); > + ? ? ? ?{ > + ? ? ? ? ?if (nbits ) > + ? ? ? ? ? ?_gcry_mpih_rshift (x->d, a->d, x->nlimbs, nbits ); > + ? ? ? ? ?else > + ? ? ? ? ? ?{ > + ? ? ? ? ? ? ?/* The rshift helper function is not specified for > + ? ? ? ? ? ? ? ? NBITS==0, thus we do a plain copy here. */ > + ? ? ? ? ? ? ?for (i=0; i < x->nlimbs; i++ ) > + ? ? ? ? ? ? ? ?x->d[i] = a->d[i]; > + ? ? ? ? ? ?} > + ? ? ? ?} > ? ? ?} > ? ?MPN_NORMALIZE (x->d, x->nlimbs); > ?} Now good: $ ./t-mpi-bit --verbose t-mpi-bit: checking that set_bit does only set one bit t-mpi-bit: r=0000000000000000000000000000000000000000000000000000000000000000000000 t-mpi-bit: checking that set_highbit does only set one bit t-mpi-bit: r=0000000000000000000000000000000000000000000000000000000000000000000000 t-mpi-bit: checking that rshift works as expected (pass 0) inp= CD570A538852236914 inp= CD570A538852236914 out= CD570A538852236914 t-mpi-bit: checking that rshift works as expected (pass 1) inp= A52197ED49D19C620A inp= A52197ED49D19C620A out= A52197ED49D19C620A t-mpi-bit: checking that rshift works as expected (pass 2) inp= 36DB517C8E2EAE0296 inp= 36DB517C8E2EAE0296 out= 36DB517C8E2EAE0296 t-mpi-bit: checking that rshift works as expected (pass 3) inp= B61E2D1C7A2A7FD12E inp= B61E2D1C7A2A7FD12E out= B61E2D1C7A2A7FD12E t-mpi-bit: checking that rshift works as expected (pass 4) inp= D30FC4FB1F415A5F8B inp= D30FC4FB1F415A5F8B out= D30FC4FB1F415A5F8B t-mpi-bit: All tests completed. Errors: 0 Thanks. 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/20060826/d308a64b/attachment.pgp From wk at gnupg.org Mon Aug 28 12:07:45 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 28 12:11:16 2006 Subject: Problem with test In-Reply-To: <200608260953.00525.bradh@frogmouth.net> (Brad Hards's message of "Sat, 26 Aug 2006 09:52:56 +1000") References: <200608222054.21693.bradh@frogmouth.net> <87ac5svq85.fsf@wheatstone.g10code.de> <200608260953.00525.bradh@frogmouth.net> Message-ID: <87k64t41hq.fsf@wheatstone.g10code.de> On Sat, 26 Aug 2006 01:52, Brad Hards said: > Now good: great. Now doing a new release. Shalom-Salam, Werner From wk at gnupg.org Tue Aug 29 11:39:19 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 29 11:41:17 2006 Subject: [patch] SEED (rfc4269) support In-Reply-To: <20060712143738.GA54909@FreeBSD.org> (Hye-Shik Chang's message of "Wed, 12 Jul 2006 23:37:38 +0900") References: <20060711134516.GA19101@FreeBSD.org> <200607122221.03229.bradh@frogmouth.net> <20060712143738.GA54909@FreeBSD.org> Message-ID: <87wt8r6fug.fsf@wheatstone.g10code.de> On Wed, 12 Jul 2006 16:37, Hye-Shik Chang said: > I'd like to provide it in public domain and let libgcrypt project > relicense or do whatever it needs. I updated the patch. Is it > enough for the statement? Also we in general like to have signed papers, I consider your signed mail okay in this case. Just applied SEED to the trunk. Thanks, Werner From perky at FreeBSD.org Tue Aug 29 13:54:16 2006 From: perky at FreeBSD.org (Hye-Shik Chang) Date: Tue Aug 29 13:52:47 2006 Subject: [patch] SEED (rfc4269) support In-Reply-To: <87wt8r6fug.fsf@wheatstone.g10code.de> References: <20060711134516.GA19101@FreeBSD.org> <200607122221.03229.bradh@frogmouth.net> <20060712143738.GA54909@FreeBSD.org> <87wt8r6fug.fsf@wheatstone.g10code.de> Message-ID: <20060829115416.GA79631@FreeBSD.org> On Tue, Aug 29, 2006 at 11:39:19AM +0200, Werner Koch wrote: > On Wed, 12 Jul 2006 16:37, Hye-Shik Chang said: > > > I'd like to provide it in public domain and let libgcrypt project > > relicense or do whatever it needs. I updated the patch. Is it > > enough for the statement? > > Also we in general like to have signed papers, I consider your signed > mail okay in this case. > > Just applied SEED to the trunk. > I sent a signed response to FSF which assigns a copyright to them by airmail 3 days ago. (It took too much time in mail transaction :) Thanks for your kind work! Hye-Shik From gcrypt at dstoecker.de Wed Aug 30 11:26:40 2006 From: gcrypt at dstoecker.de (Dirk Stoecker) Date: Wed Aug 30 11:25:04 2006 Subject: Cleanup patch In-Reply-To: References: Message-ID: On Wed, 9 Aug 2006, Dirk Stoecker wrote: > I attached a larger cleanup patch for libgcrypt SVN: Well, I ask myself why I did that work when I'm totally ignored again. May the bugs be with you. Ciao -- http://www.dstoecker.de/ (PGP key available) From wk at gnupg.org Wed Aug 30 17:36:23 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Aug 30 17:41:25 2006 Subject: Cleanup patch In-Reply-To: (Dirk Stoecker's message of "Wed, 30 Aug 2006 11:26:40 +0200 (CEST)") References: Message-ID: <878xl644nc.fsf@wheatstone.g10code.de> On Wed, 30 Aug 2006 11:26, Dirk Stoecker said: > 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: We need legal papers for such patches. It might or might not be a 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. I will also need to check the patch which is time consuming. Salam-Shalom, Werner