Hi, This is due to the fact that the integers are stored as unsigned. So, when the MSB of a computed value is set, the encoding adds an extra 0x00 to its ASN.1 representation. This is normal and it explains what you are experiencing.
Cheers, Mounir IDRASSI IDRIX - Cryptography And IT Security Experts http://www.idrix.fr On 3/7/08, JP Szikora via RT <[EMAIL PROTECTED]> wrote: > Hi, > > I try to understand why the signature length is variable in ECDSA. > Normally with 160bits EC, it must be 46 bytes long: 20 bytes for each of > the 2 components and 4 + 2 bytes for ASN.1. > > I think it must be a bug in the ASN.1 creation of the signature. > > Here is the details: > > I'm testing this with openssl-0.9.8g. > I create a key: > openssl ecparam -out ec_key.pem -name secp160k1 -genkey > And I sign with it: > openssl dgst -ecdsa-with-SHA1 -sign ec_key.pem -out test_ec.sign test.txt > > Now this signature (test_ec.sign) is between 46 and 48 bytes long if I > done it a few times. > > I compared the asn1parse output with the hexadecimal content of the > signature, and the difference is an extra 0x00 before one or the two > members of the pair (r,s). > > 1. the most frequent case: 47 bytes: > asn.1 structure: > 0:d=0 hl=2 l= 45 cons: SEQUENCE 2:d=1 hl=2 l= 21 prim: > INTEGER :BD8188D4FB9445C456FF257BC9A77E759CC63DA9 > 25:d=1 hl=2 l= 20 prim: INTEGER > :2AC486BB6DF4D81A44B38CE319935270B22CACC8 > the signature in hexadecimal: > > 302d0215_00bd8188d4fb9445c456ff257bc9a77e759cc63da9_0214_2ac486bb6df4d81a44b38ce319935270b22cacc8 > > > I put a _ to clearly separate the elements. > > 2. 48 bytes signature: > 0:d=0 hl=2 l= 46 cons: SEQUENCE 2:d=1 hl=2 l= 21 prim: > INTEGER :95CB1F3A35F4358D158BE94BA41031CE1563CD0F > 25:d=1 hl=2 l= 21 prim: INTEGER > :A07D76EF47CF74D385FF60DA7EBF8E86652AD230 > > 302e0215_0095cb1f3a35f4358d158be94ba41031ce1563cd0f_0215_00a07d76ef47cf74d385ff60da7ebf8e86652ad230 > > > > 3. 46 bytes signature: > 0:d=0 hl=2 l= 44 cons: SEQUENCE 2:d=1 hl=2 l= 20 prim: > INTEGER :22294F048F61B727DB3B0786D440717532601082 > 24:d=1 hl=2 l= 20 prim: INTEGER > :09D21753A2DD8395CB965D583F27835B051E7C42 > > 302c0214_22294f048f61b727db3b0786d440717532601082_0214_09d21753a2dd8395cb965d583f27835b051e7c42 > > > > I reproduced this on a recent snapshot of the 0.9.9-dev branch. > > Now, if I modified the signature to remove the extra 0x00 preceding one > of the members and modifying the length component in ASN.1, the > signature is still valid... > > Thanks for your help, > > Best Regards, > > Jean-Pierre > > -- > Dr Jean-Pierre Szikora e-mail: [EMAIL PROTECTED] > tel: 32-2-764.75.00 > 74, av. Hippocrate - UCL 7459 fax: 32-2-764.65.65 > 1200 Brussels - Belgium > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] > -- Mounir IDRASSI IDRIX http://www.idrix.fr ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
