[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssl-users
Subject:    Re: Generating sect163k1 key pairs
From:       Jeffrey Walton <noloader () gmail ! com>
Date:       2009-10-29 11:41:13
Message-ID: 605f8e050910290441x7e053163h27f4bd1eeb1dc1e6 () mail ! gmail ! com
[Download RAW message or body]

Hi Doug,

> After extracting the private key from the testkey.pem file and putting it into
> the vendor's tool file format, the vendor tool generated digest ends up looking
> like:
> E39C9EEB4A60BFAF93235B376E9E54883C127BC403000000
> F4760E34AC2ECB484B2DFF06E87113C9F1F9F99F02000000
Ah! Now I see where the question of padding originated. I can't
explain it other than to speculate: perhaps the vendor's hardware can
be used for 163 and and others such as 193 and 233. And maybe the
programmer dutifully dumps the latched value, even though the tail is
not used for a 163 curve.

> I realize that these will be different as they are seeded by different random
> numbers....
ECDSA uses a random, per message value (usually 'k' in the
literature). So two signatures on the same message using the same key
will always be different. If the signatures are not different,
something is most likely broken.

> However, digests produced by the vendor's tool consistently have data
> that appears to be a X-Y coordinate...
> E39C9EEB4A60BFAF93235B376E9E54883C127BC403000000
> F4760E34AC2ECB484B2DFF06E87113C9F1F9F99F02000000
If the values are the output of the signature function, I believe that
would make them R and S, which are residues of Q. In earlier versions
of DSA, Q is the 160 bit value. (The new and improved DSA, specified
in FIPS 186-3, increases the size of Q (et al)).

Here's another guess: The values almost look like byte reversed ASN.1
encodings. But it appears the length octets are wrong (I did not run
them through a decoder). Or maybe some bastard BER-ish style: Write
the ASN.1 tag (the 0x03 for the first, 0x02 for the second), discard
the length octets, and then lay out the content octets.

Personally, I prefer IEEE formatting - it is always 40 bytes.

Jeff

On Wed, Oct 28, 2009 at 5:32 PM, Doug Bailey <dbailey@digium.com> wrote:
> Thanks much for the explanations on how this data is laid out.
>
> My first attempts at using the key I generated on my hardware platform were
> unsuccessful.
>
> Stepping back, I thought I would use openssl to create a sect163k1 encrypted
> SHA1 digest of my test file and then verify it.  I have been able to do this
> successfully executing the following commands:
>
> sudo openssl ecparam -genkey -name sect163k1 -out testkey.pem
> openssl ec -in testkey.pem -pubout -out testkeypub.pem
> openssl dgst -ecdsa-with-SHA1 -sign testkey.pem -out testdigest lockex.bin
> openssl dgst -ecdsa-with-SHA1  -verify testkeypub.pem -signature testdigest lockex.bin
>
> At this point I tried to use the openssl generated key to generate an encrypted
> digest of my test file using a tool provided by my hardware vendor.  (A
> derivative of the Miracl ecsign program.)
>
> After extracting the private key from the testkey.pem file and putting it into
> the vendor's tool file format, the vendor tool generated digest ends up looking
> like:
> E39C9EEB4A60BFAF93235B376E9E54883C127BC403000000
> F4760E34AC2ECB484B2DFF06E87113C9F1F9F99F02000000
>
> The digest generated by openssl looks like:
> $ hexdump testdigest
> 0000000 2e30 1502 8101 6c91 034a 1613 8b89 a2b9
> 0000010 d691 d3d0 dd7d 2c7b 023e 0315 24c9 9a3c
> 0000020 8042 342c cf41 cec6 057b a830 f1fc 0349
>
> I realize that these will be different as they are seeded by different random
> numbers.  However, digests produced by the vendor's tool consistently have data
> that appears to be a X-Y coordinate (i.e. 0's at the same place in the digest:
> halfway through and at the end) while the digest produced by openssl is truly
> random.
>
> Am I misreading this or is this significant?  Is the digest generated by openssl
> encoded in some sort of format or is it truly random as I expect?
>
> Thanks
> Doug Bailey
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majordomo@openssl.org

[prev in list] [next in list] [prev in thread] [next in thread]