[EMAIL PROTECTED] - Thu Sep 25 11:37:20 2003]:
> as requested by Nil Larschs, i'm sending this diff to [EMAIL PROTECTED]
>
> For a discussion of these bugs and fixes, see the thread
> http://www.mail-archive.com/openssl-dev@openssl.org/msg16241.html
Yup, in fact the bignum audit propsed in that
Find attached a patch against 0.9.7d which has a new
compile-time option to have the run-time option to
precompute tables for a specific DSA key which result
in a significant speed-up on subsequent operations
using that key. All at the cost of 3 * qbits * pbits
memory per key, and some college math
Hi all,
Looking through openssl's DH code (0.9.7d, see below),
when choosing the secret exponent, openssl chooses a
random number where the most significant bit of the
exponent is always set to be 1 (that's what top=0 does
as the 3rd argument to BN_rand). I can't figure out
any security justi
This is probably another one for the FAQ:
Setting the highest bit of a random string guarantees that it's N bits long.
Technically, a bit string with the highest order several bits set to zero is
also N bits long, but not mathematically. If you are generating a pair of N
bit primes to use for
None of that FAQ applies to the DH exponents, though.
On Wed, Dec 08, 2004 at 03:28:25PM -0500, Jim Schneider wrote:
> This is probably another one for the FAQ:
>
> Setting the highest bit of a random string guarantees that it's N bits long.
>
> Technically, a bit string with the highest order
> Looking through openssl's DH code (0.9.7d, see below),
> when choosing the secret exponent, openssl chooses a
> random number where the most significant bit of the
> exponent is always set to be 1 (that's what top=0 does
> as the 3rd argument to BN_rand). I can't figure out
> any security justi
Sure, setting the high bit guarantees that it has no
shorter representation in binary. I also agree that
larger numbers are harder to factor than smaller ones.
But breaking DH (recovering the shared secret) is a
discrete logarithm problem, not a factoring one.
Ensuring that the high bit of t
Sorry, I goofed - I thought we were talking about generating the prime for DH,
not the subsequent operations. In the case of the secret exponents, there's
no real justification for it (x just needs to be larger than C*ln(p)/ln(g),
where g is the DH generator, p is the DH prime, and C is a "big
I wrote:
> Is there an algorithm that runs efficiently to
> compute discrete log over a fixed prime modulus when
> you know that the top few bits are zero?
Let me rephrase this part... my point is that the
algorithms for solving the discrete log problem (thus
breaking DH) have a time bound that gro
