[openssl-users] i2d and d2i fucntions

[Rajeswari K]

Hello Dave,

Our current signature and verification logics are working just fine with
TLS1.0 and TLS1.1 for ECDHE_ECDSA cipher suite.

But, when tested the same cipher suite with TLS1.2, SSL handshake always
failing with "bad signature".

Do we need to take care of anything specific for TLS1.2 handshake?

Thanks,
Rajeswari.

On Sat, Feb 14, 2015 at 10:20 AM, Rajeswari K <raji.kotamraju at gmail.com>
wrote:

> 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/20150216/3c2c46cd/attachment.html>