On 13/11/2015 18:00, Benjamin Kaduk wrote: > 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. > It is essentially a "proof-of-possession", just like the signature on a CSR. Another way to look at is that it is a consistency check rather than a trust check. One use would be to refuse import of an invalid root CA before even getting to the point of asking the user if she wants to add this certificate to the trusted roots store. Another use would be to detect accidental corruption of the trusted roots store (e.g. from disk I/O errors or partial disk writes during a system crash). >> 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. I have not checked the details, but the fundamental issue is this: Windows domain controller databases store only the unsalted MD4 password hash and/or the historic LM password hash, with most current systems configured to store only the MD4 hash. Thus any protocol that validates user identity via their knowledge of their domain password would need to either transmit the actual password to the domain controller or use some kind of cryptographic calculation where the computer closer to the user proves knowledge of the MD4 hash to the domain controller server. Historically, Microsoft has implemented multiple such cryptographic protocols: NTLMv1 was the oldest such protocol, based on a using DES in a silly way vastly similar to the LM protocol. NTLMv2 was the next version, based mostly on HMAC-MD5, introduced in the late 1990s and still the strongest supported when the client computer is not (yet) joined to the domain. Microsoft-specific variants/profiles of Kerberos V are used between modern (post 2000) domain joined computers and the trusted domain controllers of the users login domain. I have not yet studied which formulas they are currently using/ recommending/planning for this case, but they will all be constrained by the fact that the server knows nothing about the password except its MD4 hash or some value derived therefrom. Any upgrade of the password database to a new format would either involve requesting a different form of the password (encrypted) after a successful MD4 based login or choosing a new form mathematically derived from the MD4 hash, such as foo(HMAC(SHA3-512, salt, MD4(UTF16LE(password)))). New client protocols could challenge with salt and engage in some zero knowledge proof of knowledge of HMAC(SHA3-512, salt, MD4(UTF16LE(password))) . Also note that the inherently low entropy of human-memorable passwords means that there is little security difference between starting from MD4(UTF16LE(password)) and starting from SHA3-1024(UTF8(password)), what matters most is the calculations done on top of that. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151113/1010f009/attachment-0001.html>
