appro appro 1. I'm reluctant to include bn.h to non-bn code, because it's
appro appronothing but counterintuitive [and is not good in long run].
appro appro 2. My standpoint is [still] that pqueue/dtls1 should not have
appro approdependancy on bh.h either.
appro appro 3. Using BIGNUM
Apologies for the delayed joining of the discussion.
I chose to use BN to implement 64-bit numbers because (1) it was
little code, (2) the abstraction was clean, (3) BN works on all
supported platforms, (4) the places where emulated 64-bit numbers are
used are not performance critical, and
appro 1. I'm reluctant to include bn.h to non-bn code, because it's
appronothing but counterintuitive [and is not good in long run].
appro 2. My standpoint is [still] that pqueue/dtls1 should not have
approdependancy on bh.h either.
appro 3. Using BIGNUM for DTLS purposes is *total*
In message [EMAIL PROTECTED] on Wed, 08 Jun 2005 00:32:52 +0200, Andy
Polyakov [EMAIL PROTECTED] said:
appro appro 1. I'm reluctant to include bn.h to non-bn code, because it's
appro appronothing but counterintuitive [and is not good in long run].
appro appro 2. My standpoint is [still]
In message [EMAIL PROTECTED] on Wed, 08 Jun 2005 06:16:54 +0200 (CEST),
Richard Levitte - VMS Whacker [EMAIL PROTECTED] said:
richard In message [EMAIL PROTECTED] on Wed, 08 Jun 2005 00:32:52 +0200,
Andy Polyakov [EMAIL PROTECTED] said:
richard
richard appro appro 1. I'm reluctant to include
It's interesting to see this happening. We have two parts of OpenSSL,
sha512 and pqueue, that solve the 64-bit integer problem in very
different manners.
Would it be a bad thing to have a header file in crypto/bn that
provides a guaranteed 64-bit number, possibly through BIGNUM, with
macros to
It's interesting to see this happening. We have two parts of OpenSSL,
sha512 and pqueue, that solve the 64-bit integer problem in very
different manners.
:-)
Would it be a bad thing to have a header file in crypto/bn that
provides a guaranteed 64-bit number, possibly through BIGNUM, with
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
appronothing but counterintuitive [and is not good in long run].
appro 2. My standpoint is [still] that pqueue/dtls1
