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

[Peter Waltenberg]

Why not offer another set of  get_XYZ_byname() which resticts the caller to
socially acceptable algorithms. Or allows the opposite, it really doesn't
matter but restricted being the newer API breaks less code by default.

Give it the same call syntax and it's simply an #ifdef in the OpenSSL
headers for anyone who wants to spend hours working out why their code
doesn't work any more.

i.e. EVP_get_digestbyname() becomes EVP_get_digestbyname_r(), and if anyone
actually wants only the restricted set from say a Linux distro. they can
#define  EVP_get_digestbyname(a) EVP_get_digestbyname_r(a)

At the crypto library level this is just maths and it really doesn't make
any sense to try and enforce policy at this point. I can understand the
maintenance issues, but C code really isn't a problem and dropping
algorithms from the sources here simply makes more work for other people
elsewhere.

Peter




From:	Viktor Dukhovni <openssl-users at dukhovni.org>
To:	openssl-dev at openssl.org
Date:	17/11/2015 10:02
Subject:	Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete
            crypto from OpenSSL 1.1 - seeking feedback
Sent by:	"openssl-dev" <openssl-dev-bounces at openssl.org>



On Mon, Nov 16, 2015 at 11:23:52PM +0000, Matt Caswell wrote:

> Disabling algorithms isn't the right answer IMO. I do like the idea of a
> "liblegacycrypto". That way people that only have need of current
> up-to-date crypto can stick with the main library. Others who need the
> older crypto can still get at it. Yes, that means we still have to
> maintain this code - but I don't see it as that big a burden.

What becomes a bit tricky is having an EVP interface that can find
the algorithms in liblegacrypto.  This I think means two different
builds of the crypto library, one that depends on liblegacycrypto
and provides its algorithms, and another than does not.

Systems might then ship with:

		 libcrypto-legacy.so		 - Just the legacy algorithms

		 libcrypto-compat.so		 - Libcrypto that supports the
above
		 libcrypto-secure.so		 - Libcrypto with just the strong
algos

		 libcrypto.so		 		 - Symlink to one of the
two above

Some applications might be linked directly to "-secure" or "-compat"
to make sure they get one or the other.  This is a bunch of work.

At this time, with the resources at our disposal, I think it makes
more sense to take a more gradual approach and just drop the assembly
support.


> Being the "swiss army knife" is no bad thing (even where that includes
> old crypto). We just have to find a way to separate the two concerns:
> current crypto (and only current crypto) for most (and probably most
> importantly for libssl users); broader crypto support for those that
> want it (which is why I like the liblegacycrypto idea because it enables
> us to do that).

I like the idea, but don't see a manageable implementation...

> Whether this is the right thing to do in the 1.1.0 timeframe is another
> consideration though. Viktor's arguments are quite convincing.

The timeline is a concern.  We're fairly far into the 1.1.0
development cycle (alphas and betas soon), and this is a major
change.  I think major changes like removing the ciphers or a whole
new optional library should wait for a better opportunity.

--
		 Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151117/12fc27f1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151117/12fc27f1/attachment.gif>