> From: owner-openssl-us...@openssl.org On Behalf Of jeetendra gangele > Sent: Monday, 17 December, 2012 02:48
> Yes i am talking about signature. > ECDSA_SIG this ouptput structure will have r and s componet > of 28 bytes each. [for 224-bit curve] > So if I merge both r and s I will get 56 bytes right? > These will not have any padding information?. > The struct points to two bignums, which use an internal format; openssl can put what it likes in there. If you get the (near-trivial) encoding as big-endian btyes using BN_bn2bin, *that* does not have padding or overhead. Note that the numbers in an ECDSA signature are effectively uniform random up to the field order, so they will *rarely* be *smaller* than the keysize (here, less then 28 bytes). If you want *fixed* 28 bytes each, *you* will need to pad. (I forgot to allow for this in my earlier reply. The ASN.1 encoding can be less than 62 bytes in these cases.) ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
