[openssl.org #1072] Assertion failure in bn_div_words (bn_asm.c)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[openssl.org #1072] Assertion failure in bn_div_words (bn_asm.c)

Rich Salz via RT

The correct assertion should be
    assert((i == BN_BITS2) || (h <= (BN_ULONG)1<<i));
as it should prevent an overflow (the result doesn't fit
into a single BN_ULONG).
Please test a recent snapshot.

Thanks,
Nils
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [openssl.org #1072] Assertion failure in bn_div_words (bn_asm.c)

Rich Salz via RT

If one wants to assert that the caller didn't provide arguments that overflowed, wouldn't the assertion be

        assert (h < d);

If one is just going to assert that the initial normalizing shift doesn't overflow, then shouldn't the assertion be

        assert((i == BN_BITS2) || (h < (BN_ULONG)1<<i));

Consider the test case of "0x0200 0000 0000 0000 / 0x01.. ...." (where BN_BITS2 is 32).  BN_num_bits_word will return 25 and the normalization shift will be 7 bits.  The normalization shift will be OK for all values of h less than or equal to "0x01FF FFFF"; so, assertion should be "h < 0x2000 0000".  The equality case will, in fact, overflow the shift.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1072] Assertion failure in bn_div_words (bn_asm.c)

Nils Larsch
Robinson, Herbie via RT wrote:
> If one wants to assert that the caller didn't provide arguments that overflowed, wouldn't the assertion be
>
> assert (h < d);
>
> If one is just going to assert that the initial normalizing shift doesn't overflow, then shouldn't the assertion be
>
> assert((i == BN_BITS2) || (h < (BN_ULONG)1<<i));
>
> Consider the test case of "0x0200 0000 0000 0000 / 0x01.. ...." (where BN_BITS2 is 32).  BN_num_bits_word will return 25 and the normalization shift will be 7 bits.  The normalization shift will be OK for all values of h less than or equal to "0x01FF FFFF"; so, assertion should be "h < 0x2000 0000".  The equality case will, in fact, overflow the shift.

I must admit my first mail was somewhat inaccurate ;-) the reason
for this assertion is that this implementation of bn_div_words
needs it. It's not really to prevent an overflow in the return
value as whoever calls this internal function should ensure that
this doesn't happen, but the current implementation of bn_div_words
needs " h > d => (h - d) < d ".

Nils

PS: consider inserting some '\n' after approx. 72 char per line
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]