[Dshield] Crypto Question
Craig S. Wright
craig.wright at Information-Defense.com
Wed Mar 4 04:12:25 GMT 2009
Audit is required to be risk based. If we are talking a financial audit,
then it is mandated in law. Same for anything by a CPA firm (of course
others may not be covered).
The simple answer is to have them quantify the risk.
MD5 has known collisions, this is not the same as broken. It comes to risk
and they seem clueless on this. In fact, SSL2.0 is broken and should be
replaced by TLS (http://www.schneier.com/paper-ssl.pdf)
Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
Information Defense Pty Ltd
From: list-bounces at lists.sans.org [mailto:list-bounces at lists.sans.org] On
Behalf Of Jon Kibler
Sent: Wednesday, 4 March 2009 12:11 PM
To: General DShield Discussion List
Subject: [Dshield] Crypto Question
-----BEGIN PGP SIGNED MESSAGE-----
Is there a good crypto mailing list for "manager" level questions? The
Security Focus crypto list appears to be dead. Where would be a more
appropriate place to ask the follow question?
I am having a surreal conversation with a client's auditors regarding MD5,
and I need some advice about the issue. I understand the basic issues with
MD5, but I am having a hard time conveying the issue to the client in a way
that moves the discussion of the issue forward.
It all started with a clueless regulatory auditor finding that the client's
Linux servers used MD5 password hashes. The auditor told the client that
regulations prohibit the use of MD5 and that they had to use at least SHA-1
I explained to the client that SHA-1 was not an option. They could have DES,
which was highly insecure, or they could have the Linux standard MD5, which
was highly secure (assuming reasonable passwords), or they could have
BlowFish, which would cost them a lot of money to implement and would give
them a ridiculous degree of password security.
They contacted the auditors, whose response was "MD5 cannot be used because
MD5 is broken, and BlowFish is not a recognized standard so it cannot be
used. Since DES is a standard and it is not broken that is what you must
I tried to argue that was an assinie answer (but using more polite
phrasing), and got no where. I then tried some different tactics:
Comment: The issue with MD5 was not with password hashing, rather it was
with MACs, and the issue was essentially irrelevant for password hashing.
Response: Any and all uses of MD5 are prohibited.
Q: If MD5 is broken, why do you allow it for IPSec?
A: IPSec is not an MD5 algorithm.
Q: If MD5 is broken, why do you allow it in the VoIP phones for SIP?
A: SIP is not MD5.
Q: Your standard says that SSL 2.x and SSL 3.x are allowable protocols
(but TLS is not!), and both use MD5, so why is SSL allowed?
A: As long as the SSL certificates are not MD5, there is no use of MD5 by
Clearly, the auditors and/or regulators are clueless. If I can't win this
war, how can I at least bring this to a reasonable conclusion where my
customer has decent strength password hashing?
What would be a better list to ask this question on?
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC USA
My PGP Fingerprint is:
BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.
More information about the Dshield