Hello Dave, Based on your input, have stopped calling i2d_ECDSA_SIG() and used BN_bn2bin() to overcome the der headers. And now, my verification is working fine. Is there any function at openssl, to get the HASH used for the digest at ECDSA_verify()? I see that, for ECDSA_verify(), first argument is type. But when its calling the function pointer, ECDSA_verify() is not passing the type of the hash. So, would like to get the hash type from digest data. I can understand that for TLS1.2, openssl uses SHA512. But the same information i would like to get from digest data. Is there any way to get this? Please share. Thanks, Rajeswari. On Sat, Feb 14, 2015 at 1:24 AM, Dave Thompson <dthompson at prinpay.com> wrote: > > From: openssl-users On Behalf Of Rajeswari K > > Sent: Friday, February 13, 2015 09:48 > <snip> > > As part of [ECDSA] signature verification, we first take > lenght_of_signature received > > and compare with double the size of number_of_bytes from curve parameter. > > Have converted the ECDSA_SIG to unsigned char * using the function > i2d_ECDSA_SIG(). > > Length returned by i2d_ECDSA_SIG() is 103. > > Whereas, the number_of_bytes value from curve parameter is 48. > > An EDCSA signature, like a DSA signature, and as the 'i2d' should clue you > in, > is an ASN1 DER-encoded value. Specifically it is a SEQUENCE of two > INTEGERs. > That means it consists of: > > 2 octets tag and length for the sequence -- OR 3 if the components together > exceed 127 octets, which will occur almost always if the curve size exceeds > 496 bits and sometimes for slightly smaller curves, see below. > > For each integer, 2 octets tag and length then N octets value, as long as > the > curve size does not exceed 1015 bits (and none currently come even close). > Remember DER INTEGERs are two's complement, and the R and S values > are positive numbers that are for practical purposes uniform random up to > the curve order which is usually chosen to be nearly a power of two that > is a multiple of 8 (like 192, 256, 384) and thus require an extra sign > octet. > > Thus for a 384-bit curve, the encoded signature will be 6+2*48=102 > roughly 25% of the time, 6+48+49 about 50% and 6+49*2 about 25%. > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150214/85def9b1/attachment.html>
