×

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 Winner Announced

Soulskill posted about a year and a half ago | from the cryptic-announcement dept.

Encryption 100

An anonymous reader writes "The National Institute of Standards and Technology (NIST) has just announced the winner of the SHA-3 competition: Keccak, created by Guido Bertoni, Joan Daemen and Gilles Van Assche of STMicroelectronics and Michaël Peeters of NXP Semiconductors. 'Keccak has the added advantage of not being vulnerable in the same ways SHA-2 might be,' says NIST computer security expert Tim Polk. 'An attack that could work on SHA-2 most likely would not work on Keccak because the two algorithms are designed so differently.' For Joan Daemen it must be a 'two in a row' feeling, since he also is one of the authors of AES."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

100 comments

I guess that means... (2, Interesting)

Anonymous Coward | about a year and a half ago | (#41531799)

It's time to start building some new rainbow tables?

Re:I guess that means... (4, Funny)

plover (150551) | about a year and a half ago | (#41531875)

Now I may as well delete all the Skein rainbow tables I have been generating. Boy, did I back the wrong horse.

Re:I guess that means... (0)

Anonymous Coward | about a year and a half ago | (#41532593)

Strangely so did I.

Why? (0)

Anonymous Coward | about a year and a half ago | (#41532461)

Who would go out of their way to use a new and bleeding edge hash function, but not employ basic best practices like salting and key stretching?
Are you targeting hash function hipsters?

Re:Why? (3, Insightful)

Ash-Fox (726320) | about a year and a half ago | (#41535487)

Who would go out of their way to use a new and bleeding edge hash function, but not employ basic best practices like salting and key stretching?

The same companies that are vulnerable to SQL injection exploits because they don't even have pen testing as part of their development cycle.

Are you targeting hash function hipsters?

I think he's targeting major corporations.

Re:Why? (0)

Anonymous Coward | about a year and a half ago | (#41536423)

Those companies are storing user passwords as plaintext or as unsalted MD5 hashes. In five years some of them might start using SHA-1.

Re:I guess that means... (1)

kayditty (641006) | about a year and a half ago | (#41533815)

the SHA-family of hashes are not password hashing functions. and the idea of applying rainbow tables to a modern password hashing algorithm with adjustable cost and proper salting is so silly that I can't even laugh.

Re:I guess that means... (4, Interesting)

gstrickler (920733) | about a year and a half ago | (#41534673)

It's only silly if mainstream implementations actually make use of varying those parameters across each installation. However, if something like Windows uses the same parameters for several hundred million installations, a rainbow table will be just fine. Given the history of major software vendors, that's not a guaranteed outcome. If they use the salt properly (randomly generated for each installation, or each encoded item), then it should make them rainbow tables pointless.

Re:I guess that means... (3, Insightful)

lengau (817416) | about a year and a half ago | (#41537293)

It's pretty simple to protect against that on most implementations. Since you mentioned it, let's take Windows as an example.

To protect against rainbow tables on Windows, all we need to do is generate a 16-byte salt at the time of creation of the password and prepend it to the password pre-hashing. Then we store the salt in plaintext right next to the hashed password. Suddenly, a rainbow table is useless unless you happen to have a pre-generated rainbow table for that particular salt (note that you'd have to generate 2^127 times as many rainbow tables for a 50% chance of having a table with that salt).

Not that this protects against any other attacks, but it certainly does mitigate the rainbow table threat.

Re:I guess that means... (1)

gstrickler (920733) | about a year and a half ago | (#41537869)

Easy, yes. But all too frequently, not done. No algorithm is safe from a poor implementation.

Re:I guess that means... (1)

Bengie (1121981) | about a year and a half ago | (#41536471)

Adjustable cost password hashing is plain silly. Let the end user tack on an extra 1-3 chars to make their password secure. Give me a hash that run in one clock cycle, because a good password will still be safe, even with 100ghz graphene cpus.

Re:I guess that means... (1)

Kjella (173770) | about a year and a half ago | (#41542293)

Your average 8 character lower/upper/0-9 password has ~48 bits of crypto strength, a few characters give or take won't change that. And that's plenty if say someone is trying to hack a slashdot account, I'm sure they'd notice 2^48 log-on attempts. But if they can get their hands on the encrypted password database then it's far too easy to recover the password. The longer the password, the fewer of them are you likely to remember and the more you're likely to reuse them so you're probably actually making things worse. Use a proper password hash with salting and it's practically unrecoverable.

Re:I guess that means... (1)

Bengie (1121981) | about a year and a half ago | (#41544611)

Passphrases are easy to remember and plenty long. 96 char dictionary and 14 char length, you get 96^14 combinations. It will take a bit.

Excellent choice (1)

Anonymous Coward | about a year and a half ago | (#41531811)

Congratulations to the whole Keccak team! I happen to know some of them in person and have all confidence that this is an excellent piece of work. True quality always wins in the end.

Re:Excellent choice (4, Funny)

Anonymous Coward | about a year and a half ago | (#41531903)

Praise from an AC on Slashdot? Yeah, they're certainly going to be printing that out and framing it for posterity.

Re:Excellent choice (5, Funny)

Anonymous Coward | about a year and a half ago | (#41532013)

Criticism from an AC on Slashdot? Yeah, I'm certainly going to be printing that out and framing it for posterity.

Re:Excellent choice (5, Funny)

Anonymous Coward | about a year and a half ago | (#41532059)

Sarcasm from an AC on Slashdot? Yeah, I'm certainly going to be printing that out and framing it for posterity.

Re:Excellent choice (4, Funny)

Anonymous Coward | about a year and a half ago | (#41532129)

I think my account has been hacked.

You can post as me, but I'm not printing out ANYTHING. Fuck you guys.

This wouldn't have happened if slashdot would have been using SHA-3.

Re:Excellent choice (0)

Anonymous Coward | about a year and a half ago | (#41535119)

I think my account has been hacked.

You can post as me, but I'm not printing out ANYTHING. Fuck you guys.

This wouldn't have happened if slashdot would have been using SHA-3.

They use SHA-4 you insensitive clod.

--

Put that in your Feistel box where even fiber optics fail to shine.

Re:Excellent choice (0)

Anonymous Coward | about a year and a half ago | (#41532205)

Printing from an AC on Slashdot? Yeah, I'm certainly going to be inking a papyrus and framing it for posterity.

Re:Excellent choice (0, Funny)

Anonymous Coward | about a year and a half ago | (#41532553)

Meta on a meta from an AC on Slashdot by an AC on Slashdot? Yeah, go ahead, cue that XKCD strip...

Re:Excellent choice (0)

Anonymous Coward | about a year and a half ago | (#41533417)

https://xkcd.com/917/

Re:Excellent choice (0)

Anonymous Coward | about a year and a half ago | (#41532535)

Perseveration [merriam-webster.com] from an AC on Slashdot? Yeah, I'm certainly going to... oh, wait.

Not vulnerable in the same ways? (0)

rbarreira (836272) | about a year and a half ago | (#41531813)

'Keccak has the added advantage of not being vulnerable in the same ways SHA-2 might be,'

Out of all the ways a hash function could be vulnerable, not being vulnerable to a few of them hardly looks impressive without more context... But what do I know, I'm not a crytographer.

Re:Not vulnerable in the same ways? (2, Insightful)

Anonymous Coward | about a year and a half ago | (#41531849)

What makes you extrapolate from "It's safe against the most likely issues SHA-2 might have" to "We chose it because of that but for the rest didn't bother to study it at all?" You surely are not a cryptographer, given that you can't even spell the word.

Re:Not vulnerable in the same ways? (1, Insightful)

rbarreira (836272) | about a year and a half ago | (#41531877)

I did not extrapolate that, I just said that this sentence in the summary does not sound impressive. In fact it should be a given that SHA-X does not suffer from the same vulnerabilities as SHA-X-1.

Oh and thanks for the spell check.

Re:Not vulnerable in the same ways? (0)

Anonymous Coward | about a year and a half ago | (#41532021)

The fact that the two techniques are so different suggests that the techniques to break them will be very different as well. This means attacks on the new hash will probably have to start fresh, as opposed to working from the advanced starting point that cryptographers presumably have developed to attack SHA-2.

Re:Not vulnerable in the same ways? (0)

Anonymous Coward | about a year and a half ago | (#41532525)

He understands this, I dunno what the AC is having trouble getting.

Re:Not vulnerable in the same ways? (0)

Anonymous Coward | about a year and a half ago | (#41532653)

The AC is not having any trouble getting anything. The AC is having an issue with the poor communication standards and the desire of ignoramuses to blabber along without adding value to the discussion.The original comment does not just express what the author later claims it expresses, but it also is "negative" about either the winning algorithm or the selection procedure. The AC has no problem with people having other preferences for SHA-3 or thinking that NIST is not up to snuff (e.g. Bruce Schneier's recent comments about whether SHA-3 is relevant at all). But the AC does have an issue with people who write such negatively worded stuff knowing full well that they themselves have no clue whatsoever what they are talking about.

Re:Not vulnerable in the same ways? (0)

Anonymous Coward | about a year and a half ago | (#41533835)

Blah blah blah blah blah? STFU

Re:Not vulnerable in the same ways? (4, Informative)

FrangoAssado (561740) | about a year and a half ago | (#41535235)

In fact it should be a given that SHA-X does not suffer from the same vulnerabilities as SHA-X-1.

No, it shouldn't. Both SHA-1 and SHA-2 are based on the Merkle–Damgard construction [wikipedia.org]. If there's something really wrong with it (not that there's any reason to believe so, today), both SHA-1 and SHA-2 would be affected.

Keccak (SHA-3) has a completely different design based on the sponge construction [noekeon.org].

Re:Not vulnerable in the same ways? (0)

Anonymous Coward | about a year and a half ago | (#41535607)

If there's something really wrong with it (not that there's any reason to believe so, today)

Did you even READ the article you're quoting? Merkle-Damgard is known to have many undesirable properties. They're even mentioned in that same WIkipedia article...

When Scheier said "we don't need SHA-3" last week, he was lambasted by the remaining cryptographic community for ignoring exacly that.

Re:Not vulnerable in the same ways? (2)

FrangoAssado (561740) | about a year and a half ago | (#41537661)

Did you even READ the article you're quoting? Merkle-Damgard is known to have many undesirable properties. They're even mentioned in that same WIkipedia article...

And yet, NIST has no plans to phase-out of SHA-2, because SHA-2 is fine. There's a reason I wrote "If there's something really wrong with it": as far as we know, there's nothing really wrong with it. Cryptographic algorithms are all about trade-offs, and SHA-2 is certainly not perfect, but the same is true of almost everything else we use.

When Scheier said "we don't need SHA-3" last week, he was lambasted by the remaining cryptographic community for ignoring exacly that.

Don't be silly. If that was true, people would be recommending moving away from SHA-2, and nobody is saying that.

Re:Not vulnerable in the same ways? (0)

Anonymous Coward | about a year and a half ago | (#41535089)

What makes you extrapolate from "It's safe against the most likely issues SHA-2 might have" to "We chose it because of that but for the rest didn't bother to study it at all?" You surely are not a cryptographer, given that you can't even spell the word.

And you are obviously not a crytographer.

Re:Not vulnerable in the same ways? (2)

GuldKalle (1065310) | about a year and a half ago | (#41532563)

It makes it somewhat more impressive when the vulnerabilities of SHA-2 are not known yet.

Re:Not vulnerable in the same ways? (1)

rbarreira (836272) | about a year and a half ago | (#41535475)

It makes it somewhat more impressive when the vulnerabilities of SHA-2 are not known yet.

It's a new design, so without further knowledge all we can say is that it replaces "unknown vulnerabilities" with "unknown vulnerabities". Great :P

Re:Not vulnerable in the same ways? (1)

GuldKalle (1065310) | about a year and a half ago | (#41546763)

It still works somehow.
In case SHA3 is broken: whatever, we'll make a new one.
In case SHA2 is broken: whatever, we have SHA3.

Re:Not vulnerable in the same ways? (0)

Anonymous Coward | about a year and a half ago | (#41535585)

Some SHA-2 vulnerabilities are known, i.e. length extension attacks, that Keccak doesn't suffer from. They're not total breaks, but more things like "that's an interesting behavior that we didn't anticipate, and probably not want."

Not sure about the name... (-1, Offtopic)

Alworx (885008) | about a year and a half ago | (#41531851)

...doesn't Keccak(*) sound a bit gay in Italian, Mr Bertoni?

Anyways, great job!! My security&safety uni exam is now even more obsolete :-(

http://en.wiktionary.org/wiki/checca [wiktionary.org]

(*) prononuced as spelled, I've read the article

Re:Not sure about the name... (0)

Anonymous Coward | about a year and a half ago | (#41532145)

Thank you very much for your great contribution to the quality of the discussion. It always helps to have people who know how to keep Slashdot up to the right level.

Rolls Eyes (-1)

Anonymous Coward | about a year and a half ago | (#41531945)

They were in crunch mode to get SHA-3 rolled out before Christmas so they could get cracking on SHA-4 as quickly as possible. Nice job NIST, even though we need this like we need a new UI for Windows.

Re:Rolls Eyes (5, Interesting)

mlts (1038732) | about a year and a half ago | (#41532083)

Having a good SHA algorithm is a good thing. Yes, hash collisions may not seem to be something that can happen often, but if there is a chance that one can make a document saying "hell no" be changed to "yes, definitely", that can bankrupt a company.

Hashes also have other uses, especially as "bit blenders", so if one is able to figure out a way to decrease entropy, then keys generated from a device like /dev/random can be significantly less secure.

Each crypto algorithm is important. I just wish NIST would not just pick one candidate, but perhaps 2-3 at a time [1]. The reason for this is that if something happened that made the algorithm insecure, the standard libraries would have a backup. It also means that embedded controllers that are made to the standard wouldn't have to be chucked and replaced should one algorithm be cracked.

[1]: Not just hashing, but encryption as well. I wish NIST went wish not just Rijndael, but Serpent and Twofish for a standard. Similar with not just going with just RSA, but RSA, Merkel, DSA, ElGamel, and elliptic encryption. That way, should an attack like TWIRL or quantum computers make RSA pointless, people can switch over to Merkel or another algorithm without needing a hardware upgrade. Plus, for high security work, multiple algorithms can be cascaded [2] to ensure that one weak link won't compromise everything.

[2]: No, three 256-bit algorithms will not get you 768 bits. In reality, you end up with 258 bits of security. However, if one of the algos ends up being broken and only offering 32 bits of unique keys, the other two would continue to keep at least 256 bits of keylength.

Re:Rolls Eyes (5, Interesting)

plover (150551) | about a year and a half ago | (#41533103)

I just wish NIST would not just pick one candidate, but perhaps 2-3 at a time [1]. The reason for this is that if something happened that made the algorithm insecure, the standard libraries would have a backup. It also means that embedded controllers that are made to the standard wouldn't have to be chucked and replaced should one algorithm be cracked.

As with anything, be careful what you wish for. I've seen successful attacks on protocols that support multiple versions or algorithms, made possible by devices that support them all for various compatibility reasons. Let's suppose someone does discover an attack on SHA-3A but SHA-3B remains secure. Everybody switches their servers to SHA-3B. A flexible protocol might allow an attacker to generate an error that forces clients to re-hash their passwords with SHA-3A. This has happened more often than you might think; NTLMv2 implementations falling back to NTLM being one of the more spectacular of the exemplary failures.

Your example creates a theoretical weakness - a failure in either SHA-3A or SHA-3B could put such a device at risk. If you try to prevent this by building in an environmental protocol switch, so the device could be set in the future as to which algorithm to use, why not initially design the device to support loading a more modern algorithm in the future?

Re:Rolls Eyes (1)

bill_mcgonigle (4333) | about a year and a half ago | (#41533425)

If you try to prevent this by building in an environmental protocol switch, so the device could be set in the future as to which algorithm to use, why not initially design the device to support loading a more modern algorithm in the future?

The algorithms are implemented in hardware, e.g. Intel's AES-NI. If rijndael is found to be weak, you can't just make a that CPU do Twofish in hardware. If Intel implemented rijndael, twofish, and serpent in hardware, then if an attack is found on rijndael there would be somewhere to go. If an app becomes dependent on AES-NI and it's broken, then there's a 2-year waiting period before anything can be done about it. Which is essentially forever.

Re:Rolls Eyes (1)

Electricity Likes Me (1098643) | about a year and a half ago | (#41535893)

However we already know that this isn't really how modern cryptography works. There would be enormous forewarning in the literature that a practical attack of some sort was coming - these things aren't made out of whole cloth by lone geniuses, they're developed, analysed and slowly implemented over time.

There are some theoretical attacks against AES for example, but nothing practical has been implemented yet, and by the time it is we'll most certainly have moved on to a newer cryptography standard.

Re:Rolls Eyes (2)

alexo (9335) | about a year and a half ago | (#41538327)

I've seen successful attacks on protocols that support multiple versions or algorithms, made possible by devices that support them all for various compatibility reasons.

And I've seen attack ships on fire off the shoulder of Orion and watched C-beams glitter in the dark near the Tannhauser gate.
So there!

Re:Rolls Eyes (1)

Phunkmeister (2744681) | about a year and a half ago | (#41543333)

Wouldn't it be safe to just always use multiple hashes (e.g. SHA-2 and SHA-3 and Whirlpool) and XOR the results to generate one final hash? A weakness in one of the algorithms would not weaken the combined hash. And even if *all* hashes would be effectively broken, it would still be far from trivial to forge arbitrary data that results in the same final hash.

Re:Rolls Eyes (1)

ChoGGi (522069) | about a year and a half ago | (#41534861)

"Having a good SHA algorithm is a good thing."

still using the ATM machine?

Re:Rolls Eyes (1)

Chrisq (894406) | about a year and a half ago | (#41535395)

"Having a good SHA algorithm is a good thing."

still using the ATM machine?

Yes, I use it to withdraw money from my ISA account. I might by myself a new PC computer.

Re:Rolls Eyes (0)

Anonymous Coward | about a year and a half ago | (#41535657)

In addition to what plover noted, an important problem (especially for hardware) is cost and complexity. And we all know how more code generally leads to more bugs.

Re:Rolls Eyes (0)

Anonymous Coward | about a year and a half ago | (#41535687)

Why go through the trouble of finding a hardware efficient function that can be implemented in smart cards and embedded devices, and then more than triple the footprint by chucking them all in?
Nothing is stopping anyone from implementing SHA-3 finalists to their heart's content for their own software, but putting additional algorithms in silicon has a real cost.

Re:Rolls Eyes (1)

dkf (304284) | about a year and a half ago | (#41535707)

Having a good SHA algorithm is a good thing. Yes, hash collisions may not seem to be something that can happen often, but if there is a chance that one can make a document saying "hell no" be changed to "yes, definitely", that can bankrupt a company.

Hash collisions happen all the time.

You're enormously reducing the number of bits of information present, so you will get collisions (unless you've tuned the hash algorithm to exactly the sets of data being hashed, which is a total drag in practice). What you don't want though is the ability to say "I have the hash of something, let's easily find something else useful to me with the same hash"; preventing that is a key feature of cryptographic hashes. (Other kinds of hashes exist, where collisions are more likely between related data but the cost of calculation is much lower; there's a lot of code where that trade-off makes a huge amount of sense.)

Re:Rolls Eyes (1)

Bengie (1121981) | about a year and a half ago | (#41536503)

"Hash collisions happen all the time." Really? A 512bit hash collides "all the time"? We have systems generating tens to hundreds of thousands of 128bit GUIDs all the time for years, and don't have issues colliding. How is a 512bit hash supposed to collide regularly short of identical data?

Re:Rolls Eyes (1)

deroby (568773) | about a year and a half ago | (#41537309)

Maybe because a GUID isn't a hash ?

GUID's are kind of 'sequential' numbers based on the time and either a MAC address or a random number. By design it's (theoretically) impossible to generate the same GUID twice because either the time will have progressed in sequential calculations and/or different 'base' numbers are used when running on different hardware as to 'force' the generation happen to simultaneously.

Hash functions are based on a block of data being 'examined' and will return the same result over and over again for the same blocks of data. If the hash-result changes, the source-data must have changed, period.But! vice versa is not necessarily true : it is well possible that 2 different blocks of data return the same hash function, but are not identical and we then have a so-called Hash-collision.

If you truly believe we could safely assume that a hash represents one and only one potential data-block, you would have the ultimate compression-software in your hands ! Admittedly, decompressing would take a while because you'd have to iterate over I don't know how many blocks of random data until you find the right hash, but how often do you really need eg. backups anyway ? Just hash your entire disk, write the hash on some napkin and feel safe.

Re:Rolls Eyes (0)

Anonymous Coward | about a year and a half ago | (#41544933)

It's called being collision resistant hash function. And its a primary security requirement for "cryptographic hash functions" such as the SHA family and MD* family of hash functions. For some we know how to produce collisions with varying degrees efficiency (MD5, SHA-1) and for some we don't like SHA2 and 3.

But collision resistance doesn't mean its invertible. In other words after you hash ur HD down there's no known efficient way to recover the original even if we can't find another HD that will hash to the same value. In fact if there were then it would be trivial to break collision resistance.

Hash some long random string. Invert the result. Since many (infinite) strings hash to any given output chances are u don't back the original string. Any different preimage is a collision.

Incidental a similar trick shows that taking square roots mod a composite is essentially equivalent to factoring...

Re:Rolls Eyes (1)

deroby (568773) | about a year and a half ago | (#41546781)

Which is more ore less what I was trying to convey...?!? Maybe I should have added a smiley or 'sarcasm-tag' at the end of my 'feel safe' sentence.

Re:Rolls Eyes (1)

petermgreen (876956) | about a year and a half ago | (#41538233)

You're enormously reducing the number of bits of information present

True

so you will get collisions

No

It is true that collisions must exist but if the output of the hash function is large enough then the number of inputs you would have to try to find a collision by brute force becomes unfeasiblly large even if you don't care what it's a collision with.

Finding any collision at all is considered very bad news for a secure hashing algorithm as it is often quickly extended to finding collisions with common prefixes. From there you can construct two documents in a format like pdf with very different content but the same hash, then you can get someone to sign one using the hash algorithm and their signature will verify on the other.

Re:Rolls Eyes (1)

Phunkmeister (2744681) | about a year and a half ago | (#41543195)

Hash collisions happen all the time.

Oh, really? Can you post just ONE example of a 512-bit hash collision? I mean two different pieces of data (no matter how long or short) that have the same 512-bit hash? Or even just 384-bit perhaps? 256 maybe? 224? 160?

Re:Rolls Eyes (0)

Anonymous Coward | about a year and a half ago | (#41532309)

We do need a new UI for Windows GN. I can't even unlock the password screen without the fingerprint reader!

Was hoping a faster algorithm would be chosen... (1)

Anonymous Coward | about a year and a half ago | (#41532109)

According to the (extensive) benchmark data here [cr.yp.to], this is even slower than the previous SHAx.

Somewhat disappointing, when both Skein and Blake are about twice as fast, and appear to be perfectly acceptable from a security standpoint. (From what I have read anyway.) So, out of curiosity, what is the argument for keccak that puts it ahead?

Re:Was hoping a faster algorithm would be chosen.. (1)

viperidaenz (2515578) | about a year and a half ago | (#41532183)

Perhaps this secure hashing algorithm was chosen above the others because it was more secure than the others?

Re:Was hoping a faster algorithm would be chosen.. (1)

F.Ultra (1673484) | about a year and a half ago | (#41532257)

Since none of the remaining candidates in round 3 where broken this is probably not the case. I think that the simplicity of the design (which makes analysis more easy) was the real reason. However we do not know yet since the report from round 3 hasn't been released yet.

Re:Was hoping a faster algorithm would be chosen.. (2)

LordLimecat (1103839) | about a year and a half ago | (#41532783)

Security is only one of the factors. Speed is one of the big reasons AES was chosen IIRC.

Re:Was hoping a faster algorithm would be chosen.. (1)

Anonymous Coward | about a year and a half ago | (#41535565)

It was chosen because of speed on a variety of hardware (desktop/server CPUs, embedded, smart cards, ...), because it has very low gate/memory requirements (making it implementable on really small stuff), because it's secure, and because the design is very different from SHA-2.

The choice makes it clear that the last was an important criterion. When the SHA-3 competition was announced, everyeone expected SHA-2 to fall soon. It didn't, so likely SHA-2 won't go away anytime soon. However if it were to be broken, the replacement is already lined up.

Without that consideration, BLAKE was a clear favorite, IMHO.

Re:Was hoping a faster algorithm would be chosen.. (0)

Anonymous Coward | about a year and a half ago | (#41532207)

NIST have not yet published the details, but the press release is pretty clear concerning speed: HW implementations of Keccak are much faster than equally large/costly HW implementations of the other candidates.

Re:Was hoping a faster algorithm would be chosen.. (2)

pavon (30274) | about a year and a half ago | (#41532733)

That is a strange criteria though, as 99.9% of the people using SHA3 and depending on it's security will use a software implementation. Practically the only people who deal with hardware implementations anymore are those trying to break a cryptosystem. Of course all the speed measures for the SHA-3 contenders (hw and sw implementation) are relatively small constant multiples/divisors of SHA2, so it really isn't a big deal from a security or convenience factor.

Looking forward to reading the final report.

Re:Was hoping a faster algorithm would be chosen.. (0)

Anonymous Coward | about a year and a half ago | (#41532869)

All(?) Via CPUs have SHA and AES hardware acceleration provided by Via's 'Padlock'.

Re:Was hoping a faster algorithm would be chosen.. (0)

Anonymous Coward | about a year and a half ago | (#41533087)

The same holds for security processors in payment cards etc. They all have dedicated HW accelerators on board.

Re:Was hoping a faster algorithm would be chosen.. (1)

snemarch (1086057) | about a year and a half ago | (#41536861)

That is a strange criteria though, as 99.9% of the people using SHA3 and depending on it's security will use a software implementation. Practically the only people who deal with hardware implementations anymore are those trying to break a cryptosystem.

...and there you have the answer. *cue mysterious conspiracy music* :)

Always going to be someone like this doing it (2)

BitZtream (692029) | about a year and a half ago | (#41532473)

' For Joan Daemen it must be a 'two in a row' feeling, since he also is one of the authors of AES."

As someone who works in cryptography (no, I'm nothing like these guys, never will be) there are a limited number of people in the world qualified to design these algorithms. They are ALWAYS going to be the ones involved in the design process. Bruce Schneier is another person who is ALWAYS going to be in these sorts of competitions. There may be a new guy come in and an old guy go out over time but in general its going to be a select few people that have the type of mind to work with this sort of stuff.

Balinese Hash (1)

Melibeus (94008) | about a year and a half ago | (#41532557)

How can a strange Balinese dance perform better than SHA2 as a hash algorithm. I'm sure that hash had something to do with the creation of the Kecak dance, but not the cryptographic sort.

Re:Balinese Hash (0)

Anonymous Coward | about a year and a half ago | (#41532751)

There is indeed a logical link to the dance. :-) One of the authors explained it to me earlier today (we share an office).

Re:Balinese Hash (1)

Melibeus (94008) | about a year and a half ago | (#41533281)

I saw the Kecak dance on my honeymoon in Ubud. I'd be interested to hear what that logical link might be.

So is SHA1 unsafe now? (0)

Anonymous Coward | about a year and a half ago | (#41532599)

Sorry for the newbie question but should I replace:

INSERT INTO users SET username='admin', password=sha1('********')

for:

INSERT INTO users SET username='admin', password=sha3('********')

Re:So is SHA1 unsafe now? (0)

Anonymous Coward | about a year and a half ago | (#41533599)

Sorry for the newbie question but should I replace:

INSERT INTO users SET username='admin', password=sha1('********')

for:

INSERT INTO users SET username='admin', password=sha3('********')

No, but you should replace it for sha2. And you should salt the password. And for god's sake, sanitize your inputs!

Re:So is SHA1 unsafe now? (4, Informative)

kayditty (641006) | about a year and a half ago | (#41533837)

you're trying (poorly) to troll, but for those who actually are curious, no, you should not do anything of the sort. you should use a proper password hashing framework which makes use of hash functions actually intended for use with authentication systems, such as phpass [openwall.com].

Re:So is SHA1 unsafe now? (1)

petermgreen (876956) | about a year and a half ago | (#41538569)

So is SHA1 unsafe now?

Noone has actually found any collisions yet but there is a risk they may do so in the not too distant future. So if your system relies on collision resistance you probablly want to look into migration plans to something stronger.

Sorry for the newbie question but should I replace:

INSERT INTO users SET username='admin', password=sha1('********')

for:

INSERT INTO users SET username='admin', password=sha3('********')

Not really, collisions aren't really too much of an issue in this application, the attacker would need a preimage attack which is much harder. Generally in password hashing systems the hash function is far from the weakest link however for this use you should.

1: make sure you salt your passwords. Ideally with both a per-installation salt which is stored separately from the password DB and a per-password salt in the password db.
2: consider using a deliberately slow hash function to slow down dictionary/brute force attacks on your passwords.
3: consider privilage seperation between the part of your system that handled password validation and the rest of your system so a break in your webapp doesn't let someone download a copy of the stuff they need to start work on password craking.

Aesop again... (0)

Anonymous Coward | about a year and a half ago | (#41532771)

I mentioned [slashdot.org] that Aesop said it best, when he said 'those were sour grapes anyways,' but I guess I got modded into irrelevance. I guess that's what happens when you frame the Chuck Norris of cryptography in a negative light.

(also interesting coincidence, AESop)

Re:Aesop again... (0)

Anonymous Coward | about a year and a half ago | (#41532807)

Nope. found it [slashdot.org]. Guess I was just never modded.

Re:Aesop again... (0)

Anonymous Coward | about a year and a half ago | (#41532879)

I had the same thought when I saw that discussion back on that day. But there is no way Bruce could have known for sure that he was going to loose, as NIST didn't contact the various authors until last weekend.

shIt?! (-1)

Anonymous Coward | about a year and a half ago | (#41533241)

Feelow travel7ers? rivalry. While

Finally (0)

Anonymous Coward | about a year and a half ago | (#41533345)

Personally, I was hoping Skein would win; it was the most flexible and, in my opinion, the most innovative of the finalists. Anyway, congrats to the winner. This selection will hopefully make good hashing popular and widely-implemented (and therefore convenient enough that those in information industries will slowly adopt it).

Re:Finally (1)

jibjibjib (889679) | about a year and a half ago | (#41534653)

Innovation is a means to an end, not an end in itself. "Most innovative" on its own should not be a criterion in choosing a hash function.

Re:Finally (0)

Anonymous Coward | about a year and a half ago | (#41536265)

Thankfully, it seems it has only been used indirectly for this - basically, "most likely to remain secure in the event of feasible attacks on SHA-2".

Re:Finally (1)

Anonymous Coward | about a year and a half ago | (#41536351)

Agreed. I intend to use Skein in my cryptographic protocol anyway, because Skein has native signature pinning, native tree hashes, and a native keyed hash mode. It's also much faster, and no less secure.

NIST's stamp of SHA-3 approval frankly doesn't mean that much to me anymore, particularly if they chose it because it'd work on smartcard processors. That's not my use case, and I have no particular need to comply with any standards: indeed, a Skein Tree Hash makes a very fine replacement for a Tiger Tree Hash...

yuo Fail it (-1)

Anonymous Coward | about a year and a half ago | (#41533913)

despite the contaminated while At death's ddor schemes. Frankly

Eternal classic - hermes bags (-1)

Anonymous Coward | about a year and a half ago | (#41534359)

There are a lot of men, who do not understand why it is that women just love to spend much over one designer handbag. If you are a guy, who wants to make your partner happy,puma sneakers, maybe you can present her with a designer Hermes Birkin [hermesstore.net]. But that is, if you are willing to spend thousands of dollars on one bag. Hermes Birkin bags and Louis Vuitton Bags [louisvuittonoutlete.net] from this brand can cost much. The good thing though, is that these handbags can be used for many years.
The fashion world is to flashy, one can easily be out of his way. Either I’m not a crocodile enthusiast or a worshiper of Mammon, I just want give those whom are looking for the great bag a bit of advice. Though buying a Hermes Birkin Bags [hermesstore.net] is time-consuming and costly, pursuit of the beautiful and devotion to artistic beauty and refined taste could never go wrong. If you really love the bag, then go get it.
Life, bags can be said to be the most essential objects may be less, one of many occasions are very practical. Big this year heat agitation restoring ancient ways of the contracted flip style blew back, on the details of changes are also rich wonderful, contracted starched package form more suitable for collocation some skewed loading clothes, colorful brilliant color suits summer to use, and the material of restoring ancient ways and styles will be full of the feeling of early autumn. Thought that one day you will sell LV Meng Why? Hermes Bags [hermesstore.net] Pulsion new series, really cute fur addictive. Summer, wanted to introduce a certain tendency to the freshness of a single product, but this new series Hermes wallet LV Lockit bag Pulsion is too cute, fluffy paste my face as people really want to rub rub. Will always be ahead of fashion trends,Hermes wallets beauty and love LV to the people not to be missed this Hermes Wallets [hermesstore.net] bag nice and warm, the collection soon to move a single product for their fall and winter to prepare for Look! Hermes Victoria [hermesstore.net]
            Hermes Wallets [hermesstore.net]

Finally (0)

Anonymous Coward | about a year and a half ago | (#41534803)

Ah, some decent achievement for Belgium.... Usually the nationallity is always mentioned in such achievements but noo, not in our small country. We do have a bit of a problem with patriotism :s

Meanwhile in Spain... (0)

Anonymous Coward | about a year and a half ago | (#41536479)

I guess none of the people involved speaks Spanish, because "keccak" is pronunced almost like "'qué caca!" ("what a piece of shit!")...

Seems adequate (0)

Anonymous Coward | about a year and a half ago | (#41536625)

http://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo

But what a lousy name. I still say Blue Midnight Wish had a far cooler title. Yeah, yeah, I know, that's not what you pick hash algorithms for. But to judge from the number of skull-and-crossbones on the Hash Function Lounge, security has never been that high on the list, so why not go with the cool names?

http://www.larc.usp.br/~pbarreto/hflounge.html

Seriously, congrats to Keccak, although watch that inner permutation glitch.

http://csrc.nist.gov/groups/ST/hash/sha-3/Round2/documents/Keccak_Comments.pdf

Hardware manufacturers especially like taking shortcuts that lower cost without lowering the illusion of security (even if actual security is reduced to bugger all).

Secure, yeah - think about it. (0)

Anonymous Coward | about a year and a half ago | (#41542119)

The NSA I am certain has been instrumental in any and all security and cryptographic testing and evaluation to ensure that they, the NSA can easily crack or decode the cypher text. Do NOT for a minute think that the winner has any leg up over the NSA experts. If it doesn't have a back door it will when finished. Any cryptographic algorithm is guaranteed to have some easy was to decode, otherwise the NSA is NOT doing their job. The only way to guarantee NSA non-involvement is get the algorithm from some non-aligned nation; Russia and China come to mind.

Re:Secure, yeah - think about it. (0)

Anonymous Coward | about a year and a half ago | (#41547165)

I tend to agree. Think about it, we hear all the time in the news "U.S. Intel picks up chatter about latest bomb attack." Usually when they say "chatter" they are referring to NSA SIGINT operations. Do you really think these enemy nation-states are dumb enough not to encrypt their comms? Maybe some of the rag-tags in BFE don't, but I assure you Iran, Syria, Egypt, Hamas, et al do. Yet NSA has no problem getting a hold of the plaintexts.

NSA spends billions a year keeping a leg up on the competition. They employ more PhD's in mathematics than any entity on earth (literally). I am positive no algorithm that is public is safe from them. If this weren't the case, their intelligence would dry up instantly (and yet it hasn't). Whether this means backdoors, side-channels, or whether it means they are ahead in cryptanalysis, I can't say. It is probably a combination of all three. Indeed, I wouldn't be surprised at all if most commodity hardware had NSA backdoors baked in the metal. In fact, I expect them to do this or else they are failing.

CryptoAG is a good example of NSA's history of backdooring crypto systems and then selling them to enemy nation-states. I would be very surprised if there isn't a current version of such a project.

All of that said, SHA-3 and AES were not designed by NSA and it is doubtful the authors are working on their behest. What most likely happens is NSA instructs NIST on which candidate to pick (i.e. one that is secure, but not secure from *them*). So by the fact they picked the sponge construction we can infer NSA sees a flaw in that design. Or maybe NSA has suddenly become citizens of the world and is spreading strong crypto to all. Somehow I doubt that.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

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>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...