Doug: It is my understanding that the first byte of the public key is a flag
to indicate if the public key is compressed, uncompressed or hybrid:
-conv_form arg specifies the point conversion form
possible values: compressed
uncompressed (default)
hybrid
Your example is for an uncompressed public key. What follows the first byte
are two 21 byte fields representing Q_x and Q_y.
With regard to your question on why the private keys differ in length, the
longer one has a leading 00 to ensure it is treated as a positive number.
Without the leading 00, the C4 would make it negative. The shorter one has the
most significant bit of the leading byte as a zero; therefore, it is positive
and the leading zeros for the most significant three bits of the 163 bits are
assumed.
Bill
So I can understand why the byte descriptions of the keys differ in length.
In your response you indicate that the public key description consists of
two 163 bit numbers representing a point on the curve (Q_x, Q_y).
Given a display like:
pub:
04:01:9c:db:21:d7:49:17:cd:c4:93:56:13:e4:07:
c2:af:1b:43:70:a3:b9:03:f1:26:f8:7b:1d:02:69:
21:39:cf:d5:28:ee:3b:44:3c:c5:64:7c:aa
How can you tell where the delineation between Q_x and Q_y is? Is Q_y always
described in 163 bits and Q_x is appended to that? Is there ever any padding
inserted onto the numbers output by the -text option? What is the magic
decoder ring to the display provided by the -text option?
> > In generating some of the key sets, I notice that the printed length
> of the keys
> > differ when using the -text command option. Since openssl is
> displaying a 163
> > bits in a byte-wise display, I am trying to figure out where the
> padding bits are
> > applied?
> >
> > For example:
> >
> > ~$ sudo openssl ecparam -genkey -name sect163k1 -out testkey1.pem
> > ~$ sudo openssl ec -text -in testkey1.pem
> > read EC key
> > Private-Key: (163 bit)
> > priv:
> > 00:c4:5c:43:a9:17:57:89:ff:e8:fe:f9:d6:b0:d4:
> > 52:fc:d4:6b:71:98
> > pub:
> > 04:01:9c:db:21:d7:49:17:cd:c4:93:56:13:e4:07:
> > c2:af:1b:43:70:a3:b9:03:f1:26:f8:7b:1d:02:69:
> > 21:39:cf:d5:28:ee:3b:44:3c:c5:64:7c:aa
> > ASN1 OID: sect163k1
> > writing EC key
> > -----BEGIN EC PRIVATE KEY-----
> > MFICAQEEFMRcQ6kXV4n/6P751rDUUvzUa3GYoAcGBSuBBAABoS4DLAAEAZzbIddJ
> > F83Ek1YT5AfCrxtDcKO5A/Em+HsdAmkhOc/VKO47RDzFZHyq
> > -----END EC PRIVATE KEY-----
> >
> > ~$ sudo openssl ecparam -genkey -name sect163k1 -out testkey2.pem
> > ~$ sudo openssl ec -text -in testkey2.pem
> > read EC key
> > Private-Key: (163 bit)
> > priv:
> > 65:06:db:ea:88:38:0d:50:37:9e:3a:92:77:15:ca:
> > 3c:76:d0:00:12
> > pub:
> > 04:07:7d:dd:c1:89:12:75:42:d6:9e:06:79:24:e1:
> > 8b:4a:49:df:57:ac:e2:04:95:a1:2f:b9:dc:a7:8c:
> > 5f:c3:18:a5:a7:9c:fc:9d:be:7f:e6:d7:4e
> > ASN1 OID: sect163k1
> > writing EC key
> > -----BEGIN EC PRIVATE KEY-----
> > MFICAQEEFGUG2+qIOA1QN546kncVyjx20AASoAcGBSuBBAABoS4DLAAEB33dwYkS
> > dULWngZ5JOGLSknfV6ziBJWhL7ncp4xfwxilp5z8nb5/5tdO
> > -----END EC PRIVATE KEY-----
> >
> > The two private keys are described in a different number of bytes.
> >
> > Since the 2nd generated private key is shown in 20 bytes i.e. 160
> bits, is it
> > assumed that the MS 3 bits are 0?
> >
> > How is the public key partitioned? Where are the padding bits added
> in this
> > display?
> >
> > Thanks
> > Doug Bailey
> >
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
