Concerning the ECDSA_sig size

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

Concerning the ECDSA_sig size

shotorddnadd
I am writing a C++ application using Openssl library to sign the outgoing messages and verify it on the other end. Everything works perfectly but still there is a strange point which I would like to discuss it and your help would be really appreciated in that case.
I noticed that using private keys with the same length (256) still the ECDSA signature size is different sometimes. For example once it is 70 Bytes and next time is 72 Bytes using another key but with the same size. As far as I know the ECDSA_sig structure uses some sorta padding for the ASN.1 encoding purposes but I am not sure if it leads to different signature sizes or I have to investigate my code for a problem (Which I don't believe that is the case since the sign/verification process of my application has been tested successfully.)

Do you have any idea why the size of ECDSA_sig structure is different sometimes even though I am using the same private key length?

Regards
/Nasser
Reply | Threaded
Open this post in threaded view
|

Re: Concerning the ECDSA_sig size

redpath
I am glad someone is asking this question.
I sign the same data with same private key and sometimes the signature is 63
and sometimes it is 64 but overall the verification works for each
anyhow.




Reply | Threaded
Open this post in threaded view
|

RE: Concerning the ECDSA_sig size

Khuc, Chuong D.
I remembered encountering this problem before. And although I don't remember all the details now, the basic idea is that openssl will only allocate enough memory for the "significant" bits of the signature. So if your signature has the first byte of 0x00, it will not store that byte. And if you want consistent signature length (64 in your case), you have to manually pad it with zeros. You have to go back to the comments in the function header to get the details. But I'm pretty positive that is the case.

________________________________________
From: [hidden email] [[hidden email]] on behalf of redpath [[hidden email]]
Sent: Tuesday, September 17, 2013 2:48 PM
To: [hidden email]
Subject: Re: Concerning the ECDSA_sig size

I am glad someone is asking this question.
I sign the same data with same private key and sometimes the signature is 63
and sometimes it is 64 but overall the verification works for each
anyhow.








--
View this message in context: http://openssl.6102.n7.nabble.com/Concerning-the-ECDSA-sig-size-tp46553p46559.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           majordomo@openssl.org______________________________________________________________________
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: Concerning the ECDSA_sig size

Billy Brumley
In reply to this post by redpath
That's just the way ECDSA and DSA signatures work. Yes the ASN.1 encoding factors in but mostly it's just the way the math goes. The signature is a tuple (r,s) where r and s are mod n and n is fixed per curve. r and s are always smaller than n, normally around the same size as n, but can also be even smaller depending on how the modular reduction goes.

BBB

$ openssl ecparam -name prime256v1 -out private.pem -genkey -noout
$ echo -n "0xDEADBEEF" | openssl dgst -sign private.pem -sha256 -out sig.bin
$ openssl asn1parse -in sig.bin -inform DER
    0:d=0  hl=2 l=  70 cons: SEQUENCE         
    2:d=1  hl=2 l=  33 prim: INTEGER           :F5DCE3A83786EC0F54E0B0019DB481D30CB8DE5DB3F83349E5D00DCC87EEFEB1
   37:d=1  hl=2 l=  33 prim: INTEGER           :E5A3542861A325636D290A6133D99E7B4A28F252C5C9A5DA0B0B884D1AD70D29
$ echo -n "0xDEADBEEF" | openssl dgst -sign private.pem -sha256 -out sig.bin
$ openssl asn1parse -in sig.bin -inform DER
    0:d=0  hl=2 l=  68 cons: SEQUENCE         
    2:d=1  hl=2 l=  32 prim: INTEGER           :55B9639848C7A47DBDFEEC25B9D8CA772CB984E494BEB4DE4A843EED95254547
   36:d=1  hl=2 l=  32 prim: INTEGER           :0EF138F87E44CCBEE3BC509D661B9B565DA04D39BD0C3914A783B26762FF85B7


On Tue, Sep 17, 2013 at 12:48 PM, redpath <[hidden email]> wrote:
I am glad someone is asking this question.
I sign the same data with same private key and sometimes the signature is 63
and sometimes it is 64 but overall the verification works for each
anyhow.








--
View this message in context: http://openssl.6102.n7.nabble.com/Concerning-the-ECDSA-sig-size-tp46553p46559.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
______________________________________________________________________
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: Concerning the ECDSA_sig size

Dave Thompson-5
In reply to this post by shotorddnadd
> From: [hidden email] On Behalf Of shotorddnadd
> Sent: Tuesday, September 17, 2013 09:12

> I am writing a C++ application using Openssl library to sign the outgoing
> messages and verify it on the other end. Everything works perfectly but
> still there is a strange point which I would like to discuss it and your
> help would be really appreciated in that case.
> I noticed that using private keys with the same length (256) still the
ECDSA
> signature size is different sometimes. For example once it is 70 Bytes and
> next time is 72 Bytes using another key but with the same size. As far as
I
> know the ECDSA_sig structure uses some sorta padding for the ASN.1
> encoding
> purposes but I am not sure if it leads to different signature sizes or I
> have to investigate my code for a problem (Which I don't believe that is
the
> case since the sign/verification process of my application has been tested
> successfully.)
>
ECDSA signatures consist of two integers that are practically random over
the curve order, which usually is very slightly less than the nominal size
(for your case 2^256). (And DSA similarly over the subgroup order.)

These integers are indeed encoded in ASN.1, and integers in ASN.1 are
always two's-complement -- even when as here they cannot be negative.
That means for example a 32bit number in the range 0x00000000 to
0x7fffffff will take 4 value octets but 0x80000000 to 0xffffffff will take
5.
Since the numbers in your signatures are almost evenly divided you will
get 1 "extra" octet about 50% of the time and 2 about 25%.
In rarer cases, 1 or possibly more octets *less* are needed.

bbrumley's answer is true but his example values happen to be
in the "low half" not needing extra bytes (or fewer bytes).

chuong.khuc's answer is wrong. He may be thinking of RSA, where
the signature is one integer, and depending on how it is represented
(sometimes, not always, as an ASN.1 integer) it may be padded or not.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]