--On March 21, 2008 12:50:26 -0400 Sam Hartman <hartmans-ietf@xxxxxxx> wrote:
I don't think md5 should be used for a new mechanism. Sha-1 is very widely available in C, Java and other languages. I think you may get significant pushback in ietf last call to the use of md5 in something new; I I know I'll be part of that.
From a theoretical security viewpoint, I would go with SHA-256 as it's best
available algorithm choice today.But a security mechanism that doesn't deploy provides zero incremental security to the community regardless of how strong the theoretical security happens to be.
So I consider the question "will this deploy?" significantly more important to the security of the mechanism than any particular choice of algorithm. On that basis, any security algorithm that is widely deployed and used in application-layer code (e.g. MD5, HMAC) has a big advantage over algorithms that have not deployed in application-layer code.
I know MD5 won't be a deployment barrier. I think SHA-1 won't be a deployment barrier. I think SHA-256 will be a deployment barrier.So I presently lean towards SHA-1, but I'd like statements from likely or potential implementers about the algorithms we're discussing. Here's my statement as an implementer:
I can commit to implementing this mechanism if it uses any combination of HMAC, MD5, SHA-1, iterated-hash, or PBKDF-2. I can not commit to implementing this mechanism if it uses SHA-256. SHA-256 isn't in my code toolkit, is not something I can code from scratch and finding a cross-platform way to use it that's thread & library safe and has a company approved OSS is not something I have investigated. I can't make a commitment until I investigate it.
- Chris