Re: [openssl.org #1011] PKCS7 verifier fails to recognize sha1WithRSAEncryption digestAlgorithm
"Stephen Henson via RT" <[EMAIL PROTECTED]> writes:
>> Is there a good (suggested) workaround for the older version that
>> doesn't have this fix? Can I, perhaps, define a new hash-type that
>> defines itself as sha1WithRSAEncryption? Or do you think that would
>> cause problems?
>>
>
> Well replacing pk7_doit.c with the latest version would be one fix. If
> you need an application level fix you could always look for
> sha1WithRSAEncryption in the PKCS7 structure and change it to SHA1.
Hmm, okay.. Let me rephrase -- is there an application-level fix that
I can put into place while still using the "vendor-supplied" openssl
library? I wouldn't think that an application could supply its own
version of pk7_doit.c and get the system libssl to see it?
I tried registering a new MD type which was just a copy of the
EVP_sha1 with the type changed from NIP_sha1 to
NIP_sha1WithRSAEncryption. That seemed to get me further but then
it died in the RSA_verify() section in rsa_sign.c:
if (sigtype != dtype)
{
if (((dtype == NID_md5) &&
(sigtype == NID_md5WithRSAEncryption)) ||
((dtype == NID_md2) &&
(sigtype == NID_md2WithRSAEncryption)))
{
/* ok, we will let it through */
#if !defined(OPENSSL_NO_STDIO) && !defined(OPENSSL_SYS_WIN16)
fprintf(stderr,"signature has problems, re-make
with post SSLeay045\n");
#endif
}
else
{
RSAerr(RSA_F_RSA_VERIFY,
RSA_R_ALGORITHM_MISMATCH);
goto err;
}
}
> Steve.
In the meantime I'm also looking at the other side to see if I can
convince windows to generate pkcs7 with sha1, or some way to change
that.
Thanks,
-derek
--
Derek Atkins 617-623-3745
[EMAIL PROTECTED] www.ihtfp.com
Computer and Internet Security Consultant
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Engine and static linking
In message <[EMAIL PROTECTED]> on Fri, 18 Feb 2005 14:50:25 -0800 (PST), Prashant Kumar <[EMAIL PROTECTED]> said: pkix2005> Is it possible to use the engine implementation with pkix2005> statically linking the harware accelerator library with the pkix2005> openssl instead of dynamic linking. pkix2005> pkix2005> All the posts I have read so far suggest that I should have pkix2005> a ".so" and engine implementation will load it at run time. That's because that's the prefered way. If you look at the built-in engines, though, you will see that they have code for non-dynamic situations. In that case, the engine needs to define a loading function (ENGINE_load_foo()) which needs to be called instead of doing whatever you do to load the engine dynamically. I haven't done this for a few years, so I'm a bit rusty myself... Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1010] Bug report: Typo in blowfish manual page
[EMAIL PROTECTED] - Wed Feb 16 19:43:23 2005]: > There is a typo in openssl/doc/crypto/blowfish.pod in your CVS > repository. Please see the attached diff. Patch applied. Thanks, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1014] prngd/egd interface hard loops eating CPU if descriptor closes
[EMAIL PROTECTED] - Sat Feb 19 11:06:08 2005]: > Hi. > We had a report of sshd looping and eating CPU under some conditions > (reference below). The original report was on Solaris 8, we had other on > HP-UX 11.11 and I have reproduced it on HP-UX 11.00. It can probably > occur on any platform using egd or prngd for entropy. > > The cause of the CPU utilization appears to be a bug in OpenSSL's > egd/prngd interface. It seems that when reading from prngd, the read > loop does not test for a return of zero indicating the descriptor has > closed, and will retry the read() ad infinitum if that happens. At this > time, I am not sure why/how the descriptor ends up closed, however I have > found a way to reproduce the problem at will. Thanks, your patch to OpenSSL is obviously correct. (That will still leave the issue of PRNGD not working correctly, but this is not an OpenSSL problem :-) Patch applied to OpenSSL 0.9.7-stable (to become 0.9.7f) and openssl-dev Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1014] AutoReply: prngd/egd interface hard loops eating CPU if descriptor closes
I forgot to explicitly mention it (and you can probably infer it from the patch), but for the record this was with OpenSSL 0.9.7e. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1014] prngd/egd interface hard loops eating CPU if descriptor closes
Hi. We had a report of sshd looping and eating CPU under some conditions (reference below). The original report was on Solaris 8, we had other on HP-UX 11.11 and I have reproduced it on HP-UX 11.00. It can probably occur on any platform using egd or prngd for entropy. The cause of the CPU utilization appears to be a bug in OpenSSL's egd/prngd interface. It seems that when reading from prngd, the read loop does not test for a return of zero indicating the descriptor has closed, and will retry the read() ad infinitum if that happens. At this time, I am not sure why/how the descriptor ends up closed, however I have found a way to reproduce the problem at will. Attached are 2 patches: prngd-0.9.29-fake-failure.patch: This is a nasty hack to prngd to provoke the error in RAND_bytes() and friends. Apply it, start prngd and run something like "openssl rand -out /dev/null 512" while watching "top" or similar. "openssl" will hang while eating CPU. openssl-0.9.7e-rand-egd-loop.patch: This is my attempt to fix the problem by testing for a zero return code from read(). Tested OK on HP-UX 11.00. The original bug report is here: http://bugzilla.mindrot.org/show_bug.cgi?id=948 Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
