> From: owner-openssl-users
> Sent: Wednesday, December 04, 2013 18:32
> On 4 December 2013 22:38, Dave Thompson <dthomp...@prinpay.com>
> wrote:
> > In addition to the misplaced paren already noted, and also a surplus
paren,
> > which I'll assume were typos since they wouldn't have compiled,
>
> I think it could compile (unless there is another surplus paren I
> haven't seen?):
>
Near end of line, after EVP_SignUpdate(...)==1 term.
> EVP_SignInit(ctx, EVP_sha256() == 1)
>
> As EVP_sha_256() is not equal to 1, this is the same as
>
> EVP_SignInit(ctx, 0)
>
1 is an int, and cannot be compared to a pointer-to-function
without cast. Although gcc for one (usually) makes nonstandard
conversion like this only a warning.
> So effectively a NULL digest is being passed. This should fail
Nit: the C standard actually guarantees only that a constant
zero is a null pointer, not other zeros, but only a few very
obscure implementations actually don't or didn't work.
The gcc I have closest to hand (3.4.5) says:
aastha.c: In function `do_sign':
aastha.c:7: warning: comparison between pointer and integer
aastha.c:7: warning: passing arg 2 of `EVP_DigestInit' makes pointer from
integer without a cast
aastha.c:8: error: syntax error before '(' token
aastha.c:8: warning: comparison between pointer and integer
aastha.c:8: error: syntax error before ')' token
aastha.c:8: error: label `EVP_SignFinal' used but not defined
> although the OP omitted to show the actual code for printing the error
> in this case. In any case the return value from the OP's do_sign
> method is not being checked.
OP did show error message apparently from ERR_print_errors*.
> > your test program won't ever succeed, because you aren't verifying
> > the same data you signed. You memset ver_data to all zero bytes,
> > and then use strlen(ver_data) bytes of it, which is always no bytes at
all.
>
> Actually ver_data is memset is set to zero bytes and then strlen(data)
> is calculate (not ver_data)...but it amounts to the same thing. The OP
> needs to pass the original data to be verified.
>
You're right, I misread that. Let's hope strlen(data) <= 1024.
> > All of the places I can see dsa_do_verify sets that error look like
> > "should never happen" cases, unless there is something wrong with
> > your (public)key structure. And the command you showed (dsa -pubout)
> > should have generated a valid publickey file.
> >
>
> Well looking at the code where this error is raised:
>
> /* XXX: surely this is wrong - if ret is 0, it just didn't verify;
> there is no error in BN. Test should be ret == -1 (Ben) */
> if (ret != 1) DSAerr(DSA_F_DSA_DO_VERIFY,ERR_R_BN_LIB);
>
> Reading the code suggests there is a bug in OpenSSL - helpfully
> pointed out in a comment!! :-)
>
> This looks like not an error at all. Just a verify failure.
>
You're right! I focused on the 'goto err's but managed to miss that.
And the OP's posted (if incomplete) code didn't distinguish 0 from <0.
Verify failure is indeed a much better explanation, as above.
Sorry for the partially false alarm.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
