Re: Time for new hash standard
>From: Ian Farquhar <[EMAIL PROTECTED]> >Sent: Sep 20, 2004 10:14 PM >To: "\"Hal Finney\"" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > [EMAIL PROTECTED] >Subject: Re: Time for new hash standard >At 05:43 AM 21/09/2004, Hal Finney wrote: >>I believe this is a MAC, despite the name. It seems to be easier to >>create secure MACs than secure hash functions, perhaps because there are >>no secrets in a hash, while in a MAC there is a secret key that makes >>the attacker's job harder. >Interestingly, a crypto-specialist from DSD (Australian NSA-equivalent) >said exactly this to me in 1997-1998. He called them "strange" functions >to design. I subsequently asked if they - which in the context meant the >tier one UKUSA agencies - had many hash functions developed for classified >uses. He indicated that they had quite a few MAC-style keyed functions, >but not many unkeyed hashes. Note that in the open world, there are very nice security proofs for existing MACs based on combining universal hashing with strong crypto components (such as block ciphers). I gather that the classified world isn't as enamored of security proofs as we are, but it's pretty easy to see that it's harder to find a colliding pair of messages when you don't know the internal state, for almost any nontrivial function. Even if you're doing a differential attack on the function, you can choose message blocks to make sure that your differential clears some rounds with probability one, and you get to do all your trial hashes offline, on your own equipment, rather than online on your intended victim's equipment. >Ian. --John - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Time for new hash standard
R. A. Hettinga wrote: > Luckily, there are alternatives. The National Institute of Standards and > Technology already has standards for longer - and harder to break - hash > functions: SHA-224, SHA-256, SHA-384, and SHA-512. They're already > government standards, and can already be used. This is a good stopgap, but > I'd like to see more. I haven't seen any discussion on constructions based on "universal hashing", like the UHASH underlying UMAC[1]. Can any cryptographers comment on this? UMAC seems like a particularly nice MAC, because it is supposedly provably-secure (to the extent that AES is) and benefits from hardware speedups to AES. -d [1] http://www.cs.ucdavis.edu/~rogaway/umac/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Time for new hash standard
At 05:43 AM 21/09/2004, Hal Finney wrote: I believe this is a MAC, despite the name. It seems to be easier to create secure MACs than secure hash functions, perhaps because there are no secrets in a hash, while in a MAC there is a secret key that makes the attacker's job harder. Interestingly, a crypto-specialist from DSD (Australian NSA-equivalent) said exactly this to me in 1997-1998. He called them "strange" functions to design. I subsequently asked if they - which in the context meant the tier one UKUSA agencies - had many hash functions developed for classified uses. He indicated that they had quite a few MAC-style keyed functions, but not many unkeyed hashes. This was all over a lunch to discuss SENECA, Oz's VLSI proposal to replace DES for sensitive-but-unclassified applications (64 bit keys, produced on an otherwise moribund 1.5u fab in Sydney). SENECA lost funding, basically due to internal politics and external commercial realities. I was trying to get them to release the algorithm in SENECA publicly, knowing the hardware implementation was failing in the marketplace, but was told it wasn't going to happen as it incorporated design features that DSD considered sensitive. The actual design came out of DSTO. Ian. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Time for new hash standard
Bruce Schneier wrote: > Luckily, there are alternatives. The National Institute of Standards and > Technology already has standards for longer - and harder to break - hash > functions: SHA-224, SHA-256, SHA-384, and SHA-512. They're already > government standards, and can already be used. This is a good stopgap, but > I'd like to see more. Russell Nelson suggested: > http://cr.yp.to/antiforgery.html#hash127 I believe this is a MAC, despite the name. It seems to be easier to create secure MACs than secure hash functions, perhaps because there are no secrets in a hash, while in a MAC there is a secret key that makes the attacker's job harder. Hal - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Time for new hash standard
> Luckily, there are alternatives. The National Institute of Standards and > Technology already has standards for longer - and harder to break - hash > functions: SHA-224, SHA-256, SHA-384, and SHA-512. They're already > government standards, and can already be used. This is a good stopgap, but > I'd like to see more. http://cr.yp.to/antiforgery.html#hash127 -- --My blog is at angry-economist.russnelson.com | Violence never solves Crynwr sells support for free software | PGPok | problems, it just changes 521 Pleasant Valley Rd. | +1 212-202-2318 voice | them into more subtle Potsdam, NY 13676-3213 | FWD# 404529 via VOIP | problems. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Time for new hash standard
<http://smh.com.au/cgi-bin/common/popupPrintArticle.pl?path=/articles/2004/09/20/1095532207966.html> Sydney Morning Herald Time for new hash standard By Bruce Schneier Comment September 20, 2004 - 9:09AM At the CRYPTO conference in Santa Barbara, CA, last month, researchers announced several weaknesses in common hash functions. These results, while mathematically significant, aren't cause for alarm. But even so, it's probably time for the cryptography community to get together and create a new hash standard. One-way hash functions are a cryptographic construct used in many applications. They are used in conjunction with public-key algorithms for both encryption and digital signatures. They are used in integrity checking. They are used in authentication. They have all sorts of applications in a great many different protocols. Much more than encryption algorithms, one-way hash functions are the workhorses of modern cryptography. In 1990, Ron Rivest invented the hash function MD4. In 1992, he improved on MD4 and developed another hash function: MD5. In 1993, the National Security Agency published a hash function very similar to MD5, called SHA (Secure Hash Algorithm). Then, in 1995, citing a newly discovered weakness that it refused to elaborate on, the NSA made a change to SHA. The new algorithm was called SHA-1. Today, the most popular hash function is SHA-1, with MD5 still being used in older applications. One-way hash functions are supposed to have two properties. One, they're one way. This means that it is easy to take a message and compute the hash value, but it's impossible to take a hash value and recreate the original message. (By "impossible" I mean "can't be done in any reasonable amount of time.") Two, they're collision free. This means that it is impossible to find two messages that hash to the same hash value. The cryptographic reasoning behind these two properties is subtle, and I invite curious readers to learn more in my book "Applied Cryptography." Breaking a hash function means showing that either - or both - of those properties are not true. Cryptanalysis of the MD4 family of hash functions has proceeded in fits and starts over the last decade or so, with results against simplified versions of the algorithms and partial results against the whole algorithms. This year, Eli Biham and Rafi Chen, and separately Antoine Joux, announced some pretty impressive cryptographic results against MD5 and SHA. Collisions have been demonstrated in SHA. And there are rumors, unconfirmed at this writing, of results against SHA-1. The magnitude of these results depends on who you are. If you're a cryptographer, this is a huge deal. While not revolutionary, these results are substantial advances in the field. The techniques described by the researchers are likely to have other applications, and we'll be better able to design secure systems as a result. This is how the science of cryptography advances: we learn how to design new algorithms by breaking other algorithms. Additionally, algorithms from the NSA are considered a sort of alien technology: they come from a superior race with no explanations. Any successful cryptanalysis against an NSA algorithm is an interesting data point in the eternal question of how good they really are in there. To a user of cryptographic systems - as I assume most readers are - this news is important, but not particularly worrisome. MD5 and SHA aren't suddenly insecure. No one is going to be breaking digital signatures or reading encrypted messages anytime soon with these techniques. The electronic world is no less secure after these announcements than it was before. But there's an old saying inside the NSA: "Attacks always get better; they never get worse." These techniques will continue to improve, and probably someday there will be practical attacks based on these techniques. It's time for us all to migrate away from SHA-1. Luckily, there are alternatives. The National Institute of Standards and Technology already has standards for longer - and harder to break - hash functions: SHA-224, SHA-256, SHA-384, and SHA-512. They're already government standards, and can already be used. This is a good stopgap, but I'd like to see more. 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. Most of the hash functions we have, and all the ones in widespread use, are based on the general principles of MD4. Clearly we've learned a lot about hash functions in the past decade, and I think we can start applying that knowledge to create something even more secure. Be
