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 <

[hidden email]> 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

[hidden email]
> Automated List Manager

[hidden email]
>

______________________________________________________________________

OpenSSL Project

http://www.openssl.orgUser Support Mailing List

[hidden email]
Automated List Manager

[hidden email]