The leading 00 is there just to comply with DER encoding restrictions
-- otherwise, since the high bit is set, it would be interpereted as a
negative number. (For clarity, it is a very large positive integer.)
Besides, EC pairs are just numbers. The leading 00 does nothing to
change the value of the number. (This is also the case with RSA and
DH. One-way hashing algorithms and most block and stream ciphers
interperet their data as bitfields that can be shifted around one way
and the inverse.) The mathematical community often takes potshots at
the problems that these numbers represent, and sometimes makes strides
in solving these problems. It is this property that makes causes them
to be considered "secure" -- because no one has come up with an easier-
than-brute-force method to solve them.
-Kyle H
On Sep 22, 2009, at 18:47, Brian Kuschak <bkusc...@yahoo.com> wrote:
I'm using OpenSSL to generate EC key pairs for use in an embedded
application. As such, I need to extract and use the raw key values,
and I notice that the length of the keys as displayed by OpenSSL are
exactly one byte longer than expected. I assume the first byte
listed for both public and private are not _really_ part of the key,
but I'd like confirmation on this. If so, what is it's purpose?
Generate the key pair:
openssl ecparam -out eckey.pem -name prime192v1 -genkey
Notice how the private key is 25 bytes (not 24), and the public key
is 49 bytes, not 48:
openssl ec -in eckey.pem -text
Private-Key: (192 bit)
priv:
00:d4:7a:55:e3:0d:91:26:2e:90:02:83:97:5c:3e:
63:25:95:fe:88:28:61:4e:e7:c5
pub:
04:f4:85:cc:48:15:83:7c:ee:8d:53:e8:0b:fd:a7:
40:5f:86:d8:fc:97:72:89:04:34:a4:92:e1:33:e7:
17:1c:55:c0:39:cc:06:c1:49:5f:d3:70:8b:08:e3:
33:83:50:ae
I'm using OpenSSL 0.9.8k 25 Mar 2009.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
