[openssl-users] i2d and d2i fucntions

[Rajeswari K]

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>