From Frediano.Ziglio at vodafone.com Tue Jan 3 14:36:26 2006 From: Frediano.Ziglio at vodafone.com (ZIGLIO, Frediano, VF-IT) Date: Tue Jan 3 14:36:11 2006 Subject: [gnutls-dev] Re: living without global variables Message-ID: > > > Doesn't it? gnutls' global init function does _something_ with > > Libgcrypt. How is that different? > > Gnutls handles the Libgcrypt initialization internally and thus > requires that the user of gnutls has knowledge about the internal use > of libgcrypt. If you are using libgcrypt in a threading environment > the gnutls callers needs to make sure that Libgcrypt has been > initialized correctly - the last time I checked, gnutls does not know > the threading system in use and thus can't initialize > Libgcrypt properly. > > With an initialization function similar to the one of Libgcrypt it > would be possible to hide the use of Libgcrypt. > > We do not create thread specific versions of Libgcrypt because this > would require all libs using Libgcrypt to also come in different > flavors (plain, pthread, pth) - not very efficient. For certain OSes > we might be able to do some trickery in detecting and initializing the > threading lib in use but this is not portable. > > > Assuming you have to have global variables, of course. > > The major reason for global state is the entropy pool. Collecting > entropy is a time consuming task and we can't do it for each new > session. Another one is libgcrypt's "secure" memory allocation > functions - obviously this can't be done on a per session base or > delegated to a daemon. With encrypted swap you won't need it, but > this OS feature is not yet in widespread use. > > Thus this is all a matter of telling libgcrypt to use the correct > threading system. > > Unloading Libgcrypt is not possible unless all users agree on shutting > down all threads (but one) using Libgcrypt, restoring all hooks and > releasing all secure memory. Libgcrypt can't detect such a condition > and this is the reason we don't provide a deinit function. > > For a plugin system one could use wrapper functions to provide a > managed interface to libgcrypt. The problem is that you need to do > this for most libraries which are subject to "unloading" and change > all those libraries to use these wrapper functions. Writing a plugin > system in a portable way is not easy. Frankly, I see no way to create > in-process plugins without restricting the APIs a plugin may use. > Creating plugins as separate processes is far easier, more secure and > really portable. > > > Shalom-Salam, > > Werner > There is also another possibility that can fix (I hope) all problems. Mainly initializers in libgcrypt are functions that manage module registrations. Module registrations just add entries to some linked list. It would be possible to initialize these lists statically. Well, let me explain with an example this solution. gcry_module is defined as struct gcry_module { struct gcry_module *next; /* List pointers. */ struct gcry_module **prevp; void *spec; /* The acctual specs. */ int flags; /* Associated flags. */ int counter; /* Use counter. */ unsigned int mod_id; /* ID of this module. */ }; we could define a statically handled list as extern gcry_module _gcry_module1; extern gcry_module _gcry_module2; static gcry_module_t ciphers_registered = &_gcry_module1; gcry_module _gcry_module1 = { &_gcry_module2, &ciphers_registered, my_cipher_spec1, /* replace with correct value*/ FLAG_MODULE_STATIC_ALLOCATED, /* or whatever you decide */ 0, /* ?? */ MODULE_ID_MIN }; gcry_module _gcry_module2 = { NULL, &_gcry_module1.next, my_cipher_spec2, FLAG_MODULE_STATIC_ALLOCATED, 0, /* ?? */ MODULE_ID_MIN+1 }; This method use a static allocation (and in this case even a static initialization but this can be changed as you like). Someone could object that if a shared library adds some module dynamically to gcrypt in this case we would still have a memory leak however is up to shared library that register the module to release it. Frediano Ziglio From wk at gnupg.org Tue Jan 3 15:37:37 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Jan 3 15:42:29 2006 Subject: [gnutls-dev] Re: living without global variables In-Reply-To: (Frediano ZIGLIO's message of "Tue, 3 Jan 2006 14:36:26 +0100") References: Message-ID: <871wzppeby.fsf@wheatstone.g10code.de> On Tue, 3 Jan 2006 14:36:26 +0100, ZIGLIO, Frediano, VF-IT said: > There is also another possibility that can fix (I hope) all problems. > Mainly initializers in libgcrypt are functions that manage module > registrations. Module registrations just add entries to some linked Actually these are the less critical ones. For various other reasons we need a locking mechanism anyway and thus the static tablle creation does not really help. If you are only working with GNU based system, you can try to init Libgcrypt from the actual application (maybe even with a Libgcrypt loader plugin) so that the other plugins will use the already loaded and initialized Libgcrypt. To get everything right all libraries between Libgcrypt and and the application must be aware of the threading system in use. We tinkered a lot with libgcrypt to make this as easy as possible and ventually setlled for the current solution - it is by far the most portable one. All other more automagically working implementations are either non portable or lead to headaches when writing the build rules for larger applications. Shalom-Salam, Werner From gcrypt at dstoecker.de Sun Jan 8 14:33:27 2006 From: gcrypt at dstoecker.de (Dirk Stoecker) Date: Sun Jan 8 14:32:58 2006 Subject: memory leaks Message-ID: Hello, as promised, I released the memory leak patch for gcrypt on a webpage: http://www.dstoecker.de/gcrypt.html It includes the motivation for the patch, the way to download and apply it as well as compatibility considerations (and a not for usage in dynamic loading contexts). Ciao -- http://www.dstoecker.de/ (PGP key available) From tthomas at chubb.com Mon Jan 9 16:29:01 2006 From: tthomas at chubb.com (Tod Thomas) Date: Mon Jan 9 17:22:06 2006 Subject: Encryption Question Message-ID: <43C2813D.3080705@chubb.com> When calling gcry_cipher_encrypt using twofish with CFB mode and the two buffer method, what will the size of the encrypted value returned to the out buffer be? Is it always the size of the bufferlength passed to the function, with appropriate padding, or can it be variable in length not to exceed the passed bufferlength? Thanks - Tod From wk at gnupg.org Mon Jan 9 18:14:08 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Jan 9 18:17:44 2006 Subject: Encryption Question In-Reply-To: <43C2813D.3080705@chubb.com> (Tod Thomas's message of "Mon, 09 Jan 2006 10:29:01 -0500") References: <43C2813D.3080705@chubb.com> Message-ID: <87irst5nof.fsf@wheatstone.g10code.de> On Mon, 09 Jan 2006 10:29:01 -0500, Tod Thomas said: > Is it always the size of the bufferlength passed to the function, with > appropriate padding, or can it be variable in length not to exceed the It is always the length you pass in. CFB mode behave similar to a stream cipher. Shalom-Salam, Werner From tthomas at chubb.com Tue Jan 10 16:29:04 2006 From: tthomas at chubb.com (Tod Thomas) Date: Tue Jan 10 16:46:54 2006 Subject: Encryption Question In-Reply-To: <87irst5nof.fsf@wheatstone.g10code.de> References: <43C2813D.3080705@chubb.com> <87irst5nof.fsf@wheatstone.g10code.de> Message-ID: <43C3D2C0.3030604@chubb.com> Werner Koch wrote: > On Mon, 09 Jan 2006 10:29:01 -0500, Tod Thomas said: > > >>Is it always the size of the bufferlength passed to the function, with >>appropriate padding, or can it be variable in length not to exceed the > > > It is always the length you pass in. CFB mode behave similar to a > stream cipher. I see - I think. So MAXSIZE=64 would work, even if the passed in string was less than MAXSIZE, but I should expect upon decryption to get a string MAXSIZE in length back? I believe the answer to that question is 'no', it will only return the same string (and therefore same size) as that it was passed - correct? As always, thanks for your help. Tod From marcus.brinkmann at ruhr-uni-bochum.de Thu Jan 12 05:43:10 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Jan 12 07:18:38 2006 Subject: memory leaks In-Reply-To: References: Message-ID: <1137040990.10596.22.camel@localhost.localdomain> Hi Dirk, On Sun, 2006-01-08 at 14:33 +0100, Dirk Stoecker wrote: > as promised, I released the memory leak patch for gcrypt on a webpage: > > http://www.dstoecker.de/gcrypt.html > > It includes the motivation for the patch, the way to download and apply it > as well as compatibility considerations (and a not for usage in dynamic > loading contexts). Your website expresses a lot of frustration. That is understandable, but I think we should try to approach this issue constructively. To do so, we have to solve a complicated technical problem, given certain policy constraints. If we can successfully identify these constraints, and potential solutions, we have won a lot. At least we will better understand why certain changes are rejected, and if we can develop a long term strategy. It is very important that we untangle unrelated issues. Your patch contains different types of changes intermixed. One thing you can do to push forward this issue is to split your patch into several different patches so we can address them individually. One such issue is finalization. It seems to me that your code does not handle finalization correctly. Consider the following case: library bar and baz both use libgcrypt. They both hide this fact from the application. The application uses the library specific initializers (bar_init and baz_init) which each initialize libgcrypt. Under certain conditions this is perfectly legit, in fact, it is the only way libgrcypt can be used correctly in such a situation. Now, imagine baz comes with a finalizer, which calls the finalizer for gcrypt you added. It seems to me from skimming over your patch that in this case gcrypt is deinitialized. This will potentially break bar's use of gcrypt (I did not check if it in fact does so). It thus seems to me that your proposed solution in its current form is at best incomplete, and I don't see a trivial fix. With regards to the current libgcrypt code, one overriding concern is ABI/API compatibility. Irregardless of what we would _want_ the code to look like, the current libgcrypt version is used in dozens of important software packages, and making incompatible changes to the ABI/API to the _current_ version would need to be carefully justified. We feel that extension of the applicability of the library to new use cases (like dlopen'ed plugins) does not justify breaking existing use in dozens of software packages. So any major changes, and my suspicion is that cleaning up the allocation issues involves major changes if it is to be done right, would have to go into a major revision of the whole package including the ABI/API. This however raises a tail of other questions, like how do we carry over the confidence (security wise) that we have in the current implementation to the hypothetical major revision, how can its development be supported, etc? Equally important would be to find a convincing story how such a major revision could actually look like. Moritz does have some ideas about how to restructure the code to make it more modular and less dependent on global statics. However, some of the core issues are unresolved. We have some ideas, but I don't think we have actually found the best solution yet, and I am not sure what the best solution would look like. So here is how I suggest we proceed: If you can identify separate issues in your patch, please report them as separate issues, so they can be discussed separately. In particular, I want to understand if your finalizer actually correctly solves the problem you identified (see above). Furthermore, I would like to know if you see ways to improve the library in its current form without modifying the ABI/API. Last but not least, we can try to envision how an "ideal" libgcrypt would look like and see if we can find mechanisms that actually allow to implement it. This list of issues is losely sorted from easy to hard, and from high priority to low priority (from my perspective). Thanks, Marcus From gcrypt at dstoecker.de Thu Jan 12 09:36:12 2006 From: gcrypt at dstoecker.de (Dirk Stoecker) Date: Thu Jan 12 09:35:54 2006 Subject: memory leaks In-Reply-To: <1137040990.10596.22.camel@localhost.localdomain> References: <1137040990.10596.22.camel@localhost.localdomain> Message-ID: Hello, > > It includes the motivation for the patch, the way to download and apply it > > as well as compatibility considerations (and a note for usage in dynamic > > loading contexts). > > Your website expresses a lot of frustration. That is understandable, Well, I tried to keep the level low. Usually it is very frustrating when having a serious problem and being ignored completely. I am nevertheless required to have this page released due to the LGPL license of libgcrypt. > It is very important that we untangle unrelated issues. Your patch > contains different types of changes intermixed. One thing you can do to > push forward this issue is to split your patch into several different > patches so we can address them individually. That is a matter of fact, as it contains all the fixes necessary to get the stuff running in our environment. I will not spend any amount of time to make that perfectly seperated individual fixes when getting ignored. I really have not enough time to be wasted. Remove the finalization calls and the few related lines from the patch and you get all the other memory leak based fixes. I will no do it, as I need to assume it will get ignored again. > One such issue is finalization. It seems to me that your code does not > handle finalization correctly. Consider the following case: library bar > and baz both use libgcrypt. They both hide this fact from the > application. The application uses the library specific initializers > (bar_init and baz_init) which each initialize libgcrypt. Under certain > conditions this is perfectly legit, in fact, it is the only way > libgrcypt can be used correctly in such a situation. Now, imagine baz > comes with a finalizer, which calls the finalizer for gcrypt you added. > It seems to me from skimming over your patch that in this case gcrypt is > deinitialized. This will potentially break bar's use of gcrypt (I did > not check if it in fact does so). It thus seems to me that your > proposed solution in its current form is at best incomplete, and I don't > see a trivial fix. An fix would be to have an initialization and finalization counter and do delayed finalization. You have better insight into the topic to find out, how this would be needed to be implemented, as reference counting in the current state with automatic initializer calls is a bit complicated. Or simply forbid libraries to call finalize until a major redesign has been done. > Equally important would be to find a convincing story how such a major > revision could actually look like. Moritz does have some ideas about > how to restructure the code to make it more modular and less dependent > on global statics. However, some of the core issues are unresolved. We > have some ideas, but I don't think we have actually found the best > solution yet, and I am not sure what the best solution would look like. Well, the idea of libgcrypt 2 to have an context based approach will hopefully fix the related issues. Enforcing development in this area would surely help a lot. But if there is no Alpha or Beta software nobody will actually use it, you will not get comments and progress is slow. Projects die due to slow developments. Making an alpha release with interface description and design issues to solve would be a first step. > So here is how I suggest we proceed: If you can identify separate > issues in your patch, please report them as separate issues, so they can > be discussed separately. In particular, I want to understand if your > finalizer actually correctly solves the problem you identified (see > above). Furthermore, I would like to know if you see ways to improve > the library in its current form without modifying the ABI/API. Last but > not least, we can try to envision how an "ideal" libgcrypt would look > like and see if we can find mechanisms that actually allow to implement > it. This list of issues is losely sorted from easy to hard, and from > high priority to low priority (from my perspective). I detailed above, why I will not do this. It works for our use as static library. I followed the LGPL and released the code. I several times tried to contact the libgcrypt maintaining and did not succed, so for me the case is closed. The patch is public domain, so you may use it (or parts of it) as you want (including the necessarity to claim copyright by GNU). Or you do not. If there are questions, I will answer them. Ciao -- http://www.dstoecker.de/ (PGP key available) From Frediano.Ziglio at vodafone.com Thu Jan 12 10:09:43 2006 From: Frediano.Ziglio at vodafone.com (ZIGLIO, Frediano, VF-IT) Date: Thu Jan 12 10:57:43 2006 Subject: memory leaks Message-ID: Hi Marcus, > > On Sun, 2006-01-08 at 14:33 +0100, Dirk Stoecker wrote: > > as promised, I released the memory leak patch for gcrypt on > a webpage: > > > > http://www.dstoecker.de/gcrypt.html > > > > It includes the motivation for the patch, the way to > download and apply it > > as well as compatibility considerations (and a not for > usage in dynamic > > loading contexts). > > Your website expresses a lot of frustration. That is understandable, > but I think we should try to approach this issue > constructively. To do I think that after some months a people can be a bit frustated :) > so, we have to solve a complicated technical problem, given certain > policy constraints. If we can successfully identify these > constraints, > and potential solutions, we have won a lot. At least we will better > understand why certain changes are rejected, and if we can develop a > long term strategy. > > It is very important that we untangle unrelated issues. Your patch > contains different types of changes intermixed. One thing > you can do to > push forward this issue is to split your patch into several different > patches so we can address them individually. > I agree, there are changes like configure or syntax (comma after last enum entry) that are not related to finalization. > One such issue is finalization. It seems to me that your > code does not > handle finalization correctly. Consider the following case: > library bar > and baz both use libgcrypt. They both hide this fact from the > application. The application uses the library specific initializers > (bar_init and baz_init) which each initialize libgcrypt. > Under certain > conditions this is perfectly legit, in fact, it is the only way > libgrcypt can be used correctly in such a situation. Now, imagine baz > comes with a finalizer, which calls the finalizer for gcrypt > you added. > It seems to me from skimming over your patch that in this > case gcrypt is > deinitialized. This will potentially break bar's use of gcrypt (I did > not check if it in fact does so). It thus seems to me that your > proposed solution in its current form is at best incomplete, > and I don't > see a trivial fix. > The usual way to fix this issue are mainly two 1- use counter 2- init library at so init 1 is usually preferred (it work even with static library). It consist in using a counter in initialization. Counter is initially 0 and get incremented on initialization and decremented on deinit. Initialization occur only if you call init and counter get to 1 void init() { if (++counter != 1) return; ... init ... } while deinitialization occur if counter get 0 void deinit() { if (--counter != 0) return; ... deinit ... } (I not took into account thread problems) 2 require use of so. Just catch library load and initialize library and deinit only at library unload. Very difficult to port on Unix systems. > With regards to the current libgcrypt code, one overriding concern is > ABI/API compatibility. Irregardless of what we would _want_ > the code to > look like, the current libgcrypt version is used in dozens of > important > software packages, and making incompatible changes to the > ABI/API to the > _current_ version would need to be carefully justified. We feel that > extension of the applicability of the library to new use cases (like > dlopen'ed plugins) does not justify breaking existing use in dozens of > software packages. So any major changes, and my suspicion is that > cleaning up the allocation issues involves major changes if > it is to be > done right, would have to go into a major revision of the > whole package > including the ABI/API. This however raises a tail of other questions, > like how do we carry over the confidence (security wise) that > we have in > the current implementation to the hypothetical major revision, how can > its development be supported, etc? Well, current API is just broken for dlopen contexts... let me explain why. Assume that library A call gcry_set_allocation_handler... now any time you allocate memory inside libgcrypt you call alloc/free/realloc provided by library A. Now what happens if library B calls gcry_set_allocation_handler? Well, I think that all these globals should be removed (same problem for threadsafe callbacks). There are some solution to this problem - use only static library, any library that will use libgcrypt use a different libgcrypt library (this break ABI where you provide dynamic libraries) - use a single solution (malloc/free/realloc from libc, pthread where available) and do not use callbacks (ignoring settings), this keep ABI but you can have some problems mixing calls to gcry_malloc/free/realloc and "A malloc/free/realloc". - use a session structure to store callbacks and change all API to accept this session. This as you can imagine breaks API, however you can avoid this using a global session and adding new APIs while old one call new one adding global session, something like return_type old_function(parameters) { return new_function(global_session, parameters); } return_type new_function(session_type session, parameters) { ... do what you want ... } you can "implement " old function using macro to keep API but no ABI gcry_global_session_t gcry_global_session; #define old_function(a,b,c) new_function(gcry_global_session,a,b,c) This keep source compatibility. you can keep ABI providing 2 library: the old one and a new one, on new one (ie libgcrypting.so in Linux) we have only functions that use session like return_type new_function(session_type session, parameters) { ... } while old library (that keep old names, ie libgcrypt.so on Linux) return_type old_function(parameters) { return new_function(global_session, parameters); } You can also use a mix of define and libraries so old programs compiled with new libgcrypt will use new library just adding minimal changes (define a program session somewhere and call functions in old way) > > Equally important would be to find a convincing story how such a major > revision could actually look like. Moritz does have some ideas about > how to restructure the code to make it more modular and less dependent > on global statics. However, some of the core issues are > unresolved. We > have some ideas, but I don't think we have actually found the best > solution yet, and I am not sure what the best solution would > look like. > > So here is how I suggest we proceed: If you can identify separate > issues in your patch, please report them as separate issues, > so they can > be discussed separately. In particular, I want to understand if your > finalizer actually correctly solves the problem you identified (see > above). Furthermore, I would like to know if you see ways to improve > the library in its current form without modifying the > ABI/API. Last but > not least, we can try to envision how an "ideal" libgcrypt would look > like and see if we can find mechanisms that actually allow to > implement > it. This list of issues is losely sorted from easy to hard, and from > high priority to low priority (from my perspective). > > Thanks, > Marcus > bye Frediano Ziglio From marcus.brinkmann at ruhr-uni-bochum.de Thu Jan 12 14:29:09 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Jan 12 14:28:46 2006 Subject: memory leaks In-Reply-To: References: <1137040990.10596.22.camel@localhost.localdomain> Message-ID: <1137072549.12630.16.camel@localhost.localdomain> On Thu, 2006-01-12 at 09:36 +0100, Dirk Stoecker wrote: > I am > nevertheless required to have this page released due to the LGPL license > of libgcrypt. You are required to comply with the conditions of the LGPL. These conditions say nothing about a web page. > That is a matter of fact, as it contains all the fixes necessary to > get the stuff running in our environment. I will not spend any amount of > time to make that perfectly seperated individual fixes when getting > ignored. I really have not enough time to be wasted. If you want to have your patches applied to the main tree, then you are asked to submit patches for separat issues individually, so we can review them individually and accept/reject/ignore them on an individual basis. This also helps you, because you will decrease your chances of being ignored completely. You say you don't want to spend any amount of time to make the patches perfect and separate when getting ignored. However, why do you expect that we spend this time to make the patches perfect and separate if we don't even know what they would do? Developing free software cooperatively is not a game where one party tries to get the other party to do the work for you. We did not ask you to spend the work on these patches without prior discussion what would be a good way to accomplish your goal. Consecutively, I think it is a bit unfair to blame us for not accepting your patches and ignoring your work. > Remove the finalization calls and the few related lines from the patch > and you get all the other memory leak based fixes. I will no do it, as I > need to assume it will get ignored again. A quick glance shows that this is not true. For example, there is an unexplained modification to configure.ac. If you want a guideline for what a good policy is to follow when submitting patches, have a look at what is required from patch submitters to the glibc project. > > One such issue is finalization. It seems to me that your code does not > > handle finalization correctly. > > An fix would be to have an initialization and finalization counter > and do delayed finalization. I agree that this sounds like a promising strategy. > You have better insight into the topic to > find out, how this would be needed to be implemented, as reference > counting in the current state with automatic initializer calls is a bit > complicated. I don't understand what's complicated about it. Can you elaborate? > Well, the idea of libgcrypt 2 to have an context based approach will > hopefully fix the related issues. It might, but it's some time I talked to Moritz about it, and I don't know if he addressed the shared global resource issues and how. > Enforcing development in this area would surely help a lot. Development is not enforced. It is done voluntarily, and/or funded. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu Jan 12 14:51:38 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Jan 12 14:51:09 2006 Subject: memory leaks In-Reply-To: References: Message-ID: <1137073899.12630.28.camel@localhost.localdomain> On Thu, 2006-01-12 at 10:09 +0100, ZIGLIO, Frediano, VF-IT wrote: > The usual way to fix this issue are mainly two > 1- use counter > 2- init library at so init > > 1 is usually preferred (it work even with static library). Yeah, 1 seems to be better. > (I not took into account thread problems) That's not so hard to do, as (1) the first init has to be done before creating other threads using the library, and (2) all users must agree on the thread library to use. So you can implement the necessary mutex. > Well, current API is just broken for dlopen contexts... Yes. Also, the current API is very stable, in the sense that we don't want to modify it, for the reasons I gave. This means that we may not be able to fix this issue for you in the current version. > Assume that library A call gcry_set_allocation_handler... now any > time you allocate memory inside libgcrypt you call alloc/free/realloc > provided by library A. Now what happens if library B calls > gcry_set_allocation_handler? Well, I think that all these globals should > be removed (same problem for threadsafe callbacks). For the thread callbacks, this is not an issue, as you are required to use the same threadsafe callbacks in all users. We thought about it, and we could not think of a credible story where you would use more than one thread library in a single program. Do you know one? Allocation routines are a problem here, yes. > > There are some solution to this problem > - use only static library, any library that will use libgcrypt use a > different libgcrypt library (this break ABI where you provide dynamic > libraries) You need to elaborate on that. I suppose you mean linking with some sort of private scope, where every user gets their own copy of the library. This is possible on GNU platforms, as far as I know, but not at all portable. Am I wrong? > - use a single solution (malloc/free/realloc from libc, pthread where > available) and do not use callbacks (ignoring settings), this keep ABI > but you can have some problems mixing calls to gcry_malloc/free/realloc > and "A malloc/free/realloc". There are good reasons why some people want to avoid linking to pthread, so we can't just require it. Also, we want to retain support for GNU Pth. These are our design constraints. We considered creating library variants "libgcrypt-pthread" etc, but does this really solve anything? Would users start to introduce libopenldap-pthread, etc? > - use a session structure to store callbacks and change all API to > accept this session. This as you can imagine breaks API, however you can > avoid this using a global session and adding new APIs while old one call > new one adding global session, something like Yes. We are now talking about a new project, though. Ie, a major rewrite. Also, you can't just easily separate everything. You really want to share your random pool as much as possible, because otherwise you will be entropy drained very quickly. Thanks, Marcus From gcrypt at dstoecker.de Thu Jan 12 15:05:50 2006 From: gcrypt at dstoecker.de (Dirk Stoecker) Date: Thu Jan 12 15:05:26 2006 Subject: memory leaks In-Reply-To: <1137072549.12630.16.camel@localhost.localdomain> References: <1137040990.10596.22.camel@localhost.localdomain> <1137072549.12630.16.camel@localhost.localdomain> Message-ID: On Thu, 12 Jan 2006, Marcus Brinkmann wrote: > > I am > > nevertheless required to have this page released due to the LGPL license > > of libgcrypt. > > You are required to comply with the conditions of the LGPL. These > conditions say nothing about a web page. It is one of the cheapest forms of complying to LGPL/GPL. > being ignored completely. You say you don't want to spend any amount of > time to make the patches perfect and separate when getting ignored. > However, why do you expect that we spend this time to make the patches > perfect and separate if we don't even know what they would do? Because I already had multiple time bad experience and don't believe additional work will help. I will no longer discuss this part about who is to blame for what as like always this brings nothing for both sides. Any further discussions restricted to the helpful parts of technical issues. > > You have better insight into the topic to > > find out, how this would be needed to be implemented, as reference > > counting in the current state with automatic initializer calls is a bit > > complicated. > > I don't understand what's complicated about it. Can you elaborate? Reference counting would require exactly one INIT and one FINISH for each party using the software. As there are "automagically" initialisations in some calls, it may be complicated to track down different parties (e.g. libraries, which do no explicit init call). I do not know the internals well enough to decide how exact reference counting would be. It is always more complicated to implement such stuff in existing code, where it has not been designed from the very beginning. This greatly depends on the real world usage of libgcrypt. Probably a first step would be an assertion for these cases, so that the programmers get an information and implement explicit init and shutdown calls. In the time inbetween the finalize call would not release anything and a configuration option in autoconf would toogle dummy/real-mode. Maybe the best would be the introduction of "contexts" into the API/ABI as additional option and having a global context for legacy applications as Frediano explained in his mail. Using the deprecated attribute and proper texts how to fix it in the header file will make updating of legacy applications much easier. It would not break ABI and API. In 2-3 years the deprecated stuff and the global context can be removed (breaking the API) and the problem is solved. Thought before this the new API must be designed or there will be incompatible changes for libgcrypt 2 again. Ciao -- http://www.dstoecker.de/ (PGP key available) From misc at dstoecker.de Thu Jan 12 15:27:05 2006 From: misc at dstoecker.de (Dirk Stoecker) Date: Thu Jan 12 16:48:30 2006 Subject: memory leaks In-Reply-To: <1137073899.12630.28.camel@localhost.localdomain> References: <1137073899.12630.28.camel@localhost.localdomain> Message-ID: On Thu, 12 Jan 2006, Marcus Brinkmann wrote: > On Thu, 2006-01-12 at 10:09 +0100, ZIGLIO, Frediano, VF-IT wrote: > > - use a session structure to store callbacks and change all API to > > accept this session. This as you can imagine breaks API, however you can > > avoid this using a global session and adding new APIs while old one call > > new one adding global session, something like > > Yes. We are now talking about a new project, though. Ie, a major > rewrite. Also, you can't just easily separate everything. You really > want to share your random pool as much as possible, because otherwise > you will be entropy drained very quickly. It's not so much a major rewrite. Only the few calls to global variables must be redirect to context-based-calls. The sharing can be done library internal: - Only one global variable containing a list of contexts. - If there is already a context, the shared data is taken from it. - Only the last freed context releases the stuff. Thought this again introduces strange memory issues and must be threading save. I would prefer seperate contexts. There shouldn't be such a big difference if f.e. two plugins in one program use the library or you have two programs. Ciao -- http://www.dstoecker.de/ (PGP key available) From marcus.brinkmann at ruhr-uni-bochum.de Thu Jan 12 16:22:09 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Jan 12 17:21:41 2006 Subject: memory leaks In-Reply-To: References: <1137040990.10596.22.camel@localhost.localdomain> <1137072549.12630.16.camel@localhost.localdomain> Message-ID: <1137079329.14171.0.camel@localhost.localdomain> On Thu, 2006-01-12 at 15:05 +0100, Dirk Stoecker wrote: > On Thu, 12 Jan 2006, Marcus Brinkmann wrote: > > > You have better insight into the topic to > > > find out, how this would be needed to be implemented, as reference > > > counting in the current state with automatic initializer calls is a bit > > > complicated. > > > > I don't understand what's complicated about it. Can you elaborate? > > Reference counting would require exactly one INIT and one FINISH for each > party using the software. As there are "automagically" initialisations in > some calls, it may be complicated to track down different parties (e.g. > libraries, which do no explicit init call). I understand now, thank you for the explanation. Marcus From bradh at frogmouth.net Sat Jan 14 05:25:06 2006 From: bradh at frogmouth.net (Brad Hards) Date: Sat Jan 14 09:48:31 2006 Subject: Two key triple DES? Message-ID: <200601141525.12589.bradh@frogmouth.net> Is there an easier way to do two key triple DES in gcrypt than just manually duplicating the first key? 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/20060114/7181e638/attachment.pgp From giga at le-pec.org Sun Jan 15 13:45:13 2006 From: giga at le-pec.org (Jean-Philippe Garcia Ballester) Date: Sun Jan 15 15:48:24 2006 Subject: Using libgcrypt and a library using it Message-ID: <200601151345.23152.giga@le-pec.org> Hello ! We're using libgcrypt in a library that uses secure memory. We have a problem when a program that uses our library also uses libgcrypt. We're checking if libgcrypt has already been initialized, so that we don't initialize it again in the library. But what if it has already been initalized without secure memory? Is there something in gcry_control to check that, and the amount of secure memory (the documentation to gcry_control is either hard to find or inexistant)? Is there a solution to this problem other than saying to our users "if you use libgcrypt, please initialize that amount of secure memory"? Regards, -- Jean-Philippe Garcia Ballester -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060115/0c3e5de0/attachment.pgp From wk at gnupg.org Sun Jan 15 17:32:19 2006 From: wk at gnupg.org (Werner Koch) Date: Sun Jan 15 17:36:52 2006 Subject: Two key triple DES? In-Reply-To: <200601141525.12589.bradh@frogmouth.net> (Brad Hards's message of "Sat, 14 Jan 2006 15:25:06 +1100") References: <200601141525.12589.bradh@frogmouth.net> Message-ID: <87fynpsb8s.fsf@wheatstone.g10code.de> 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. Salam-Shalom, Werner From wk at gnupg.org Sun Jan 15 17:41:09 2006 From: wk at gnupg.org (Werner Koch) Date: Sun Jan 15 17:46:49 2006 Subject: Using libgcrypt and a library using it In-Reply-To: <200601151345.23152.giga@le-pec.org> (Jean-Philippe Garcia Ballester's message of "Sun, 15 Jan 2006 13:45:13 +0100") References: <200601151345.23152.giga@le-pec.org> Message-ID: <87bqydsau2.fsf@wheatstone.g10code.de> On Sun, 15 Jan 2006 13:45:13 +0100, Jean-Philippe Garcia Ballester said: > We're checking if libgcrypt has already been initialized, so that we don't > initialize it again in the library. But what if it has already been > initalized without secure memory? You mean by explictly disabling secure memory? Thn there is no way to change this later (due to the mlock restrictions when using Linux) > Is there something in gcry_control to check that, and the amount of secure > memory (the documentation to gcry_control is either hard to find or > inexistant)? Is there a solution to this problem other than saying No. There is only the GCRYCTL_DUMP_SECMEM_STATS but this does not help you program. Adding such a feature isn't hard and if you really need it, we can do so. Due to the problems with the secure memory I am currently thinking about an option to get rid of mlocked secure memory but keeping the automatic overwriting of that memory with a free. In case you have an encrypted swap. Shalom-Salam, Werner From giga at le-pec.org Sun Jan 15 18:00:36 2006 From: giga at le-pec.org (Jean-Philippe Garcia Ballester) Date: Sun Jan 15 18:00:10 2006 Subject: Using libgcrypt and a library using it In-Reply-To: <87bqydsau2.fsf@wheatstone.g10code.de> References: <200601151345.23152.giga@le-pec.org> <87bqydsau2.fsf@wheatstone.g10code.de> Message-ID: <200601151800.41736.giga@le-pec.org> On Sunday 15 January 2006 17:41, Werner Koch wrote: > On Sun, 15 Jan 2006 13:45:13 +0100, Jean-Philippe Garcia Ballester said: > > We're checking if libgcrypt has already been initialized, so that we > > don't initialize it again in the library. But what if it has already been > > initalized without secure memory? > > You mean by explictly disabling secure memory? Thn there is no way to > change this later (due to the mlock restrictions when using Linux) I mean in the program, there is just a call to : gcry_control(GCRYCTL_INITIALIZATION_FINISHED,0); In the library used by the program, there is if (!gcry_control(GCRYCTL_INITIALIZATION_FINISHED_P,0)){ gcry_control(GCRYCTL_INIT_SECMEM,524288,0); gcry_control(GCRYCTL_INITIALIZATION_FINISHED,0); } The gcry_control(GCRYCTL_INIT_SECMEM,524288,0) will not be done since libgcrypt has already been initialized. > > > Is there something in gcry_control to check that, and the amount of > > secure memory (the documentation to gcry_control is either hard to find > > or inexistant)? Is there a solution to this problem other than saying > > No. There is only the GCRYCTL_DUMP_SECMEM_STATS but this does not > help you program. Adding such a feature isn't hard and if you really > need it, we can do so. Not that it's really needed, but if some user initalize libgcrypt without initalizing secure memory, that would end up in bugs coming from our lib. The possibility to check if secure memory has been initialize and if there's enough and the possibility to initalize secure memory and adjust the size of secure memory after the call to gcry_control(GCRYCTL_INITIALIZATION_FINISHED,0) would prevent users to initialize libgcrypt in their programs like our library should do. -- Jean-Philippe Garcia Ballester -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060115/e065735f/attachment.pgp From wk at gnupg.org Mon Jan 16 16:40:20 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Jan 16 16:47:02 2006 Subject: Using libgcrypt and a library using it In-Reply-To: <200601151800.41736.giga@le-pec.org> (Jean-Philippe Garcia Ballester's message of "Sun, 15 Jan 2006 18:00:36 +0100") References: <200601151345.23152.giga@le-pec.org> <87bqydsau2.fsf@wheatstone.g10code.de> <200601151800.41736.giga@le-pec.org> Message-ID: <87u0c4npuj.fsf@wheatstone.g10code.de> On Sun, 15 Jan 2006 18:00:36 +0100, Jean-Philippe Garcia Ballester said: > gcry_control(GCRYCTL_INIT_SECMEM,524288,0); Are you really sure that you need 512k for secure memory? The algorithm to maintain that memory area is not very advanced and too many allocs/frees may slow those oeprations down. > The possibility to check if secure memory has been initialize and if there's > enough and the possibility to initalize secure memory and adjust the size of > secure memory after the call to > gcry_control(GCRYCTL_INITIALIZATION_FINISHED,0) would prevent users to That is unfortunately not possible. The whole mess with mlocking is that under Linux you need to have root rights or appropriate capabilities. After the initialization Libgcrypt will relinquish these permissions (unless you are running under root). There is at least one assertion to make sure that rights have been dropped. These mlock restrictions are really silly given that there so many other ways of eating up resources. The new approach to allow for a certain amount of locked memory seems to be more sensible to the problem but as of now we can't rely on it. Shalom-Salam, Werner From giga at le-pec.org Mon Jan 16 18:29:01 2006 From: giga at le-pec.org (Jean-Philippe Garcia Ballester) Date: Mon Jan 16 18:28:43 2006 Subject: Using libgcrypt and a library using it In-Reply-To: <87u0c4npuj.fsf@wheatstone.g10code.de> References: <200601151345.23152.giga@le-pec.org> <200601151800.41736.giga@le-pec.org> <87u0c4npuj.fsf@wheatstone.g10code.de> Message-ID: <200601161829.08366.giga@le-pec.org> On Monday 16 January 2006 16:40, Werner Koch wrote: > On Sun, 15 Jan 2006 18:00:36 +0100, Jean-Philippe Garcia Ballester said: > > gcry_control(GCRYCTL_INIT_SECMEM,524288,0); > > Are you really sure that you need 512k for secure memory? The > algorithm to maintain that memory area is not very advanced and too > many allocs/frees may slow those oeprations down. I'm not sure at all, and I would really much appreciate some explanations or advices, since I'm not an expert programmer, and I'm not sure to understand what should be in secure memory and what should not. We're developping a ssh library. I just made the port from libcrypto to libgcrypt, so for now, secure memory is only used with hashes and ciphers. Is this needed? It seems to me that encrypted packets are not highly confidential. I did not change the allocations for structures containing cryptographic keys, but shouldn't they be in secure memory? It seems also that hashes used in DH handshake should be in secure memory to, shouldn't they? What secure memory is needed, considering that we have no limitation on the number of ssh connections? I'm sorry to bother you, but some explanation would be of much help. I'll also take a look a the gsti library, but I'm not sure I'll understand why things are in secure memory or not. > > > The possibility to check if secure memory has been initialize and if > > there's enough and the possibility to initalize secure memory and adjust > > the size of secure memory after the call to > > gcry_control(GCRYCTL_INITIALIZATION_FINISHED,0) would prevent users to > > That is unfortunately not possible. The whole mess with mlocking is > that under Linux you need to have root rights or appropriate > capabilities. After the initialization Libgcrypt will relinquish > these permissions (unless you are running under root). There is at > least one assertion to make sure that rights have been dropped. > > These mlock restrictions are really silly given that there so many > other ways of eating up resources. The new approach to allow for a > certain amount of locked memory seems to be more sensible to the > problem but as of now we can't rely on it. Thanks a lot for this clear answer. -- Jean-Philippe Garcia Ballester -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060116/254af81e/attachment.pgp From whatever at fsrz.net Tue Jan 17 00:47:53 2006 From: whatever at fsrz.net (Rich Fought) Date: Tue Jan 17 02:48:23 2006 Subject: _gcry_ath_mutex_lock in GnuTLS Message-ID: <43CC30A9.4060802@fsrz.net> Hello everyone, I hope someone may be able to help me out here. I've got a multi-threaded server-type application using GnuTLS 1.2.9 and libgcrypt 1.2.2. Usually after about 5-10 minutes of hammering on it with simultaneous connections, I'm getting the dreaded ath.c:184: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)' failed. which tells me that perhaps libgcrypt is not being initialized properly for thread safety. Almost always this happens when two handshakes are happening concurrently. However, there are complicating factors. 1) I am using Haskell bindings to GnuTLS through foreign functions calls/imports (hsgnutls). There is an initilization routine being completed at the topmost level before any threads are being created (which looks OK given what I've found on the net) and the call to gnutls_global_init: GCRY_THREAD_OPTION_PTHREAD_IMPL; void gcry_init_helper(void) { gcry_control(GCRYCTL_DISABLE_SECMEM_WARN); gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0); gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); } Does this look OK? 2) These initialization functions (gcry_init_helper and gnutls_global_init) are also called with every new session creation in the Haskell bindings. I thought this was odd, but from what I've found this is not unheard of. gnutls_global_init should be fine, but what about gcry_init_helper? Shouldn't libgcrypt initialization only be done once? 3) The Haskell (Glasgow Haskell Compiler, to be specific) runtime threading model is a mix of Haskell light threads (for lack of a better term) running in the same single OS thread, and actual OS threads depending on how they are forked (and if any foreign calls are in the thread). I've made sure that all threads handling TLS handshakes are bound to dedicated OS threads (pthreads, BTW). The error still persists. Perhaps all threads that access any libgcrypt library functions should be bound so? A gdb dump is attached. TIA, Rich ------------------------------------------- ath.c:184: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 1933321 (LWP 22018)] 0x005d5bd1 in kill () from /lib/i686/libc.so.6 Thread 120 (Thread 1933321 (LWP 22018)): #0 0x005d5bd1 in kill () from /lib/i686/libc.so.6 #1 0x00433251 in pthread_kill () from /lib/i686/libpthread.so.0 #2 0x004335bb in raise () from /lib/i686/libpthread.so.0 #3 0x005d5838 in raise () from /lib/i686/libc.so.6 #4 0x005d6e80 in abort () from /lib/i686/libc.so.6 #5 0x005ce821 in __assert_fail () from /lib/i686/libc.so.6 #6 0x00119449 in _gcry_ath_mutex_lock (lock=0x157908) at ath.c:180 #7 0x0011d880 in gcry_pk_decrypt (r_plain=0x2b68c4c, s_data=0x82e33a0, s_skey=0x82e35d8) at pubkey.c:1502 #8 0x00b2b101 in _gnutls_pk_decrypt () from /usr/local/lib/libgnutls.so.12 #9 0x00b2a0ba in _gnutls_pkcs1_rsa_decrypt () from /usr/local/lib/libgnutls.so.12 #10 0x00b2803a in _gnutls_proc_rsa_client_kx () from /usr/local/lib/libgnutls.so.12 #11 0x00b2166f in _gnutls_recv_client_kx_message () from /usr/local/lib/libgnutls.so.12 #12 0x00b1dc90 in _gnutls_handshake_server () from /usr/local/lib/libgnutls.so.12 #13 0x00b1c696 in gnutls_handshake () from /usr/local/lib/libgnutls.so.12 #14 0x0818f4ac in rbbY_info () #15 0xb7e2e5c0 in ?? () #16 0x00000000 in ?? () Thread 119 (Thread 1916936 (LWP 22014)): #0 0x004321b0 in pthread_handle_sigrestart () from /lib/i686/libpthread.so.0 #1 #2 0x004330d4 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0 #3 0x00432708 in __pthread_wait_for_restart_signal () from /lib/i686/libpthread.so.0 #4 0x00434720 in __pthread_alt_lock () from /lib/i686/libpthread.so.0 #5 0x0043114e in pthread_mutex_lock () from /lib/i686/libpthread.so.0 #6 0x0060fe53 in free () from /lib/i686/libc.so.6 #7 0x00115dbc in gcry_free (p=0x438ff4) at global.c:487 #8 0x00148248 in _gcry_mpi_free_limb_space (a=0x8, nlimbs=4294967292) at mpiutil.c:102 #9 0x0014835d in _gcry_mpi_free (a=0xb7e23990) at mpiutil.c:158 #10 0x001438bd in gcry_mpi_sub (w=0xb7e06070, u=0xb7e101c0, v=0xb7e1c658) at mpi-add.c:219 #11 0x001449d1 in _gcry_mpi_invm (x=0xb7e11640, a=0xb7e26260, n=0xb7e357f8) at mpi-inv.c:242 #12 0x00144cb5 in gcry_mpi_invm (x=0xb7e11640, a=0xb7e26260, n=0xb7e357f8) at mpi-inv.c:273 #13 0x0013a46d in _gcry_rsa_decrypt (algo=1, result=0xfffffffc, data=0xb7e291a0, skey=0x438ff4, flags=0) at rsa.c:531 #14 0x0011bfb2 in pubkey_decrypt (algorithm=1, result=0x5478bf8, data=0xb7e291a0, skey=0xb7e570b0, flags=0) at pubkey.c:594 #15 0x0011d9fc in gcry_pk_decrypt (r_plain=0x5478c4c, s_data=0xb7e58880, s_skey=0xb7e05e20) at pubkey.c:1521 #16 0x00b2b101 in _gnutls_pk_decrypt () from /usr/local/lib/libgnutls.so.12 #17 0x00b2a0ba in _gnutls_pkcs1_rsa_decrypt () from /usr/local/lib/libgnutls.so.12 #18 0x00b2803a in _gnutls_proc_rsa_client_kx () from /usr/local/lib/libgnutls.so.12 #19 0x00b2166f in _gnutls_recv_client_kx_message () from /usr/local/lib/libgnutls.so.12 #20 0x00b1dc90 in _gnutls_handshake_server () from /usr/local/lib/libgnutls.so.12 #21 0x00b1c696 in gnutls_handshake () from /usr/local/lib/libgnutls.so.12 #22 0x0818f4ac in rbbY_info () #23 0xb7e30a28 in ?? () #24 0x00000000 in ?? () Thread 118 (Thread 1900552 (LWP 21959)): #0 0x004321b0 in pthread_handle_sigrestart () from /lib/i686/libpthread.so.0 #1 #2 0x004330d4 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0 #3 0x00432708 in __pthread_wait_for_restart_signal () from /lib/i686/libpthread.so.0 #4 0x00434720 in __pthread_alt_lock () from /lib/i686/libpthread.so.0 #5 0x0043114e in pthread_mutex_lock () from /lib/i686/libpthread.so.0 #6 0x0060fe53 in free () from /lib/i686/libc.so.6 #7 0x00115dbc in gcry_free (p=0x438ff4) at global.c:487 #8 0x00148248 in _gcry_mpi_free_limb_space (a=0x8, nlimbs=4294967292) at mpiutil.c:102 #9 0x0014835d in _gcry_mpi_free (a=0xb7e23990) at mpiutil.c:158 #10 0x001438bd in gcry_mpi_sub (w=0xb7e06070, u=0xb7e101c0, v=0xb7e1c658) at mpi-add.c:219 #11 0x001449d1 in _gcry_mpi_invm (x=0xb7e11640, a=0xb7e26260, n=0xb7e357f8) at mpi-inv.c:242 #12 0x00144cb5 in gcry_mpi_invm (x=0xb7e11640, a=0xb7e26260, n=0xb7e357f8) at mpi-inv.c:273 #13 0x0013a46d in _gcry_rsa_decrypt (algo=1, result=0xfffffffc, data=0xb7e291a0, skey=0x438ff4, flags=0) at rsa.c:531 #14 0x0011bfb2 in pubkey_decrypt (algorithm=1, result=0x5478bf8, data=0xb7e291a0, skey=0xb7e570b0, flags=0) at pubkey.c:594 #15 0x0011d9fc in gcry_pk_decrypt (r_plain=0x5478c4c, s_data=0xb7e58880, s_skey=0xb7e05e20) at pubkey.c:1521 #16 0x00b2b101 in _gnutls_pk_decrypt () from /usr/local/lib/libgnutls.so.12 #17 0x00b2a0ba in _gnutls_pkcs1_rsa_decrypt () from /usr/local/lib/libgnutls.so.12 #18 0x00b2803a in _gnutls_proc_rsa_client_kx () from /usr/local/lib/libgnutls.so.12 #19 0x00b2166f in _gnutls_recv_client_kx_message () from /usr/local/lib/libgnutls.so.12 #20 0x00b1dc90 in _gnutls_handshake_server () from /usr/local/lib/libgnutls.so.12 #21 0x00b1c696 in gnutls_handshake () from /usr/local/lib/libgnutls.so.12 #22 0x0818f4ac in rbbY_info () #23 0xb7e30a28 in ?? () #24 0x00000000 in ?? () From wk at gnupg.org Tue Jan 17 11:08:00 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Jan 17 11:11:49 2006 Subject: _gcry_ath_mutex_lock in GnuTLS In-Reply-To: <43CC30A9.4060802@fsrz.net> (Rich Fought's message of "Mon, 16 Jan 2006 17:47:53 -0600") References: <43CC30A9.4060802@fsrz.net> Message-ID: <87mzhv5fr3.fsf@wheatstone.g10code.de> On Mon, 16 Jan 2006 17:47:53 -0600, Rich Fought said: > GCRY_THREAD_OPTION_PTHREAD_IMPL; > void gcry_init_helper(void) { > gcry_control(GCRYCTL_DISABLE_SECMEM_WARN); > gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0); > gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); Swap the last two calls. Setting the threading model must be the very first operation. Calling DISABLE_SECMEN_WARN earlier is okay as it only sets a flag. Make sure that gcry_init_helper is called before the first thread accesses Libgcrypt. You should also rename gcry_init_helper because it uses Libgcrypt's namespace. > but what about gcry_init_helper? Shouldn't libgcrypt initialization only > be done once? Yes. However, INIT_SECMEM should simply fail and the other calls protect themself. Salam-Shalom, Werner From wk at gnupg.org Tue Jan 17 11:28:31 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Jan 17 11:31:53 2006 Subject: Using libgcrypt and a library using it In-Reply-To: <200601161829.08366.giga@le-pec.org> (Jean-Philippe Garcia Ballester's message of "Mon, 16 Jan 2006 18:29:01 +0100") References: <200601151345.23152.giga@le-pec.org> <200601151800.41736.giga@le-pec.org> <87u0c4npuj.fsf@wheatstone.g10code.de> <200601161829.08366.giga@le-pec.org> Message-ID: <87irsj5esw.fsf@wheatstone.g10code.de> On Mon, 16 Jan 2006 18:29:01 +0100, Jean-Philippe Garcia Ballester said: > libgcrypt, so for now, secure memory is only used with hashes and ciphers. Is > this needed? It seems to me that encrypted packets are not highly I can';t tell. It depends on your threat model. > confidential. I did not change the allocations for structures containing > cryptographic keys, but shouldn't they be in secure memory? It seems also It depends on the keys and whether you expect atatckers to be able to read the swap space. For session keys and DH secrets I doubt that it is needed at all. > I'm sorry to bother you, but some explanation would be of much help. I'll also > take a look a the gsti library, but I'm not sure I'll understand why things > are in secure memory or not. GSTI does not make use of secure memory at all. However Libcgrypt itself uses secure memory for certain operations. Thus there is a way to initialize it; that code is pretty old and not as it should be. What you should do ist to decide whether there are any long living keys (host key, user key) and they are sensible enough to have an extra protection. In this case, use gcry_malloc_secure for these secret keys. I'd do that. For session keys, MACs and such I doubt that under common threat models it makes sense to use this secure memory. One advantage of the secure memory is that the gcry_free will overwrite the release memory and saves you a "burn" call. For failsafe reasons I tend to add a burn call anyway before doing a free - if I know that the releaed memory has sensitive data and I know the size of the memeory block at that point. Shalom-Salam, Werner From bradh at frogmouth.net Wed Jan 18 11:55:04 2006 From: bradh at frogmouth.net (Brad Hards) Date: Wed Jan 18 13:43:56 2006 Subject: [patch] OFB implementation Message-ID: <200601182155.13770.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/20060118/bc87862f/attachment-0001.pgp From wk at gnupg.org Wed Jan 18 17:39:50 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Jan 18 17:41:48 2006 Subject: [patch] OFB implementation In-Reply-To: <200601182155.13770.bradh@frogmouth.net> (Brad Hards's message of "Wed, 18 Jan 2006 21:55:04 +1100") References: <200601182155.13770.bradh@frogmouth.net> Message-ID: <87irshxzft.fsf@wheatstone.g10code.de> On Wed, 18 Jan 2006 21:55:04 +1100, Brad Hards said: > This will obviously have to wait until my copyright assignment form is > processed, but I thought I'd put it out for initial review and comment. I'll check the copyright list in a few days and will then apply your patches. Many thanks, Werner From jas at extundo.com Thu Jan 19 11:17:03 2006 From: jas at extundo.com (Simon Josefsson) Date: Thu Jan 19 12:48:30 2006 Subject: cross-compiling to mingw32 Message-ID: I'm trying to get GnuTLS working under mingw32 again, but I can't seem to get libgcrypt 1.2.2 to build. libgpg-error 1.1 built fine. The cipher/ and src/ directories build fine, but the tests/ fails. The resulting library isn't usable, it seems all symbols are prefixed with an unnecessary '_' if I run 'nm' on it. Any ideas? Building libgsasl against the generated libgcrypt fails with similar errors: i586-mingw32msvc-gcc -g -O2 -o test-gc-hmac-md5.exe test-gc-hmac-md5.o ../gl/.libs/libgl.a -L/usr/local/w32root//lib /usr/local/w32root//lib/libgcrypt.a /usr/local/w32root//lib/libgpg-error.a /usr/local/w32root//lib/libgcrypt.a(mpi-bit.o): In function `gcry_mpi_rshift': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-bit.c:206: undefined reference to `__gcry_mpih_rshift' /usr/local/w32root//lib/libgcrypt.a(mpi-div.o): In function `_gcry_mpi_tdiv_qr':/home/jas/src/libgcrypt-1.2.2/mpi/mpi-div.c:223: undefined reference to `__gcry_mpih_lshift' Libgsasl without libgcrypt builds fine and work fine from both self-tests and on Windows, so I have confidence in the compiler. I'm using current mingw32 from Debian testing. Build log of libgcrypt 1.2.2 below. Thanks! jas@latte:~/src/libgcrypt-1.2.2$ ./configure --host=i586-mingw32msvc --prefix=/usr/local/w32root/ --with-gpg-error-prefix=/usr/local/w32root/ configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking build system type... i686-pc-linux-gnu checking host system type... i586-pc-mingw32msvc checking target system type... i586-pc-mingw32msvc checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for i586-mingw32msvc-strip... i586-mingw32msvc-strip checking whether to enable maintainer-specific portions of Makefiles... no checking whether make sets $(MAKE)... (cached) yes checking for i586-mingw32msvc-gcc... i586-mingw32msvc-gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether i586-mingw32msvc-gcc accepts -g... yes checking for i586-mingw32msvc-gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of i586-mingw32msvc-gcc... gcc3 checking how to run the C preprocessor... i586-mingw32msvc-gcc -E checking for library containing strerror... none required checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... (cached) gawk checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by i586-mingw32msvc-gcc... /usr/i586-mingw32msvc/bin/ld checking if the linker (/usr/i586-mingw32msvc/bin/ld) is GNU ld... yes checking for /usr/i586-mingw32msvc/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/i586-mingw32msvc-nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... file_magic file format pei*-i386(.*architecture: i386)? checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... no checking dlfcn.h presence... no checking for dlfcn.h... no checking for i586-mingw32msvc-g++... i586-mingw32msvc-g++ checking whether we are using the GNU C++ compiler... yes checking whether i586-mingw32msvc-g++ accepts -g... yes checking dependency style of i586-mingw32msvc-g++... gcc3 checking how to run the C++ preprocessor... i586-mingw32msvc-g++ -E checking for i586-mingw32msvc-g77... no checking for i586-mingw32msvc-f77... no checking for i586-mingw32msvc-xlf... no checking for i586-mingw32msvc-frt... no checking for i586-mingw32msvc-pgf77... no checking for i586-mingw32msvc-fort77... no checking for i586-mingw32msvc-fl32... no checking for i586-mingw32msvc-af77... no checking for i586-mingw32msvc-f90... no checking for i586-mingw32msvc-xlf90... no checking for i586-mingw32msvc-pgf90... no checking for i586-mingw32msvc-epcf90... no checking for i586-mingw32msvc-f95... no checking for i586-mingw32msvc-fort... no checking for i586-mingw32msvc-xlf95... no checking for i586-mingw32msvc-ifc... no checking for i586-mingw32msvc-efc... no checking for i586-mingw32msvc-pgf95... no checking for i586-mingw32msvc-lf95... no checking for i586-mingw32msvc-gfortran... no checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/i586-mingw32msvc-nm -B output from i586-mingw32msvc-gcc object... ok checking for objdir... .libs checking for i586-mingw32msvc-ar... i586-mingw32msvc-ar checking for i586-mingw32msvc-ranlib... i586-mingw32msvc-ranlib checking for i586-mingw32msvc-strip... (cached) i586-mingw32msvc-strip checking if i586-mingw32msvc-gcc static flag works... yes checking if i586-mingw32msvc-gcc supports -fno-rtti -fno-exceptions... no checking for i586-mingw32msvc-gcc option to produce PIC... -DDLL_EXPORT checking if i586-mingw32msvc-gcc PIC flag -DDLL_EXPORT works... yes checking if i586-mingw32msvc-gcc supports -c -o file.o... yes checking whether the i586-mingw32msvc-gcc linker (/usr/i586-mingw32msvc/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by i586-mingw32msvc-g++... /usr/i586-mingw32msvc/bin/ld checking if the linker (/usr/i586-mingw32msvc/bin/ld) is GNU ld... yes checking whether the i586-mingw32msvc-g++ linker (/usr/i586-mingw32msvc/bin/ld) supports shared libraries... yes checking for i586-mingw32msvc-g++ option to produce PIC... -DDLL_EXPORT checking if i586-mingw32msvc-g++ PIC flag -DDLL_EXPORT works... yes checking if i586-mingw32msvc-g++ supports -c -o file.o... yes checking whether the i586-mingw32msvc-g++ linker (/usr/i586-mingw32msvc/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking whether byte ordering is bigendian... no checking for unsigned short... yes checking size of unsigned short... 2 checking for unsigned int... yes checking size of unsigned int... 4 checking for unsigned long... yes checking size of unsigned long... 4 checking for unsigned long long... yes checking size of unsigned long long... 8 configure: WARNING: No 64-bit types. Disabling TIGER/192, SHA-384, and SHA-512 checking which symmetric ciphers to include... arcfour blowfish cast5 des aes twofish serpent rfc2268 checking which public-key ciphers to include... dsa elgamal rsa checking which message digests to include... crc md4 md5 rmd160 sha1 sha256 checking which random module to use... default checking whether use of /dev/random is requested... yes checking whether assembler modules are requested... yes checking whether memory guard is requested... no checking whether use of capabilities is requested... no checking whether non excutable stack support is requested... no checking for gpg-error-config... /usr/local/w32root//bin/gpg-error-config checking for GPG Error - version >= 0.5... yes checking for gethostbyname in -lnsl... no checking for socket in -lsocket... no checking for gethostbyname in -lnsl... (cached) no checking for ANSI C header files... (cached) yes checking for unistd.h... (cached) yes checking sys/select.h usability... no checking sys/select.h presence... no checking for sys/select.h... no checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking return type of signal handlers... void checking whether sys_siglist is declared... no checking for byte typedef... no checking for ushort typedef... no checking for ulong typedef... no checking for u16 typedef... no checking for u32 typedef... no checking for socklen_t... no checking for vprintf... yes checking for _doprnt... no checking for stpcpy... no checking for strcasecmp... yes checking for strtoul... yes checking for memmove... yes checking for stricmp... yes checking for atexit... yes checking for raise... yes checking for strerror... yes checking for rand... yes checking for mmap... no checking for getpagesize... yes checking for waitpid... no checking for wait4... no checking for gettimeofday... no checking for getrusage... no checking for gethrtime... no checking for clock_gettime... no checking for mlock... no checking sys/mman.h usability... no checking sys/mman.h presence... no checking for sys/mman.h... no checking for random device... (cached) no checking for _ prefix in compiled symbols... no checking for mpi assembler functions... done configure: creating ./config.status config.status: creating Makefile config.status: creating mpi/Makefile config.status: creating cipher/Makefile config.status: creating doc/Makefile config.status: creating src/Makefile config.status: creating src/libgcrypt-config config.status: creating tests/Makefile config.status: creating w32-dll/Makefile config.status: creating config.h config.status: linking ./mpi/i586/mpih-add1.S to mpi/mpih-add1.S config.status: linking ./mpi/i586/mpih-sub1.S to mpi/mpih-sub1.S config.status: linking ./mpi/i586/mpih-mul1.S to mpi/mpih-mul1.S config.status: linking ./mpi/i586/mpih-mul2.S to mpi/mpih-mul2.S config.status: linking ./mpi/i586/mpih-mul3.S to mpi/mpih-mul3.S config.status: linking ./mpi/i586/mpih-lshift.S to mpi/mpih-lshift.S config.status: linking ./mpi/i586/mpih-rshift.S to mpi/mpih-rshift.S config.status: linking ./mpi/generic/mpi-asm-defs.h to mpi/mpi-asm-defs.h config.status: executing depfiles commands config.status: executing gcrypt-conf commands Configured for: MingW32 (i586-pc-mingw32msvc) jas@latte:~/src/libgcrypt-1.2.2$ jas@latte:~/src/libgcrypt-1.2.2$ make ... make[2]: Entering directory `/home/jas/src/libgcrypt-1.2.2/tests' if i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I/usr/local/w32root//include -g -O2 -Wall -MT prime.o -MD -MP -MF ".deps/prime.Tpo" -c -o prime.o prime.c; \ then mv -f ".deps/prime.Tpo" ".deps/prime.Po"; else rm -f ".deps/prime.Tpo"; exit 1; fi /bin/sh ../libtool --tag=CC --mode=link i586-mingw32msvc-gcc -I/usr/local/w32root//include -g -O2 -Wall -o prime.exe prime.o ../src/libgcrypt.la mkdir .libs i586-mingw32msvc-gcc -I/usr/local/w32root//include -g -O2 -Wall -o prime.exe prime.o ../src/.libs/libgcrypt.a -L/usr/local/w32root//lib /usr/local/w32root//lib/libgpg-error.a ../src/.libs/libgcrypt.a(mpi-add.o): In function `gcry_mpi_add': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-inline.h:118: undefined reference to `__gcry_mpih_sub_n' ../src/.libs/libgcrypt.a(mpi-add.o): In function `gcry_mpi_add': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-add.c:140: undefined reference to `__gcry_mpih_sub_n' ../src/.libs/libgcrypt.a(mpi-add.o): In function `gcry_mpi_add': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-inline.h:72: undefined reference to `__gcry_mpih_add_n' ../src/.libs/libgcrypt.a(mpi-add.o): In function `gcry_mpi_add': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-add.c:133: undefined reference to `__gcry_mpih_sub_n' ../src/.libs/libgcrypt.a(mpi-div.o): In function `_gcry_mpi_tdiv_qr': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-div.c:223: undefined reference to `__gcry_mpih_lshift' /home/jas/src/libgcrypt-1.2.2/mpi/mpi-div.c:229: undefined reference to `__gcry_mpih_lshift' /home/jas/src/libgcrypt-1.2.2/mpi/mpi-div.c:274: undefined reference to `__gcry_mpih_rshift' ../src/.libs/libgcrypt.a(mpi-div.o): In function `_gcry_mpi_tdiv_q_2exp': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-div.c:308: undefined reference to `__gcry_mpih_rshift' ../src/.libs/libgcrypt.a(mpi-bit.o): In function `gcry_mpi_rshift': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-bit.c:206: undefined reference to `__gcry_mpih_rshift' ../src/.libs/libgcrypt.a(mpi-pow.o): In function `gcry_mpi_powm': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-pow.c:92: undefined reference to `__gcry_mpih_lshift' /home/jas/src/libgcrypt-1.2.2/mpi/mpi-pow.c:258: undefined reference to `__gcry_mpih_lshift' /home/jas/src/libgcrypt-1.2.2/mpi/mpi-pow.c:277: undefined reference to `__gcry_mpih_rshift' ../src/.libs/libgcrypt.a(mpi-pow.o): In function `gcry_mpi_powm': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-inline.h:118: undefined reference to `__gcry_mpih_sub_n' ../src/.libs/libgcrypt.a(mpi-pow.o): In function `gcry_mpi_powm': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-pow.c:285: undefined reference to `__gcry_mpih_rshift' ../src/.libs/libgcrypt.a(mpi-mul.o): In function `gcry_mpi_mul_ui': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-mul.c:55: undefined reference to `__gcry_mpih_mul_1' ../src/.libs/libgcrypt.a(mpi-mul.o): In function `_gcry_mpi_mul_2exp': /home/jas/src/libgcrypt-1.2.2/mpi/mpi-mul.c:90: undefined reference to `__gcry_mpih_lshift' ../src/.libs/libgcrypt.a(mpih-div.o): In function `_gcry_mpih_divrem': /home/jas/src/libgcrypt-1.2.2/mpi/mpih-div.c:322: undefined reference to `__gcry_mpih_sub_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-div.c:367: undefined reference to `__gcry_mpih_submul_1' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-div.c:370: undefined reference to `__gcry_mpih_add_n' ../src/.libs/libgcrypt.a(mpih-mul.o): In function `mul_n_basecase': /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:106: undefined reference to `__gcry_mpih_addmul_1' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:91: undefined reference to `__gcry_mpih_mul_1' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:103: undefined reference to `__gcry_mpih_add_n' ../src/.libs/libgcrypt.a(mpih-mul.o): In function `mul_n': /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:135: undefined reference to `__gcry_mpih_addmul_1' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:137: undefined reference to `__gcry_mpih_addmul_1' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:171: undefined reference to `__gcry_mpih_sub_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:179: undefined reference to `__gcry_mpih_sub_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:194: undefined reference to `__gcry_mpih_add_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:199: undefined reference to `__gcry_mpih_sub_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:213: undefined reference to `__gcry_mpih_add_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:218: undefined reference to `__gcry_mpih_add_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:201: undefined reference to `__gcry_mpih_add_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:175: undefined reference to `__gcry_mpih_sub_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:183: undefined reference to `__gcry_mpih_sub_n' ../src/.libs/libgcrypt.a(mpih-mul.o): In function `_gcry_mpih_sqr_n_basecase': /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:258: undefined reference to `__gcry_mpih_addmul_1' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:243: undefined reference to `__gcry_mpih_mul_1' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:255: undefined reference to `__gcry_mpih_add_n' ../src/.libs/libgcrypt.a(mpih-mul.o): In function `_gcry_mpih_sqr_n': /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:285: undefined reference to `__gcry_mpih_addmul_1' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:287: undefined reference to `__gcry_mpih_addmul_1' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:308: undefined reference to `__gcry_mpih_sub_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:317: undefined reference to `__gcry_mpih_add_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:321: undefined reference to `__gcry_mpih_sub_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:331: undefined reference to `__gcry_mpih_add_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:337: undefined reference to `__gcry_mpih_add_n' ../src/.libs/libgcrypt.a(mpih-mul.o): In function `_gcry_mpih_mul': /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:515: undefined reference to `__gcry_mpih_addmul_1' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:512: undefined reference to `__gcry_mpih_add_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:500: undefined reference to `__gcry_mpih_mul_1' ../src/.libs/libgcrypt.a(mpih-mul.o): In function `_gcry_mpih_mul_karatsuba_case': /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:412: undefined reference to `__gcry_mpih_add_n' /home/jas/src/libgcrypt-1.2.2/mpi/mpih-mul.c:434: undefined reference to `__gcry_mpih_add_n' collect2: ld returned 1 exit status make[2]: *** [prime.exe] Error 1 make[2]: Leaving directory `/home/jas/src/libgcrypt-1.2.2/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jas/src/libgcrypt-1.2.2' make: *** [all] Error 2 jas@latte:~/src/libgcrypt-1.2.2$ From wk at gnupg.org Fri Jan 20 10:38:46 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Jan 20 10:41:46 2006 Subject: cross-compiling to mingw32 In-Reply-To: (Simon Josefsson's message of "Thu, 19 Jan 2006 11:17:03 +0100") References: Message-ID: <87hd7ztf15.fsf@wheatstone.g10code.de> On Thu, 19 Jan 2006 11:17:03 +0100, Simon Josefsson said: > resulting library isn't usable, it seems all symbols are prefixed with > an unnecessary '_' if I run 'nm' on it. Any ideas? Check the output of GNUPG_SYS_SYMBOL_UNDERSCORE() in configure.ac it is later used in mpi/config.links to generate sysdep.h: if test x$ac_cv_sys_symbol_underscore = xyes; then A special case for mingw32 might be justified. Alternativly you ./configure --disable-asm should work too. The stable branch has an option to build libgcrypt as a static library; from ./autogen.sh --build-w32: ./configure --enable-maintainer-mode --prefix=${w32root} \ --host=i586-mingw32msvc --build=${build} \ --with-gpg-error-prefix=${w32root} \ --disable-shared IIRC I had some problems with DLL creation at that time and thus i used a static library for porting gnupg 1.9: > Libgsasl without libgcrypt builds fine and work fine from both > self-tests and on Windows, so I have confidence in the compiler. I'm Indeed, that works pretty well I have even dripeed support for my own corss compiling kity in the meantime. I can build most of my software now for W32 As well as Sylpheed-claws. BTW, I always use the option --build-w32 for autogen.sh to record the configure options required for a W32 build and to test for available compilers etc. If you want to build and publish a DLL, libtool works fine; see gpgme or libgpg-error for details. Salam-Shalom, Werner From jas at extundo.com Fri Jan 20 14:21:43 2006 From: jas at extundo.com (Simon Josefsson) Date: Fri Jan 20 14:21:54 2006 Subject: cross-compiling to mingw32 In-Reply-To: <87hd7ztf15.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 20 Jan 2006 10:38:46 +0100") References: <87hd7ztf15.fsf@wheatstone.g10code.de> Message-ID: Werner Koch writes: > On Thu, 19 Jan 2006 11:17:03 +0100, Simon Josefsson said: > >> resulting library isn't usable, it seems all symbols are prefixed with >> an unnecessary '_' if I run 'nm' on it. Any ideas? > > Check the output of > > GNUPG_SYS_SYMBOL_UNDERSCORE() > > in configure.ac it is later used in mpi/config.links to generate sysdep.h: > > if test x$ac_cv_sys_symbol_underscore = xyes; then > > A special case for mingw32 might be justified. Alternativly you > > ./configure --disable-asm That seem to work fine, thanks! The self tests doesn't build, although I suppose that is a minor issue. I'm pretty sure I have tried that before, and failed, but most likely the mingw32 packages have evolved meantime. Regards, Simon From whatever at fsrz.net Fri Jan 20 23:20:30 2006 From: whatever at fsrz.net (Rich Fought) Date: Fri Jan 20 23:20:17 2006 Subject: _gcry_ath_mutex_lock in GnuTLS In-Reply-To: <87mzhv5fr3.fsf@wheatstone.g10code.de> References: <43CC30A9.4060802@fsrz.net> <87mzhv5fr3.fsf@wheatstone.g10code.de> Message-ID: <43D1622E.2080708@fsrz.net> Werner Koch wrote: > >> void gcry_init_helper(void) { >> gcry_control(GCRYCTL_DISABLE_SECMEM_WARN); >> gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0); >> gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); >> > > Swap the last two calls. Setting the threading model must be the very > first operation. Calling DISABLE_SECMEN_WARN earlier is okay as it > only sets a flag. Make sure that gcry_init_helper is called before > the first thread accesses Libgcrypt. > Thanks, I *think* that did the trick. Time will tell ... Regards, Rich From joel.vennin at gmail.com Sun Jan 29 23:46:18 2006 From: joel.vennin at gmail.com (joel vennin) Date: Mon Jan 30 10:43:36 2006 Subject: Hexa format Message-ID: <88a64070601291446h3ca86ef7k@mail.gmail.com> Hello, i'm a new user of the gcrypt library. It is a really great library with really lots of feature. So thank you for you job ! I've just a simple question for you, i would like to know if there is a function inside the gcrypt library to convert digest buffer to a hexa string representation. In fact, i'm using the gcry_md_hash_buffer function and i want to display on the screen the hexa representation of the digest buffer. I've got another question, i want to know what it is more efficient: - use the gcry_md_hash_buffer function - or use the set of functions: - gcry_md_write - gcry_md_read Thank you ! I've you can send me the email to my box because i've not subcribed to the ML From wk at gnupg.org Mon Jan 30 12:46:21 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Jan 30 12:51:57 2006 Subject: Hexa format In-Reply-To: <88a64070601291446h3ca86ef7k@mail.gmail.com> (joel vennin's message of "Sun, 29 Jan 2006 23:46:18 +0100") References: <88a64070601291446h3ca86ef7k@mail.gmail.com> Message-ID: <87u0bm546q.fsf@wheatstone.g10code.de> On Sun, 29 Jan 2006 23:46:18 +0100, joel vennin said: > hexa string representation. In fact, i'm using the gcry_md_hash_buffer > function and i want to display on the screen the hexa representation > of the digest buffer. No, there is no such function. > I've got another question, i want to know what it is more efficient: > - use the gcry_md_hash_buffer function > - or use the set of functions: > - gcry_md_write > - gcry_md_read That depends. If you need to hash a string you are already holding entirely and as one chunk in memory, gcry_md_hash_buffer is a bit more effcient. You should use this function only if you can hard wire the digest algorithm (like SHA1) because the fucntion will abort the process in case of an unknown digest algorithm. Salam-Shalom, Werner From bradh at frogmouth.net Mon Jan 30 11:26:59 2006 From: bradh at frogmouth.net (Brad Hards) Date: Mon Jan 30 13:37:11 2006 Subject: Hexa format In-Reply-To: <88a64070601291446h3ca86ef7k@mail.gmail.com> References: <88a64070601291446h3ca86ef7k@mail.gmail.com> Message-ID: <200601302127.05755.bradh@frogmouth.net> On Monday 30 January 2006 09:46 am, joel vennin wrote: > I've just a simple question for you, i would like to know if there is > a function inside the gcrypt library to convert digest buffer to a > hexa string representation. In fact, i'm using the gcry_md_hash_buffer > function and i want to display on the screen the hexa representation > of the digest buffer. There is some code in src/sexp.c that does this (look at convert_to_hex()), but it is trivial to write your own. > I've got another question, i want to know what it is more efficient: > - use the gcry_md_hash_buffer function > - or use the set of functions: > - gcry_md_write > - gcry_md_read For SHA1 and RMD160, gcry_md_hash_buffer will probably be faster. Otherwise it probably isn't going to make much difference, although it does depend on your exact setup (where the data comes from, costs of caching, memory limits). If it is really important, do both and time it. BTW: You could have read the code in cipher/md.c - that is all I did. 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/20060130/4459d9af/attachment.pgp