On 11/13/2015 09:31 AM, Jakob Bohm wrote: > On 13/11/2015 14:40, Emilia K?sper wrote: >> Hi all, >> >> We are considering removing from OpenSSL 1.1 known broken or outdated >> cryptographic primitives. As you may know the forks have already done >> this but I'd like to seek careful feedback for 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 >> I wonder why single-DES is not in the above list. (Maybe because no one has spoken up as being interested in disentangling triple-DES from single-DES?) >> 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. >> My hope as well :) >> 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 >> 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.) > MD2 is still present in the self-signature on some major > root certificates that are still trusted in signatures > on old/historic data and documents. Note that the > default OpenSSL code currently skips checking the > self-signature on self-signed root certificates, but > that was done based as a workaround for the disabling > of MD2, and is based on the (unreliable) assumption > that checking their internal consistency had no value > in determining the trust. Accepting MD2 only for this > limited role (and thus keeping the code around for that > case only) would be more secure. > I am not sure that I agree with the claim that this assumption is unreliable. There have been some (heated) discussions on the IETF tls WG list recently regarding the self-signatures on trust anchors, and I have not seen any compelling arguments there for checking the self-signature. The trust anchor is just a key and an identifier; its presence in the trust store seems necessary and sufficient to me. > The use of MD4 in NTLM is closely related to its use in > the password database format of computers that > interoperate with NTLM, SMB, CIFS, Microsoft Kerberos > extensions etc. Those password databases and related > protocols will probably outlive NTLM itself by many > years. > The MD4 in the NTLM password hash is unsalted, for extra insecurity. The only real reason to still be using MD4 (by way of the RC4 enctype) in Kerberos is if you need to interoperate with WinXP or Server 2003 machines, but those are not really supported anymore. We are working to get RC4 explicitly deprecated for Kerberos at the IETF. -Ben Kaduk -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151113/de2335f8/attachment.html>
