I should have also said that this is called by X509_REQ_sign. So, in short, the EVP_MD.digest atrtibute is not used to do signing when passed to X509_REQ_sign.
You know, it's only writing that the word "digest" has jumped out at me. Is that even the right place for doing signing? Or is it meant o just calculate a digest (hash)? So that confusion may not be helping things. Sorry. Andrew On Tue, Dec 17, 2013 at 03:45:46PM -0300, Andrew Cooke wrote: > > Hi, > > I realise the 1.0.0 to 1.0.1 transition happened some time ago, but it only > hit Centos recently (with the 6.5 release). Some of our code broke, and while > I suspect the problem is too low-level / detailed for anyone to say anything > useful, I thought I better ask, just in case... (if you can help, thanks in > advance). > > What the code is doing is intercepting signing during the creation of an X509 > request. It does this by creating an EVP_MD via EVP_dss1 and then assigning > the digest attribute (a function pointer). > > In 1.0.0, this was then somehow called to do the signing, at which point our > library leapt into action and delegated the work to a hardware token. > > In 1.0.1, however, the digest attribute is not being called. Instead some > default routine for signatures is used, which segfaults because there is no > private key (the segfault is in the multiplication of large integers when a > NULL value - the key - is dereferenced). > > In both cases, it seems that some kind of "context" object is constructed, > which is then used in the signing. What seems to differ is how that is > constructed (and so what procedure is called to do the signing). > > If I use gdb then the code for the two versions diverges when ASN1_item_sign > (in crypto/asn1/a_sign.c) is called: > > In 1.0.0k this is a fairly long routine that creates the context, and then > calls EVP_SignInit_ex, EVP_SignUpdate and EVP_SignFinal. > > In 1.1.1 that is replaced with EVP_DigestSignInit (in crypto/evp/m_sigver.c) > and then ASN1_item_sign_ctx. > > It seems like the logic in those two paths, constructing the context, is > different (the code certainly looks different). > > I haven't yet worked through the details, but if the above sounds familiar to > anyone and there's an obvious fix, I'd love to know (this is very old code > that I didn't write - if I were working on it now, I would probably use an > engine, but what I describe is what I have to work with). > > Thanks, > Andrew > > PS Is there any way to see the patches that were applied? Perhaps reading the > relevant patch would make more sense... > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
