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

[Valerie Anne Fenwick]

Hi Jakob -

On 11/22/15 08:17 PM, Jakob Bohm wrote:

On 20/11/2015 23:26, Short, Todd wrote:

While I am all for simplicity, I also think that removing functionality is a 
“bad idea”.

To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longer receive fixes.
2. Remove any assembly implementations
3. Disable them by default.

I suggest following the 80/20 rule (sometimes the 95/5 rule):

Those “who care” (the minority) about the ciphers can re-enable them and 
rebuild the
library.
Those “who don’t care” (the majority) about the ciphers, should get the 
functionality
that most people care about, basically SSL/TLS connectivity.


You all seem to misunderstand the fundamental release engineering
issues involved.

1. Very shortly after you release OpenSSL 1.1.0, many
   distributions and pointy haired managers will blindly
   switch to the new version as the only version available.
This will not at all await the "end of support" for
   OpenSSL 1.0.x .  So breaking changes will cause harm much
   sooner than you claim.


As one of those pointy haired managers, I have to say that
this scenario is simply not possible with the ABI incompatibility
between OpenSSL 1.0.2 and OpenSSL 1.1.0 - applications will
have to be updated, too. (unless I'm completely misunderstanding
something). So, most likely we're looking at a universe where
both will coexist for awhile (that seems to match up with
OpenSSL's support plans as well).

Think of this like when OpenSSL went from 0.9.8 to 1.0.0.
Both co-existed for quite awhile.



2. Because of the need to easily keep up with routine security
   updates to OpenSSL, it is highly impractical to maintain
   locally reconfigured build scripts and patches, though some
   of us have no choice (and are still struggling with the
   massively huge and disorganized code reformatting in the
   middle of the 1.0.1 security update series).


I do not envy this work, but we're talking about a security
toolkit - it should not stay in the past. It's, quite simply,
dangerous to do so.



3. When distributions upgrade OpenSSL, many applications that
   have not been actively and deliberately ported to the new
   OpenSSL version will be blindly recompiled with the new
   versions, and if they break, random developers with no
   understanding of either the application, OpenSSL or even
   security will do ill-informed rushed patches to try to undo
   the breakage you caused.


Sadly, that happens when any toolkit updates.



4. OpenSSL is THE primary crypto library for the FOSS universe.
   You may be volunteers, but you are working on a massively
   important piece of software, not some random optional library.


Yes, but they are still allowed to change for the better.

GnuTLS did this as well, between their 2.x release and 3.x.
There is precendence. It is not pain free, but it is what
we all need to do to make a better and safter internet.

Bad choices made now will haunt us for another 10+ years.

Valerie



5. In these times of panic and marshal law, it is essential
   that the key resources for open source crypto remain
   unrestrained by the politics of any single country, such that
   the sudden outlawing of crypto in the current home of the
   maintainers does not prevent the project from being continued
   by a different team in a different country.  This makes it
   essential not to tie any legal or technical aspect to a single
   place, country, political alliance, company or person.  It is
   also critical to avoid any and all legal ties to the
   historically most problematic jurisdictions, such as the US.
So don't pay people through any US bank accounts, foundations
   or legal entities.  Don't keep any technical assets (such as
   repositories or mail archives) in one country.  Don't create
   legal documents that tie any license permissions to any
   specific country or organization.
These same considerations exclude any of the US based
   libraries and forks from being relevant outside that country.

6. All of this requires a lot more caution and a lot less
   arrogance from the people making decisions about changes
   in the OpenSSL library and project.


Enjoy

Jakob



Valerie
--
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic & Key Management Technologies, Manager
Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jakob Bohm]

Someone picked up an old dead thread, but I'll make some brief
responses.

On 11/02/2016 20:49, Valerie Anne Fenwick wrote:


Hi Jakob -

On 11/22/15 08:17 PM, Jakob Bohm wrote:

On 20/11/2015 23:26, Short, Todd wrote:
While I am all for simplicity, I also think that removing 
functionality is a “bad idea”.


To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longer receive 
fixes.

2. Remove any assembly implementations
3. Disable them by default.

I suggest following the 80/20 rule (sometimes the 95/5 rule):

Those “who care” (the minority) about the ciphers can re-enable them 
and rebuild the

library.
Those “who don’t care” (the majority) about the ciphers, should get 
the functionality

that most people care about, basically SSL/TLS connectivity.


You all seem to misunderstand the fundamental release engineering
issues involved.

1. Very shortly after you release OpenSSL 1.1.0, many
   distributions and pointy haired managers will blindly
   switch to the new version as the only version available.
This will not at all await the "end of support" for
   OpenSSL 1.0.x .  So breaking changes will cause harm much
   sooner than you claim.


As one of those pointy haired managers, I have to say that
this scenario is simply not possible with the ABI incompatibility
between OpenSSL 1.0.2 and OpenSSL 1.1.0 - applications will
have to be updated, too. (unless I'm completely misunderstanding
something). So, most likely we're looking at a universe where
both will coexist for awhile (that seems to match up with
OpenSSL's support plans as well).

This shows you are not pointy-haired enough to fit this
example.


Think of this like when OpenSSL went from 0.9.8 to 1.0.0.
Both co-existed for quite awhile.


However the differences between 0.9.8 and 1.0.0 were
much smaller than the upcoming differences between
1.0.x and 1.1.x .

They are basically removing lots of functionality
for very little gain.



2. Because of the need to easily keep up with routine security
   updates to OpenSSL, it is highly impractical to maintain
   locally reconfigured build scripts and patches, though some
   of us have no choice (and are still struggling with the
   massively huge and disorganized code reformatting in the
   middle of the 1.0.1 security update series).


I do not envy this work, but we're talking about a security
toolkit - it should not stay in the past. It's, quite simply,
dangerous to do so.


But it should not do things that leave past "customers"
unprotected because they can no longer use the current
but incompatible toolkit.  Because that in and of itself
is also very dangerous.



3. When distributions upgrade OpenSSL, many applications that
   have not been actively and deliberately ported to the new
   OpenSSL version will be blindly recompiled with the new
   versions, and if they break, random developers with no
   understanding of either the application, OpenSSL or even
   security will do ill-informed rushed patches to try to undo
   the breakage you caused.


Sadly, that happens when any toolkit updates.

Yes, but some updates are more likely to cause such
harm than others.  Thisis the whole reason the entire
computer industryis so keen on backwards compatibility.





4. OpenSSL is THE primary crypto library for the FOSS universe.
   You may be volunteers, but you are working on a massively
   important piece of software, not some random optional library.


Yes, but they are still allowed to change for the better.

GnuTLS did this as well, between their 2.x release and 3.x.
There is precendence. It is not pain free, but it is what
we all need to do to make a better and safter internet.

Bad choices made now will haunt us for another 10+ years.


I was arguing that they *are* making bad choices now.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Emilia Käsper]

To close off this thread: OpenSSL will not be making any changes.

The team voted on moving a set of algorithms to maintenance mode, and
removing the corresponding assembly implementations from libcrypto, but the
vote did not pass.

Emilia

On Fri, Nov 27, 2015 at 10:19 AM, Tim Hudson  wrote:

> On 24/11/2015 4:09 AM, Jakob Bohm wrote:
> > But they care very much if Cisco AnyConnect (or any other
> > OpenSSL using program they may need) stops working or
> > becomes insecure because the OpenSSL team is breaking
> > stuff just because it is not needed in their own handful
> > of example uses.
>
> The OpenSSL team (like most open source projects) is made up of
> individuals that have widely varying backgrounds and experiences - and
> those experiences lead to different view points on a lot of fairly
> fundamental topics. This is a good thing - as frankly a project that
> doesn't have a mix of view points tends to not last.
>
> Between the OpenSSL team members our experiences cover a very wide range
> of uses and many of us have been working on the code base for 17+ years
> and have worked in areas that are certainly well outside the average or
> common uses. However despite that experience we certainly don't think
> that we know what all the users of the code base are doing.
>
> Increasingly we are making sure any debate on project direction where
> there are mixed view points within the team brings in the openssl-users
> and/or openssl-dev lists so we get to have input from a wider set of
> people - who may or may not represent uses that we don't already know
> about.
>
> All the view points being expressed are valid and there are good reasons
> why we could as a team head in either direction (dropping out code or
> keeping everything or anything along that spectrum) and what is
> important is to listen to the input and see the varying points of view
> and add that into the decision making process.
>
> So if you have a use of OpenSSL that you think the team might not know
> about then please express that clearly on the list. View points on what
> has been proposed are also welcome - but I think you'll find increasing
> the awareness of the team about what our users are doing is the more
> important of the two objectives in seeking feedback.
>
> Tim.
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Tim Hudson]

On 24/11/2015 4:09 AM, Jakob Bohm wrote:
> But they care very much if Cisco AnyConnect (or any other
> OpenSSL using program they may need) stops working or
> becomes insecure because the OpenSSL team is breaking
> stuff just because it is not needed in their own handful
> of example uses.

The OpenSSL team (like most open source projects) is made up of
individuals that have widely varying backgrounds and experiences - and
those experiences lead to different view points on a lot of fairly
fundamental topics. This is a good thing - as frankly a project that
doesn't have a mix of view points tends to not last.

Between the OpenSSL team members our experiences cover a very wide range
of uses and many of us have been working on the code base for 17+ years
and have worked in areas that are certainly well outside the average or
common uses. However despite that experience we certainly don't think
that we know what all the users of the code base are doing.

Increasingly we are making sure any debate on project direction where
there are mixed view points within the team brings in the openssl-users
and/or openssl-dev lists so we get to have input from a wider set of
people - who may or may not represent uses that we don't already know about.

All the view points being expressed are valid and there are good reasons
why we could as a team head in either direction (dropping out code or
keeping everything or anything along that spectrum) and what is
important is to listen to the input and see the varying points of view
and add that into the decision making process.

So if you have a use of OpenSSL that you think the team might not know
about then please express that clearly on the list. View points on what
has been proposed are also welcome - but I think you'll find increasing
the awareness of the team about what our users are doing is the more
important of the two objectives in seeking feedback.

Tim.

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jakob Bohm]

But they care very much if Cisco AnyConnect (or any other
OpenSSL using program they may need) stops working or
becomes insecure because the OpenSSL team is breaking
stuff just because it is not needed in their own handful
of example uses.

And while ordinary people may not know or care, they will
be deeply affected by the increase in undiscovered
vulnerabilities if the white hat research community stops
supporting OpenSSL by researching its code more deeply
than any other crypto library.  It is already bad enough
that no code review made before the giant reformat
provides much insight into the current code, because it
is virtually impossible to independently review the mega-
patch that mixed reformatting and actual code changes.

Fundamentally, appealing to what "ordinary users" care
about in the way you just did is an appeal to stupidity.
Ordinary users don't know how the innards of OpenSSL
affect their lives, as was so clearly seen when the first
a lot of them heard about OpenSSL was Heartbleed and the
resulting "gut reactions" was to say that OpenSSL must be
a fundamentally bad thing (spurred along by mass media
describing Heartbleed as a "virus").  Or think about all
the people confusing the Android stagefreight multimedia
library with the recently discovered vulnerabilities in
that same library.

Note that I am not saying ordinary users are stupid,
they just don't know a lot of things about our
profession, as they don't know much about each others
professions either.  This is the fundamental principle
of specialization ever since the concept of professions
was invented millennia ago.

On 23/11/2015 17:05, Short, Todd wrote:
I suspect that most “users” of OpenSSL are doing it indirectly through 
other applications that use TLS (or crypto) functionality. Example: 
the Cisco AnyConnect client is reportedly one of the most installed 
pieces of software regardless of platform; it uses OpenSSL for TLS.


Taking those indirect users into account, they don’t care about the 
research or advanced uses of OpenSSL; they just want to connect 
securely to their corporate network.


On Nov 20, 2015, at 9:09 PM, Peter Waltenberg > wrote:


Quite reasonable except.

I'm not sure you have majority and minority the right way around. My 
guess would be that the majority of OpenSSL users are libcrypto. 
consumers rather than SSL/TLS consumers.


A point several of us have been trying to get through for some time.

-"openssl-dev" > wrote: -
To: "openssl-...@openssl.org " 
>

From: "Short, Todd"
Sent by: "openssl-dev"
Date: 11/21/2015 08:28AM
Cc: "openssl-users@openssl.org " 
>
Subject: Re: [openssl-dev] [openssl-users] Removing obsolete crypto 
from OpenSSL 1.1 - seeking feedback


While I am all for simplicity, I also think that removing 
functionality is a “bad idea”.


To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longer receive 
fixes.

2. Remove any assembly implementations
3. Disable them by default.

I suggest following the 80/20 rule (sometimes the 95/5 rule):

Those “who care” (the minority) about the ciphers can re-enable them 
and rebuild the library.
Those “who don’t care” (the majority) about the ciphers, should get 
the functionality that most people care about, basically SSL/TLS 
connectivity.


On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL 
> wrote:


On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
 on behalf of 
bka...@akamai.com > wrote:



On 11/18/2015 07:05 AM, Hubert Kario wrote:

So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
support
both relatively modern TLS with user certificates, preferably the
newest
cryptosystems and hashes as well as the oldest ones that were
standardised and used.

That means that old algorithms MUST remain in OpenSSL as supported
functionality. It may require linking to a specific library to 
make the

EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
from it completely, definitely not before at least 50 years _after_
they
became obsolete and broken.


There seems to be a logical leap between these two paragraphs.  Why is
it necessary that OpenSSL be the only cryptographic library used by
CAdES-A/etc. implementations?


Because it used to be the only real game in town, and *people learned to
rely upon it*.


Is it in fact even necessary that only a
single version of a single cryptographic library be used for such
software?


No, of course not. But after letting people depend on this “single

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

[Jakob Bohm]

On 23/11/2015 21:36, Karl Vogel wrote:

On Mon, 23 Nov 2015 05:17:33 +0100,
Jakob Bohm  said:

J> You all seem to misunderstand the fundamental release engineering issues
J> involved.

Actually, we don't.

J> 1.  Very shortly after you release OpenSSL 1.1.0, many distributions
J> and pointy haired managers will blindly switch to the new version as
J> the only version available.

I've installed new OS releases and distributions for over 20 years,
and I don't ever remember having that particular problem with OpenSSL.
On the contrary, our vendors are very conservative and I frequently end
up replacing their version.

I am saying that some distributions will switch to the
branch currently planned to be named 1.1.0 long before
support for 1.0.2 ends.  And those distributions will
then run try to routinely recompile all openSSL-
referencing software packages against the new OpenSSL
(along with the new libc, the new kernel, the new zlib
etc. etc.) and dispatch bug fixers to fix the resulting
compile errors with no special considerations for crypto
expertise.  (More on this later in this e-mail).

By the time such an 1.1.0-based OS release is shipped,
that 1.1.0 code will probably be a few letter-patches
behind the latest upstream, at least in name (some
distributions backport the changes but don't change
the letter in the version number, naming it instead
something like 1.1.0d+ourpatch7).


J> This will not at all await the "end of support" for OpenSSL 1.0.x.
J> So breaking changes will cause harm much sooner than you claim.

If we'd waited for the lowest common denominators (aka PHBs) to start
doing their jobs right, we'd still be using DOS 5 and looking forward
to that new-fangled windows thing.

I am talking about the breakage caused by PHBs that
insist on using the highest OpenSSL version listed
as "fixed" in the most recent CVE entry, even when
a letter patch to an earlier branch is equally safe.
 This combined with code that has not (for any
reason) been ported from 1.0.2 to 1.1.0 by its
primary authors, perhaps because they need some
featureremoved in 1.1.0.



J> 2.  Because of the need to easily keep up with routine security updates to
J> OpenSSL, it is highly impractical to maintain locally reconfigured build
J> scripts and patches, though some of us have no choice (and are still
J> struggling with the massively huge and disorganized code reformatting
J> in the middle of the 1.0.1 security update series).

Do you mean reformatting or refactoring?  Would the API itself undergo
significant changes just because some obsolete crypto was removed?
Not being snarky, honestly curious.

I understand that people do more complex things than simply install
the openssl binary and associated libraries, but I keep CentOS-6,
Solaris-10, and Solaris-11 boxes patched with the same set of scripts.
Aside from the (rare) portability tweak, I don't touch them.

I am talking about applying usage/application specific
patches to the OpenSSL source tree and the fact that the
reformatting requires all such patches to be reimplemented
one by one to apply to the reformatted code.



J> 3.  When distributions upgrade OpenSSL, many applications that have not
J> been actively and deliberately ported to the new OpenSSL version will
J> be blindly recompiled with the new versions, and if they break, random
J> developers with no understanding of either the application, OpenSSL or
J> even security will do ill-informed rushed patches to try to undo the
J> breakage you caused.

If you blindly recompile *anything* just because a version number
changed, any resulting breakage is YOUR problem.  People who understand
release engineering issues know better; they also know how to read a
changelog and tell their customers when (and why) to expect something
different.

When OpenSSL-1.1.whatever comes out, I'll do the same thing I've
always done -- wait a bit for the initial reactions, install it on my
workstation first to make sure it doesn't barf, and then move it out
to the production boxes.

You are talking about internal corporate careful roll-out
procedures, I am talking about OS distributions such as
*BSD and *Linux doing their usual preparations for a new
OS release by importing new versions of upstream sources,
recompiling and fixing obvious bugs until it "looks OK",
while failing to detect subtle breakage or new security
issues.

A classic example is how Debian (a few years back) did a
patch to the OpenSSL RNG, creating an RNG that worked but
had way too little entropy.  It is that kind of crypto-
unskilled mistakes that I fear will proliferate in the
fall-out from the breaking changes in OpenSSL 1.1.0.



J> 4.  OpenSSL is THE primary crypto library for the FOSS universe.
J> You may be volunteers, but you are working on a massively important
J> piece of software, not some random optional library.

Most of them *are* 

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

[Short, Todd]

I suspect that most “users” of OpenSSL are doing it indirectly through other 
applications that use TLS (or crypto) functionality. Example: the Cisco 
AnyConnect client is reportedly one of the most installed pieces of software 
regardless of platform; it uses OpenSSL for TLS.

Taking those indirect users into account, they don’t care about the research or 
advanced uses of OpenSSL; they just want to connect securely to their corporate 
network.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Nov 20, 2015, at 9:09 PM, Peter Waltenberg 
> wrote:

Quite reasonable except.

I'm not sure you have majority and minority the right way around. My guess 
would be that the majority of OpenSSL users are libcrypto. consumers rather 
than SSL/TLS consumers.

A point several of us have been trying to get through for some time.

Peter

-"openssl-dev" 
> 
wrote: -
To: "openssl-...@openssl.org" 
>
From: "Short, Todd"
Sent by: "openssl-dev"
Date: 11/21/2015 08:28AM
Cc: "openssl-users@openssl.org" 
>
Subject: Re: [openssl-dev] [openssl-users] Removing obsolete crypto from 
OpenSSL 1.1 - seeking feedback

While I am all for simplicity, I also think that removing functionality is a 
“bad idea”.

To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longer receive fixes.
2. Remove any assembly implementations
3. Disable them by default.

I suggest following the 80/20 rule (sometimes the 95/5 rule):

Those “who care” (the minority) about the ciphers can re-enable them and 
rebuild the library.
Those “who don’t care” (the majority) about the ciphers, should get the 
functionality that most people care about, basically SSL/TLS connectivity.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL 
> wrote:

On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
 on 
behalf of bka...@akamai.com> wrote:

On 11/18/2015 07:05 AM, Hubert Kario wrote:
So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
support
both relatively modern TLS with user certificates, preferably the
newest
cryptosystems and hashes as well as the oldest ones that were
standardised and used.

That means that old algorithms MUST remain in OpenSSL as supported
functionality. It may require linking to a specific library to make the
EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
from it completely, definitely not before at least 50 years _after_
they
became obsolete and broken.

There seems to be a logical leap between these two paragraphs.  Why is
it necessary that OpenSSL be the only cryptographic library used by
CAdES-A/etc. implementations?

Because it used to be the only real game in town, and *people learned to
rely upon it*.

Is it in fact even necessary that only a
single version of a single cryptographic library be used for such
software?

No, of course not. But after letting people depend on this “single
cryptographic library” for many years, telling them “too bad” isn’t very
nice.

While OpenSSL may try to be a general-purpose crypto library,
when a software has stringent or unusual crypto requirements, it seems
reasonable that such a software may need to involve unusual
implementations.

The requirements did not change. What changed was the maintainers
expressing their desire to stop supporting some of them.

I do not believe that OpenSSL has promised anywhere that it will support
this sort of use case.

Implicitly, by providing that kind of service for so long. And explicitly,
as pointed out by Hubert:

From the main web page of project:

The OpenSSL Project is a collaborative effort to develop a robust,
commercial-grade, *full-featured*, and Open Source toolkit
implementing the Transport Layer Security (TLS) and Secure Sockets
Layer (SSL) protocols as well as a full-strength *general purpose*
*cryptography library* .

___
openssl-dev mailing list
To unsubscribe: 

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

[Karl Vogel]

>> On Mon, 23 Nov 2015 05:17:33 +0100,
>> Jakob Bohm  said:

J> You all seem to misunderstand the fundamental release engineering issues
J> involved.

   Actually, we don't.

J> 1.  Very shortly after you release OpenSSL 1.1.0, many distributions
J> and pointy haired managers will blindly switch to the new version as
J> the only version available.

   I've installed new OS releases and distributions for over 20 years,
   and I don't ever remember having that particular problem with OpenSSL.
   On the contrary, our vendors are very conservative and I frequently end
   up replacing their version.

J> This will not at all await the "end of support" for OpenSSL 1.0.x.
J> So breaking changes will cause harm much sooner than you claim.

   If we'd waited for the lowest common denominators (aka PHBs) to start
   doing their jobs right, we'd still be using DOS 5 and looking forward
   to that new-fangled windows thing.

J> 2.  Because of the need to easily keep up with routine security updates to
J> OpenSSL, it is highly impractical to maintain locally reconfigured build
J> scripts and patches, though some of us have no choice (and are still
J> struggling with the massively huge and disorganized code reformatting
J> in the middle of the 1.0.1 security update series).

   Do you mean reformatting or refactoring?  Would the API itself undergo
   significant changes just because some obsolete crypto was removed?
   Not being snarky, honestly curious.

   I understand that people do more complex things than simply install
   the openssl binary and associated libraries, but I keep CentOS-6,
   Solaris-10, and Solaris-11 boxes patched with the same set of scripts.
   Aside from the (rare) portability tweak, I don't touch them.

J> 3.  When distributions upgrade OpenSSL, many applications that have not
J> been actively and deliberately ported to the new OpenSSL version will
J> be blindly recompiled with the new versions, and if they break, random
J> developers with no understanding of either the application, OpenSSL or
J> even security will do ill-informed rushed patches to try to undo the
J> breakage you caused.

   If you blindly recompile *anything* just because a version number
   changed, any resulting breakage is YOUR problem.  People who understand
   release engineering issues know better; they also know how to read a
   changelog and tell their customers when (and why) to expect something
   different.

   When OpenSSL-1.1.whatever comes out, I'll do the same thing I've
   always done -- wait a bit for the initial reactions, install it on my
   workstation first to make sure it doesn't barf, and then move it out
   to the production boxes.

J> 4.  OpenSSL is THE primary crypto library for the FOSS universe.
J> You may be volunteers, but you are working on a massively important
J> piece of software, not some random optional library.

   Most of them *are* volunteers, and they seem to be taking their
   work more seriously than the people disparaging them, not to mention
   the folks who are supposed to get this right (i.e., U.S. Office of
   Personnel Management).

J> 5.  In these times of panic and marshal law, it is essential that the
J> key resources for open source crypto remain unrestrained by the politics
J> of any single country...

   What does this have to do with removing obsolete crypto from a library?

J> 6.  All of this requires a lot more caution and a lot less arrogance
J> from the people making decisions about changes in the OpenSSL library
J> and project.

   "Arrogance" would be slamming the changes in without discussion or
   notification and saying "like it or lump it".  Haven't seen that.

-- 
Karl Vogel  I don't speak for the USAF or my company

eBay scammer steals identity of Special Agent investigating him
--"Register" headline, 18 Nov 2015

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jakob Bohm]

On 20/11/2015 23:26, Short, Todd wrote:
While I am all for simplicity, I also think that removing 
functionality is a “bad idea”.


To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longer receive 
fixes.

2. Remove any assembly implementations
3. Disable them by default.

I suggest following the 80/20 rule (sometimes the 95/5 rule):

Those “who care” (the minority) about the ciphers can re-enable them 
and rebuild the library.
Those “who don’t care” (the majority) about the ciphers, should get 
the functionality that most people care about, basically SSL/TLS 
connectivity.



You all seem to misunderstand the fundamental release engineering
issues involved.

1. Very shortly after you release OpenSSL 1.1.0, many
  distributions and pointy haired managers will blindly
  switch to the new version as the only version available.
   This will not at all await the "end of support" for
  OpenSSL 1.0.x .  So breaking changes will cause harm much
  sooner than you claim.

2. Because of the need to easily keep up with routine security
  updates to OpenSSL, it is highly impractical to maintain
  locally reconfigured build scripts and patches, though some
  of us have no choice (and are still struggling with the
  massively huge and disorganized code reformatting in the
  middle of the 1.0.1 security update series).

3. When distributions upgrade OpenSSL, many applications that
  have not been actively and deliberately ported to the new
  OpenSSL version will be blindly recompiled with the new
  versions, and if they break, random developers with no
  understanding of either the application, OpenSSL or even
  security will do ill-informed rushed patches to try to undo
  the breakage you caused.

4. OpenSSL is THE primary crypto library for the FOSS universe.
  You may be volunteers, but you are working on a massively
  important piece of software, not some random optional library.

5. In these times of panic and marshal law, it is essential
  that the key resources for open source crypto remain
  unrestrained by the politics of any single country, such that
  the sudden outlawing of crypto in the current home of the
  maintainers does not prevent the project from being continued
  by a different team in a different country.  This makes it
  essential not to tie any legal or technical aspect to a single
  place, country, political alliance, company or person.  It is
  also critical to avoid any and all legal ties to the
  historically most problematic jurisdictions, such as the US.
   So don't pay people through any US bank accounts, foundations
  or legal entities.  Don't keep any technical assets (such as
  repositories or mail archives) in one country.  Don't create
  legal documents that tie any license permissions to any
  specific country or organization.
   These same considerations exclude any of the US based
  libraries and forks from being relevant outside that country.

6. All of this requires a lot more caution and a lot less
  arrogance from the people making decisions about changes
  in the OpenSSL library and project.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Short, Todd]

While I am all for simplicity, I also think that removing functionality is a 
“bad idea”.

To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longer receive fixes.
2. Remove any assembly implementations
3. Disable them by default.

I suggest following the 80/20 rule (sometimes the 95/5 rule):

Those “who care” (the minority) about the ciphers can re-enable them and 
rebuild the library.
Those “who don’t care” (the majority) about the ciphers, should get the 
functionality that most people care about, basically SSL/TLS connectivity.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL 
> wrote:

On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
 on 
behalf of bka...@akamai.com> wrote:

On 11/18/2015 07:05 AM, Hubert Kario wrote:
So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
support
both relatively modern TLS with user certificates, preferably the
newest
cryptosystems and hashes as well as the oldest ones that were
standardised and used.

That means that old algorithms MUST remain in OpenSSL as supported
functionality. It may require linking to a specific library to make the
EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
from it completely, definitely not before at least 50 years _after_
they
became obsolete and broken.

There seems to be a logical leap between these two paragraphs.  Why is
it necessary that OpenSSL be the only cryptographic library used by
CAdES-A/etc. implementations?

Because it used to be the only real game in town, and *people learned to
rely upon it*.

Is it in fact even necessary that only a
single version of a single cryptographic library be used for such
software?

No, of course not. But after letting people depend on this “single
cryptographic library” for many years, telling them “too bad” isn’t very
nice.

While OpenSSL may try to be a general-purpose crypto library,
when a software has stringent or unusual crypto requirements, it seems
reasonable that such a software may need to involve unusual
implementations.

The requirements did not change. What changed was the maintainers
expressing their desire to stop supporting some of them.

I do not believe that OpenSSL has promised anywhere that it will support
this sort of use case.

Implicitly, by providing that kind of service for so long. And explicitly,
as pointed out by Hubert:

From the main web page of project:

The OpenSSL Project is a collaborative effort to develop a robust,
commercial-grade, *full-featured*, and Open Source toolkit
implementing the Transport Layer Security (TLS) and Secure Sockets
Layer (SSL) protocols as well as a full-strength *general purpose*
*cryptography library* .

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

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Viktor Dukhovni]

On Thu, Nov 19, 2015 at 11:01:26AM +0100, Tomas Mraz wrote:

> 3. remove the respective EVP_add_cipher(), EVP_add_digest(),... from the
> OpenSSL_add* functions so the users have to explicitly add these to use
> them automatically.

This does not work.  Often the code that calls OpenSSL_add_all_algorithms()
is not the code that knows which algorithms will be used (think
scripting languages).  Having a single call that adds all the
algorithms or just the non-legacy algorithms can work, hance Matt's
suggestion of a #define that selects between two implementations,
and requires linking with the legacy library.

-- 
Viktor.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Benjamin Kaduk]

On 11/18/2015 07:05 AM, Hubert Kario wrote:
> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support 
> both relatively modern TLS with user certificates, preferably the newest 
> cryptosystems and hashes as well as the oldest ones that were 
> standardised and used.
>
> That means that old algorithms MUST remain in OpenSSL as supported 
> functionality. It may require linking to a specific library to make the 
> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed 
> from it completely, definitely not before at least 50 years _after_ they 
> became obsolete and broken.
>

There seems to be a logical leap between these two paragraphs.  Why is
it necessary that OpenSSL be the only cryptographic library used by
CAdES-A/etc. implementations?  Is it in fact even necessary that only a
single version of a single cryptographic library be used for such
software?  While OpenSSL may try to be a general-purpose crypto library,
when a software has stringent or unusual crypto requirements, it seems
reasonable that such a software may need to involve unusual implementations.

I do not believe that OpenSSL has promised anywhere that it will support
this sort of use case.

-Ben
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Richard Moore]

On 18 November 2015 at 17:57, Hubert Kario  wrote:

> On Wednesday 18 November 2015 11:12:59 Benjamin Kaduk wrote:
> > On 11/18/2015 07:05 AM, Hubert Kario wrote:
> > > So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
> > > support both relatively modern TLS with user certificates,
> > > preferably the newest cryptosystems and hashes as well as the
> > > oldest ones that were standardised and used.
> > >
> > > That means that old algorithms MUST remain in OpenSSL as supported
> > > functionality. It may require linking to a specific library to make
> > > the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be
> > > removed from it completely, definitely not before at least 50 years
> > > _after_ they became obsolete and broken.

>
> > There seems to be a logical leap between these two paragraphs.  Why is
> > it necessary that OpenSSL be the only cryptographic library used by
> > CAdES-A/etc. implementations?  Is it in fact even necessary that only
> > a single version of a single cryptographic library be used for such
> > software?
> >
> > While OpenSSL may try to be a general-purpose crypto
> > library, when a software has stringent or unusual crypto
> > requirements, it seems reasonable that such a software may need to
> > involve unusual implementations.
> >
> > I do not believe that OpenSSL has promised anywhere that it will
> > support this sort of use case.
>
> From the main web page of project:
>
>   The OpenSSL Project is a collaborative effort to develop a robust,
>   commercial-grade, *full-featured*, and Open Source toolkit
>   implementing the Transport Layer Security (TLS) and Secure Sockets
>   Layer (SSL) protocols as well as a full-strength *general purpose*
>   *cryptography library* .
>
> (emphasis mine)
>
>
​I think now is the time for those who are going to provide the 50 year
support to step up to the plate then. Saying "oh but we can get it for free
for the next 50 years" doesn't work.

I think your emphasis here is exactly right though, the aim is *general
purpose*​ you are most definitely describing an extremely specialised
purpose that has unusual requirements.

​Cheers

Rich.​
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Benjamin Kaduk]

On 11/18/2015 12:52 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
>  wrote:
>
>> On 11/18/2015 07:05 AM, Hubert Kario wrote:
>>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
>>> support 
>>> both relatively modern TLS with user certificates, preferably the
>>> newest 
>>> cryptosystems and hashes as well as the oldest ones that were
>>> standardised and used.
>>>
>>> That means that old algorithms MUST remain in OpenSSL as supported
>>> functionality. It may require linking to a specific library to make the
>>> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
>>> from it completely, definitely not before at least 50 years _after_
>>> they 
>>> became obsolete and broken.
>> There seems to be a logical leap between these two paragraphs.  Why is
>> it necessary that OpenSSL be the only cryptographic library used by
>> CAdES-A/etc. implementations?
> Because it used to be the only real game in town, and *people learned to
> rely upon it*.
>
>> Is it in fact even necessary that only a
>> single version of a single cryptographic library be used for such
>> software? 
> No, of course not. But after letting people depend on this “single
> cryptographic library” for many years, telling them “too bad” isn’t very
> nice.

I guess I'm just having a hard time wrapping my head around why, upon
hearing that the volunteer-run project is giving years' advance notice
that certain features will be removed, the response is insistence that
everything must remain supported forever, instead of using the advance
notice to investigate alternatives.  Volunteers should be allowed to
ease up when they need to, after all.


>> While OpenSSL may try to be a general-purpose crypto library,
>> when a software has stringent or unusual crypto requirements, it seems
>> reasonable that such a software may need to involve unusual
>> implementations.
> The requirements did not change. What changed was the maintainers
> expressing their desire to stop supporting some of them.

Surely the requirements for a general-purpose crypto library must change
over time!  In 1995, such a library did not (could not!) include AES
support, whereas even by 2005 it would have been pretty essential to
have.  As the state of the art advances, the library must adapt to
match, and removing components that are no longer widespread or
essential seems a natural part of that adaptation.  The requirements are
not an append-only list.

>> I do not believe that OpenSSL has promised anywhere that it will support
>> this sort of use case.
> Implicitly, by providing that kind of service for so long. And explicitly,
> as pointed out by Hubert:

Well, I see this thread as notice that the implicit support should no
longer be taken for granted, with plenty of advance notice.

>   From the main web page of project:
>
>   The OpenSSL Project is a collaborative effort to develop a 
> robust,
>   commercial-grade, *full-featured*, and Open Source toolkit
>   implementing the Transport Layer Security (TLS) and Secure 
> Sockets
>   Layer (SSL) protocols as well as a full-strength *general 
> purpose*
>   *cryptography library* .
>
>


That text reads as if it was originally drafted 10+ years ago, when
"full-featured" meant "we support both encryption and decryption" as
well as "we provide both export-grade and strong crypto".  I'm sure we
could put some updated text in if that would help clarify what exactly
the goals of the project are.  And, as Richard notes, general-purpose
does not mean "usable for every possible specific use case under the
sun", it means "usable for most common things", which to me does not
include CAdES-A and the like.

-Ben
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Viktor Dukhovni]

On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote:

> > No, of course not. But after letting people depend on this “single
> > cryptographic library” for many years, telling them “too bad” isn’t very
> > nice.
> 
> I guess I'm just having a hard time wrapping my head around why, upon
> hearing that the volunteer-run project is giving years' advance notice
> that certain features will be removed, the response is insistence that
> everything must remain supported forever, instead of using the advance
> notice to investigate alternatives.  Volunteers should be allowed to
> ease up when they need to, after all.

Culture-clash.  Security culture says everything remotely weak must
go, but release-engineering culture emphasizes compatibilty.  The
crypto library is more of a systems component, not a security
component.  The SSL library is more of a security component than
a systems component, and has algorithm negotiation.

For example, Linux never breaks user-land, you can do all kinds of
things inside the kernel, but user-land software (for a fixed libc)
that worked before is going to continue working on new kernels.
Doing that since 1991 or so.

SunOS libc implemented multiple ABIs to ensure application
compatibility.  Many other operating systems do likewise.

For better or worse, libcrypto is part of that world.  It is a
building block library for whatever applications the users want to
use it for.  It is not a security technology in its own right.


> Surely the requirements for a general-purpose crypto library must change
> over time!  

Yes, by accretion.  And "general-purpose" does not mean "the expected
use-cases", it really means "general".

> have.  As the state of the art advances, the library must adapt to
> match, and removing components that are no longer widespread or
> essential seems a natural part of that adaptation.  The requirements are
> not an append-only list.

Except that they are, just as Linux and libc provide an append-only
set of interfaces.

> > The OpenSSL Project is a collaborative effort to develop a 
> > robust,
> > commercial-grade, *full-featured*, and Open Source toolkit
> > implementing the Transport Layer Security (TLS) and Secure 
> > Sockets
> > Layer (SSL) protocols as well as a full-strength *general 
> > purpose*
> > *cryptography library* .
> 
> 
> That text reads as if it was originally drafted 10+ years ago, when
> "full-featured" meant "we support both encryption and decryption" as
> well as "we provide both export-grade and strong crypto".  I'm sure we
> could put some updated text in if that would help clarify what exactly
> the goals of the project are.  And, as Richard notes, general-purpose
> does not mean "usable for every possible specific use case under the
> sun", it means "usable for most common things", which to me does not
> include CAdES-A and the like.

No, general purpose really means whatever purpose the user has in
mind.  The "most common things" is not "general purpose".

-- 
Viktor.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Emilia Käsper]

On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton  wrote:

> > MD2 - (The argument that someone somewhere may want to keep verifying old
> > MD2 signatures on self-signed certs doesn't seem like a compelling enough
> > reason to me. It's been disabled by default since OpenSSL 1.0.0.)
> > ...
> Apple still provides two Verisign certificates using
> md2WithRSAEncryption. Confer,
> https://support.apple.com/en-us/HT203065.
>

Setting aside the debate of whether verifying trust store signatures is
useful, whether verifying MD2 signatures has any practical security value,
or whether OpenSSL + iOS is a meaningful combination:

This is iOS7. The current release is iOS9 (trust store here:
https://support.apple.com/en-us/HT205205, MD2 certs are gone).

Arguments like this illustrate a fundamental misunderstanding in this
thread. We are not pulling the carpet from any users TODAY. We are asking
whether there are applications that will need this code 2..3..5 years down
the line. When I referred to the fact that users of 1.1 will have to
recompile, I didn't mean that errors would be revealed by recompilation. I
meant that you would have to be an actively maintained application or
library, and be doing a new release, and be stuck using an old algorithm,
to even be impacted by this change.




> Jeff
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Mark H. Wood]

With regard to the idea that one can simply make older algorithms
Somebody Else's Problem:  is it *known* that another viable,
well-maintained product sees this as one of its roles?  That would be
more reassuring, I think, than just hoping that some unknown group
will step into the gap.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: Digital signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

>> We can significantly reduce that liability by removing any assembler
>> optimisations. Also just because something is available doesn't mean it
>> has to be "default". We can have good defaults whilst keeping old crypto.
>
> Zooko Wilcox O'Hearn recently gave a talk at a software assurance
> conference on the downsides of assembly language routines in software.
> I'm trying to locate it now. All in all, this is probably a move in
> the right direction, especially for non-contemporary algorithms, to
> help sunset them and maintain them with minimal effort.

My bad... I just talked to Zooko about the presentation. He was not
able to attend the conference, so there is no presentation to link to.

However, here is the write-up in the Tahoe-LAFS Bug Reporter:
https://tahoe-lafs.org/trac/pycryptopp/ticket/85#comment:20. It makes
the case for No-ASM. (And was the corpus of knowledge for the
presentation).

Jeff
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

On Tue, Nov 17, 2015 at 7:21 AM, Emilia Käsper  wrote:
>
>
> On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton  wrote:
>>
>> > MD2 - (The argument that someone somewhere may want to keep verifying
>> > old
>> > MD2 signatures on self-signed certs doesn't seem like a compelling
>> > enough
>> > reason to me. It's been disabled by default since OpenSSL 1.0.0.)
>> > ...
>> Apple still provides two Verisign certificates using
>> md2WithRSAEncryption. Confer,
>> https://support.apple.com/en-us/HT203065.
>
>
> Setting aside the debate of whether verifying trust store signatures is
> useful, whether verifying MD2 signatures has any practical security value,
> or whether OpenSSL + iOS is a meaningful combination:
>
> This is iOS7. The current release is iOS9 (trust store here:
> https://support.apple.com/en-us/HT205205, MD2 certs are gone).
>
> Arguments like this illustrate a fundamental misunderstanding in this
> thread. We are not pulling the carpet from any users TODAY. We are asking
> whether there are applications that will need this code 2..3..5 years down
> the line.

My bad... I was not arguing either way. I was just presenting facts.

Also, if OpenSSL requires iOS 9 or above, then its setting policy for users.

I still have iOS 6, 7 and 8 devices because (1) some of my hardware is
old and abandoned by Apple (they are trying to set policy, too, in an
effort to boost sales). (2) I dislike the "cartoony" interface of iOS
7 and above. (3) I have down level OS X operating systems (due to
operational requirements and personal taste), and they can't talk to
iOS 8 or 9 devices.

Jeff
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Viktor Dukhovni]

On Tue, Nov 17, 2015 at 11:24:17AM -0800, Jay Foster wrote:

> I can understand the desire to remove the assembly code options,

*ONLY* for deprecated legacy algorithms, as an alternative to the
proposal to remove the algorithm entirely.

> I recently updated a product I support (50MHz single core) to OpenSSL
> 1.0.2d, and found that the assembly optimizations gave me a 40% increase in
> performance over the C version (AES decryption).  40% was very significant
> in my case.  Seems like the low power IoT devices might be similarly CPU
> challenged in the future.

The AES assembly packs are staying either way.  Enjoy.

-- 
Viktor.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jay Foster]

On 11/17/2015 9:56 AM, Jeffrey Walton wrote:

We can significantly reduce that liability by removing any assembler
optimisations. Also just because something is available doesn't mean it
has to be "default". We can have good defaults whilst keeping old crypto.

Zooko Wilcox O'Hearn recently gave a talk at a software assurance
conference on the downsides of assembly language routines in software.
I'm trying to locate it now. All in all, this is probably a move in
the right direction, especially for non-contemporary algorithms, to
help sunset them and maintain them with minimal effort.

My bad... I just talked to Zooko about the presentation. He was not
able to attend the conference, so there is no presentation to link to.

However, here is the write-up in the Tahoe-LAFS Bug Reporter:
https://tahoe-lafs.org/trac/pycryptopp/ticket/85#comment:20. It makes
the case for No-ASM. (And was the corpus of knowledge for the
presentation).

Jeff
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

I can understand the desire to remove the assembly code options, but I 
think there are legitimate reasons to leave them in.  From the write-up 
referenced (above), "because the added speed really makes no difference 
to our uses, as far as I know" was a reason given for removing 
assembly.  I think this is based on some assumptions that are not 
universally true, such as OpenSSL is running on multi-GHz multi-core 
64-bit processors.  This is not always the case.  I recently updated a 
product I support (50MHz single core) to OpenSSL 1.0.2d, and found that 
the assembly optimizations gave me a 40% increase in performance over 
the C version (AES decryption).  40% was very significant in my case.  
Seems like the low power IoT devices might be similarly CPU challenged 
in the future.


Jay
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

> MD2 - (The argument that someone somewhere may want to keep verifying old
> MD2 signatures on self-signed certs doesn't seem like a compelling enough
> reason to me. It's been disabled by default since OpenSSL 1.0.0.)
> ...
Apple still provides two Verisign certificates using
md2WithRSAEncryption. Confer,
https://support.apple.com/en-us/HT203065.

Jeff
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jeffrey Walton]

>> I asked for mainstream use-cases for algorithms whose removal could
>> cause widespread pain. Some individual users, undoubtedly, will be hit
>> by this, and I acknowledge that they may not be reading this list. But I
>> wanted to know if I'd missed something endemic. I also asked elsewhere:
>> Adam Langley pointed me to the MD4 use-case and Steve confirmed that RC2
>> must stay.
>>
>> There is a tradeoff: by attempting to accommodate every single use-case,
>> we will weaken the library for a substantial amount of our user base, by
>> offering them bad defaults, or simply by virtue of the fact that our
>> developer resources are not infinite. (Near)-dead code is a liability.
>
> We can significantly reduce that liability by removing any assembler
> optimisations. Also just because something is available doesn't mean it
> has to be "default". We can have good defaults whilst keeping old crypto.

Zooko Wilcox O'Hearn recently gave a talk at a software assurance
conference on the downsides of assembly language routines in software.
I'm trying to locate it now. All in all, this is probably a move in
the right direction, especially for non-contemporary algorithms, to
help sunset them and maintain them with minimal effort.

Its probably a good idea for mainstream algorithms, too. But the guys
I know who provide the highest-performance implementations probably
won't want to leave it to a compiler.

Jeff
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Benjamin Kaduk]

On 11/17/2015 12:00 PM, Jeffrey Walton wrote:
>
>
> Also, if OpenSSL requires iOS 9 or above, then its setting policy for users.

In some sense, yes.  But it has always done so -- OpenSSL only supports
certain platforms, and certain versions of certain platforms.  There are
prerequisites to being able to build any piece of software, and those
prerequisites can and must change as new versions of that software are
released.  In particular...

> I still have iOS 6, 7 and 8 devices because (1) some of my hardware is
> old and abandoned by Apple (they are trying to set policy, too, in an
> effort to boost sales). (2) I dislike the "cartoony" interface of iOS
> 7 and above. (3) I have down level OS X operating systems (due to
> operational requirements and personal taste), and they can't talk to
> iOS 8 or 9 devices.
>

Will Apple still be supporting even iOS 8 in two years?  I find it hard
to make a case that OpenSSL should make an active push to support
platforms no longer receiving security updates, given that we are
supposed to be security software.  In your personal case, you seem happy
to use older versions of OS X and iOS; what is different about those
compared to OpenSSL that you could not continue using an older version
of OpenSSL if you found some functionality of the old version to be
preferable?


-Ben
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Emilia Käsper]

Thanks all for your feedback!

I asked for mainstream use-cases for algorithms whose removal could cause
widespread pain. Some individual users, undoubtedly, will be hit by this,
and I acknowledge that they may not be reading this list. But I wanted to
know if I'd missed something endemic. I also asked elsewhere: Adam Langley
pointed me to the MD4 use-case and Steve confirmed that RC2 must stay.

There is a tradeoff: by attempting to accommodate every single use-case, we
will weaken the library for a substantial amount of our user base, by
offering them bad defaults, or simply by virtue of the fact that our
developer resources are not infinite. (Near)-dead code is a liability.

So far, excluding suspicions that something may be used somewhere, I've
received one clear argument, for RC5. And, while I'm sympathetic to the
cause, I believe this is the case where we have to balance one user's needs
against everyone else's.

As for specific deprecation strategies:
- Don't forget that all applications will have to recompile against 1.1.

- Disabling algorithms doesn't work well for us as it's just pushing the
decision on the distros. It also wouldn't win us any resources as we'd
still be responsible for keeping the code bug-free. The only win would be
in default compiled code size.

- We can leave OPENSSL_NO_XXX defines around so wrapper libraries (Python,
PHP etc) who correctly account for the fact that an implementation may be
missing (which they have to, anyway) will continue to work.

- Removing assembly support is a GREAT suggestion to simplify the
complexity, and I think we should do this for anything we end up leaving
in, and perhaps even for some things not yet on the hit list (RC4?).

- I appreciate OpenSSL's role as a "Swiss army knife" research tool but
research needs shouldn't prevail over those of real applications. We are
generally not on the frontline of deprecating things - RC4 isn't yet on the
list. SSLv3 isn't yet on the list, etc. But we can't become the Internet
Archive of All Old Crypto either, and there's some cleanup to do that's
long overdue.

- I believe that the OpenSSL community generally tends to overlook the
positive impact of change when trying to round up the negative impact of
breakage. Applications are generally able to move along and fix things when
presented with the right incentives. Applications that aren't generally
able to move along are rather unlikely to jump onto OpenSSL 1.1, and all
these algorithms will be supported as part of OpenSSL 1.0.2 until 2020 for
them. Finally, removing support for these algorithms from OpenSSL doesn't
render your encrypted storage inaccessible. You can always use another
implementation to decrypt/re-encrypt your data, and I fully believe in the
power of the community in providing such tools where necessary.

- Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty
widespread MySQL breakage. That made MySQL backport a change increasing the
DH key length from 512 to 2048 bits. For end user security, it's a win. I
would prefer that we start cashing in these improvements before the next
Logjam happens. (This is my view; as you can see views differ even within
the team.)

- On binary elliptic curves: with recent cryptographic advances, I believe
these are now firmly planted in the "internet archive" category, even if
not practically broken yet. The other reason for removing these is that our
implementations are crappy. They're not constant-time, and they've been
shown to contain bugs. Improving upon these implementations is not a good
use of dev time imo, given their decreasing credibility.

Here's the list of algorithms gone from BoringSSL:

IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves

This isn't of course entirely representative of widespread usage. However
Google's multi-billion line codebase now builds against BoringSSL and
therefore largely does not depend on these algorithms. Those billions of
lines aren't all new and shiny code written in 2015, and some of it does
have to interoperate with the outside world.

And here's the list gone from LibreSSL, from what I can tell:

MD2, MDC2, RC5, SEED

Neither have removed CAST, and there is presumably a good reason for that.
(PGP?)

It seems to me that these can pretty safely go:

MD2 - (The argument that someone somewhere may want to keep verifying old
MD2 signatures on self-signed certs doesn't seem like a compelling enough
reason to me. It's been disabled by default since OpenSSL 1.0.0.)
MDC2
SEED
RC5

These could probably stay (C only):

CAST
IDEA
RIPEMD (used in Bitcoin?)
WHIRLPOOL

as well as

BLOWFISH
MD4
RC2

I am on the fence about the binary curves: I am not aware of any usage,
really, and it's not about to pick up now.

Cheers,
Emilia

On Mon, Nov 16, 2015 at 2:21 PM, Hubert Kario  wrote:

> On Friday 13 November 2015 14:40:33 Emilia Käsper wrote:
> > Hi all,
> >
> > We are considering removing from OpenSSL 1.1 known broken or outdated
> > 

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

[Viktor Dukhovni]

On Mon, Nov 16, 2015 at 04:51:10PM +0100, Emilia Käsper wrote:

> As for specific deprecation strategies:
> - Don't forget that all applications will have to recompile against 1.1.

The EVP_get_cipherbyname() and EVP_get_digestbyname() interfaces
remain, so nothing changes at compile-time.  Most code does not
use EVP_() directly.  This means that:

* Most errors are not caught at compile time.

* Porting is not the difficult part, the much more difficult
  problem is dealing with runtime access to any algorithms needed
  to handle data at rest.

> - Disabling algorithms doesn't work well for us as it's just pushing the
> decision on the distros. It also wouldn't win us any resources as we'd
> still be responsible for keeping the code bug-free. The only win would be
> in default compiled code size.

Removing assembly support would substantially lower support cost.
For many of the algorithms we can likely find a reference implementation
in an RFC or similar standards document, if our own code is
substantially more refined (and requires greater support effort).

> - We can leave OPENSSL_NO_XXX defines around so wrapper libraries (Python,
> PHP etc) who correctly account for the fact that an implementation may be
> missing (which they have to, anyway) will continue to work.

These don't help with EVP "by name" indirection.

> - Removing assembly support is a GREAT suggestion to simplify the
> complexity, and I think we should do this for anything we end up leaving
> in, and perhaps even for some things not yet on the hit list (RC4?).

Yes, and probably.

> - I appreciate OpenSSL's role as a "Swiss army knife" research tool but
> research needs shouldn't prevail over those of real applications. We are
> generally not on the frontline of deprecating things - RC4 isn't yet on the
> list. SSLv3 isn't yet on the list, etc. But we can't become the Internet
> Archive of All Old Crypto either, and there's some cleanup to do that's
> long overdue.

Researchers can indeed use older toolkits, my concern is real users,
with non-SSL applications (data at rest).

> - Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty
> widespread MySQL breakage. That made MySQL backport a change increasing the
> DH key length from 512 to 2048 bits. For end user security, it's a win. I
> would prefer that we start cashing in these improvements before the next
> Logjam happens. (This is my view; as you can see views differ even within
> the team.)

This is SSL/TLS where we have algorithm agility.  I support the
Logjam changes.  It is likely time for us to take the next (not
final) step from 768 to 1024 as the min prime size.

> - On binary elliptic curves: with recent cryptographic advances, I believe
> these are now firmly planted in the "internet archive" category, even if
> not practically broken yet. The other reason for removing these is that our
> implementations are crappy. They're not constant-time, and they've been
> shown to contain bugs. Improving upon these implementations is not a good
> use of dev time imo, given their decreasing credibility.

I agree they need to go from SSL/TLS.  What about S/MIME and CMS?

> Here's the list of algorithms gone from BoringSSL:
> 
> IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves

Boring SSL has a very narrow user base.  By all means drop
as much as you can get away with.

> And here's the list gone from LibreSSL, from what I can tell:
> 
> MD2, MDC2, RC5, SEED

Likewise, not a wide user base.  We can make incremental steps,
drop assembly support and SSL/TLS codepoints in this release, and
assess things from there.  My hope is that the support cost of a
stable reference implementation in C (yes, likely not constant
time) is not that onerous.

-- 
Viktor.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jakob Bohm]

On 16/11/2015 16:51, Emilia Käsper wrote:

Thanks all for your feedback!

I asked for mainstream use-cases for algorithms whose removal could 
cause widespread pain. Some individual users, undoubtedly, will be hit 
by this, and I acknowledge that they may not be reading this list. But 
I wanted to know if I'd missed something endemic. I also asked 
elsewhere: Adam Langley pointed me to the MD4 use-case and Steve 
confirmed that RC2 must stay.


There is a tradeoff: by attempting to accommodate every single 
use-case, we will weaken the library for a substantial amount of our 
user base, by offering them bad defaults, or simply by virtue of the 
fact that our developer resources are not infinite. (Near)-dead code 
is a liability.


So far, excluding suspicions that something may be used somewhere, 
I've received one clear argument, for RC5. And, while I'm sympathetic 
to the cause, I believe this is the case where we have to balance one 
user's needs against everyone else's.


As for specific deprecation strategies:
- Don't forget that all applications will have to recompile against 1.1.

- Disabling algorithms doesn't work well for us as it's just pushing 
the decision on the distros. It also wouldn't win us any resources as 
we'd still be responsible for keeping the code bug-free. The only win 
would be in default compiled code size.


- We can leave OPENSSL_NO_XXX defines around so wrapper libraries 
(Python, PHP etc) who correctly account for the fact that an 
implementation may be missing (which they have to, anyway) will 
continue to work.


- Removing assembly support is a GREAT suggestion to simplify the 
complexity, and I think we should do this for anything we end up 
leaving in, and perhaps even for some things not yet on the hit list 
(RC4?).


- I appreciate OpenSSL's role as a "Swiss army knife" research tool 
but research needs shouldn't prevail over those of real applications. 
We are generally not on the frontline of deprecating things - RC4 
isn't yet on the list. SSLv3 isn't yet on the list, etc. But we can't 
become the Internet Archive of All Old Crypto either, and there's some 
cleanup to do that's long overdue.
There is also the point that OpenSSL is the worlds most well known 
"Swiss army knife" crypto package for non-research uses.  The more you 
overfocus on the single SSL/TLS use case, the less attractive OpenSSL 
becomes to all other uses.  If OpenSSL makes itself useless, others will 
have to reinvent it.


- I believe that the OpenSSL community generally tends to overlook the 
positive impact of change when trying to round up the negative impact 
of breakage. Applications are generally able to move along and fix 
things when presented with the right incentives. Applications that 
aren't generally able to move along are rather unlikely to jump onto 
OpenSSL 1.1, and all these algorithms will be supported as part of 
OpenSSL 1.0.2 until 2020 for them. Finally, removing support for these 
algorithms from OpenSSL doesn't render your encrypted storage 
inaccessible. You can always use another implementation to 
decrypt/re-encrypt your data, and I fully believe in the power of the 
community in providing such tools where necessary.


- Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty 
widespread MySQL breakage. That made MySQL backport a change 
increasing the DH key length from 512 to 2048 bits. For end user 
security, it's a win. I would prefer that we start cashing in these 
improvements before the next Logjam happens. (This is my view; as you 
can see views differ even within the team.)
The Logjam protection was an SSL-only change.  It has NO relevance to 
the deleterious effects of crippling the non-SSL functionality in the 
OpenSSL libraries.


- On binary elliptic curves: with recent cryptographic advances, I 
believe these are now firmly planted in the "internet archive" 
category, even if not practically broken yet. The other reason for 
removing these is that our implementations are crappy. They're not 
constant-time, and they've been shown to contain bugs. Improving upon 
these implementations is not a good use of dev time imo, given their 
decreasing credibility.


Here's the list of algorithms gone from BoringSSL:

IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves

This isn't of course entirely representative of widespread usage. 
However Google's multi-billion line codebase now builds against 
BoringSSL and therefore largely does not depend on these algorithms. 
Those billions of lines aren't all new and shiny code written in 2015, 
and some of it does have to interoperate with the outside world.


And here's the list gone from LibreSSL, from what I can tell:

MD2, MDC2, RC5, SEED

Neither have removed CAST, and there is presumably a good reason for 
that. (PGP?)


It seems to me that these can pretty safely go:

MD2 - (The argument that someone somewhere may want to keep verifying 
old MD2 signatures on self-signed certs doesn't seem 

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

[Emilia Käsper]

One more time,

I know that someone, somewhere is probably using any given feature of
OpenSSL. I am looking to gather information about concrete, actively
maintained applications that may be using one of those algorithms, to build
a more complete picture.

If you are aware of a concrete use of MD2 or any of the other algorithms,
please let us know!

Thanks,
Emilia

On Mon, Nov 16, 2015 at 7:25 PM, Hubert Kario  wrote:

> On Monday 16 November 2015 16:51:10 Emilia Käsper wrote:
> > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves
> >
> > This isn't of course entirely representative of widespread usage.
> > However Google's multi-billion line codebase now builds against
> > BoringSSL and therefore largely does not depend on these algorithms.
> > Those billions of lines aren't all new and shiny code written in
> > 2015, and some of it does have to interoperate with the outside
> > world.
> >
> > And here's the list gone from LibreSSL, from what I can tell:
> >
> > MD2, MDC2, RC5, SEED
> >
> > Neither have removed CAST, and there is presumably a good reason for
> > that. (PGP?)
> >
> > It seems to me that these can pretty safely go:
> >
> > MD2 - (The argument that someone somewhere may want to keep verifying
> > old MD2 signatures on self-signed certs doesn't seem like a
> > compelling enough reason to me. It's been disabled by default since
> > OpenSSL 1.0.0.) MDC2
> > SEED
> > RC5
> >
> > These could probably stay (C only):
> >
> > CAST
> > IDEA
> > RIPEMD (used in Bitcoin?)
> > WHIRLPOOL
> >
> > as well as
> >
> > BLOWFISH
> > MD4
> > RC2
> >
> > I am on the fence about the binary curves: I am not aware of any
> > usage, really, and it's not about to pick up now.
>
> I'm afraid you're too focused on TLS/SSL use case. And while it is
> important it's not the only use case the OpenSSL does serve.
>
> And for what it's worth, I'm very much *for* removing as much (and as
> fast as possible) support for the old junk (or unused stuff - like
> curves < 256 bit) in TLS. Search the archives for "Insecure DEFAULT
> cipher set" for an example.
>
> But stuff like this:
>
> > The argument that someone somewhere may want to keep verifying
> > old MD2 signatures on self-signed certs
>
> is not true. I was talking about document signatures, time stamps, CRL
> signatures and certificate signatures in general. Not the trust anchors
> or their self-signatures.
>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Richard Moore]

On 16 November 2015 at 19:05, Hubert Kario  wrote:

> Example: CAdES V1.2.2 was published in late 2000, the first serious
> attacks on MD2 were not published until 2004. I think it is not
> unreasonable for CAdES-A documents to exist today which were originally
> signed with MD2 while it was still considered secure and that are still
> relevant today, just 15 years later.
>
>
​This doesn't explain why the code needs to exist in future versions of
openssl. The previous ones aren't going to vanish and can be compiled and
used to rescue data in theoretical edge cases like this. You're making it
sound like this is making the data totally inaccessible which is not the
case.

Cheers

Rich.​
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Matt Caswell]

On 16/11/15 15:51, Emilia Käsper wrote:
> Thanks all for your feedback!
> 
> I asked for mainstream use-cases for algorithms whose removal could
> cause widespread pain. Some individual users, undoubtedly, will be hit
> by this, and I acknowledge that they may not be reading this list. But I
> wanted to know if I'd missed something endemic. I also asked elsewhere:
> Adam Langley pointed me to the MD4 use-case and Steve confirmed that RC2
> must stay.
> 
> There is a tradeoff: by attempting to accommodate every single use-case,
> we will weaken the library for a substantial amount of our user base, by
> offering them bad defaults, or simply by virtue of the fact that our
> developer resources are not infinite. (Near)-dead code is a liability.

We can significantly reduce that liability by removing any assembler
optimisations. Also just because something is available doesn't mean it
has to be "default". We can have good defaults whilst keeping old crypto.


> 
> So far, excluding suspicions that something may be used somewhere, I've
> received one clear argument, for RC5. And, while I'm sympathetic to the
> cause, I believe this is the case where we have to balance one user's
> needs against everyone else's.
> 
> As for specific deprecation strategies:
> - Don't forget that all applications will have to recompile against 1.1.
> 
> - Disabling algorithms doesn't work well for us as it's just pushing the
> decision on the distros. It also wouldn't win us any resources as we'd
> still be responsible for keeping the code bug-free. The only win would
> be in default compiled code size.

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.

> 
> - We can leave OPENSSL_NO_XXX defines around so wrapper libraries
> (Python, PHP etc) who correctly account for the fact that an
> implementation may be missing (which they have to, anyway) will continue
> to work.
> 
> - Removing assembly support is a GREAT suggestion to simplify the
> complexity, and I think we should do this for anything we end up leaving
> in, and perhaps even for some things not yet on the hit list (RC4?).
> 
> - I appreciate OpenSSL's role as a "Swiss army knife" research tool but
> research needs shouldn't prevail over those of real applications. We are
> generally not on the frontline of deprecating things - RC4 isn't yet on
> the list. SSLv3 isn't yet on the list, etc. But we can't become the
> Internet Archive of All Old Crypto either, and there's some cleanup to
> do that's long overdue.

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).


> It seems to me that these can pretty safely go:
> 
> MD2 - (The argument that someone somewhere may want to keep verifying
> old MD2 signatures on self-signed certs doesn't seem like a compelling
> enough reason to me. It's been disabled by default since OpenSSL 1.0.0.)
> MDC2
> SEED
> RC5 

All candidates for liblegacycrypto IMO rather than deletion.

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

Matt
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Salz, Rich]

Ø  If you are aware of a concrete use of MD2 or any of the other algorithms, 
please let us know!

Also, note that we have an extended alpha and-beta test period, so we can add 
things back if mistakes are made.

/r$

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dr. Stephen Henson]

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 (including major web browsers) still
produce PKCS#12 files which include 40 bit RC2 for certificate "encryption"
and OpenSSL would fail to decrypt those if it removed RC2.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users