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

[Hubert Kario]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151116/dcb8a2a6/attachment-0001.sig>