Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

SHA-3 Finalist Candidates Known

timothy posted more than 3 years ago | from the not-enough-like-line-noise dept.

Encryption 194

Skuto writes "NIST just announced the final selection of algorithms in the SHA-3 hash competition. The algorithms that are candidates to replace SHA-2 are BLAKE, Grøstl, JH, Keccak and Skein. The selection criteria included performance in software and hardware, hardware implementation size, best known attacks and being different enough from the other candidates. Curiously, some of the faster algorithms were eliminated as they were felt to be 'too fast to be true.' A full report with the (non-)selection rationale for each candidate is forthcoming."

cancel ×

194 comments

Sorry! There are no comments related to the filter you selected.

SHA-SHA-SHA-KE YOUR BOOTY !! (0, Offtopic)

Anonymous Coward | more than 3 years ago | (#34520296)

Yeah, man !! Do it to it !!

Re:SHA-SHA-SHA-KE YOUR BOOTY !! (5, Funny)

larry bagina (561269) | more than 3 years ago | (#34520680)

That's funny, but SHAKEs ("elder") are arabic, SHAs ("king") are persian/iranian. There is a difference and they get mad when you confuse them. They all look alike to me, but whatever.

For those of us that didn't read the article, wikileaks revealed that the SHA has terminal cancer and will die soon. That's why they're looking for a new SHA-3. The SHA is kind of like the Dalai Lama, but with a unix greybeard. I'm glad they've narrowed down the candidates. Hopefully, the next one will bring peace in the middle east.

Re:SHA-SHA-SHA-KE YOUR BOOTY !! (2, Funny)

Anonymous Coward | more than 3 years ago | (#34520718)

Sheik Yerbouti?

Re:SHA-SHA-SHA-KE YOUR BOOTY !! (1)

Ethanol-fueled (1125189) | more than 3 years ago | (#34521400)

Sheik Yerbouti(Peace Be Upon Him) died of prostate cancer in 1993.

:(

Re:SHA-SHA-SHA-KE YOUR BOOTY !! (2)

morgan_greywolf (835522) | more than 3 years ago | (#34520934)

For those of us that didn't read the article, wikileaks revealed that the SHA has terminal cancer and will die soon.

SHA-1 has had terminal cancer a very long time: it was cracked over 4 years ago [h-online.com] . Anything Wikileaks may have revealed about SHA-1 is very old news indeed.

Re:SHA-SHA-SHA-KE YOUR BOOTY !! (4, Informative)

Martin Blank (154261) | more than 3 years ago | (#34521070)

SHA-1 was not "cracked." A weakness was found in it that reduced the strength by 2^11 to 2^69 instead of 2^80 when conducting preimage attacks. Even on specialized hardware, this is not a practical attack, requiring thousands of years to come up with a message that hashes to the same value. Papers since then have found variations on the weakness, but they have only been demonstrated in reduced-round variants of SHA-1, not in full implementations due to the processing power required.

The weakness was recognized as a potential problem, hence the recommended move to SHA-2, particularly the stronger variants of it. The SHA-3 competition was born out of concern that SHA-2 could suffer from similar weaknesses, which may doom the SHA-3 contestants that draw from SHA-2 at a political level if not a technical level.

Re:SHA-SHA-SHA-KE YOUR BOOTY !! (2, Informative)

Anonymous Coward | more than 3 years ago | (#34521280)

Wrong. The same year (2005) improvements reduced the complexity to 2^63. See http://www.rsa.com/rsalabs/node.asp?id=2927

Also, the attack was for finding collisions, not preimage attacks. A preimage attack would be more devastating, but collisions still allow for faking certificates and checksums, depending on the protocol.

SHA-1 might not be broken, but it's about as close to being broken as any crypto primitive can be without being official broken. Everybody should have begun the process of moving away from SHA-1 in 2005.

Re:SHA-SHA-SHA-KE YOUR BOOTY !! (0)

Anonymous Coward | more than 3 years ago | (#34521404)

You mean 2^69 instead of 2^80 for collision attacks.

A preimage attack would still take 2^160 calls.

"Too fast to be true" (4, Insightful)

MrEricSir (398214) | more than 3 years ago | (#34520328)

Well that's mathematically sound reasoning!

Re:"Too fast to be true" (4, Insightful)

icebike (68054) | more than 3 years ago | (#34520380)

Exactly my reaction.

Is this a beauty contest or what?

There may be some tendency to think that something that hashes too quickly would be trivial, but without even a glance at the methodology and a modicum of trials this is just like assuming the cute girl is an air-head without so much as a conversation.

Who are these guys anyway? You expect better from NIST.

Re:"Too fast to be true" (1)

PopeRatzo (965947) | more than 3 years ago | (#34520816)

Beauty contest? Nah, this is fantasy football. Maybe Dancing with the Stars.

Anybody know what the point spread is on this SHA-3 hash competition? I'd like to get a bet down before the line moves.

Re:"Too fast to be true" (0)

Anonymous Coward | more than 3 years ago | (#34521396)

Don't you mean before the line is shifted/xor'd? :P

SHAs decrypts just like a woman? (1)

Zero__Kelvin (151819) | more than 3 years ago | (#34520932)

You didn't think that when sha gave up the goods that fast that you were the only one sha was giving it up to, did you?

Re:"Too fast to be true" (3, Insightful)

nedlohs (1335013) | more than 3 years ago | (#34521166)

You believe what you read in a slashdot summary???

Re:"Too fast to be true" (1)

ocdscouter (1922930) | more than 3 years ago | (#34521750)

You're right. It looks like it was written too quickly to be accurate.

Re:"Too fast to be true" (4, Informative)

Skuto (171945) | more than 3 years ago | (#34521944)

"We preferred to be conservative about security, and in some cases did not select algorithms with exceptional performance, largely because something about them made us “nervous,” even though we knew of no clear attack against the full algorithm."

William Burr, NIST

Re:"Too fast to be true" (2, Insightful)

Surt (22457) | more than 3 years ago | (#34521192)

Technically, if your hash algorithm is too fast, it gets easier to brute force. So it isn't completely unscientific.

Re:"Too fast to be true" (1)

swillden (191260) | more than 3 years ago | (#34521426)

Technically, if your hash algorithm is too fast, it gets easier to brute force. So it isn't completely unscientific.

Only if the input is small, which translates to "only if the protocol designer is clueless". Also, you can always make a fast algorithm slower by iterating it, so your point is irrelevant.

Re:"Too fast to be true" (2)

moderatorrater (1095745) | more than 3 years ago | (#34521980)

It's not unreasonable to leave out an algorithm that's as secure mathematically as the others as far as we can tell but that has a concerning characteristic. Previously, they've eliminated competitors for having simple mathematical representations and things like that. Since those algorithms were no more secure than the ones without the worrisome attribute, they could be eliminated without much problem. Remember, these are security guys, so they're paranoid about stuff like that.

I'm a little curious about that portion of the summary, though, since one of Skein's distinguishing features is that it runs nearly as fast on a processor as it would on specialized hardware due to the way that it's designed. If those algorithms were much faster than that then I would probably agree with the committee that the speed was suspicious.

Re:"Too fast to be true" (1)

Haedrian (1676506) | more than 3 years ago | (#34520384)

Probably so that brute-forcing the plaintext never sounds like a good idea.

Yeah I know that the increase is exponential (based on the string length) - but if you only do dictionary words... you'll still hit a few passwords.

Re:"Too fast to be true" (-1, Offtopic)

icebike (68054) | more than 3 years ago | (#34520490)

But a hash is just a hash. Its not designed as an encryption tool. It is predominantly used to determine if two blocks of arbitrary input are equal.

Was the binary file corrupted in transit? Compare the hash of the Original to the hash of the copy.

There are some cryptographic uses of hashs but they are tangential for the most part.

Re:"Too fast to be true" (4, Insightful)

Omnifarious (11933) | more than 3 years ago | (#34520572)

Tangential? What are you talking about? The cryptographic uses of hashes are the whole reason SHA-1, SHA-2 224,256,384,512 were created in the first place. It's also the reason the competition is being run.

I would also submit that your use case is not as security insensitive as you might think.

Re:"Too fast to be true" (5, Informative)

Anonymous Coward | more than 3 years ago | (#34520598)

There are some cryptographic uses of hashs but they are tangential for the most part.

This is the Secure Hash Algorithm - 3 selection competition. The cryptographic uses are pretty much at the forefront of the judges' minds.

A perfectly acceptable hash for error correction purposes can be doomed for cryptographic purposes. For example, being able to find "a different plaintext input that would have given the same hash as input X" is not a problem for an error correction hash provided that the pair of inputs are not similar (and so transmission errors are unlikely to turn one into the other). However it would make many uses of cryptographic hashes totally unviable.

Re:"Too fast to be true" (0)

Anonymous Coward | more than 3 years ago | (#34520694)

are you daft? cryptographic use is the POINT of the SHA-3 competition

Re:"Too fast to be true" (1)

Darinbob (1142669) | more than 3 years ago | (#34520730)

Those examples are where you just want a hash algorithm. You want a SECURE hash algorithm for extra security. Ie, not to tell if the file was corrupted in transmit, but whether someone has hacked the server and put up a compromised version of the software, or that a certificate is valid, or that the bank transfer order is valid, or that the order to launch really came from the POTUS.

Re:"Too fast to be true" (2, Insightful)

Anonymous Coward | more than 3 years ago | (#34521554)

checksum != hash table function != cryptographic hash != hashish

Re:"Too fast to be true" (1)

moderatorrater (1095745) | more than 3 years ago | (#34521986)

The SOAP WSSE standard uses SHA-1 for authentication and all password storage should be hashes. If all your doing is a checksum, then use something faster than SHA, you're using a sledgehammer to open a walnut.

Re:"Too fast to be true" (2)

LainTouko (926420) | more than 3 years ago | (#34522010)

If you're only concerned about accidental corruption, you should use a CRC, which will be much faster than a cryptographic hash. Spending a load of extra CPU time on acquiring good cryptographic properties is silly if you're not interested in any cryptographic properties.

Re:"Too fast to be true" (1)

Arancaytar (966377) | more than 3 years ago | (#34520500)

Short strings are supposed to be salted anyway.

Re:"Too fast to be true" (4, Funny)

Anonymous Coward | more than 3 years ago | (#34520460)

what if they were optimized? would sleep(10) make them finalists?

Re:"Too fast to be true" (2)

jewelises (739285) | more than 3 years ago | (#34520672)

When you want to slow down a fast hash you just do it a lot of times. See PBKDF2, for example.

Re:"Too fast to be true" (2)

Fry-kun (619632) | more than 3 years ago | (#34520862)

FTFA: "Cryptologist Ron 'The R in RSA' Rivest withdrew his MD6 process - it was highly-rated but conspicuously sluggish"

Someone simply misread or misunderstood "sluggish" for "too fast"

Re:"Too fast to be true" (0)

Anonymous Coward | more than 3 years ago | (#34520926)

No it was really really slow.

Re:"Too fast to be true" (0)

Anonymous Coward | more than 3 years ago | (#34521226)

Actually it was just too slow.

Yes, but will Simon say? (-1)

Anonymous Coward | more than 3 years ago | (#34520354)

Which one will be the next SHA-3 Idol?!

Bruce Schneier (2)

Jackanackanoree (1607689) | more than 3 years ago | (#34520362)

Bruce Schneier helped to make skein http://www.schneier.com/skein.html [schneier.com]

Re:Bruce Schneier (1)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34520410)

But only he is capable of using it for lossless compression...

Re:Bruce Schneier (0)

Anonymous Coward | more than 3 years ago | (#34520428)

Rumors has it that djb has broken skein, though.

Re:Bruce Schneier (1)

Martin Blank (154261) | more than 3 years ago | (#34521092)

That may well be true -- djb is one of the smartest guys out there -- but if he hasn't provided the proof to either NIST or the Skein team, it shouldn't really factor into the results.

Re:Bruce Schneier (1)

e9th (652576) | more than 3 years ago | (#34521206)

I see that his own entry, CubeHash, [wikipedia.org] made it into Round Two, but not the finals.

good! (3, Funny)

larry bagina (561269) | more than 3 years ago | (#34520376)

Our lawyers won't let us convert our svn repositories to git since git uses SHA-1, which is known to be vulnerable to collisions. Hopefully, they pick a SHA-3 soon!

Re:good! (0)

Anonymous Coward | more than 3 years ago | (#34520408)

Why do your insec^Wlawyers even have a say in the matter?

Re:good! (0)

Anonymous Coward | more than 3 years ago | (#34520464)

i'm assuming it's a joke. if they're waiting for a hash without collisions they'll be waiting a while...

Re:good! (2)

icebike (68054) | more than 3 years ago | (#34520494)

And if they were waiting for a lawyer who understood the issue they would be waiting longer.

Re:good! (0)

Anonymous Coward | more than 3 years ago | (#34520558)

I'm sure you know this, but for the record, when stupid people say a hash function "has teh collisions", they intend to say that it is easier to find collisions than to randomly stumble over them in a brute-force attack. Collisions are a natural necessity of a hash function.

Re:good! (1)

arth1 (260657) | more than 3 years ago | (#34520606)

Collisions are a natural necessity of a hash function.

Not necessarily, no. If the hash is bigger than the hashed data, that's not a certainty.

And yes, hashes longer than the hashed data can be useful too. You don't have to look further than /etc/shadow or a .htpasswd file for practical examples.

Re:good! (0)

Anonymous Coward | more than 3 years ago | (#34520810)

True. That said, when you hash data smaller than the hash, you are usually using regular hash functions with collisions in their original intended use case(DES, MD5, Blowfish).

Re:good! (1)

Haedrian (1676506) | more than 3 years ago | (#34520438)

I find the suggestion that Lawyers make purely technical decisions in the company to be incredibly confusing.

Isn't this the sort of decision that the IT staff take?

Re:good! (1)

hedwards (940851) | more than 3 years ago | (#34521146)

Eh, is letting lawyers make purely technical decisions really that much worse than letting the accountants or the non-IT managers do it?

Re:good! (1)

CoderJoe (97563) | more than 3 years ago | (#34520450)

I don't understand why your lawyers have a say in the matter, but I think you are out of luck. ANY hash function is going to have collisions. That is just the nature of the beast. The only thing you get from SHA-2 or SHA-3 over SHA-1 is better probability of not colliding, and a more difficult time of deliberately creating a collision.

Re:good! (1)

noidentity (188756) | more than 3 years ago | (#34520470)

Actually, some hash functions have no collisions, for example one that returns the entire input as the hash. They should use that as their git hashes. Oh, wait...

Re:good! (3, Insightful)

John Hasler (414242) | more than 3 years ago | (#34520506)

The only thing you get from SHA-2 or SHA-3 over SHA-1 is better probability of not colliding, and a more difficult time of deliberately creating a collision.

And the risk of accidental collisions is negligible while deliberate collisions are irrelevant to the use of hashes in Git as they have no security-related function there.

Re:good! (5, Informative)

Anonymous Coward | more than 3 years ago | (#34520692)

The only thing you get from SHA-2 or SHA-3 over SHA-1 is better probability of not colliding, and a more difficult time of deliberately creating a collision.

And the risk of accidental collisions is negligible while deliberate collisions are irrelevant to the use of hashes in Git as they have no security-related function there.

Actually SHA-1s do have a security related function. I don't remember where I read this explanation, but it is plausible, although difficult.

SHA-1s are used to uniquely identify the object in GIT. An attacker could write a new patch and generate a collision for it. The attacker would then submit the good patch and get the maintainers to accept the patch and sign it with their GPG key. The attacker would then create a rogue mirror site and replace the good patch with the malicious collision. Because the SHA-1s would match this would not invalidate the GPG signature of the maintainers. If anyone went to the rogue site they would receive a poisoned copy of the git repository that appears cryptographically valid.

Now the collision would be pretty easy to see if the replaced object was plain source code, because generating a collision usually involves writing out a whole bunch of garbage to a file. However if the replaced object was a binary blob for a driver or a checked in library or something, then it would be much less obvious.

Mod parent up. (0)

John Hasler (414242) | more than 3 years ago | (#34520798)

n/t

Re:Mod parent up. (0)

John Hasler (414242) | more than 3 years ago | (#34521222)

Um, I meant mod the AC's response to me up, not my comment.

Re:good! (2)

Omnifarious (11933) | more than 3 years ago | (#34521100)

People are always saying "Oh, collisions aren't important for this application.". And they're almost always wrong. Stop trying to be a security expert and just quit using an algorithm when it's broken instead of coming up with excuses not to change it.

It will never work (1)

Zero__Kelvin (151819) | more than 3 years ago | (#34521148)

"An attacker could write a new patch and generate a collision for it. The attacker would then submit the good patch and get the maintainers to accept the patch and sign it with their GPG key. The attacker would then create a rogue mirror site and replace the good patch with the malicious collision."

If you use source code it will not compile. If you use a blob it will not run. Even if those things were not true, whatever you came up with would certainly not do what you wanted it to do.

Re:It will never work (1)

Omnifarious (11933) | more than 3 years ago | (#34521212)

That's an ignorant defense. There is a really nice example of someone creating two Postscript files that both generate perfectly intelligible pages that contain the same hash. Doing this and still hiding the exploit just requires sticking it in code that nobody will review. You have the exploit code and the non-exploit code in the same file and have a decision based on a bunch of random garbage that's different in the two files.

Code is NOT English prose (FTFY) (1)

Zero__Kelvin (151819) | more than 3 years ago | (#34521248)

Let me know when the replacement page says exactly what they want it to rather than merely something that appears intelligible, and using SHA-1 rather than MD5. Don't forget that changing a period to a semicolon in a page of text has little implication, but in source code it changes everything completely.

Re:Code is NOT English prose (FTFY) (1)

Omnifarious (11933) | more than 3 years ago | (#34521410)

I google for 'md5 postscript attack' and found this: Hash Collisions (The Poisoned Message Attack) [uni-mannheim.de] . Using this technique they were able to make either document say exactly and precisely what they wanted it to say. The postscript merely makes a decision about what display code to run based on the contents of some garbage in the middle of the file that's different in each file. The rest of both files are the same.

git objects don't live in a vacuum (1)

Zero__Kelvin (151819) | more than 3 years ago | (#34521474)

You are ignoring the fact that git doesn't blindly store the object and hash independently. It is a hierarchical tree of objects, each with a size element. If you plug your new object in I believe it will break the hashes of the other objects. For example a directory is an object with a hash that includes the size of the object. For this reason I am almost certain that your object must not only have the same hash, it has to be the same size as well.

Re:git objects don't live in a vacuum (1)

PseudonymousBraveguy (1857734) | more than 3 years ago | (#34522016)

So you have a situation where an attacker may substitute a patch with a malicious patch. That may or may not invalidate other hashes, depending on several circumstances of the attack, which are basically speculation. You can now either simply change the hash function, eliminating the problem, or ignore the problem and hope nothing will go wrong. Which option is better from a security standpoint?

Re:It will never work (1)

pavon (30274) | more than 3 years ago | (#34521308)

That isn't an issue at all. Most collision generating attacks append filler data to the end of the desired file to get the desired hash. For source code you just insert the filler data in comment at the end of the file. It is a trivial modification to the existing algorithms.

Re:It will never work (1)

Zero__Kelvin (151819) | more than 3 years ago | (#34521402)

I believe that you need to have to have a git object [git-scm.com] that is the same size to replace your target object with, or git will sense the corruption. I don't have time to look more closely at the moment, but I trust that Linus did ;-)

Re:It will never work (1)

pavon (30274) | more than 3 years ago | (#34521792)

Needing to match the length of the original object doesn't make the problem that much harder (unless the desired code is already close in length to the original code). In fact many collision attacks are designed for fixed size inputs, because it makes things easier.

Requiring valid formatting of the file is not a hard problem compared to the much more fundamental problem of finding a practical preimage attack in general. If SHA-1 were broken (it isn't yet), then it would certainly be plausible to attack git in the manner that the AC described.

Re:good! (1)

TheLink (130905) | more than 3 years ago | (#34521262)

Now the collision would be pretty easy to see if the replaced object was plain source code, because generating a collision usually involves writing out a whole bunch of garbage to a file.

That assumes people would actually 1) look at the source code and 2) notice the problem.

In most source code you can insert comments. So the whole bunch of garbage can be commented out.

Re:good! (3, Insightful)

Mysteray (713473) | more than 3 years ago | (#34522018)

An attacker could write a new patch and generate a collision for it. The attacker would then submit the good patch and get the maintainers to accept the patch and sign it with their GPG key. The attacker would then create a rogue mirror site and replace the good patch with the malicious collision.

That would definitely win you the prize for "the most absurdly over-complicated and difficult way of pwning a Linux box".

Why don't you just watch [Full-disclosure] for the 0-day of the week like everyone else?

The bear only has to be faster than the first of the two hunters.

One of the many, many reasons why IANAL (1)

Zero__Kelvin (151819) | more than 3 years ago | (#34521002)

"Our lawyers won't let us convert our svn repositories to git since git uses SHA-1, which is known to be vulnerable to collisions."

That makes perfect sense. Better to use an SCM that gives no assurance that what you get back is the same as what committed [youtube.com] than use one that was designed in large part to fix that known problem with Subversion, and has been used to make hundreds of thousands of changes to one of the biggest software products on the planet without any such problem.

Re:One of the many, many reasons why IANAL (1)

CoderJoe (97563) | more than 3 years ago | (#34521478)

I'm going to have to ask for more concrete demonstrations of that claim than "Linus said so" before I believe it.

Re:One of the many, many reasons why IANAL (2)

Zero__Kelvin (151819) | more than 3 years ago | (#34521518)

"I'm going to have to ask for more concrete demonstrations of that claim than "Linus said so" before I believe it."

Damn. I was just about to go to sleep too. Now I have to stay up all night worrying what you think, and how I'm going to do that thinking for you 8-(

Re:One of the many, many reasons why IANAL (1)

CoderJoe (97563) | more than 3 years ago | (#34521870)

You're trying to make a persuasive argument that using SVN is a bad choice, and the only thing you have provided to back that claim up is a video of Linus saying the exact same statement you made. So far, I have not found any evidence to back up this argument.

I'm going to guess your (and Linus') reasoning is that because git has the SHA-1 hashes, and checks them, that you get the same data out as you put in. I have not seen anything that ensures that git will not silently overwrite or discard data in the case that there is a hash collision.

Yes, the probability is small, but that does not mean you can ignore it completely. There is a small probability that a hard drive will be DOA (yes, gigantic compared to hash collisions, but bear with me). However, I have had the bad luck of having two different model drives, purchased 9 months apart be bad out of the box. This is without buying large quantities of drives. Just because some is statistically improbable does not mean that it cannot happen.

Re:One of the many, many reasons why IANAL (1)

Anonymous Coward | more than 3 years ago | (#34521988)

I think linus may have referred to svn backend implementations which at that time used Berkeley db which had a nasty corruption habit or fsfs which was their in house project which had always had a lot of shortcomings and was generally an immature project

(look, they say this themselves, they're going to throw it away for the next big release iteration in favor of WC-NG)

it has to be said that I've used svn for many years now without a problem.

Skein (1)

betterunixthanunix (980855) | more than 3 years ago | (#34520466)

Skein is broken, last I heard...

Re:Skein (2)

Omnifarious (11933) | more than 3 years ago | (#34520604)

I've been following the progress on the SHA-3 Zoo [tugraz.at] and I haven't seen anything indicating Skein is broken. I've been following Skein with particular interest because I like how it can be tweaked in various ways to serve particular needs.

Re:Skein (0)

Anonymous Coward | more than 3 years ago | (#34520992)

djb has released some stuff:

http://eprint.iacr.org/2010/623.pdf [iacr.org]

No details at all, but .. certainly .. heh .. provoking. :)

Re:Skein (1)

Omnifarious (11933) | more than 3 years ago | (#34521040)

Well, that's amusing. But without details, it's only slightly better than saying "Skein sucks!".

Re:Skein (2, Insightful)

Anonymous Coward | more than 3 years ago | (#34521314)

Woosh!

Definition of skein: A loosely-wound, oblong ball of yarn

Re:Skein (1)

Sancho (17056) | more than 3 years ago | (#34520728)

It was broken, but it has been fixed.

Actually, Threefish was broken (which Skein relied upon.)

Re:Skein (1)

Omnifarious (11933) | more than 3 years ago | (#34521030)

Is this the attack by djb that even he hasn't posted clear details of? Or is this a previous attack that Schneier and company solved with their 2nd round tweaks that improved diffusion?

Re:Skein (1)

Sancho (17056) | more than 3 years ago | (#34521064)

I was referring to the previous attack which was solved in the 2nd round tweaks.

Bah! (5, Interesting)

jd (1658) | more than 3 years ago | (#34520482)

None of the good names survived!

Still, there was a lot of debate on the SHA3 mailing list governing the criteria as it was felt that some of the criteria were being abused and others were being ignored. I, and a few others, advocated an approach where the best compromise solution was the "winner" for SHA3 but the runner-up that was best for some specific specialist problem (and still ok at everything else, since it's a runner-up, and also free of known issues) would then be considered the winner as "SHA3b". That way, you'd also get a strong specialist hash. The idea for this compromise was due to SHA2 not being widely adopted because it IS ok for everything but not good for anything. Some people wanted SHA3 to be wholly specialised, others wanted it to be as true to the original specs as possible, the compromise was suggested as a means of providing both without making the bake-off unnecessarily complex or having to have a whole parallel SHA3 contest for the specialist system.

The main problem with the finalists is the inclusion of Skein. The use of narrow-pipe algorithms has been widely criticised by people far more knowledgable than myself because it violates some of the security guarantees that are supposed to be present. The argument for Skein is that the objection is theoretical.

Re:Bah! (2)

Omnifarious (11933) | more than 3 years ago | (#34520612)

I'm really curious as to why Blue Midnight Wish wasn't selected. I've read a bunch of the papers and nobody seemed to be able to come up with any reasonable reason it was weak, and it's very fast.

Re:Bah! (1)

jhnphm (892864) | more than 3 years ago | (#34521742)

It has a non-regular structure that causes it to be very large when implemented in hardware - it's one of the largest, if not the largest period, of the round 2 candidates in terms of chip area, and the performance isn't all that great in hardware to make up for this either.

Re:Bah! (2)

jhnphm (892864) | more than 3 years ago | (#34521758)

In addition, the NIST email said "No algorithm survived to become a finalist that did not have a clear round structure that could be readily adjusted to trade security for perfomance." This probably refers to BMW.

Re:Bah! (0)

Anonymous Coward | more than 3 years ago | (#34521268)

That way, you'd also get a strong specialist hash. The idea for this compromise was due to SHA2 not being widely adopted because it IS ok for everything but not good for anything. Some people wanted SHA3 to be wholly specialised, others wanted it to be as true to the original specs as possible, the compromise was suggested as a means of providing both without making the bake-off unnecessarily complex or having to have a whole parallel SHA3 contest for the specialist system.

Nothing stops protocol designers from using other algorithms. Just make sure you use a protocol field so implementations can negotiate, and perhaps set "preference levels".

Some implementers will need to use SHA-3 (whatever algorithm that ends up being) because of regulatory restrictions (government vendors in the US will need to use NIST-approved stuff), but the general public may able to profit from one of the runner-up algorithms that could be a better, specialized fit for the application in question. SSL/TLS support multiple algorithms, as do SSH and PGP. If what you're doing is best suited to a particular algorithm, use it—just make sure it can be expanded—because, after all, all algorithms tend to be "broken" eventually, so you might as well put some flexibility in from the start.

Re:Bah! (1)

mdmkolbe (944892) | more than 3 years ago | (#34521720)

Which specialist problem would SHA3b have been for? Any random specialist problem or is there a particularly important specialist problem? The former doesn't sound very useful, but I don't know what the later would be.

Yet another crappy summary... (3, Informative)

msauve (701917) | more than 3 years ago | (#34520630)

Curiously, some of the faster algorithms were eliminated as they were felt to be "too fast to be true."

Not only is the claimed quote ("too fast to be true") nowhere to be found in the linked article, but there isn't even a basis for that claim.

Re:Yet another crappy summary... (0)

Anonymous Coward | more than 3 years ago | (#34521332)

That's not how Slashdot works. Slashdot guarantees that any claims made in the Slashdot summary cannot be found in TFA.

Re:Yet another crappy summary... (5, Informative)

udittmer (89588) | more than 3 years ago | (#34521928)

Not only is the claimed quote ("too fast to be true") nowhere to be found in the linked article, but there isn't even a basis for that claim.

There is in fact a basis for that claim, even if it isn't mentioned in that particular article. See http://crypto.junod.info/2010/12/10/sha-3-finalists-announced-by-nist/ [junod.info] for more about that.

Re:Yet another crappy summary... (4, Informative)

Skuto (171945) | more than 3 years ago | (#34522040)

>Not only is the claimed quote ("too fast to be true") nowhere to be found in the linked article, but there isn't even a basis for that claim.

People read the articles? That's new.

My original post had no links, because the original announcement was on a password protected mailing list. If you read that (it's been posted elsewhere since), you will see the statement it refers to.

Some fast algorithms were eliminated based on partial attacks or observations that are not real attacks. This means there's a potential we miss out on a faster but good algorithm, because most partial attacks never make it to full attacks. Using this to eliminate ciphers means the selection is a bit of a black art (that shouldn't surprise insiders too much).

Some people were advocating the opposite approach, namely to just pick the fastest/smallest ciphers and then see which one wasn't broken at the end of the process. Clearly, NIST is taken a very different approach. And given hash function history, an understandable one.

Use them all! (1, Funny)

Anonymous Coward | more than 3 years ago | (#34520848)

Use them all, and XOR the results together to get your final hashvalue.

That way, you're safe unless they're all broken, right?

Re:Use them all! (0)

Anonymous Coward | more than 3 years ago | (#34520946)

As a bonus, it's not "too fast"!

Re:Use them all! (1)

PseudonymousBraveguy (1857734) | more than 3 years ago | (#34522024)

For extra security, use each of them twice!

"password" (0, Troll)

pgn674 (995941) | more than 3 years ago | (#34520854)

A friend of mine discovered and I verified the other day that BASE64(SHA256("password")) == XohImNooBHFR0OVvjcYpJ3NgPQ1qq73WKhHvch0VQtg=

Is that "ohImNooB" just a coincidence? If so, then it's quite the coincidence. Taking the SHA256 of a password and converting it to BASE64 is a fairly common way of storing and displaying a password on a system. To have the representation of the word "password", which is a very noobish password to choose, contain the string "ohImNooB". Quite the coincidence indeed.

Unless it's not a coincidence. Would that be possible?

Re:"password" (1)

johanatan (1159309) | more than 3 years ago | (#34521024)

It is most surely a coincidence.

Re:"password" (1)

mx_mx_mx (1625481) | more than 3 years ago | (#34521066)

Who modded that Troll?

Re:"password" (1)

pgn674 (995941) | more than 3 years ago | (#34521784)

Dunno. I had meant to also link it to the article, but I forgot.

I was thinking that it may not be a coincidence. What if, while developing the SHA256 algorithm, they needed an arbitrary starting point or seed, like deciding where to begin drawing a circle? And so, whoever made that choice chose the one that gave this hash for this string? And what if someone did something similar in the SHA3 algorithm? That would be cool to find.

But, I don't know how the SHA2 algorithms work, and there probably is not any arbitrary starting point or seed.

Re:"password" (0)

Anonymous Coward | more than 3 years ago | (#34521114)

A friend of mine discovered and I verified the other day that BASE64(SHA256("password")) == XohImNooBHFR0OVvjcYpJ3NgPQ1qq73WKhHvch0VQtg=

Is that "ohImNooB" just a coincidence? If so, then it's quite the coincidence. Taking the SHA256 of a password and converting it to BASE64 is a fairly common way of storing and displaying a password on a system. To have the representation of the word "password", which is a very noobish password to choose, contain the string "ohImNooB". Quite the coincidence indeed.

Unless it's not a coincidence. Would that be possible?

Is "jcYpJ3NgPQ" just a coincidence also? I think not!

Re:"password" (1)

ducomputergeek (595742) | more than 3 years ago | (#34521658)

Yeah, must be noobs. They forgot the ROT13 step...pfffst, bloody amateurs.

tfhjuft (-1, Troll)

vipgoto (1936430) | more than 3 years ago | (#34520984)

hi, everybody, take your time and a little bit. Now I introduce a website http://www.vipgoto.com/ [vipgoto.com] is specialized in online service on Jordan air max oakland raiders $30--39; Ed Hardy AF JUICY POLO Bikini $20; Handbags (Coach lv fendi d&g) $30 T shirts (Polo ,edhardy,lacoste) $15 Jean(True Religion,edhardy,coogi) $30 Sunglasses (Oakey,coach,gucci,Armaini) $15 New era cap $15 Bikini (Ed hardy,polo) $20 ACCEPT PYAPAL PAYMENT AND CREDIT CARDS DELIVERY TO YOU DOOR TO DOOR Welcome to: == http://www.vipgoto.com/ [vipgoto.com] ==== Air jordan(1-24)shoes $33 Handbags(Coach l v f e n d i d&g) $35 Tshirts (ed hardy,lacoste) $16 Jean(True Religion,ed hardy,coogi) $30 Sunglasses(Oakey,coach,gucci,A r m a i n i) $16 New era cap $15 Bikini (Ed hardy) $25 FREE sHIPPING == http://www.vipgoto.com/ [vipgoto.com] ==== =(b..r..a..n..d.)s.h.o.e.s.
c.l.o.t.h.i.n.g,j.e.a.n,,h.a.n.d.b.a.g,(f.r.e.e)s.h.i.p.p.i.n.g
>>>------I love you! ----> http://www.vipgoto.com/ [vipgoto.com]
Believe you will love it. Accept paypal or credit card and free shipping.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>