Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

classic Classic list List threaded Threaded
70 messages Options
1234
pl
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

pl
On 14/11/2015 18:32, Viktor Dukhovni wrote:

> On Sat, Nov 14, 2015 at 07:32:33AM +0000, Peter Waltenberg wrote:
>
>>    I also can't see any point expunging old algorithms from the sources,
>>    making them not build by default should be enough.
> It is difficult enough to maintain code that is typically built,
> dead code is even harder to keep correct.  And what are distributions
> of the library to do?  Break a lot of customer code by shipping
> with the algorithms disabled?  Or re-enable compilation?
>
>>    The only thing I would suggest is dropping assembler support for
>>    anything that's been retired, just to cut the maintenance effort / risk
>>    of breakage. If it's legacy only, performance shouldn't be an issue.
> That probably makes more sense.  Drop associated SSL/TLS ciphersuite
> codepoints and drop assembly support (if any).  Leave the C
> implementation in libcrypto to support legacy "data at rest"
> applications.
>
> The proposed list was:
>
>     CAST
>     IDEA
>     MDC2
>     MD2 [ already disabled by default ]
>     RC5 [ already disabled by default ]
>     RIPEMD
>     SEED
>     WHIRLPOOL
>     ALL BINARY ELLIPTIC CURVES
>
> If I were to guess, it would be that the base crypto implementations
> of IDEA, SEED and binary elliptic curves need to stay.  We could
> perhaps get away with removing CAST and RIPEMD.  No idea about the
> rest.
>

It is perhaps time to split crypto library in two libraries
libcryptolegacy and libcryptostrong...

My two cents.

Philippe L.



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Loganaden Velvindron
On Sun, Nov 15, 2015 at 8:48 AM, pl <[hidden email]> wrote:

> On 14/11/2015 18:32, Viktor Dukhovni wrote:
>> On Sat, Nov 14, 2015 at 07:32:33AM +0000, Peter Waltenberg wrote:
>>
>>>    I also can't see any point expunging old algorithms from the sources,
>>>    making them not build by default should be enough.
>> It is difficult enough to maintain code that is typically built,
>> dead code is even harder to keep correct.  And what are distributions
>> of the library to do?  Break a lot of customer code by shipping
>> with the algorithms disabled?  Or re-enable compilation?
>>
>>>    The only thing I would suggest is dropping assembler support for
>>>    anything that's been retired, just to cut the maintenance effort / risk
>>>    of breakage. If it's legacy only, performance shouldn't be an issue.
>> That probably makes more sense.  Drop associated SSL/TLS ciphersuite
>> codepoints and drop assembly support (if any).  Leave the C
>> implementation in libcrypto to support legacy "data at rest"
>> applications.
>>
>> The proposed list was:
>>
>>     CAST
>>     IDEA
>>     MDC2
>>     MD2 [ already disabled by default ]
>>     RC5 [ already disabled by default ]
>>     RIPEMD
>>     SEED
>>     WHIRLPOOL
>>     ALL BINARY ELLIPTIC CURVES
>>

Perhaps, it might be worth looking at what LibreSSL has already
removed without affecting their 3rd party packages ?
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Richard Levitte - VMS Whacker-2
In reply to this post by pl
In message <[hidden email]> on Sun, 15 Nov 2015 09:48:36 +0100, pl <[hidden email]> said:

pl> On 14/11/2015 18:32, Viktor Dukhovni wrote:
pl> > The proposed list was:
pl> >
pl> >     CAST
pl> >     IDEA
pl> >     MDC2
pl> >     MD2 [ already disabled by default ]
pl> >     RC5 [ already disabled by default ]
pl> >     RIPEMD
pl> >     SEED
pl> >     WHIRLPOOL
pl> >     ALL BINARY ELLIPTIC CURVES
pl> >
pl> > If I were to guess, it would be that the base crypto implementations
pl> > of IDEA, SEED and binary elliptic curves need to stay.  We could
pl> > perhaps get away with removing CAST and RIPEMD.  No idea about the
pl> > rest.
pl> >
pl>
pl> It is perhaps time to split crypto library in two libraries
pl> libcryptolegacy and libcryptostrong...
pl>
pl> My two cents.

I though could be to make a "legacy" engine that holds the removed
crypto algos.  It could be maintained outside of mainstream OpenSSL,
really by anyone...

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Viktor Dukhovni
In reply to this post by Loganaden Velvindron
On Sun, Nov 15, 2015 at 10:24:02AM +0000, Loganaden Velvindron wrote:

> Perhaps, it might be worth looking at what LibreSSL has already
> removed without affecting their 3rd party packages ?

There are not many arms-length packages for OpenBSD, the ports are
maintained by the same crowd as the OS.  Nor very many users of
all the BSD'd combined (I'm editing this email on a BSD server).
This would not be a very meaningful datapoint.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Viktor Dukhovni
In reply to this post by Richard Levitte - VMS Whacker-2
On Sun, Nov 15, 2015 at 01:11:37PM +0100, Richard Levitte wrote:

> pl> It is perhaps time to split crypto library in two libraries
> pl> libcryptolegacy and libcryptostrong...
> pl>
> pl> My two cents.
>
> I though could be to make a "legacy" engine that holds the removed
> crypto algos.  It could be maintained outside of mainstream OpenSSL,
> really by anyone...

If the engine is not automatically loaded, then scripting languages
that provide wrappers around the various algorithms, as does other
software that needs the legacy algoriths, but has never needed any
engines and makes no provisions for loading any.

With a separate library one might imagine its "init" method calling
some function in libcrypto that makes the legacy algorithms available
via EVP, and then Python, Perl, ... could be linked with:

    -lweakcrypto -lssl -lcrypto

That's something distribution maintainers could do, but is this
really a productive step to take at this time?  That library will
take more effort to produce than leaving things as they are.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Sun, 15 Nov 2015 17:09:48 +0000, Viktor Dukhovni <[hidden email]> said:

openssl-users> On Sun, Nov 15, 2015 at 01:11:37PM +0100, Richard Levitte wrote:
openssl-users>
openssl-users> > pl> It is perhaps time to split crypto library in two libraries
openssl-users> > pl> libcryptolegacy and libcryptostrong...
openssl-users> > pl>
openssl-users> > pl> My two cents.
openssl-users> >
openssl-users> > I though could be to make a "legacy" engine that holds the removed
openssl-users> > crypto algos.  It could be maintained outside of mainstream OpenSSL,
openssl-users> > really by anyone...
openssl-users>
openssl-users> If the engine is not automatically loaded, then scripting languages
openssl-users> that provide wrappers around the various algorithms, as does other
openssl-users> software that needs the legacy algoriths, but has never needed any
openssl-users> engines and makes no provisions for loading any.

/PATH/TO/openssl.cnf:

openssl_conf = openssl_init

[openssl_init]
engines = default_engines

[default_engines]
legacy = legacy

[legacy]
engine_id = legacy
init = 1
default_algorithms = cast, idea, mdc2, md2, rc5, ripemd, seed, whirlpool, ...

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Viktor Dukhovni
On Sun, Nov 15, 2015 at 09:14:43PM +0100, Richard Levitte wrote:

> openssl-users> If the engine is not automatically loaded, then scripting languages
> openssl-users> that provide wrappers around the various algorithms [break], as does other
> openssl-users> software that needs the legacy algoriths, but has never needed any
> openssl-users> engines and makes no provisions for loading any.
>
> /PATH/TO/openssl.cnf:
>
> openssl_conf = openssl_init
>
> [openssl_init]
> engines = default_engines
>
> [default_engines]
> legacy = legacy
>
> [legacy]
> engine_id = legacy
> init = 1
> default_algorithms = cast, idea, mdc2, md2, rc5, ripemd, seed, whirlpool, ...

There's lots of code that does not read any ".cnf" files.  The CONF
interface has not historically been terribly well documented.  What
happens if the engine fails to load?  Are any environment variables
that determine CONF file locations honoured in setuid/setgid programs
(do we use secure_getenv(3) where available?).

We'd need to provide a migration document and code samples, that
show how to do "CONF" initialization, and of course create the
legacy engine.  All this may delay adoption, as distributions will
need patch upstream code to perform such initialization.

Is the pain worth the gain?  I'm inclined to think that dropping
TLS ciphersuite code points, and assembly support, is a rather
sensible first step.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Matt Caswell-2


On 15/11/15 21:16, Viktor Dukhovni wrote:
> Is the pain worth the gain?  I'm inclined to think that dropping
> TLS ciphersuite code points, and assembly support, is a rather
> sensible first step.

I agree with this. I am wary of dropping too much too quickly.

Matt

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Hubert Kario
In reply to this post by Emilia Käsper-2
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
> 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 candidates for removal:
>
> CAST
> IDEA
> MDC2
> MD2 [ already disabled by default ]
> RC5 [ already disabled by default ]
> RIPEMD
> SEED
> WHIRLPOOL
> ALL BINARY ELLIPTIC CURVES
>
> My preference would be to remove these algorithms completely (as in,
> delete the code). Disabled-by-default code will either be re-enabled
> by distros (if there's widespread need for it - in which case we
> might as well leave it in) or will be poorly tested and is likely to
> just silently rot and break. This code is bloat and maintentance
> burden for us - my hope is that much of this code is effectively dead
> and can be removed.
>
> *Are you aware of any mainstream need to continue supporting these
> algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or
> binary, or a standalone implementation or another crypto toolkit can
> always be used to continue supporting a legacy standalone
> application, or to decrypt ciphertext from the distant past. I am
> looking for use cases that could cause e.g. interop breakage between
> new and old peers, or major pain to distro end-users.
>
> These algorithms are obsolete but removing them doesn't look feasible:
>
> BLOWFISH - probably still in use though I don't know where exactly?
> MD4 - used in NTLM
> RC2 - used in PKCS#12
>
> *Did I miss anything from the list?*
I'd say that this is the wrong approach.

If you have old stuff signed with MD2, and then timestamped with MD5,
SHA-1, SHA-256 over the years, with new timestamp added every year this
makes the MD2 signature _valid_ and _secure_.

If you have stuff that is encrypted, but in deep storage with any of
those algorithms, then yes, it's less than optimal. Removing support for
those algorithm will make this data inaccessible. Not to mention that
stuff like IDEA or SEED may never get broken before the data in them
needs to remain secret - and after that creating a new archive with
unencrypted data after it can become public would simply cost money.

And as some pointed out, few OpenSSL users actually read mailing lists,
fewer still know what actual primitives are necessary for their stuff to
work (e.g. PKCS#8 files specify inside them the cipher and key
derivation necessary for decryption).


What I think is the correct course of action, is to have in the
configuration file settings which specify the set of algorithms that are
set as available and trusted. So that we can disable them by default and
require the users to make a concious decision to enable support for
them. (Make openssl print to stderr info about them being
administratively disabled when application tries using them for bonus
points).

This allows to place the information about this depreciation in a place
where users will actually see it and will make them concious of using
weak and badly tested algorithms. At the same time it will protect most
of the users that don't require such obsolete algorithms.

But this concious decision MUST NOT require recompilation of the
package. Few if any distributions support recompiled packages. For many
end-users this is also a hurdle they simply can't cross.

And this also allows openssl to change the cryptographic policy in
stable branches without breaking the API/ABI promise. (POODLE, FREAK,
Logjam)
--
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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Emilia Käsper-2
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 <[hidden email]> 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
> 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 candidates for removal:
>
> CAST
> IDEA
> MDC2
> MD2 [ already disabled by default ]
> RC5 [ already disabled by default ]
> RIPEMD
> SEED
> WHIRLPOOL
> ALL BINARY ELLIPTIC CURVES
>
> My preference would be to remove these algorithms completely (as in,
> delete the code). Disabled-by-default code will either be re-enabled
> by distros (if there's widespread need for it - in which case we
> might as well leave it in) or will be poorly tested and is likely to
> just silently rot and break. This code is bloat and maintentance
> burden for us - my hope is that much of this code is effectively dead
> and can be removed.
>
> *Are you aware of any mainstream need to continue supporting these
> algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or
> binary, or a standalone implementation or another crypto toolkit can
> always be used to continue supporting a legacy standalone
> application, or to decrypt ciphertext from the distant past. I am
> looking for use cases that could cause e.g. interop breakage between
> new and old peers, or major pain to distro end-users.
>
> These algorithms are obsolete but removing them doesn't look feasible:
>
> BLOWFISH - probably still in use though I don't know where exactly?
> MD4 - used in NTLM
> RC2 - used in PKCS#12
>
> *Did I miss anything from the list?*

I'd say that this is the wrong approach.

If you have old stuff signed with MD2, and then timestamped with MD5,
SHA-1, SHA-256 over the years, with new timestamp added every year this
makes the MD2 signature _valid_ and _secure_.

If you have stuff that is encrypted, but in deep storage with any of
those algorithms, then yes, it's less than optimal. Removing support for
those algorithm will make this data inaccessible. Not to mention that
stuff like IDEA or SEED may never get broken before the data in them
needs to remain secret - and after that creating a new archive with
unencrypted data after it can become public would simply cost money.

And as some pointed out, few OpenSSL users actually read mailing lists,
fewer still know what actual primitives are necessary for their stuff to
work (e.g. PKCS#8 files specify inside them the cipher and key
derivation necessary for decryption).


What I think is the correct course of action, is to have in the
configuration file settings which specify the set of algorithms that are
set as available and trusted. So that we can disable them by default and
require the users to make a concious decision to enable support for
them. (Make openssl print to stderr info about them being
administratively disabled when application tries using them for bonus
points).

This allows to place the information about this depreciation in a place
where users will actually see it and will make them concious of using
weak and badly tested algorithms. At the same time it will protect most
of the users that don't require such obsolete algorithms.

But this concious decision MUST NOT require recompilation of the
package. Few if any distributions support recompiled packages. For many
end-users this is also a hurdle they simply can't cross.

And this also allows openssl to change the cryptographic policy in
stable branches without breaking the API/ABI promise. (POODLE, FREAK,
Logjam)
--
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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] 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_<algorithm-name>() 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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Hubert Kario
In reply to this post by Emilia Käsper-2
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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Emilia Käsper-2
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 <[hidden email]> 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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Hubert Kario
On Monday 16 November 2015 19:51:08 Emilia Käsper wrote:
> 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!

And I'm saying that it is next-to impossible for me to say for certain
because standards like CMS, S/MIME, PKCS#8 and X.509 are extensible and
self descriptive. The file itself says which algorithms are needed to
process it.

So without access to _all_ _data_ that the applications need to process
it is impossible for me to tell which of those algorithms are necessary
for continued operation of those applications.


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.

> Thanks,
> Emilia
>
> On Mon, Nov 16, 2015 at 7:25 PM, Hubert Kario <[hidden email]>
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
--
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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Richard Moore

On 16 November 2015 at 19:05, Hubert Kario <[hidden email]> 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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Blumenthal, Uri - 0553 - MITLL
On 16 November 2015 at 19:05, Hubert Kario <[hidden email]> 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.

Of course people can keep the current OpenSSL version indefinitely – and if the maintainers are too aggressive, it might just happen.

But the vast majority of the uses would like to upgrade to new releases with hopefully more bugs fixed and fewer bugs introduced – and maintain their current functionality. Because if the new version stops decrypting their documents, who needs it?

Several people pointed out: SSL/TLS is where the algorithm agility is, where the exploits are, and what needs to be pruned. So remove the dead wood from libssl. Leave libcrypto alone – it is useful as-is, and real-life big packages (like Perl) depend on it providing all the services it currently offers. Don’t punish users for choosing OpenSSL library to handle their non-SSL cryptographic needs and implicitly trusting the developers that they won’t be left in the cold.

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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Peter Waltenberg
In reply to this post by Richard Moore

The reason for keeping the old crypto. algorithms around is the obvious one, that's been stated over and over. OpenSSL's SSL isn't the only consumer of the algorithms, remove the low level algorithms and you risk breaking more than OpenSSL. SSH, IKE,IPSec, Kerberos and I'm sure there are more, and the scripting languages like Perl that use OpenSSL to provide algorithm support.

There are a lot of ecosystems built on top of OpenSSL's crypto, it's not just SSL, and for someone like a distro. maintainer it's between a rock and a hard place, stick with the old code and patch the security vulnerabilities, or break stuff. Which is why them being still available in the old code isn't a good enough answer to the problems this would create.

And in this case 'breaking stuff' is unecessary. Do what you like with TLS in terms of pruning algorithms in use, but removing the algorithms is a lot like burning books in a library for being irrelevant. They may be irrelevant to you, but they aren't necessarilly irrelevant to everyone.

Peter



Inactive hide details for Richard Moore ---17/11/2015 06:29:24---On 16 November 2015 at 19:05, Hubert Kario <hkario@redhat.com>Richard Moore ---17/11/2015 06:29:24---On 16 November 2015 at 19:05, Hubert Kario <[hidden email]> wrote: > Example: CAdES V1.2.2 was pu

From: Richard Moore <[hidden email]>
To: [hidden email]
Cc: [hidden email]
Date: 17/11/2015 06:29
Subject: Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
Sent by: "openssl-dev" <[hidden email]>






On 16 November 2015 at 19:05, Hubert Kario <[hidden email]> 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-dev mailing list
To unsubscribe:
https://mta.openssl.org/mailman/listinfo/openssl-dev




_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Salz, Rich
In reply to this post by Emilia Käsper-2

 

Ø  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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Salz, Rich
In reply to this post by Blumenthal, Uri - 0553 - MITLL

> Don’t punish users for choosing OpenSSL library to handle their non-SSL cryptographic needs and implicitly trusting the developers that they won’t be left in the cold.

 

Can we please be less inflammatory?

 

Old unused code is a security risk.  We’re trying to reduce the attack surface *responsibly.*

 


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Walton-3
In reply to this post by Emilia Käsper-2
> 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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
1234