Re: Apple are, apparently, dicks...

On Thu, Jun 13, 2013 at 6:39 PM, Ben Laurie wrote: It is therefore suggested that I pull this patch: > > > https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d The behavior change applies only if new option SSL_OP_SAFARI_ECDHE_ECDSA_BUG is used (part of SSL_OP_ALL), as

Re: Apple are, apparently, dicks...

> Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared >> libraries are updated to include the patch existing applications wont set >> it: >> they'd all need to be recompiled. >> > > That's a valid point. This is true, unfortunately. > > > Possibly alternative is to reuse

Re: not fork-safe if pids wrap

> Most other libraries I've seen handle this by saving the pid in a static > variable, and then comparing the current pid to it. This has the advantage > of not needing pthreads, and also of only adding the entropy to the child > if it is actually needed (i. e. it doesn't exec after fork). > We m

Re: not fork-safe if pids wrap

On Thu, Aug 22, 2013 at 4:50 AM, Bodo Moeller wrote: > > Most other libraries I've seen handle this by saving the pid in a static >> variable, and then comparing the current pid to it. This has the advantage >> of not needing pthreads, and also of only adding the entrop

Re: not fork-safe if pids wrap

> > (So we probably should use the current time in addition to the PID to > get a > > general solution to the PID wrap-around problem even on systems where > > actual independent reseeding isn't possible.) > > The FIPS PRNG uses a combination of PID, a counter and a form of system > timer > for the

Re: Locking inefficiency

Geoffrey Thorpe : First, you're right, pthreads_locking_callback() is collapsing everything > to a mutex. > I was well aware of this and thought we did this for compatibility reasons (because I couldn't think of any other reasonable explanation, I guess). If actual read-write locks are just as p

Re: Locking inefficiency

Geoffrey Thorpe : So I'm going to propose that we initially put this patch into the > development head only, and defer a decision on whether to cherry-pick it > into stable branches until that testing is in place. > Sure, sounds right. (Will you go ahead and handle the patch?) I certainly don'

Re: Locking inefficiency

Thor, can you quantify what you mean by "much more expensive"? (And qualify it - what platform, what operations?) The way we use the locks, in heavily multi-threaded applications, you can have a lot of contention with mutexes that wouldn't exist with read/write locks, because often all threads wo

Re: splitting clientHello into fragments?

> > Does openssl handle a clientHello (or any handshake message) that splits > across records? Mostly yes (I know because I made the changes to allow this a long time ago). A notable exception is that the cross-version code in s23_srvr.c requires that the first fragment contain at least 6 bytes

Re: EC_METHOD struct

balaji marisetti : > In the EC_METHOD structure, the pointers to methods for converting > between affine and projective coordinates are named: > > `point_set_Jprojective_coordinates_GFp` and > `point_get_Jprojective_coordinates_GFp` > > Does that mean any implementation of EC_METHOD (for prime cu

Re: EC_METHOD struct

Thulasi Goriparthi : Wouldn't it have been simpler to name these function pointers just > projective instead of Jprojective? > > This way, EC methods that use different projective system than jacobian > could have their own implementation to set/get projective co-ordinates and > use these function

Patch to mitigate CVE-2014-3566 ("POODLE")

Here's a patch for the OpenSSL 1.0.1 branch that adds support for TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack (CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf). Note well that this is not about a bug in OpenSSL -- it's a protocol issue. If SSL 3.0 is disabled in e

Re: Patch to mitigate CVE-2014-3566 ("POODLE")

mancha : > Any reason for the s_client -fallback_scsv option check to be within an > #ifndef OPENSSL_NO_DTLS1 block? Thanks for catching this. No, there's no good reason for that; I should move it elsewhere. Bodo

Re: Patch to mitigate CVE-2014-3566 ("POODLE")

This is not quite the same discussion as in the TLS Working Group, but I certainly think that the claim that "new SCSV does not help with [the SSL 3.0 protocol issue related to CBC padding] at all" is wrong, and that my statement that TLS_FALLBACK_SCSV can be used to counter CVE-2014-3566 is right.

Re: Patch to mitigate CVE-2014-3566 ("POODLE")

mancha : > Bodo Moeller wrote: > > I certainly think that the claim that "new SCSV does not help with > > [the SSL 3.0 protocol issue related to CBC padding] at all" is wrong, > > and that my statement that TLS_FALLBACK_SCSV can be used to counter > > CVE-2

Re: Patch to mitigate CVE-2014-3566 ("POODLE")

Jeffrey Walton : > Is there a way to compile without the patch? I think I would rather > 'config no=ssl3' and omit the additional complexity. Its additional > protocol complexity and heartbleed is still fresh in my mind. > There's no way to compile without the patch, other than reverting it. It'

Re: [openssl.org #3575] [BUG] FALLBACK_SCSV early in the cipher list breaks handshake

The fix will be in the next version. Note that OpenSSL servers aren't expected to see TLS_FALLBACK_SCSV in normal operation (the code is sufficiently version tolerant, etc.), and if you've enabled TLS 1.2, there isn't even a higher protocol version that the client could be falling back from, so th

OpenSSL 1.0.0d released

p4qKI7363uBnLgLGQIgS8BBar0n8QARYv4t6c7O+HR3Kn7VCix8cErUm5MkoL79n C2YJVRKPmpuwoPkLGwC6beB1fBiwvUaJd/n+BSU5LO534QcSzF+u4UKczsGnPX72 HSA/Mzf8C6w= =Rpu4 -END PGP SIGNATURE- -- Bodo Moellerb...@openssl.org OpenSSL Project http://www.openssl.org

OpenSSL Security Advisory: OCSP stapling vulnerability

. Neel Mehta (Google) identified the vulnerability. Adam Langley and Bodo Moeller (Google) prepared the fix. Which applications are affected - --- Applications are only affected if they act as a server and call SSL_CTX_set_tlsext_status_cb on the server's SSL_CTX.

OpenSSL Security Advisory: OCSP stapling vulnerability

. Neel Mehta (Google) identified the vulnerability. Adam Langley and Bodo Moeller (Google) prepared the fix. Which applications are affected - --- Applications are only affected if they act as a server and call SSL_CTX_set_tlsext_status_cb on the server's SSL_CTX.

OpenSSL 1.0.0d released

p4qKI7363uBnLgLGQIgS8BBar0n8QARYv4t6c7O+HR3Kn7VCix8cErUm5MkoL79n C2YJVRKPmpuwoPkLGwC6beB1fBiwvUaJd/n+BSU5LO534QcSzF+u4UKczsGnPX72 HSA/Mzf8C6w= =Rpu4 -END PGP SIGNATURE- -- Bodo Moellerb...@openssl.org OpenSSL Project http://www.openssl.org

Re: OpenSSL 1.0.0d released

On Tue, Feb 8, 2011 at 7:48 PM, Corinna Vinschen wrote:> OpenSSL version 1.0.0d released >> > > I'm missing an official release mail for 0.9.8r. Will you create one? > I wasn't planning to -- http://www.openssl.org/news/secadv_20110208.txt also announces 0.9.8r for those using the 0.9.8 branch,

Re: OpenSSL Security Advisory: OCSP stapling vulnerability

Thanks, Rob; I have updated the Security Advisory at http://www.openssl.org/news/secadv_20110208.txt. Bodo

Re: openssl-1.0.1-stable-SNAP-20111019 failure

On Wed, Oct 19, 2011 at 4:48 PM, Kenneth Robinette < supp...@securenetterm.com> wrote: > The openssl-1.0.1-stable-20111019 build fails as follows: > > fips_premain.c > link /nologo /subsystem:console /opt:ref /debug /dll /map /base:0xFB0 > /out:o > ut32dll\libeay32.dll /def:ms/LIBEAY32.def > @

Re: Limiting EC curves in ClientHello

> It appears there is no way to specify that only a subset should be used? > Yes, this is a know deficiency in the current code. I'm more familiar with the server side, but I think it's similar: if you set up *one* curve, then negotiation should happen accordingly; if you use a callback to provide

Re: Limiting EC curves in ClientHello

On Thu, Mar 1, 2012 at 11:16 AM, Erik Tkal wrote: > I looked around and found RFC 5430 - Suite B Profile for Transport Layer > Security (TLS), which states: > > RFC 4492 defines a variety of elliptic curves. For cipher suites > defined in this specification, only secp256r1(23) or secp384r1(2

Re: Limiting EC curves in ClientHello

On Thu, Mar 1, 2012 at 4:06 PM, Erik Tkal wrote: You mentioned previously that you can get it to specify none or one curve? > I don’t see how you would specify this, as it appears the client hello > preparation adds all of them is any EC cipher suite is specified? > Oh, sorry, you are right. Set

Re: Limiting EC curves in ClientHello

On Thu, Mar 1, 2012 at 11:28 PM, Erik Tkal wrote: > So then the question is will this be addressed in 1.0.1 or later? > Probably a bit later. Bodo

Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0

On Sat, Mar 17, 2012 at 3:53 PM, Stephen Henson via RT wrote: > > My reading of RFC4492 is that the ECC ciphersuites apply only to TLS > > 1.0 or later. According to it: "This document describes additions to TLS > > to support ECC, applicable both to TLS Version 1.0 [2] and to TLS > > Version 1.

Re: OpenSSL 1.0.1c deadlock

> We've managed on a few occasions now to reproduce an issue where OpenSSL > deadlocks while trying to acquire a mutex it already has. I filed > > > about this issue. I > currently have a server

Re: OpenSSL 1.0.1c deadlock

On Wed, Sep 5, 2012 at 3:06 PM, Bodo Moeller wrote: > > We've managed on a few occasions now to reproduce an issue where OpenSSL >> deadlocks while trying to acquire a mutex it already has. I filed >> <http://rt.openssl.org/Ticket/**Display.html?id=2866<http://rt.op

Re: [CVS] OpenSSL: OpenSSL_1_0_1-stable: openssl/crypto/ cryptlib.c

> Doh. I see it doesn't write to it. Nevertheless, seems like a bad > piece of code - its assuming errno is thread local, right? > This code uses the address of errno as a default thread ID for OpenSSL purposes. This works precisely because you typically have something like #define errno (*__error

Re: OCB Authenticated Encryption

On Tue, Feb 5, 2013 at 9:20 AM, Ted Krovetz wrote: > At last month's Workshop on Real-World Cryptography at Stanford > University, Phil Rogaway released a new license for OCB, granting free use > for all open-source implementations. > > http://www.cs.ucdavis.edu/~rogaway/ocb/license1.pdf > The

Re: OCB Authenticated Encryption

On Tue, Feb 5, 2013 at 1:41 PM, Ted Krovetz wrote: > There are actually two licenses. The second allows all software (even > closed), but only for non-military use. > > http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm > Thanks. Is some explanation of the non-military use condition available

Re: OpenSSL init races (WAS: Any updates on 0.9.6.(h))

On Sat, Nov 09, 2002 at 12:39:43PM +, Miles Sabin wrote: >> What do the C standards guarantee if we use 'volatile static'? > They don't say anything about semantics in multi-threaded/processor > environments. What exactly do they say about 'volatile' anyway? >> Your proposed code can't wo

Re: OpenSSL init races (WAS: Any updates on 0.9.6.(h))

Miles Sabin <[EMAIL PROTECTED]>: > First, the init flag needs to be volatile to prevent an aggressive > compiler from optimizing away the second check (nb. there may be issues > with compilers respecting volatile as mentioned in the key zeroizing > thread). I know it should really be volatile

Re: OpenSSL Bug

On Thu, Nov 14, 2002 at 11:14:49AM +0100, Lutz Jaenicke wrote: > On Wed, Nov 13, 2002 at 04:14:54PM -0800, Jeremiah Gowdy wrote: >> I was doing application development (not the topic of this email) >> interacting with an IBM developed SSL library. I experienced unexpected >> disconnects immediate

Re: man page location

On Sun, Jan 26, 2003 at 01:31:48PM -0800, Tim Rice wrote: > I looks like man pages are being installed in the wrong place on > non default installs. Ie. --prefix=/usr --openssldir=/etc/ssl It is intentional that we use the --openssldir value rather than the --prefix value in such cases. Files in

Re: [openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error

Arne Ansper <[EMAIL PROTECTED]>: >> Like I say, they should only do this if there was an error reported, surely? > No. Take a look at the SSL_CTX_use_certificate_chain_file: > > ret=SSL_CTX_use_certificate(ctx,x); > if (ERR_peek_error() != 0) > ret = 0; /* Key/certificate mismat

Re: no-err option

On Thu, Jan 30, 2003 at 11:02:33AM +0100, Martin Witzel wrote: > This refers to 0.9.7. I have not verified it with earlier versions > > When I setup the build process with the 'config no-err' option, I get a lot > of _link_ errors in the apps directory, because the complete crypto/err > directory

Re: openssl req prompting behavior

On Wed, Jan 22, 2003 at 04:20:37PM -0600, Joel Daniels wrote: > The "openssl req" command, when set up to prompt for the Distinguished Name, > uses fgets() to read the Distinguished Name fields. This means that if > someone uses the backspace key, a 0x08 character is inserted wherever they > type

Re: Win32 update to the ssleay32.def file

On Tue, Feb 04, 2003 at 04:32:24PM -0500, Joseph Ferner wrote: > In OpenSSL 0.9.7 SSL_add_dir_cert_subjects_to_stack (ssl_cert.c) was > added for Win32 but was omitted in the ssleay32.def file. Could this be > added? Thanks for the report, this is now fixed. > It would also be nice to have ssl3

Re: [openssl.org #461] Minor makefile/ranlib problem in crypto/{engine krb5ocsp ui}

On Thu, Jan 16, 2003 at 12:13:11PM -0500, Rich Salz wrote: >> $(RANLIB) $(LIB) || echo Never mind. > How about putting a leading minus sign; it's simpler. Using the minus sign is simpler to write in the Makefile -- but 'make' will still report an error (and say that it's ignored), which ten

Re: S/MIME PKCS7 and the famous CRLF

On Tue, Feb 11, 2003 at 10:51:56AM +0100, Holger Sesterhenn wrote: > I am playing around with PKCS7 mails and also have noticed the small > gliches when dealing with multipart/mime. (yes, I have spent some time > reading groups.google and the mailing list archives). > > If I understand RFC2046

IMPORTANT: please test snapshot openssl-0.9.7-stable-SNAP-20030214.tar.gz

Please test snapshot openssl-0.9.7-stable-SNAP-20030214.tar.gz (or later), which will be available today around 8 p.m. GMT at ftp://ftp.openssl.org/snapshot;type=d >. We plan to release version 0.9.7a soon (next week if all goes well). OpenSSL 0.9.7a will be a bugfix release based on 0.9.7; thus t

Re: [openssl.org #511] BUG: crypto/ec/ec_key.c:EC_KEY_dup()

Bodo Moeller via RT <[EMAIL PROTECTED]>: [nothing] RT has cut off the message, which said that the fix will be in the next snapshot (which should be the latest snapshot by now). -- Bodo Möller <[EMAIL PROTECTED]> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x3

Re: [CVS] OpenSSL: openssl/crypto/asn1/ d2i_pu.c i2d_pu.c openssl/crypto/e...

On Fri, Feb 21, 2003 at 02:58:24PM +0100, Bodo Moeller wrote: > Log: > ECPublicKey_set_octet_string and ECPublicKey_get_octet_string > behaviour was not quite consistent with the conventions > for d2i and i2d functions as far as handling of the 'out' &g

Re: [openssl.org #541] Problem with the blinding patch

Bobco, Pete <[EMAIL PROTECTED]>: > After applying the March 17, 2003 RSA Blinding patch, I am seeing > some intermittant problems when I browse to my test server to > retrieve pages. Sometimes a GIF file does not appear, but using the > Refresh key will get it. I am wondering if anyone else out

[OpenSSL Advisory] Klima-Pokorny-Rosa attack on PKCS #1 v1.5 padding

OpenSSL Security Advisory [19 March 2003] Klima-Pokorny-Rosa attack on RSA in SSL/TLS === Czech cryptologists Vlastimil Klima, Ondrej Pokorny, and Tomas Rosa have come up with an extension of the "Bleichenbacher attack" on RSA with PKCS #1 v1.5 padding as u

Re: RSA Blinding patch and a recent snapshot.

On Mon, Mar 31, 2003 at 03:01:27PM -0500, Greaney, Kevin wrote: > I downloaded a snapshot recently, > openssl-e-0.9.6-stable-SNAP-20030327.tar.gz, > and was comparing the files [.crypto.rsa]rsa_eay.c AND > [.crypto.rsa]rsa_lib.c. I noticed > that in rsa_eay.c that the patch used the "posi

Re: PATCH: p2q (or rather q2p) 'RSA' option (also "TSU NOTIFICATION")

On Tue, Apr 26, 2005 at 01:25:03PM -0700, Marius Schilder wrote: > See attached, I removed the extra field I added to > rsa_st. All computation is done in-line, very > unintrusive patch now. Any reason this can't make it > in the dist? Speed improvements like this are certainly interesting, but u

Re: "openssl -req" dumping core

On Fri, Feb 23, 2001 at 10:31:51AM +0100, Per Winkvist wrote: > localhost: ~> /bin/openssl req -inform DER -in /tmp/tmp.crt -verify > Using configuration from /usr/local/ssl/openssl.cnf > Unable to load config info > Segmentation fault (core dumped) > > #0 0xa51dc in lh_retrieve () > (gdb) bt [

Re: Bug#87547: format problem in RAND_add.3ssl

Christoph Martin <[EMAIL PROTECTED]>: > Wichert Akkerman writes: >> Package: openssl >> Version: 0.9.6-1 >> Severity: normal >> >> The HISTORY section of RAND_add(3ssl) isn't formated correctly, its end >> looks like this: >> >> RAND_event() in OpenSSL 0.9.5a. >> >> entropy to the PR

Re: [PATCH] Make SSL_peek() work with SSLv23_server_method

Dan Kegel <[EMAIL PROTECTED]>: >> (Your are right that it is strange that the SSL23_methods support >> SSL_read but not SSL_peek, but this should be fixed in s23_lib.c >> and not in s23_srvr.c.) > Your wish is my command. How about this patch? It's not complete, > since it doesn't deal with cl

Re: Operating System supported by OpenSSL

> From: Ulf Moeller <[EMAIL PROTECTED]> > On Thu, Mar 08, 2001, Richard Levitte - VMS Whacker wrote: > >> CDive> - Solaris 2.8 with 32bits or 64 bits libraries >> >> I've tested 0.9.6 32bit, I haven't tested 64bit. My tests showed it >> worked. >> >> CDive> - HPUX

Re: cvs commit: openssl/doc/apps ocsp.pod req.pod x509.pod

On Fri, Mar 09, 2001 at 02:57:18PM +0100, [EMAIL PROTECTED] wrote: > --- x509.pod2001/01/10 14:35:20 1.11 > +++ x509.pod2001/03/09 13:57:14 1.12 > @@ -36,6 +36,7 @@ >[B<-addreject arg>] >[B<-setalias arg>] >[B<-days arg>] > +[B<-set_serial n>] >[B<-

Re: cvs commit: openssl/test bctest

On Fri, Mar 16, 2001 at 11:07:07AM +0100, Richard Levitte - VMS Whacker wrote: >>> +# >>> +# Find the full pathname(s) of bc >>> +# >>> +findBc() >>> +{ >>> +IFS=: >>> +for i in $PATH; do >>> + eval test -x $i/bc -a ! -d $i/bc && { echo $i/bc ; } >>> +done >>> +

Re: cvs commit: openssl/crypto/rand rand.h

On Wed, Mar 21, 2001 at 07:43:16PM +0100, [EMAIL PROTECTED] wrote: > levitte 21-Mar-2001 19:43:15 > Modified:crypto/rand rand.h > Log: > Use stdlib.h to get size_t. > > Revision ChangesPath > 1.22 +1 -7 openssl/crypto/rand/rand.h > > Index: rand.h >

Re: cvs commit: openssl/apps s_server.c

Ben Laurie <[EMAIL PROTECTED]>: > Attempting to make URL to file translations safe is a tricky task. I > suggest we don't even bother with s_server - why would we want to? It is > a test/demo tool? Richard add a -WWW option that makes available the files under the current directory. It's just a

Re: cvs commit: openssl/apps s_server.c

On Sat, Mar 31, 2001 at 09:46:34AM +0200, Bodo Moeller wrote: > Richard add a -WWW option that makes available the files under the ^^^ I thought I typed "added" ... -- Bodo Möller <[EMAIL PROTECTED]> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moel

Re: Memory Leaks

On Wed, Apr 04, 2001 at 09:23:26AM -0500, Brook A. Keele wrote: > [...]OpenSSL built fine, I can make the connection, most of the > time, but after a short while I have to close the server because I am out of > memory. These memory leaks in CRYPTO_malloc are baffling me. Anyone who ca

Re: [PATCH] for -DNO_RSA option

On Thu, Apr 05, 2001 at 09:52:57AM -0400, Eric Bolinger wrote: > I ran into a problem when stripping out the RSA code. Following the format > of other source files, I added an "#ifndef NO_RSA" around the entire > rsautl.c code. Actually such a change has already been done; see http://www.openss

Re: cvs commit: openssl/ssl s3_enc.c ssl.h ssl_err.c ssl_lib.c

On Mon, Apr 09, 2001 at 12:29:32PM +0200, Richard Levitte - VMS Whacker wrote: > bodo> Log: > bodo> Avoid assert() in the library. > Hmm, my thinking with that assert is that it should be caught > *EARLY*. If we release anything with a buf too small for any ciphers > and digests that we sup

Re: cvs commit: openssl/ssl s3_enc.c ssl.h ssl_err.c ssl_lib.c

On Mon, Apr 09, 2001 at 04:23:41PM +0200, Richard Levitte - VMS Whacker wrote: > From: Bodo Moeller <[EMAIL PROTECTED]> > > moeller> I don't think it's good to have active assert()s in default > moeller> compilations of libraries -- in particular, libra

Re: Reason codes for Err_error_string()

On Mon, Apr 09, 2001 at 10:27:37AM -0500, Brook A. Keele wrote: > Where is it that I can find the what the reason codes mean? > i.e. > error:0005:lib(0):func(0):reason(5) > > where can i look these up to find out what is actually wrong? If the program uses ERR_load_crypto_strings() (and S

Re: Problems with random seed initialization on Windows platforms.

On Wed, Apr 18, 2001 at 09:20:31AM -0400, Jeffrey Altman wrote: >> 2. The following piece of code seems to have race condition, causing >> very long initialization time for our application, especially when there are >> very many processes and threads running in the system (file: >> crypto/rand/

Re: Problems with random seed initialization on Windows platforms.

On Wed, Apr 18, 2001 at 03:47:27PM +0200, Bodo Moeller wrote: >> This fix seems reasonable. > Except for the deadlock. add_do_not_lock must be set *before* RAND_poll > is called if the lock is held at that time. Actually, add_do_not_lock is broken too: When one thread has set add

Re: Solaris gcc shared library target is broken in 0.9.6a

On Sat, Apr 14, 2001 at 07:49:36PM +0200, Richard Levitte - VMS Whacker wrote: > carson> The solaris-*-gcc targets all seem to assume you're using GNU > carson> ld, which nobody _I_ know does under solaris (does it even > carson> compile?). This causes the shared library builds to > carson> bomb.

Re: int return values from ssl(3) API functions

On Fri, Apr 20, 2001 at 11:29:51AM -0400, Tom Biggs wrote: > I'm implementing code to do OpenSSL handshake/read/write > for some radically different hardware. These will completely > replace the standard OpenSSL handshake state machine > and most of the API functions at the SSL_METHOD level. >

Re: mt issue in md_rand.c?

ng the CRYPTO_LOCK_RAND lock (and may even illegaly release the lock that they do not hold after the first thread unsets add_do_not_lock). [Bodo Moeller] Please try the latest 0.9.6-stable snapshot (ftp://ftp.openssl.org/snapshot/) and report if the problem has been solved. -- Bo

Re: mt issue in md_rand.c?

On Mon, Jul 09, 2001 at 09:44:29AM -0700, Travis Vitek wrote: > This fix seems to work fine, but there is still a (small) potential > problem... > > Consider the situation where thread id 0 is valid (this is true for some > systems). If one thread (thread id N) unsets the flags and releases the

Re: mt issue in md_rand.c?

On Mon, Jul 09, 2001 at 10:34:52PM +0200, Bodo Moeller wrote: [...] >> would be written like this... >> >> CRYPTO_w_lock(CRYPTO_LOCK_RAND); >> >> locking_thread = CRYPTO_thread_id(); >> crypto_lock_rand = 1; > This wa

Re: [ANNOUNCE] OpenSSL 0.9.6b

On Tue, Jul 10, 2001 at 11:47:01AM +0200, Götz Babin-Ebell wrote: >> The distribution file names are: >> >> o openssl-0.9.6b.tar.gz [normal] >> o openssl-engine-0.9.6b.tar.gz [engine] > Could you start signing such mails ? > > And please, include a hash for the distribution files

Re: variable size pedant patch to 0.9.6a (or 0.9.6)

On Mon, Jun 25, 2001 at 04:01:01AM +0100, Ben Laurie wrote: > Sorry, I'd managed to forget about opensslconf.h! It does also solve the > problem and I have no problem with it. However, it would be safer if data strutures in exported headers did not depend on disabled ciphers. In the OPENSSL_NO_

Re: cvs commit: openssl/crypto/des Makefile.ssl cbc_cksm.c cfb64ede.c cfb64enc.c cfb_enc.c des.h des_enc.c des_locl.h destest.c ecb3_enc.c ecb_enc.c ede_cbcm_enc.c enc_read.c enc_writ.c fcrypt.c fcrypt_b.c ncbc_enc.c ofb64ede.c ofb64enc.c ofb_enc.c pcbc_enc.c rpc_enc.c set_key.c str2key.c xcbc_enc.c

On Mon, Jul 30, 2001 at 07:47:13PM +0200, [EMAIL PROTECTED] wrote: > Index: des.h > === > RCS file: /e/openssl/cvs/openssl/crypto/des/des.h,v > retrieving revision 1.32 > retrieving revision 1.33 > diff -u -r1.32 -r1.33 >

Re: bugs in openssl make test

On Thu, Jul 05, 2001 at 10:57:21AM +0100, Sean O'Riordain wrote: >> test BN_mod_exp >> test BN_exp >> running bc >> >> Failed! bc: /bin/sh: bc: command not found >> make[1]: *** [test_bn] Error 255 >> make[1]: Leaving directory `/home/tmp/openssl-0.9.5/test' >> make: *** [tests] Error 2 > not a

Re: cvs commit: openssl/crypto/des Makefile.ssl cbc_cksm.ccfb64ede.c cfb64enc.c cfb_enc.c des.h des_enc.c des_locl.h destest.cecb3_enc.c ecb_enc.c ede_cbcm_enc.c enc_read.c enc_writ.c fcrypt.cfcrypt_b.c ncbc_enc.c ofb64ede.c ofb64enc.c ofb_enc.c pcbc_enc.crpc_enc.c set_key.c str2key.c xcbc_enc.c

On Tue, Jul 31, 2001 at 01:49:24PM -0400, Jeffrey Altman wrote: >>> Please be very careful with the changes that are made to DES. The DES >>> structures and functions from OpenSSL were originally designed by Eric >>> to be compatible with the MIT Kerberos DES implementation. This has >>> allowe

Re: cvs commit: openssl/crypto/des Makefile.ssl cbc_cksm.ccfb64ede.c cfb64enc.c cfb_enc.c des.h des_enc.c des_locl.h destest.cecb3_enc.c ecb_enc.c ede_cbcm_enc.c enc_read.c enc_writ.c fcrypt.cfcrypt_b.c ncbc_enc.c ofb64ede.c ofb64enc.c ofb_enc.c pcbc_enc.crpc_enc.c set_key.c str2key.c xcbc_enc.c

On Wed, Aug 01, 2001 at 12:49:31PM +0100, Ben Laurie wrote: > (incidentally, when > did the weak_key member get introduced [in the wrong place]?). When: SSLeay 0.9.1b. Why: No idea. -- Bodo Möller <[EMAIL PROTECTED]> PGP http://www.informat

Re: cvs commit: openssl/crypto/rsa rsa.h rsa_lib.c

On Sat, Aug 25, 2001 at 07:24:23PM +0200, [EMAIL PROTECTED] wrote: > +/* "up" the DSA object's reference count */ > +intDSA_up(DSA *r); > +/* "up" the RSA object's reference count */ > +intRSA_up(RSA *r); Shouldn't the function names contain the word "references" (or "re

Re: Bug in primality testing in OpenSSL

Young, Adam [NCSUS Non J&J] <[EMAIL PROTECTED]>: > I found a cryptographic bug in bn_prime.c in the function > BN_is_prime_fasttest(). > [...] the value > check, which may turn out to be a witness of compositeness for the > value being tested fo

Re: cvs commit: openssl/crypto/engine enginetest.c

On Thu, Sep 06, 2001 at 03:08:09PM +0100, Ben Laurie wrote: > [EMAIL PROTECTED] wrote: >> - free((char *)(ENGINE_get_id(block[loop]))); >> - free((char *)(ENGINE_get_name(block[loop]))); >> + OPENSSL_free((char *)(ENGINE_get_id(block[loop]))); >> +

Re: cvs commit: openssl/crypto/engine enginetest.c

On Mon, Sep 10, 2001 at 02:20:16PM +0100, Ben Laurie wrote: > I don't see why it goes back to me, I didn't write the code! Oops, for some reason I had assumed that you did. -- Bodo Möller <[EMAIL PROTECTED]> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU

Re: cvs commit: openssl/crypto/engine enginetest.c

Ben Laurie <[EMAIL PROTECTED]>: >> --- enginetest.c 2001/09/10 14:10:10 1.10 >> +++ enginetest.c 2001/09/10 17:46:54 1.11 >> @@ -234,8 +234,8 @@ >> } >> for(loop = 0; loop < 512; loop++) >> { >> - OPENSSL_free(ENGINE_ge

Re: IP renaming problem...

Rich Salz <[EMAIL PROTECTED]>: > Unfortunately, the OpenSSL wrapper around gethostbyname cache's lookup > results forever, so you'll need to restart your application. I know you > said you can't do that. Good luck figuring out how to address this. > > Infinite caching of gethostbyname() result

Re: excessive m essage size

On Tue, Jul 31, 2001 at 07:41:32PM +0400, Antony Uspensky wrote: > Problem description: > > Trying to use 4096 bit RSA keys I get a error in SSL_accept (): > > error:1408E098:SSL routines:SSL3_GET_MESSAGE:excessive message size > > The error is signaled only if RSA key length is more then ~350

Re: [PATCH] Tru64 UNIX build improvements for 0.9.6b

On Wed, Aug 15, 2001 at 09:31:16PM -0500, [EMAIL PROTECTED] wrote: > On Thu, Aug 09, 2001 at 02:46:03PM +0200, Richard Levitte - VMS Whacker wrote: > > From: Andy Polyakov <[EMAIL PROTECTED]> >>> And as for -rpath option. What are the arguments against making it >>> default? >> Distribution. If

Re: [PATCH] openssl-0.9.6b config fix for `make reports' hang

On Thu, Aug 23, 2001 at 06:23:12PM -0500, Tim Mooney wrote: [...] > Because `config' detected that it was possible to build a 64 bit version > of OpenSSL, it will stop and wait for user input from /dev/tty. When > the `report' make target is built, it runs > > perl util/selftest.pl > > w

Re: [Eric Rescorla ] Re: SSL renegotiation and SSL_bio (more data)

Eric Rescorla <[EMAIL PROTECTED]>: > P.S. Does OpenSSL have some official way to report bugs? [EMAIL PROTECTED] (which is gated to [EMAIL PROTECTED]). __ OpenSSL Project http://www.openssl.org Dev

Re: [Eric Rescorla ] Re: SSL renegotiation and SSL_bio (more data)

On Thu, Sep 20, 2001 at 12:00:00AM +, Eric Rescorla wrote: [...] > After some investigation, the problem appears to be that > you can't safely interlace SSL_write() with rehandshakes. > > Consider the following sequence of events: > > CLIENTSERVER > >

Re: cvs commit: openssl STATUS

On Tue, Sep 25, 2001 at 01:34:51PM +0100, Ben Laurie wrote: > [EMAIL PROTECTED] wrote: >> 'openssl speed' does not include AES support yet > It does if you use an EVP. The at least the usage output should be corrected: $ ./openssl speed foo Error: bad option or value Available values: md2

Re: [Design] changes to des.h

Michael Richardson <[EMAIL PROTECTED]>: >> My suggestion: >> >> change the typedef, (or probably, add a new one): >> >> struct des_ks_struct >> { >> union { >> des_cblock _; >> /* make sure things are correct size on machines with >> * 8 b

Re: bug in ssl3_get_key_exchange

nagendra modadugu <[EMAIL PROTECTED]>: > SSLv3 clients call ssl3_get_key_exchange regardless of whether this > message is required for the chosen cipher. > > As a result, ssl3_get_message called from ssl3_get_key_exchange ends up > reading the certificate request message (when doing client auth

Re: OpenSSL ignores client version number in v3/TLS mode

Eric Rescorla <[EMAIL PROTECTED]>: > DESCRIPTION: If you have your server configured to support only > SSLv3 or only TLS (SSLv3_method, SSLv3_server_method, TLSv1_method, > TLSv1_server_method) then the server will simply attempt to > use whatever version of SSL/TLS it is configured to, ignoring

Re: function declarations with no parameter specifications

Jeremy Hylton <[EMAIL PROTECTED]>: [...] > There are a lot of struct and function declarations that define > function pointers without parameter specifications. These are > problematic on several grounds, no least of which is the anal goal we > have of making Python compile without any warnings

Re: e_os.h allways defines _REENTRANT on sun ?

On Fri, Nov 02, 2001 at 04:11:59PM +0100, Götz Babin-Ebell wrote: > from e_os.h: > > #if defined(THREADS) || defined(sun) > ^^^ > #ifndef _REENTRANT > #define _REENTRANT > #endif > #endif > > why ? Historical reasons. As now Configure knows about multi-threadi

Re: DES changes...

On Tue, Nov 06, 2001 at 11:58:30AM +0100, Richard Levitte - VMS Whacker wrote: >> In OpenSSL, there are no similarly named functions for ciphers other >> than DES; so we can simply rename DES_random_key() to DES_rnd_key() or >> DES_rand_key() or DES_create_random_key() without causing too much >>

Re: non-MONOLITH build no longer works in 0.9.6b

On Wed, Nov 21, 2001 at 11:48:38AM +, Adam Back wrote: > I tried to build without MONOLITH defined, to check the object size > for the subset of functions in one of the programs, and it seems that > the build system is broken if you undefine MONOLITH. > > This was with openssl-0.9.6b. Can y

Re: OpenSSL client side library hungs, when received SSLv3 Hello Request.

Yoshihiro Kawabe <[EMAIL PROTECTED]>: > I found a small bug in `ssl/s3_both.c'. > > The ssl3_get_message function configured client side (! s->server) > receives SSL3_MT_HELLO_REQUEST (SSLv3 Hello Request), then fall into > eternal loop. > > `do-while loop` between 362 line and 388 line has no

Re: CLK_TCK weird in Linux

On Thu, Sep 27, 2001 at 02:15:57PM +0200, Richard Levitte - VMS Whacker wrote: > I was quite surprised when running openssl speed today, and got 0.00s > as user time for everything. This is on a RH 6.2 box. [...] Do 'ssltest' timings make sense (they are automatically displayed while running '

Re: CLK_TCK weird in Linux

On Fri, Sep 28, 2001 at 12:17:28PM +0200, Richard Levitte - VMS Whacker wrote: > From: Bodo Moeller <[EMAIL PROTECTED]> >> If you want elapsed real time ('openssl speed -elapsed'), you need >> times(), which measures in clock ticks and not in CLOCKS_PER_SEC.

  1   2   3   4   5   6   7   8   >