Re: [openssl-dev] procedure for adding new engine registration

Hi Matt, Very useful information. I too agree with you that we need not have a new engine distribution. I see some options like dynamic engines and static engine support. If we have built a library with dynamic engine interface, how can we do speed test using openssl speed command. Thanks

Re: [openssl-dev] procedure for adding new engine registration

On 13/11/15 11:16, Vemulapalli Jyothi wrote: > Hi Matt, > > Very useful information. > > I too agree with you that we need not have a new engine distribution. > > I see some options like dynamic engines and static engine support. > > If we have built a library with dynamic engine interface,

Re: [openssl-dev] procedure for adding new engine registration

On 12/11/15 18:21, Vemulapalli Jyothi wrote: > Hi all, > > > > We would like to add a new engine registration to openssl. > > > > Can you please explain a procedure? > > > > When we gone through the code, we could find an engines directory in > openssl , but those files are not

Re: [openssl-dev] [openssl.org #4138] Detection of assembler version

Am 12.11.2015 um 22:20 schrieb Andy Polyakov via RT: > Hi, > >> I just found out that building with at least with the French >> locale the AVX code is missing. The problem is this code in >> crypto/sha/asm/sha1-x86_64.pl: >> if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1` >>

Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code

> So, does the above mean that my patch is not going to be merged? No. It will be. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 11/13/2015 09:31 AM, Jakob Bohm wrote: > On 13/11/2015 14:40, Emilia Käsper wrote: >> Hi all, >> >> We are considering removing from OpenSSL 1.1 known broken or outdated >> cryptographic primitives. As you may know the forks have already done >> this but I'd like to seek careful feedback for

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Hi, > We are considering removing from OpenSSL 1.1 known broken > or outdated cryptographic primitives. As you may know the forks > have already done this but I'd like to seek careful feedback for > OpenSSL first to ensure we won't be breaking any major applications. [...] > My preference

[openssl-dev] OCSP integration into TLS handshake

Has there been/will there be any development towards integrating OCSP checking into the handshake the way CRL checking is, along the lines of Alexander Komyagin's patch from 2012? https://marc.info/?l=openssl-dev=133994624016769=2 https://marc.info/?l=openssl-users=134035740600560=2 This would

Re: [openssl-dev] [openssl.org #4138] Detection of assembler version

Am 12.11.2015 um 22:20 schrieb Andy Polyakov via RT: Hi, I just found out that building with at least with the French locale the AVX code is missing. The problem is this code in crypto/sha/asm/sha1-x86_64.pl: if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1`

[openssl-dev] [openssl.org #4139] bug: lacking OPENSSL_load_builtin_modules() docs

Hey The man page for the function OPENSSL_load_builtin_modules() doesn't include any details on how the memory it allocates is supposed to get freed by a user. I assume CONF_modules_free() is the funtion to use for this purpose? -- / daniel.haxx.se

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Fri, Nov 13, 2015, Benjamin Kaduk wrote: > > As another thread calls to mind, PKCS#12 could potentially just use > triple-DES. (BTW, the CMS tests fail when openssl is configured with > no-rc2, due to this; I have a WIP patch sitting around.) > The issue is that some cuurent software

[openssl-dev] Fwd: [openssl-users] How to get list of TLS protocols supported by OpenSSL?

Hi guys, I recently confirmed, from the openssl-users mailing list, that there's no suitable API call to determine what TLS versions a given compiled copy of the OpenSSL library is capable of. This would be a functionality that would be useful to a lot of real-world users. I was thinking of

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

> ALL BINARY ELLIPTIC CURVES This one may be premature. I understand the TLS WG is moving against it. However, I am aware of implementations of Shoup's ECIES, and they, in turn, depend on OpenSSL. I don't know if the ECIES implementations rely solely on prime fields or not, however. > BLOWFISH

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Hi, On 13/11/15 17:08, stefan.n...@t-online.de wrote: >> We are considering removing from OpenSSL 1.1 known broken >> or outdated cryptographic primitives. > [...] >> My preference would be to remove these algorithms completely >> (as in, delete the code). > > From the formal[istic] point of

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Fri, Nov 13, 2015 at 06:03:33PM +, Jonathan Larmour wrote: > I strongly agree with this. Not every OpenSSL user reads the openssl-dev > mailing list (nor -announce). I have been bitten by this in the past in > other FOSS projects which only solicited comments from mailing list readers. >

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Fri, Nov 13, 2015 at 03:20:58PM -0500, Daniel Kahn Gillmor wrote: > Perhaps it would be useful to gather data on this by looking at large > codebases (e.g. large linux distros like fedora or debian) to see > whether these particular functions of libcrypto are being used or linked > to. > > I

[openssl-dev] [openssl.org #2667] Add -starttls irc support to s_client

Done in master. Thanks. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Fri, Nov 13, 2015 at 05:24:01PM -0500, Daniel Kahn Gillmor wrote: > I'm less sympathetic in this case, since these functions have > well-defined semantics when a cipher has been removed (or simply isn't > present in the first place): they return NULL on error, and if code X > doesn't handle

Re: [openssl-dev] Openssl Memory Leak

Ø Can anyone let us know about the leaks and will SSL_FREE() will free the above memory. It should. Try it. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 11/13/2015 02:20 PM, Daniel Kahn Gillmor wrote: > On Fri 2015-11-13 14:48:41 -0500, Viktor Dukhovni wrote: >> The simplest approach is to remove ciphersuites from the SSL/TLS >> code (effectively making them unavailable even via ALL:COMPLEMENTOFALL), >> but leave the underlying crypto in the

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Fri 2015-11-13 14:48:41 -0500, Viktor Dukhovni wrote: > The simplest approach is to remove ciphersuites from the SSL/TLS > code (effectively making them unavailable even via ALL:COMPLEMENTOFALL), > but leave the underlying crypto in the library. > > Similarly, one might remove algorithms from

Re: [openssl-dev] Fwd: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode

Why are you running on such an old OS? How old are your Windows and Linux systems? Certainly not of the same generation. Solaris 8 & 9 are no longer supported, so you can't get security patches or anything. I highly recommend you try at least S10, or better, yet - S11. the /dev/[u]random on

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

> Actually deleting algorithms is *very* difficult. Yes. And we're doing the best we can by asking reasonably. Some people may get burnt. Oh well. It's open source, fork if you have to. ___ openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] OCSP integration into TLS handshake

> Has there been/will there be any development towards integrating OCSP > checking into the handshake the way CRL checking is, along the lines of > Alexander Komyagin's patch from 2012? There are no plans to do so at this time. ___ openssl-dev mailing

[openssl-dev] Fwd: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode

-- Forwarded message -- From: Tom Kacvinsky Date: Tue, Nov 10, 2015 at 5:51 PM Subject: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode To: openssl-us...@openssl.org I have an interesting case

Re: [openssl-dev] Fwd: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode

Hi Valerie, On Fri, Nov 13, 2015 at 4:06 PM, Valerie Fenwick wrote: > Why are you running on such an old OS? How old are your Windows and Linux > systems? Certainly not of the same generation. > > We still support S8 because some of our very important customers

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 11/13/2015 1:20 PM, Salz, Rich wrote: Actually deleting algorithms is *very* difficult. Yes. And we're doing the best we can by asking reasonably. Some people may get burnt. Oh well. It's open source, fork if you have to. With all of the "unacceptable" rules coming down from Gov'ts

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Fri, Nov 13, 2015 at 09:20:47PM +, Salz, Rich wrote: > > Actually deleting algorithms is *very* difficult. > > Yes. > > And we're doing the best we can by asking reasonably. > > Some people may get burnt. Oh well. It's open source, fork if you have to. What we primarily don't want to

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

> So I'm trying to help move forward, without creating artificial barriers. > Let's fix TLS (libssl) first, and we can tackle libcrypto in a later release. I disagree. I think the main driver will be OpenSSL 1.1-next, which will have TLS 1.3 support. So the purpose of this realease will be

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Fri 2015-11-13 16:16:56 -0500, Viktor Dukhovni wrote: > This is very difficult, because most applications use libcrypto > algorithms indirectly, via EVP_get_cipherbyname(), EVP_get_digestbyname() > and so on. So the code will link, but there'll be runtime errors > due to missing ciphers or

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Fri, Nov 13, 2015 at 10:02:02PM +, Salz, Rich wrote: > > So I'm trying to help move forward, without creating artificial barriers. > > Let's fix TLS (libssl) first, and we can tackle libcrypto in a later > > release. > > I disagree. > > I think the main driver will be OpenSSL 1.1-next,

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

FWIW, I agree with Viktor. ‎ ‎ Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Salz, Rich‎ Sent: Friday, November 13, 2015 17:02 To: openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Removing obsolete

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

I also can't see any point expunging old algorithms from the sources, making them not build by default should be enough. They are known to work and there's always the issue of 'legacy' support. With the number and variety of consumers OpenSSL has that's likely to be a problem for years to

[openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Hi all, We are considering removing from OpenSSL 1.1 known broken or outdated cryptographic primitives. As you may know the forks have already done this but I'd like to seek careful feedback for OpenSSL first to ensure we won't be breaking any major applications. These algorithms are currently