On 2013-06-28 1:43, Dave Thompson wrote: >> From: owner-openssl-us...@openssl.org On Behalf Of Lukas Haase >> Sent: Thursday, 27 June, 2013 04:46 > > <snip previous> >> I think I found the problem but I am unsure how to deal with it :-( >> >> There are two ways to create a signature: The original message can be >> part of the signature (put=true) or not (put=false). In the first case, >> the signature gets larger (this is what I observe, the signature is not >> exactly 32 Bytes) and only the signature needs to be presented to the >> verifier. In the latter case, the concatenation message|signature needs >> to be presented [cite to cryptopp]. >> > That doesn't make sense. The ECDSA signature format in openssl (also DSA) > is an ASN.1 encoding; it is almost never 32 bytes for a p-128 curve. > It contains two values normally the size of the curve order (for DSA > the subgroup) but maybe smaller with low probability, plus overhead > from 6-11 bytes seemingly at random. It does not include the data > and does not get longer for long data, as you can easily test.
Yeeeeeeah, that was it!!! Crypto++ does not seem to use ASN1 but just concatenates the raw numbers. I do not understand why verification worked with putMessage=true though... However, I can get the raw representation this way: cat testakt.txt | openssl dgst -ecdsa-with-SHA1 -sign activation.key -keyform DER | openssl asn1parse -inform DER when I just concatenate the two resulting integers they successfully validate in my Crypto++ application! Happy!! :-) > [...] Thanks a lot! Luke ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
