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 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_00bd8188d4fb9445c456ff257bc9a77e759cc63da 9_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_0095cb1f3a35f4358d158be94ba41031ce1563cd0 f_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: jean-pierre.szikora@uclouvain.be
> 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 majordomo@openssl.org
>




--
Mounir IDRASSI
IDRIX
http://www.idrix.fr
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org