Hi Paul! On Tue, Feb 12, 2013 at 01:46:55PM +0100, Paul Bakker wrote: > Hi, > > > > Let's start with: Congratulations on the addition ;) >
Thanks! > > > I'm the lead maintainer for PolarSSL and just saw your tweet after coming > back from a week on leave. > > > > If you run into any issues, please let us know! > > > > I did a first cursory check on the patch that was included. I wanted to give > some extra information / tips that might help. > > > > One of the things I noticed was the use of a thread-specific entropy pool.. > > > > I would like to point to this article > https://polarssl.org/kb/development/entropy-collection-and-random-generation > -in-threaded-environment. (Which is just up). About the use of the entropy > collector and random generator in multi-threaded applications like yours. > Our advice: Use only a single entropy pool. > > Thanks for the article. I wrongfully assumed that new entropy was required more often and having only one would block the other threads. >From the article I gather that this is not the case. I will patch the plugin for use with one entropy context and multiple thread local crt_drbg context. > > Secondly I saw the inclusion of my_dhm_P and my_dhm_G. I apologize for the > fact that some of our examples used these values in the past to show the > possibilities of our API. If you are using the 1.2 branch for PolarSSL, it > is not needed to set the DHM parameters for SSL. Check out > https://polarssl.org/kb/cryptography/providing-diffie-hellman-or-dhm-paramet > ers for more info. The default are the RFC 5144 MODP P and G values. > The my_dhm_P and my_dhm_G are only used if no external parameters are provided. They are there only because I wanted the plugin to be usable without any configuration. To inform the user they use built-in DH parameters or certificates, warnings are printed at startup. In the message a command to generate parameters is included. I'll consider dropping the warnings with newer versions of polarssl where standardized parameters are available. > > > error_strerror() is used without checking in advance if POLARSSL_ERROR_C is > used. As of 1.2.5 this is not needed anymore. If POLARSSL_ERROR_C is not > defined, a dummy error_strerror() is provided. But before 1.2.4, this will > result in a compile error. I'd advise you to either check the PolarSSL > version for a minimum of 1.2.5 or require POLARSSL_ERROR_C at the start. > I'll add preprocessor directives to correct this. > > > Hope this helps a bit. > Indeed it does. Thanks a lot for taking the time to look at our implementation! Your assistance is greatly appreciated. > > > Regards, > > Paul Bakker > > > > _______________________________________________ > Monkey mailing list > [email protected] > http://lists.monkey-project.com/listinfo/monkey -- Sonny Karlsson [email protected] _______________________________________________ Monkey mailing list [email protected] http://lists.monkey-project.com/listinfo/monkey
