Slashdot Mirror
SHA-3 Second Round Candidates Released
Jeremy A. Hansen writes "NIST just announced their selections for algorithms going to the second round of the SHA-3 competition. Quoting: 'NIST received 64 SHA-3 candidate hash function submissions and accepted 51 first round candidates as meeting our minimum acceptance criteria. We have now selected 14 second round candidates to continue in the competition. Information about the second round candidate algorithms will be available here. We were pleased by the amount and quality of the cryptanalysis we received on the first round candidates, and more than a little amazed by the ingenuity of some of the attacks. ... In selecting this set of second round candidates we tried to include only algorithms that we thought had a chance of being selected as SHA-3. We were willing to extrapolate higher performance for conservative designs with apparently large safety factors, but comparatively unforgiving of aggressive designs that were broken, or nearly broken during the course of the review. We were more willing to accept disquieting properties of the hash function if the designer had apparently anticipated them, than if they were discovered during the review period, even if there were apparent fixes. We were generally alarmed by attacks on compression functions that seemed unanticipated by the submitters.'"
I was a little worried by the plethora of submissions. I was worried it would take them forever to decide. But luckily they've been rather ruthless in culling for the third round. Given the data available on the The SHA-3 Zoo they chose wisely.
Personally, I think Skein is interestingly feature rich, which both worries and intrigues me. Looking it appears that all the features are built on a core in which the real security lies, so I'm not too worried. Skein's core in fact appears to be extremely simple.
Need a Python, C++, Unix, Linux develop
Don't attack the encryption: attack how it's used!
The World Wide Web is dying. Soon, we shall have only the Internet.
Pff. I'm already using SHA-256.
Congratulations.
We were generally alarmed by attacks on compression functions that seemed unanticipated by the submitters.
Just when you think Entropy's a bitch...
#fuckbeta #iamslashdot #dicemustdie
You fail, google came up with "first post" not "First Post". Please hash before you post, or google :P
e30830f3776f02798a92a2a7a2a6bce455b28e18
It would be less funny and harder to decode if I did this version.
MD5 isn't a hash function now?
This has all happened before:
http://slashdot.org/articles/04/08/17/0030243.shtml#9987007
You got the caps wrong though.
Nerd rage is the funniest rage.
Why didn't Whirlpool make the list of candidates? That sucker is fort knox.
One of my favourites (Blue Midnight Wish) made it through, and one of the others with a really cool name (SandSTORM) wasn't broken in the 1st round.
Yes, I know, that's NOT how to pick hash functions, but you've got to admit that cryptography isn't capturing the popular imagination at the present time, leaving data dangerously insecure. I believe that part of this is because most popular crypto-related functions (and cryptographic hashing is definitely one) have names that are a turnoff.
Once upon a time, computing was for "the Egg Heads" and anyone daring to mention computers was automatically One Of Them. The Apple made computing sexy and it became fashionable.
Cryptography has to do the same thing, if security is to be meaningful. Otherwise, it will remain for "Egg Heads Only" and we will continue to see horrific losses from naive and pathetic practices by people trying to avoid being tarred as geeky.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I was disappointed that TIB3 wasn't selected. It had a great performance profile and a lot of novel design features -- e.g., long-pipe, a message expansion function that couldn't easily be reversed, etc.
It doesn't matter how cool the name is: once the winner is picked it will be SHA-3, in the same way that Rijndael became AES. In fact, the name Rijndael had slipped my memory and I had to Google it - and I'm interested in crypto.
Besides, the general public might be able to name WEP and WPA as "types of encryption", but to hope for more than that, no matter how cool the name, is optimistic.
I'm quite surprised Rivest didn't make it to round 2. Could anybody share some details about this decision?
I've been doing a fair bit of reading about secure hashes recently... as I'm interested in one specific property of hash functions that, as far as I can tell, is not discussed as widely as I'd expect... While collisions seem to draw a lot of attention, they are not of particular interest to me... since collisions (for me) affect only performance - not security.
The closest term for what I'm interested in is preimage resistance - but, as far as I can tell, this property is often disregarded as it is considered implausible to reconstruct a large input from a small output.
In a context in which I'm interested, however, the input to my hash function is itself a hash. I'm interested to know if I can rely on attackers being unable to compute the inverse of the hash function. Is there any work on formally establishing that any hash function is 'one way'?
It is trivial to prove that a function is one way. If the input is from a larger domain than the output. ie a^b=c is one way. given c I cannot recover a and b. Of course this is not a good function to use for other reasons....
If however the input is the same length then its a little harder...The only way we know how to do is the way this competition is doing it. Propose a "one way" function, others then try and break it. Otherwise you need a collision which in this context is a bad thing due to reduced randomness. ie f(a)=b and f(a')=b which a b and a' are the same bit length.
The Grey Goo disaster happened 3 billion years ago. This rock is covered in self replicating machines!
3 Second Rule Candidates Released?
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
It's an open mathematical/theoretical computer science question about whether there can truly be a one way function with NP-hard computational bounds (which is probably what you mean). If P = NP then there are no one way functions. Many problems that are NP complete are not NP-hard for the vast majority of particular instances of the problem. Encryption algorithms based on NP-complete problems are generally easy to break because the particular problems that are generated have a relatively fast solution by the best algorithms.
In general, preimage resistance is equivalent to one-wayness for hash functions. This is clear because the straightforward way to generate a preimage of a hash is to find an input that generates the known output. The security implication is more obvious for HMACs; if you know only the output of a HMAC function and the function is not one-way, it is not secure for message authentication. Since all modern HMACs basically operate by hashing a secret key along with the message (which may be known by the attacker), I'd say you could consider modern hash functions to be one-way.
The ultimate SHA should have a hash space as large as the count of atoms in the universe - then you can just select the atom involved and use its assigned number. Of course, collisions between atoms might be an issue.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
Everything you say makes sense, and I'm familiar with this technical background.
If I were to re-phrase my question, in the context of your reply, I'd be asking if equivalences have been shown between known-hard problems and the inverse to standard HMACs.
The particular issue that interests me is extremely similar to (type-1) preimage... but it is slightly easier to break. T1-preimage requires me to find m where H(m) is known. In my specific situation, we also know the length of m - it's the same as H(m) - or, equivalently, it is longer than H(m) but all except length(H(m)) bits are known to the attacker.
This might sound uninformed, but it simply makes me feel uneasy that I can't find any work (from a theoretical perspective) to show how hard a problem this is for specific HMACs... just a hypothesis and an open challenge. This might be good enough for the day-to-day, but is it OK if trying to put together a system that I want to remain robust for 50 years or longer?
Hash functions in general are not meant to hash an input that is the same size as the output. That is essentially encryption. RSA will do this and is provably (or close enough anyway) secure. You can get the same functionality by encrypting with the public key (so it is verifiable, like a hash function) and just throwing the private key away.