RE: [Cfrg] Re: [saag] Bad day at the hash function factory

[Matthew_Chalmers at bankone.com]

I for one think your classification idea is good. You also bring up good points about certificate replacement; there is much to consider before outright abandoning such a pervasive algorithm.

Regarding "good crypto practice," I once heard someone say it is "hard." On the one hand, we can say MD5 should/must not be used, period. But what if the (only) alternative turned out just as broken tomorrow? Obsolete it too? What do we have then? On the other hand, we could acknowledge MD5 as still suitable for certain applications, e.g. HMAC-MD5, digesting human-processed messages (e.g. text email, since the liklihood of an attacker finding any reasonable message with the same digest is low, i.e. the literal attack of "Alice pay Bob $10" replaced by "Alice pay Bob $100" is unlikely), or any low-value applications where speed and/or size matter; but seems clear we don't want to use plain MD5 for digesting computer-processed messages (e.g. integrity-checked device commands, or perhaps passwords) or any highly-entropic source such as key (even if human-processed, it could be difficult or impossible to tell whether "039AB03CF8DD32AC" or "FF03ABC3228CAF31" is the real key if they hash the same). The former is easy, and perhaps dangerous if we "run out" of good algorithms; the latter is hard, and perhaps dangerous if further weaknesses are found or if programmers simply implement inappropriately.

Cryptologists will do what they feel is right based on their understanding of the issues but they sometimes only understand the cryptologic ones; laypersons will do what they're told (by IETF, NIST, etc.) unless they misunderstand the guidance due to complexity or gray areas, but they sometimes use what's readily available even if it's only the bare minimum. So we can either tell them "don't use MD5 at all" or "only use MD5 for this, that, and another thing."

We don't have a perfect algorithm ideally suited to all needs--cryptologists', implementers', users'--so we have complexity, gray area, and degrees of risk. We need a balance between them. Perhaps the classifications below will do, or perhaps we need to define appropriate applications for each algorithm--not simply that encrypting is for confidentiality, hashing is for integrity, etc. but as I said above, MD5 is for integrity of human-processed (or processable) messages such as text email but not highly-entropic, computer-processed messages such as key.

P.S. Thanks to James H. and Hugo K. for their clarifications, and to David M. for pointing us to links to both their messages.

-----Original Message-----
From: saag-bounces at mit.edu [mailto:saag-bounces at mit.edu]On Behalf Of
Hallam-Baker, Phillip
Sent: Thursday, August 26, 2004 1:32 PM
To: 'Steven M. Bellovin'; Hughes, James P
Cc: 'kent at bbn.com'; 'cfrg at ietf.org'; 'saag at mit.edu'
Subject: RE: [Cfrg] Re: [saag] Bad day at the hash function factory 


I think that we should track status of crypto algs independently of their
standards status. In particular I think that we should distinguish between
Recommended and Acceptable status.

New applications should specify algorithms with Recommended status
Continued use of algorithms with Acceptable status should not raise concern.


So I would classify as follows:

Proposed: SHA-2
Recommended: SHA-1, HMAC-SHA1, RSA-2048, RSA-4096, AES, DH-1024
Acceptable: HMAC-MD5, RSA-1024, 3DES, DSA, DH-512, RC4
Depricated: IDEA, RSA1024+MD5
Obsolete: MD4, MD5, RSA-512, DES

The reason that I distinguish between Depricated and obsolete is that there
are uses of RSA signatures with MD5 hash that are still acceptably secure
and the applications concerned do not support SHA1. The reason I put DSA as
acceptable rather than recommended is that it does need a good random seed,
the key size is small and it is unlikely at this point to see much use.

RC4 has been compromised by Shamir & co, but as a general rule I don't think
any stream cipher should ever get a higher status than acceptable. A stream
cipher always allows a person who has a plaintext and ciphertext
corresponding to a key to encode or decode all messages with that key that
are shorter or the same size. In effect all stream ciphers are vulnerable to
a trivial form of known plaintext attack, the attack does not reveal the key
but this is not necessary.

I do not feel confident in recommending moving to SHA2 at this point. Before
jumping I want to see that the place we are going to is better than where we
left. SHA2 is not currently widely used. If it turns out that the recent
cryptanalysis of SHA1 is also applicable to the structures used in SHA2 then
the rationale for a change is lost. I would feel happier moving to a hash
function based on AES encryption (which i had eroneously assumed had been
the point of the SHA2 work).

I think that after the Crypto 2004 results sink in it would make sense for
NIST to be asked to hold another contest for a hash function standard,
alternatively if NIST want to make SHA2 a contest entry then someone else
should organize.


I would prefer that any statements about certificates be carfeully thought
through since the criteria applicable to certs are very different to the
criteria applicable to applications.

In particular root certificates have to exist for a very long time and
premature expiry of certs is itself a huge problem that creates security
issues. Over the past few days I have been looking into the implications of
hash function use on root certs, I don't think that there are any. Once the
root is distributed the hash and signature have done their work.

If a hash function is vulnerable then there is a vulnerability due to the
fact that the algorithm is accepted at all. What this comes down to is that
we should not revoke root certs because the hash is bad, nor is this
actually possible since the attacker could manipulate the serial number.
What we should do instead is to revoke algorithms.

The concerns for end entity certs are much less of an issue since the expiry
interval is usually three years or less. There are SSL products in use that
only recognize MD5. RSA+MD5 is still secure for cert use under controlled
circumstances.


What this comes down to is that people should not look to the actions of CAs
for guidance as to what is good crypto practice. Good security practice
requires us to be conservative on both ends of the curve. When we distribute
new roots these should have a very long lifetime and use recommended
strength algorithms.

As far as process goes something seems to be broken. It should be very hard
to push algorithms up the hill but easy to roll them back down. The IETF
process is equally slow in both directions and all decisions are
concentrated in a body where only two members have positions that qualify
them to make an opinion.


> -----Original Message-----
> From: cfrg-bounces at ietf.org [mailto:cfrg-bounces at ietf.org]On Behalf Of
> Steven M. Bellovin
> Sent: Thursday, August 26, 2004 11:46 AM
> To: Hughes, James P
> Cc: 'saag at mit.edu'; 'cfrg at ietf.org'; 'kent at bbn.com'
> Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory 
> 
> 
> In message 
> <151A63B4E33B4F49896AC6D1BA788A6E15C57F at EXCHVS2.louisville.stortek.c
> om>, "Hughes, James P" writes:
> >
> >Thanks Steve [Bellovin] for the "ad on" statement. I would 
> like to agree and
> >even suggest that it goes without saying that you may want future new
> >applications of HMAC to pass over MD5 (for SHA-x where x>0) 
> if they have the
> >option. 
> >
> 
> I was asking a question, to see what the sense of the 
> community is -- and
> I've gotten very few responses.  Certainly, I have my own 
> opinion -- I 
> don't think we should have any new specs based on MD5 except for 
> HMAC-MD5 -- but I don't think that that's completely up to 
> me.  (I even 
> saw one private response advocating retaining MD5.)
> 
> 		--Steve Bellovin, http://www.research.att.com/~smb
> 
> 
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg at ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
> 
_______________________________________________
saag mailing list
saag at mit.edu
https://jis.mit.edu/mailman/listinfo/saag


**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************


_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg