It's not clear if you're talking about the private or public part of the key.
If you're talking about the private part, that's because only a
negligible number of private keys for that curve need 233 bits to be
stored. This is due to the fact that the large, prime-order subgroup
has the form 2^{232} + a where a is a constant close to sqrt(2^{232}).
So with overwhelming probability, the top bit will always be zero.
(You can still hit these negligible private keys in OpenSSL; it just
won't happen in your lifetime. The implementation is correct.)
Billy
On Thu, May 12, 2011 at 9:37 AM, PMHager <h...@prima.de> wrote:
> dhoward wrote on Wednesday, May 11, 2011 20:01:
>
>> I was recently playing around with OpenSSL's EC_KEY interface, specifically
>> generating and examining keys generated using the curve sect233r1, when I
>> decided to print the raw key out, in hex form. A quick analysis showed me
>> that the key was stored in 232 bits, not 233 bits as the curve sect233r1
>> requires - in fact, no matter how many keys I generated and checked this
>> way, I was always missing a bit. Is there some reason that OpenSSL uses only
>> 232 bits instead of the full 233?
>
> Did you take into account the point compression as described in
> SEC 1: Elliptic Curve Cryptography
> 2.3.3 EllipticCurvePoint-to-OctetString Conversion
> [http://www.secg.org/collateral/sec1_final.pdf]
>
> --
>
> Peter-Michael Hager - acm senior - HAGER-ELECTRONICS GmbH - Germany
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
