key length discrepancy in key generated by sect233r1

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

key length discrepancy in key generated by sect233r1

dhoward
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?

In case it matters, I am using version 1.0.0d on Windows XP.
Reply | Threaded
Open this post in threaded view
|

RE: key length discrepancy in key generated by sect233r1

PMHager
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]
Reply | Threaded
Open this post in threaded view
|

Re: key length discrepancy in key generated by sect233r1

Billy Brumley
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.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]