<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 13/11/2015 18:00, Benjamin Kaduk
wrote:<br>
</div>
<blockquote class=" cite" id="mid_56461746_7040808_akamai_com"
cite="mid:56461746.7040808@akamai.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
On 11/13/2015 09:31 AM, Jakob Bohm wrote:<br>
<blockquote class=" cite" id="mid_56460267_1080802_wisemo_com"
cite="mid:56460267.1080802@wisemo.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class="moz-cite-prefix">On 13/11/2015 14:40, Emilia Käsper
wrote:<br>
</div>
<blockquote class=" cite"
id="mid_CAGZjfUYJLnD7Qo28r_iQgnUYAsZay_Ftp8KEG_7MPY5pY_248A_mail_gmail_com"
cite="mid:CAGZjfUYJLnD7Qo28r_iQgnUYAsZay_Ftp8KEG=7MPY5pY+248A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">
<div>Hi all,</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>These algorithms are currently candidates for
removal:</div>
<div><br>
</div>
<div>CAST</div>
<div>IDEA</div>
</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">MDC2</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">MD2
[ already disabled by default ]</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">RC5
[ already disabled by default ]</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">RIPEMD</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">SEED</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">WHIRLPOOL</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">ALL
BINARY ELLIPTIC CURVES</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px"><br>
</div>
</div>
</blockquote>
</blockquote>
<br>
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?)<br>
<br>
<blockquote class=" cite" id="mid_56460267_1080802_wisemo_com"
cite="mid:56460267.1080802@wisemo.com" type="cite">
<blockquote class=" cite"
id="mid_CAGZjfUYJLnD7Qo28r_iQgnUYAsZay_Ftp8KEG_7MPY5pY_248A_mail_gmail_com"
cite="mid:CAGZjfUYJLnD7Qo28r_iQgnUYAsZay_Ftp8KEG=7MPY5pY+248A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">
</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">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.</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px"><br>
</div>
</div>
</blockquote>
</blockquote>
<br>
My hope as well :)
<blockquote class=" cite" id="mid_56460267_1080802_wisemo_com"
cite="mid:56460267.1080802@wisemo.com" type="cite">
<blockquote class=" cite"
id="mid_CAGZjfUYJLnD7Qo28r_iQgnUYAsZay_Ftp8KEG_7MPY5pY_248A_mail_gmail_com"
cite="mid:CAGZjfUYJLnD7Qo28r_iQgnUYAsZay_Ftp8KEG=7MPY5pY+248A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">These
algorithms are obsolete but removing them doesn't look
feasible:</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px"><br>
</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">BLOWFISH
- probably still in use though I don't know where exactly?</div>
<div style="color:rgb(33,33,33);font-family:'Helvetica
Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:19.5px">
<div>MD4 - used in NTLM</div>
<div>RC2 - used in PKCS#12</div>
<br>
</div>
</div>
</blockquote>
</blockquote>
<br>
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.)<br>
<br>
<blockquote class=" cite" id="mid_56460267_1080802_wisemo_com"
cite="mid:56460267.1080802@wisemo.com" type="cite"><tt> </tt><tt>MD2
is still present in the self-signature on some major <br>
root certificates that are still trusted in signatures <br>
on old/historic data and documents. Note that the <br>
default OpenSSL code currently skips checking the <br>
self-signature on self-signed root certificates, but <br>
that was done based as a workaround for the disabling <br>
of MD2, and is based on the (unreliable) assumption <br>
that checking their internal consistency had no value <br>
in determining the trust. Accepting MD2 only for this <br>
limited role (and thus keeping the code around for that <br>
case only) would be more secure.</tt><tt><br>
</tt><tt><br>
</tt></blockquote>
<br>
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.<br>
<br>
</blockquote>
<tt>It is essentially a "proof-of-possession", just like the <br>
signature on a CSR. Another way to look at is that it is <br>
a consistency check rather than a trust check. One use <br>
would be to refuse import of an invalid root CA before <br>
even getting to the point of asking the user if she wants <br>
to add this certificate to the trusted roots store. <br>
Another use would be to detect accidental corruption of <br>
the trusted roots store (e.g. from disk I/O errors or <br>
partial disk writes during a system crash).<br>
<br>
</tt>
<blockquote class=" cite" id="mid_56461746_7040808_akamai_com"
cite="mid:56461746.7040808@akamai.com" type="cite">
<blockquote class=" cite" id="mid_56460267_1080802_wisemo_com"
cite="mid:56460267.1080802@wisemo.com" type="cite"><tt> </tt><tt>The
use of MD4 in NTLM is closely related to its use in <br>
the password database format of computers that <br>
interoperate with NTLM, SMB, CIFS, Microsoft Kerberos <br>
extensions etc. Those password databases and related <br>
protocols will probably outlive NTLM itself by many <br>
years.</tt><tt><br>
</tt><tt><br>
</tt></blockquote>
<br>
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.<br>
</blockquote>
<tt>I have not checked the details, but the fundamental issue is
this:</tt><tt><br>
</tt><tt><br>
</tt><tt>Windows domain controller databases store only the unsalted
<br>
MD4 password hash and/or the historic LM password hash, with <br>
most current systems configured to store only the MD4 hash. <br>
Thus any protocol that validates user identity via their <br>
knowledge of their domain password would need to either <br>
transmit the actual password to the domain controller or use <br>
some kind of cryptographic calculation where the computer <br>
closer to the user proves knowledge of the MD4 hash to the <br>
domain controller server. Historically, Microsoft has <br>
implemented multiple such cryptographic protocols:</tt><tt><br>
</tt><tt><br>
</tt><tt>NTLMv1 was the oldest such protocol, based on a using DES
in <br>
a silly way vastly similar to the LM protocol.</tt><tt><br>
</tt><tt><br>
</tt><tt>NTLMv2 was the next version, based mostly on HMAC-MD5, <br>
introduced in the late 1990s and still the strongest supported <br>
when the client computer is not (yet) joined to the domain.</tt><tt><br>
</tt><tt><br>
</tt><tt>Microsoft-specific variants/profiles of Kerberos V are used
<br>
between modern (post 2000) domain joined computers and the <br>
trusted domain controllers of the users login domain. I have <br>
not yet studied which formulas they are currently using/<br>
recommending/planning for this case, but they will all be <br>
constrained by the fact that the server knows nothing about <br>
the password except its MD4 hash or some value derived <br>
therefrom</tt><tt>.<br>
</tt><tt><br>
</tt><tt>Any upgrade of the password database to a new format would
<br>
either involve requesting a different form of the password <br>
(encrypted) after a successful MD4 based login or choosing <br>
a new form mathematically derived from the MD4 hash, such <br>
as foo(HMAC(SHA3-512, salt, MD4(UTF16LE(password)))). New <br>
client protocols could challenge with salt and engage in <br>
some zero knowledge proof of knowledge of HMAC(SHA3-512, <br>
salt, MD4(UTF16LE(password))) .</tt><tt><br>
<br>
Also note that the inherently low entropy of human-memorable <br>
passwords means that there is little security difference <br>
between starting from MD4(UTF16LE(password)) and starting <br>
from SHA3-1024(UTF8(password)), what matters most is the <br>
calculations done on top of that.<br>
<br>
</tt>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
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 </pre>
</body>
</html>