In message <[EMAIL PROTECTED]> on Mon, 06 Jun 2005 22:32:05 +0200, Andy Polyakov <[EMAIL PROTECTED]> said:
appro> 1. I'm reluctant to include bn.h to non-bn code, because it's appro> nothing but counterintuitive [and is not good in long run]. appro> 2. My standpoint is [still] that pqueue/dtls1 should not have appro> dependancy on bh.h either. appro> 3. Using BIGNUM for DTLS purposes is *total* overkill. To back appro> this up I'm going to suggest alternative, 64-bit neutral pq appro> code shortly:-) I agree. I'd rather see something like crypto/64bit.h (which is exported) and crypto/64bit.c. However, considering we're not very far from releasing 0.9.8 (everyone look at http://www.openssl.org/news/state.html!) I'd say a change to something completely new in this department should only be added to the 0.9.8 tree with lots of caution, and that the BIGNUM reference in pqueue may be a necessary compromise. In 0.9.9-dev, the matter is different, and I for one welcome any more developed 64-bit integer handling there. About the code in crypto/bn: there are some low-level routines that are specifically designed to handle 64-bit integers represented as two 32-bit integers. That code should be used, there's no point not to. So it would be natural to depend on that part of crypto/bn... Cheers, Richard ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
