On Wed, Nov 01, 2000 at 01:51:24PM -0500, Lawrence MacIntyre wrote:
> But bin2bn is generating BNs from the static P and G which don't have
> trailing 0s.
It's actually *leading* zeroes that we are talking about, although
those are trailing zeroes in the low-endian representation used for
bignum
Ulf:
But bin2bn is generating BNs from the static P and G which don't have
trailing 0s. It is BN_num_bytes that reports 55 when it should be
saying 56. Is there a better way to determine the length of the key?
Do I just need to know the length of the key apriori? I had allowed the
client to p
On Wed, Nov 01, 2000, Lawrence MacIntyre wrote:
> I use bin2bn to generate the BNs for P and G, and the char lengths are
> correct AND statically defined in the .h file, so they are the same
> every time. Then I generate the key using DH_generate_key() and
> BN_num_bytes() to determine the lengt
Ulf:
I use bin2bn to generate the BNs for P and G, and the char lengths are
correct AND statically defined in the .h file, so they are the same
every time. Then I generate the key using DH_generate_key() and
BN_num_bytes() to determine the length of the key. Is that incorrect?
The reason I fou
On Wed, Nov 01, 2000, Lawrence MacIntyre wrote:
> When you run the program 1000 times, somewhere between 3 and 9
> times the length of the public key will be 55 bytes instead of 56, as it
> should be. This breaks my client:-( Once, the key was actually 54
> bytes.
You really should fix the c
Hi:
I have been having spurious problems with one of my client server
programs. It uses a DH Key exchange to generate a blowfish key and
encrypts the data using that key. I believe I have isolated the problem
to the minimum of code. I'm attaching the test program, Makefile, and a
bash script t
