Defining Hash functions without security properties
The paradox in this situation is that the reason to define hash functions with no security properties is because many current hash functions has been found out to be considerably weaker than originally thought.
This has caused intense activities in security protocol standardisation, such as in the TLS WG in the IETF where TLS 1.2 recently updated TLS 1., adding the capability to negotiate and use a variety of algorithms, including a variety of hash algorithms. However, one not so great side effect of this transition from old hashes like MD5 and SHA-1, is that people in general believe that all use of these algorithms is bad.
But this is absolutely not the case. Some hashes used in protocols are not used to provide security, but simply to generate identifiers with low probability of collisions. A collision would cause ambiguity and hurt performance but would not be a security problem.
The point is that algorithm agility is painful. It often takes major updates to a protocol, not only to identify what algorithms that are being used, but to allow parties to declare what algorithms they support and to negotiate what algorithms that are to be used. We don’t want to go through this exercise for the algorithms that are not selected to provide security. To avoid confusion about for what purpose a hash algorithm is used, it could be really helpful if standard algorithms are available that are selected for their randomness but also for their lack of other security properties.
Eric Rescorla made an interesting presentation at the IETF Security Area Advisory Group at the IETF 73 meeting in Minneapolis 2008. This presentation is available here.
This has caused intense activities in security protocol standardisation, such as in the TLS WG in the IETF where TLS 1.2 recently updated TLS 1., adding the capability to negotiate and use a variety of algorithms, including a variety of hash algorithms. However, one not so great side effect of this transition from old hashes like MD5 and SHA-1, is that people in general believe that all use of these algorithms is bad.
But this is absolutely not the case. Some hashes used in protocols are not used to provide security, but simply to generate identifiers with low probability of collisions. A collision would cause ambiguity and hurt performance but would not be a security problem.
The point is that algorithm agility is painful. It often takes major updates to a protocol, not only to identify what algorithms that are being used, but to allow parties to declare what algorithms they support and to negotiate what algorithms that are to be used. We don’t want to go through this exercise for the algorithms that are not selected to provide security. To avoid confusion about for what purpose a hash algorithm is used, it could be really helpful if standard algorithms are available that are selected for their randomness but also for their lack of other security properties.
Eric Rescorla made an interesting presentation at the IETF Security Area Advisory Group at the IETF 73 meeting in Minneapolis 2008. This presentation is available here.