Re: OpenSSL Security Advisory: Record of death

2010-03-26 Thread Adam Langley
On Thu, Mar 25, 2010 at 5:16 PM, Claus Assmann ca+ssl-...@esmtp.org wrote: So far I haven't been able to determine which change caused the problem, so I'm still looking at various diff's, but I'm not familiar with the source code to (easily) spot the problem. I imagine the reason that the

Re: OpenSSL Security Advisory

2010-03-26 Thread Jean-Marc Desperrier
Bodo Moeller wrote: it's code elsewhere that no longer tolerates the coarse logic we are changing in the patch, which has been around forever. In fact, I already suspected that, thanks for the confirmation. __ OpenSSL Project

Re: libcrypto safe for library use?

2010-03-26 Thread Mark Phalan
On 03/26/10 04:44 AM, David Schwartz wrote: Mark Phalan wrote: The threads(3) manpage states that to use OpenSSL in multi-threaded applications then locking callback functions must be set otherwise random crashes may occur. That is correct. This poses a challenge when using OpenSSL in a

Re: libcrypto safe for library use?

2010-03-26 Thread Darryl Miles
Mark Phalan wrote: The threads(3) manpage states that to use OpenSSL in multi-threaded applications then locking callback functions must be set otherwise random crashes may occur. This poses a challenge when using OpenSSL in a library which should be MT safe. There is no safe way to set

[openssl.org #2206] [PATCH] Implicitly support non-delegated OCSP response signing

2010-03-26 Thread Rob Stradling via RT
The attached patches (generated against OpenSSL 0.9.8n and OpenSSL-1.0.0- beta5) cause openssl ocsp to implicitly trust the Issuing CA Certificate (as denoted by the -issuer parameter) as a candidate OCSP Response signer. This non-delegated model is allowed by RFC 2560. With this patch, it's

Re: libcrypto safe for library use?

2010-03-26 Thread Mark Phalan
On 03/25/10 02:13 PM, Mark Phalan wrote: The threads(3) manpage states that to use OpenSSL in multi-threaded applications then locking callback functions must be set otherwise random crashes may occur. This poses a challenge when using OpenSSL in a library which should be MT safe. There is no

RE: [openssl.org #2045] [PATCH] Use Intel AES-NI automatically where available.

2010-03-26 Thread David Woodhouse
On Thu, 2010-03-25 at 17:57 +0100, PMHager wrote: As all major compilers for Intel CPUs support intrinsics and, if used correctly, optimize to the same instructions as direct assembler, IMHO these policies should be reconsidered to keep OpenSSL competitive. For good reasons perlasm is

Re: [openssl.org #2045] [PATCH] Use Intel AES-NI automatically where available.

2010-03-26 Thread Andy Polyakov
My question was about the inconsistency between, for example, SSE-optimised and AESNI-optimised functions. Both are implemented as perlasm; that's not relevant. What _is_ relevant, however, is that the SSE optimisations end up in the 'core' AES_encrypt() function which is tested by 'openssl

Re: [openssl.org #2045] [PATCH] Use Intel AES-NI automatically where available.

2010-03-26 Thread Andy Polyakov
PM, Though I am not a member of the OpenSSL team, I totally agree with you. As for the AES, the Westmere CPUs have also a new instruction for the GHASH (pclmulqdq / _mm_clmulepi64_si128). It's not an instruction *for* GHASH, it's an instruction that among other thing can be used for GHASH.

RE: libcrypto safe for library use?

2010-03-26 Thread David Schwartz
Mark Phalan wrote: Unfortunately that's not really practical. To take an example I'm familiar with - libgss. libgss can end up calling into OpenSSL in the following way: libgss - kerberos - pkinit plugin - openssl It's simply not practical to change libkrb5 and libgss and all