Hi,
I think I've encountered a problem with BN_num_bits. I have experienced
that BN_num_bits often returns 1 (sometimes more) bits less than the
actual key size of a BIGNUM. With 2048 bit DH key pairs, I've often seen
2047 bit returned by BN_num_bits (checking the public key). I'm seeing a
Hello steve,
I was out of office for the last one week and so I was not able to
follow up with the core dump errrors.
The following commands core dumps on my machine.
1) openssl asn1parse -in cacertificate.pem -strparse 29 [
cacertificate.pem = openssl req -new -x509
Well, that depends on what you mean with number of bits. Take a number
like 0x0432, how many bits does it have? You could view it as a word,
and say it has 16 bits, or you could look at it more closely, and find
out that it has 11 *significant* bits.
BN_num_bits() counts significant bits.
Richard Levitte via RT schrieb:
Well, that depends on what you mean with number of bits. Take a number
like 0x0432, how many bits does it have? You could view it as a word,
and say it has 16 bits, or you could look at it more closely, and find
out that it has 11 *significant* bits.
Hi,
I don't know if you have any responses about this, but this is still an error for
openssl 0.9.7d, on HP-UX 11-23.
But it is fixed by reducing the optimisation to +O2.
Hope that's of use.
G.
---
George Shaw
Senior Software Engineer
Axway
a Sopra Group company
Michael Schmidt via RT wrote:
Richard Levitte via RT schrieb:
Well, that depends on what you mean with number of bits. Take a number
like 0x0432, how many bits does it have? You could view it as a word,
and say it has 16 bits, or you could look at it more closely, and find
out that it has 11
[EMAIL PROTECTED] - Thu Jul 1 12:52:19 2004]:
I'd suggest to clarify the man page of 'BN_num_bits':
People (such as me) are tempted to use 'BN_num_bits' to get the key
size
(class) of a private or public key, and expect that its size matches
the
size (class) of its counterpart (public or
Richard Levitte via RT schrieb:
[EMAIL PROTECTED] - Thu Jul 1 12:52:19 2004]:
I'd suggest to clarify the man page of 'BN_num_bits':
People (such as me) are tempted to use 'BN_num_bits' to get the key
size
(class) of a private or public key, and expect that its size matches
the
You're welcome, and thanks for bringing this to our attention.
Ticket resolved.
[EMAIL PROTECTED] - Thu Jul 1 14:42:46 2004]:
Perfect!
Thanks a lot.
--
Richard Levitte
[EMAIL PROTECTED]
__
OpenSSL Project
[levitte - Thu Jul 1 15:05:07 2004]:
You're welcome, and thanks for bringing this to our attention.
Ticket resolved.
[EMAIL PROTECTED] - Thu Jul 1 14:42:46 2004]:
Perfect!
Thanks a lot.
RSA, from memory, will always set the bits appropriately so the modulus
size matches the
[steve - Thu Jul 1 15:17:46 2004]:
RSA, from memory, will always set the bits appropriately so the
modulus
size matches the number of bits in genrsa (et al).
I assume you mean the OpenSSL implementation of RSA, or is that an
absolute rule? The bugdemo that is attached to the bug report
Michael Schmidt via RT wrote:
Hi,
I think I've encountered a problem with BN_num_bits. I have experienced
that BN_num_bits often returns 1 (sometimes more) bits less than the
actual key size of a BIGNUM. With 2048 bit DH key pairs, I've often seen
2047 bit returned by BN_num_bits
The file openssl/crypto/x509v3/pcy_node.c references the non-POSIX header
memory.h. However, if one simply removes this reference, the program
still compiles, at least on my system.
My feeling is that the line can simply be deleted. But if this causes
problems, then it should just be replaced
[EMAIL PROTECTED] - Thu Jul 1 12:52:19 2004]:
Richard Levitte via RT schrieb:
Well, that depends on what you mean with number of bits. Take a number
like 0x0432, how many bits does it have? You could view it as a word,
and say it has 16 bits, or you could look at it more closely, and
14 matches
Mail list logo
