JustinT wrote: |
Perhaps this need for strategic variety requires an initiative. Maybe a design-by-contest; it worked exceptionally well for the AES selection process. |
Bruce Schneier wrote: |
I'd like to see NIST orchestrate a worldwide competition for a new hash function, like they did for the new encryption algorithm, AES, to replace DES. NIST should issue a call for algorithms, and conduct a series of analysis rounds, where the community analyzes the various proposals with the intent of establishing a new standard. |
mxb wrote: |
Yet again a seemingly silent period from you, brought to an end with a well written post.
|
mxb wrote: |
It is true that the media has overblown the whole hash function attacks to generalize that a large proportion of the cryptographic systems in use are now insecure. It is also much more true that you should never rush the implementation stage of a cryptographic system. Security takes time to implement correctly, and ever advancing deadlines do nothing to help the process. |
mxb wrote: |
I agree that the majority of the hash functions in use at the moment are very similar in design, and that needs to change. The most interesting thing I found about your post was that you are suggesting that a new standard hash function should be found by a 'trial-by-competition', much like the AES standard was found. |
mxb wrote: |
I didn't realize that so many cryptographers liked this method of choosing a standard. I found it interesting at first, but after some thought I did come to the conclusion that it would probably result in the best method being chosen for the job. It's definitely a much better method that a standards committee, where everyone has to agree. |
Amitabh wrote: |
Out of curiosity, do we know of even a single instance of collision in MD5? (I mean does anyone explicitly have two values m1 and m2 such that MD5(m1)=MD5(m2) ?) I guess from the definitions of MD5, it may be possible to manually construct two such values working backwards from somewhere in the "middle" of the hash.
|
Amitabh wrote: |
Also, I want to know if this sort of hash function is possible: (a) Given a specific hash value it is hard to find a collision (b) It is easy to generate chosen hash values with collisions |
Quote: |
* Vanilla Hash functions are inherently insecure. They are non-random and cannot be considered secure. The only use of a hash function should be to "map" elements to a finite set for some higher level cryptographic operation that is independently secure (without the hash). Example the recent published schemes of Boneh, Boyen etc that do not rely on random oracles. |
Quote: |
* Keyed hash functions can be used instead of normal hash for people and organizations who are very paranoid. The "key" is generated and made public by a trusted central authority so that anyone can authenticate files using the hash function. The central authority peroidically changes the key so that the hash not only authenticates the file, but also the time at which the file was hashed. |
Quote: |
Out of curiosity, do we know of even a single instance of collision in MD5? (I mean does anyone explicitly have two values m1 and m2 such that MD5(m1)=MD5(m2) ?) I guess from the definitions of MD5, it may be possible to manually construct two such values working backwards from somewhere in the "middle" of the hash. |
Quote: |
Also, I want to know if this sort of hash function is possible: (a) Given a specific hash value it is hard to find a collision (b) It is easy to generate chosen hash values with collisions |
Quote: | ||
I'm not quite sure I understand your definitions of (a) and (b) |
output generated using printer-friendly topic mod, All times are GMT + 2 Hours