From simon at josefsson.org Fri May 9 22:46:50 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 09 May 2008 22:46:50 +0200 Subject: Build failure for minimal builds Message-ID: <87ve1nyzlx.fsf@mocca.josefsson.org> Werner, Building a minimal libgcrypt 1.4.1 using: ./configure --enable-digests="md5 sha1 sha256" --enable-ciphers="arcfour des aes" --enable-pubkey-ciphers="rsa dsa" results in a library that calls an unknown symbol: ../src/.libs/libgcrypt.so: undefined reference to `_gcry_ecc_get_param' This patch makes sure the function isn't called if ECC is disabled: diff -ur libgcrypt-1.4.1.orig/cipher/pubkey.c libgcrypt-1.4.1/cipher/pubkey.c --- libgcrypt-1.4.1.orig/cipher/pubkey.c 2007-12-13 13:40:38.000000000 +0100 +++ libgcrypt-1.4.1/cipher/pubkey.c 2008-05-09 22:34:14.000000000 +0200 @@ -805,6 +805,7 @@ return err; } +#if USE_ECC /* Internal function used for ecc. Note, that this function makes use of its intimate knowledge about the ECC parameters from ecc.c. */ static gcry_err_code_t @@ -887,7 +888,7 @@ } return err; } - +#endif /**************** @@ -978,9 +979,11 @@ err = gpg_err_code_from_errno (errno); if (!err) { +#if USE_ECC if (is_ecc) err = sexp_elements_extract_ecc (list, elems, array); else +#endif err = sexp_elements_extract (list, elems, array, pubkey->name); } However, the self-tests fail catastrophically. The remaining patch fixes that too. diff -ur libgcrypt-1.4.1.orig/tests/basic.c libgcrypt-1.4.1/tests/basic.c --- libgcrypt-1.4.1.orig/tests/basic.c 2008-04-22 11:03:33.000000000 +0200 +++ libgcrypt-1.4.1/tests/basic.c 2008-05-09 22:41:41.000000000 +0200 @@ -1,5 +1,5 @@ /* basic.c - basic regression tests - * Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc. + * Copyright (C) 2001, 2002, 2003, 2005, 2008 Free Software Foundation, Inc. * * This file is part of Libgcrypt. * @@ -1137,12 +1137,15 @@ const char *expect; } algos[] = { +#if USE_MD4 { GCRY_MD_MD4, "", "\x31\xD6\xCF\xE0\xD1\x6A\xE9\x31\xB7\x3C\x59\xD7\xE0\xC0\x89\xC0" }, { GCRY_MD_MD4, "a", "\xbd\xe5\x2c\xb3\x1d\xe3\x3e\x46\x24\x5e\x05\xfb\xdb\xd6\xfb\x24" }, { GCRY_MD_MD4, "message digest", "\xd9\x13\x0a\x81\x64\x54\x9f\xe8\x18\x87\x48\x06\xe1\xc7\x01\x4b" }, +#endif +#if USE_MD4 { GCRY_MD_MD5, "", "\xD4\x1D\x8C\xD9\x8F\x00\xB2\x04\xE9\x80\x09\x98\xEC\xF8\x42\x7E" }, { GCRY_MD_MD5, "a", @@ -1151,6 +1154,8 @@ "\x90\x01\x50\x98\x3C\xD2\x4F\xB0\xD6\x96\x3F\x7D\x28\xE1\x7F\x72" }, { GCRY_MD_MD5, "message digest", "\xF9\x6B\x69\x7D\x7C\xB7\x93\x8D\x52\x5A\x2F\x31\xAA\xF1\x61\xD0" }, +#endif +#if USE_SHA1 { GCRY_MD_SHA1, "abc", "\xA9\x99\x3E\x36\x47\x06\x81\x6A\xBA\x3E" "\x25\x71\x78\x50\xC2\x6C\x9C\xD0\xD8\x9D" }, @@ -1161,6 +1166,8 @@ { GCRY_MD_SHA1, "!" /* kludge for "a"*1000000 */ , "\x34\xAA\x97\x3C\xD4\xC4\xDA\xA4\xF6\x1E" "\xEB\x2B\xDB\xAD\x27\x31\x65\x34\x01\x6F" }, +#endif +#if USE_SHA224 /* From RFC3874 */ { GCRY_MD_SHA224, "abc", "\x23\x09\x7d\x22\x34\x05\xd8\x22\x86\x42\xa4\x77\xbd\xa2\x55\xb3" @@ -1172,6 +1179,8 @@ { GCRY_MD_SHA224, "!", "\x20\x79\x46\x55\x98\x0c\x91\xd8\xbb\xb4\xc1\xea\x97\x61\x8a\x4b" "\xf0\x3f\x42\x58\x19\x48\xb2\xee\x4e\xe7\xad\x67" }, +#endif +#if USE_SHA256 { GCRY_MD_SHA256, "abc", "\xba\x78\x16\xbf\x8f\x01\xcf\xea\x41\x41\x40\xde\x5d\xae\x22\x23" "\xb0\x03\x61\xa3\x96\x17\x7a\x9c\xb4\x10\xff\x61\xf2\x00\x15\xad" }, @@ -1182,15 +1191,20 @@ { GCRY_MD_SHA256, "!", "\xcd\xc7\x6e\x5c\x99\x14\xfb\x92\x81\xa1\xc7\xe2\x84\xd7\x3e\x67" "\xf1\x80\x9a\x48\xa4\x97\x20\x0e\x04\x6d\x39\xcc\xc7\x11\x2c\xd0" }, +#endif +#if USE_SHA384 { GCRY_MD_SHA384, "abc", "\xcb\x00\x75\x3f\x45\xa3\x5e\x8b\xb5\xa0\x3d\x69\x9a\xc6\x50\x07" "\x27\x2c\x32\xab\x0e\xde\xd1\x63\x1a\x8b\x60\x5a\x43\xff\x5b\xed" "\x80\x86\x07\x2b\xa1\xe7\xcc\x23\x58\xba\xec\xa1\x34\xc8\x25\xa7" }, +#endif +#if USE_SHA512 { GCRY_MD_SHA512, "abc", "\xDD\xAF\x35\xA1\x93\x61\x7A\xBA\xCC\x41\x73\x49\xAE\x20\x41\x31" "\x12\xE6\xFA\x4E\x89\xA9\x7E\xA2\x0A\x9E\xEE\xE6\x4B\x55\xD3\x9A" "\x21\x92\x99\x2A\x27\x4F\xC1\xA8\x36\xBA\x3C\x23\xA3\xFE\xEB\xBD" "\x45\x4D\x44\x23\x64\x3C\xE8\x0E\x2A\x9A\xC9\x4F\xA5\x4C\xA4\x9F" }, +#endif { GCRY_MD_RMD160, "", "\x9c\x11\x85\xa5\xc5\xe9\xfc\x54\x61\x28" "\x08\x97\x7e\xe8\xf5\x48\xb2\x25\x8d\x31" }, @@ -1203,6 +1217,7 @@ { GCRY_MD_RMD160, "message digest", "\x5d\x06\x89\xef\x49\xd2\xfa\xe5\x72\xb8" "\x81\xb1\x23\xa8\x5f\xfa\x21\x59\x5f\x36" }, +#if USE_CRC { GCRY_MD_CRC32, "", "\x00\x00\x00\x00" }, { GCRY_MD_CRC32, "foo", "\x8c\x73\x65\x21" }, { GCRY_MD_CRC32_RFC1510, "", "\x00\x00\x00\x00" }, @@ -1222,6 +1237,8 @@ #endif { GCRY_MD_CRC24_RFC2440, "", "\xb7\x04\xce" }, { GCRY_MD_CRC24_RFC2440, "foo", "\x4f\xc2\x55" }, +#endif +#if USE_TIGER { GCRY_MD_TIGER, "", "\x24\xF0\x13\x0C\x63\xAC\x93\x32\x16\x16\x6E\x76" "\xB1\xBB\x92\x5F\xF3\x73\xDE\x2D\x49\x58\x4E\x7A" }, @@ -1258,6 +1275,8 @@ "TUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+-", "\x00\xB8\x3E\xB4\xE5\x34\x40\xC5\x76\xAC\x6A\xAE" "\xE0\xA7\x48\x58\x25\xFD\x15\xE7\x0A\x59\xFF\xE4" }, +#endif +#if USE_WHIRLPOOL { GCRY_MD_WHIRLPOOL, "", "\x19\xFA\x61\xD7\x55\x22\xA4\x66\x9B\x44\xE3\x9C\x1D\x2E\x17\x26" "\xC5\x30\x23\x21\x30\xD4\x07\xF8\x9A\xFE\xE0\x96\x49\x97\xF7\xA7" @@ -1285,6 +1304,7 @@ "\x29\x05\x7F\xD8\x6B\x20\xBF\xD6\x2D\xEC\xA0\xF1\xCC\xEA\x4A\xF5" "\x1F\xC1\x54\x90\xED\xDC\x47\xAF\x32\xBB\x2B\x66\xC3\x4F\xF9\xAD" "\x8C\x60\x08\xAD\x67\x7F\x77\x12\x69\x53\xB2\x26\xE4\xED\x8B\x01" }, +#endif { 0 }, }; int i; @@ -1523,6 +1543,7 @@ "\xaa\xaa\xaa", "\x3a\x85\x41\x66\xac\x5d\x9f\x02\x3f\x54\xd5\x17\xd0\xb3\x9d\xbd" "\x94\x67\x70\xdb\x9c\x2b\x95\xc9\xf6\xf5\x65\xd1" }, +#if USE_SHA384 { GCRY_MD_SHA384, "what do ya want for nothing?", "Jefe", "\xaf\x45\xd2\xe3\x76\x48\x40\x31\x61\x7f\x78\xd2\xb5\x8a\x6b\x1b" "\x9c\x7e\xf4\x64\xf5\xa0\x1b\x47\xe4\x2e\xc3\x73\x63\x22\x44\x5e" @@ -1582,6 +1603,8 @@ "\x66\x17\x17\x8e\x94\x1f\x02\x0d\x35\x1e\x2f\x25\x4e\x8f\xd3\x2c" "\x60\x24\x20\xfe\xb0\xb8\xfb\x9a\xdc\xce\xbb\x82\x46\x1e\x99\xc5" "\xa6\x78\xcc\x31\xe7\x99\x17\x6d\x38\x60\xe6\x11\x0c\x46\x52\x3e" }, +#endif +#if USE_SHA512 { GCRY_MD_SHA512, "what do ya want for nothing?", "Jefe", "\x16\x4b\x7a\x7b\xfc\xf8\x19\xe2\xe3\x95\xfb\xe7\x3b\x56\xe0\xa3" "\x87\xbd\x64\x22\x2e\x83\x1f\xd6\x10\x27\x0c\xd7\xea\x25\x05\x54" @@ -1647,6 +1670,7 @@ "\xde\xbd\x71\xf8\x86\x72\x89\x86\x5d\xf5\xa3\x2d\x20\xcd\xc9\x44" "\xb6\x02\x2c\xac\x3c\x49\x82\xb1\x0d\x5e\xeb\x55\xc3\xe4\xde\x15" "\x13\x46\x76\xfb\x6d\xe0\x44\x60\x65\xc9\x74\x40\xfa\x8c\x6a\x58" }, +#endif { 0 }, }; int i; @@ -1931,6 +1955,7 @@ "\xc6\x39\x83\x1a\x43\xe5\x05\x5d\xc6\xd8" "\x4a\xa6\xf9\xeb\x23\xbf\xa9\x12\x2d\x5b" } }, +#if USE_ELGAMAL { GCRY_PK_ELG, FLAG_SIGN | FLAG_CRYPT, @@ -1962,6 +1987,7 @@ "\xa7\x99\x61\xeb\x88\x83\xd2\xf4\x05\xc8" "\x4f\xba\x06\xf8\x78\x09\xbc\x1e\x20\xe5" } }, +#endif }; int i; if (verbose) diff -ur libgcrypt-1.4.1.orig/tests/pubkey.c libgcrypt-1.4.1/tests/pubkey.c --- libgcrypt-1.4.1.orig/tests/pubkey.c 2008-03-18 14:25:36.000000000 +0100 +++ libgcrypt-1.4.1/tests/pubkey.c 2008-05-09 22:36:57.000000000 +0200 @@ -1,5 +1,5 @@ /* pubkey.c - Public key encryption/decryption tests - * Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc. + * Copyright (C) 2001, 2002, 2003, 2005, 2008 Free Software Foundation, Inc. * * This file is part of Libgcrypt. * @@ -326,6 +326,7 @@ gcry_sexp_release (pkey); gcry_sexp_release (skey); +#if USE_ELGAMAL if (verbose) fprintf (stderr, "Checking generated Elgamal key.\n"); get_elg_key_new (&pkey, &skey, 0); @@ -339,6 +340,7 @@ check_keys (pkey, skey, 800, 0); gcry_sexp_release (pkey); gcry_sexp_release (skey); +#endif } Thanks, Simon From nmav at gnutls.org Fri May 16 19:05:02 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 16 May 2008 20:05:02 +0300 Subject: [Help-gnutls] libgcrypt In-Reply-To: References: Message-ID: <482DBEBE.2070502@gnutls.org> preeti.shandilya wrote: > Hi! > > I am facing core dump in libgcypt library on Solaris, during TLS handshake > Following are the library versions. It could be an alignment problem. What kind of hardware is this? I CC the gcrypt mailing list since this is relevant to libgcrypt mostly. regards, Nikos PS. Does the make check in libgcrypt succeed? > > 1. libgpg-error-1.5 > 2. libgcrypt-1.4.1 > 3. gnutls-1.6.3 and tried with gnutls-2.2.3 also > > Pl find the back trace. > > #0 0xfea28598 in do_decrypt (ctx=0xfe37b5f8, > bx=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?", > ax=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?") at rijndael.c:261 > #1 0xfea28b34 in rijndael_decrypt (context=0xfe37b5f8, > b=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?", > a=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?") at rijndael.c:679 > #2 0xfea28d0c in rijndael_setkey (context=0xa1c6e0, > key=0xa15868 "???g[0?? ??7\020?\221\237", keylen=16) at rijndael.c:833 > #3 0xfea13de4 in _gcry_cipher_ctl (h=0xa1c678, cmd=1, buffer=0xa15868, > buflen=16) at cipher.c:831 > #4 0xfeb4a07c in gc_cipher_setkey (handle=0xa1c678, keylen=16, > key=0xa15868 "???g[0?? ??7\020?\221\237") at gc-libgcrypt.c:190 > #5 0xfeb2884c in _gnutls_cipher_init (cipher=GNUTLS_CIPHER_AES_128_CBC, > key=0xa1aa44, iv=0xa1aa34) at gnutls_cipher_int.c:83 > #6 0xfeb34080 in _gnutls_write_connection_state_init (session=0xa1a6d8) > at gnutls_constate.c:820 > #7 0xfeb1e6a0 in _gnutls_send_handshake_final (session=0xa1a6d8, init=1) > at gnutls_handshake.c:2438 > #8 0xfeb22964 in _gnutls_handshake_common (session=0xa1a6d8) > at gnutls_handshake.c:2651 > #9 0xfeb22bec in gnutls_handshake (session=0xa1a6d8) > at gnutls_handshake.c:2255 > #10 0x0010d4cc in AAATLSWrapper::performHandshake (this=0x9b7330, socketFd=9) > > Pl suggest the solution if anybody has faced this problem. I have a multithreaded application. > > Regards > Preeti From nmav at gnutls.org Sat May 17 19:10:24 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 17 May 2008 20:10:24 +0300 Subject: const tables Message-ID: <482F1180.7030408@gnutls.org> It seems that same tables in the included cipher algorithms are not defined as const. In cipher/ directory and in digest algorithms, the asn OID bytes are defined as static byte asn[18] (in md5.c). Also in crc.c the CRC table is not defined as const. The same occurs in des.c (sboxes, weak keys). The same is in tiger.c which also has the sboxes in static non constant tables. In some self tests also (blowfish.c -> selftest()) the plaintext values could be defined as constants. From nmav at gnutls.org Wed May 21 14:45:56 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 21 May 2008 15:45:56 +0300 Subject: [Fwd: Re: [Help-gnutls] libgcrypt] Message-ID: <48341984.5070307@gnutls.org> An embedded message was scrubbed... From: "preeti.shandilya" Subject: RE: [Help-gnutls] libgcrypt Date: Mon, 19 May 2008 13:43:40 +0530 Size: 8540 URL: From wk at gnupg.org Wed May 21 17:02:42 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 May 2008 17:02:42 +0200 Subject: [Fwd: Re: [Help-gnutls] libgcrypt] In-Reply-To: <48341984.5070307@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 21 May 2008 15:45:56 +0300") References: <48341984.5070307@gnutls.org> Message-ID: <87r6bv7l9p.fsf@wheatstone.g10code.de> Hi, That forwarded bug message is not very helpful. Too many things are mixed up or cut off. The orginal reporter (who's email is not given) should prepare a proper bug report and send it again. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri May 23 20:09:56 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 23 May 2008 20:09:56 +0200 Subject: [Fwd: Re: [Help-gnutls] libgcrypt] In-Reply-To: <48341984.5070307@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 21 May 2008 15:45:56 +0300") References: <48341984.5070307@gnutls.org> Message-ID: <87iqx4yjrf.fsf@wheatstone.g10code.de> Hi, There might be an alignment problem. #define W (ctx->keySched2) for (r = 1; r < ctx->ROUNDS; r++) { w = W[r][0]; *((u32*)w) = *((u32*)U1[w[0]]) ^ *((u32*)U2[w[1]]) ^ *((u32*)U3[w[2]]) ^ *((u32*)U4[w[3]]); W is union { PROPERLY_ALIGNED_TYPE dummy; byte keyschedule[MAXROUNDS+1][4][4]; } u2; } RIJNDAEL_context; #define keySched u1.keyschedule #define keySched2 u2.keyschedule Thus it should be properly aligned. Well, on a 32 bit boundary for array elements > 0. Ux is might not be properly aligned, hwoever all compilers I know place tables on a word boundary and thus there should be no problem. We never had any problems with that code, it is really old and thus can be believied to be matured. It is used in gpg as well. Thus I wonder what is special on your setup. What we need are hardware information and the config.log from the libgcrypt build as well as a log of the make run. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From michael at gorven.za.net Wed May 28 20:21:57 2008 From: michael at gorven.za.net (Michael Gorven) Date: Wed, 28 May 2008 20:21:57 +0200 Subject: Purpose of _gcry_burn_stack Message-ID: <200805282022.03821.michael@gorven.za.net> Hi I am using parts of libgcrypt in my implementation of LUKS support in GRUB2. Most of the ciphers have a number of calls to _gcry_burn_stack, but I can't figure out what exactly this does. It doesn't affect the operation of the ciphers (I currently have it commented out). What is the purpose of this function, and can I leave it out? Thanks Michael -- http://michael.gorven.za.net PGP Key ID 6612FE85 S/MIME Key ID D33AEB31 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From preeti.shandilya at aricent.com Tue May 27 07:45:19 2008 From: preeti.shandilya at aricent.com (Preeti Shandilya) Date: Tue, 27 May 2008 11:15:19 +0530 Subject: [Fwd: Re: [Help-gnutls] libgcrypt] In-Reply-To: <87iqx4yjrf.fsf@wheatstone.g10code.de> References: <48341984.5070307@gnutls.org> <87iqx4yjrf.fsf@wheatstone.g10code.de> Message-ID: Hi Werner ! Thanks for your response We could successfully run our product using following version of libraries libgcrypt-1.2.2 gnutls-1.6.3 But libgcrypt-1.4.1 gives core. Attached is config.log : Following is the system information through prtconf Regards Preeti -----Original Message----- From: Werner Koch [mailto:wk at gnupg.org] Sent: Friday, May 23, 2008 11:40 PM To: Preeti Shandilya Cc: gcrypt-devel at gnupg.org Subject: Re: [Fwd: Re: [Help-gnutls] libgcrypt] Hi, There might be an alignment problem. #define W (ctx->keySched2) for (r = 1; r < ctx->ROUNDS; r++) { w = W[r][0]; *((u32*)w) = *((u32*)U1[w[0]]) ^ *((u32*)U2[w[1]]) ^ *((u32*)U3[w[2]]) ^ *((u32*)U4[w[3]]); W is union { PROPERLY_ALIGNED_TYPE dummy; byte keyschedule[MAXROUNDS+1][4][4]; } u2; } RIJNDAEL_context; #define keySched u1.keyschedule #define keySched2 u2.keyschedule Thus it should be properly aligned. Well, on a 32 bit boundary for array elements > 0. Ux is might not be properly aligned, hwoever all compilers I know place tables on a word boundary and thus there should be no problem. We never had any problems with that code, it is really old and thus can be believied to be matured. It is used in gpg as well. Thus I wonder what is special on your setup. What we need are hardware information and the config.log from the libgcrypt build as well as a log of the make run. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility forloss or damage arising from the use of the information transmitted by this email including damage from virus." -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 63320 bytes Desc: config.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: info Type: application/octet-stream Size: 2583 bytes Desc: info URL: From agl at imperialviolet.org Wed May 28 21:52:54 2008 From: agl at imperialviolet.org (Adam Langley) Date: Wed, 28 May 2008 12:52:54 -0700 Subject: Purpose of _gcry_burn_stack In-Reply-To: <200805282022.03821.michael@gorven.za.net> References: <200805282022.03821.michael@gorven.za.net> Message-ID: <396556a20805281252u31f4106apb781e0be1bab6e98@mail.gmail.com> On Wed, May 28, 2008 at 11:21 AM, Michael Gorven wrote: > I am using parts of libgcrypt in my implementation of LUKS support in GRUB2. > Most of the ciphers have a number of calls to _gcry_burn_stack, but I can't > figure out what exactly this does. It doesn't affect the operation of the > ciphers (I currently have it commented out). What is the purpose of this > function, and can I leave it out? The source to this function can be seen at the end of [1]. What it's going is clearing some number of bytes from the stack. Consider the following code: void inner() { char buffer[32]; fill_buffer_with_secret_key(buffer); } void outer() { inner() /* (1) */ } Now, at point (1) the secret key is still in memory - on the stack. _gcry_burn_stack will zero that out. [1] http://www.google.com/codesearch?hl=en&q=+_gcry_burn_stack+show:Fy9qBXkJCU8:yt2DAu8VuEs:bl3DScJ85K4&sa=N&cd=1&ct=rc&cs_p=ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.1.44.tar.gz&cs_f=libgcrypt-1.1.44/src/misc.c AGL -- Adam Langley agl at imperialviolet.org http://www.imperialviolet.org From michael at gorven.za.net Wed May 28 22:06:08 2008 From: michael at gorven.za.net (Michael Gorven) Date: Wed, 28 May 2008 22:06:08 +0200 Subject: Purpose of _gcry_burn_stack In-Reply-To: <396556a20805281252u31f4106apb781e0be1bab6e98@mail.gmail.com> References: <200805282022.03821.michael@gorven.za.net> <396556a20805281252u31f4106apb781e0be1bab6e98@mail.gmail.com> Message-ID: <200805282206.15404.michael@gorven.za.net> On Wednesday 28 May 2008 21:52:54 you wrote: > Now, at point (1) the secret key is still in memory - on the stack. > _gcry_burn_stack will zero that out. That's what my guess was :-) I suppose I should get it working, but since the master key for the partition is going to be sitting in memory anyway, it probably isn't a serious vulnerability. Thanks for your reply. Michael -- http://michael.gorven.za.net PGP Key ID 6612FE85 S/MIME Key ID D33AEB31 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Sat May 31 13:14:04 2008 From: wk at gnupg.org (Werner Koch) Date: Sat, 31 May 2008 13:14:04 +0200 Subject: [Fwd: Re: [Help-gnutls] libgcrypt] In-Reply-To: (Preeti Shandilya's message of "Tue, 27 May 2008 11:15:19 +0530") References: <48341984.5070307@gnutls.org> <87iqx4yjrf.fsf@wheatstone.g10code.de> Message-ID: <87hccehgjn.fsf@wheatstone.g10code.de> On Tue, 27 May 2008 07:45, preeti.shandilya at aricent.com said: > Attached is config.log : > Following is the system information through prtconf Thanks. It seems that I would need to debug this. I have no such machine available right now, so this is not easily possible. Let's see whether other folks have such a problem too and are able to track down the problem. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.