Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What is going on with NIST’s SHA-3?

cdt.org

Post reply on HN
Print view View original

41–50 of 50 posts

Re: What is going on with NIST’s SHA-3?

#41

Post by zimpenfish »

emillon wrote: post #40
afhof wrote: post #38

Earlier quoted context omitted.

Its deeply troublesome when these kinds of comments come up for two reasons: first and lesser: its wrong; secondly: its inconspicuously wrong. Processor speeds double approximately every generation which we can estimate is once every two years. What do we have to count to: 2^128 = 3.402823669209385e+38 How many times can we count in a year with a 3GHz core: 3e9 * 3600 * 24 * 365.24 = 9.4670208e+16 In two years, when…

> Processor speeds double approximately every generation which we can estimate is once every two years. Do you have any sources to back up this claim? Max processor speed has stalled to ~4GHz since 2005. If you're referring to Moore's law, it concerns the amount of transistors in ICs, and will eventually hit a limit (not before 10 years, but not after 140 years).

I think "speed" here is "flops", not "hertz".

Re: What is going on with NIST’s SHA-3?

#42

Post by ckozlowski »

rainsford wrote: post #21
marshray wrote: post #2

Basically, NIST seems to be reasoning that because Keccack's sponge construction has no internal resistance to meet-in-the-middle attacks, the collision and preimage resistances are the same. An upper bound on the security of Keccack is set by the expression c + r = 1600. 'c' represents the internal bandwidth of the hash that is not directly controllable by an attacker. 'r' is the rate (bits per expensive f() functio…

I guess I don't really understand the objection to NIST's reasoning. While a larger capacity (c) would increase pre-image resistance, it wouldn't help generic collision resistance (which would always be limited by the output size). There are certainly contexts where a pre-image attack would be more damaging than a collision, but collisions can be a problem in other situations. Asking the user to figure out which secu…

I think you're on to something there with regards to the performance. Schneier was making some noise towards the end of the competition that none of the entries really improved on speed. ( https://www.schneier.com/blog/archives/2012/09/sha-3_will_be... ) Contrary to to article, hashing is used a lot, and there are a few areas where performance will be an issue for sometime (mobile space, and high-density virtualized environments) It may be that the key space was indeed deemed excessive, and of little added benefit compared to the rewards gained in greater speed.

As another mentioned further down, no one is simply going around busting up 256bit keys, and when it finally happens, it will be with a computational paradigm that will require a defense built to an entirely different set of requirements: out of the scope of this competition.

Re: What is going on with NIST’s SHA-3?

#43

Post by dchest »

NelsonMinar wrote: post #30
dsl wrote: post #15

Can someone fix the title? SHA3 is not an encryption standard.

I've long since given up trying to give meaningful titles to Hacker News posts since the anonymous silent moderators rewrite them. The blog post I linked is titled "What the heck is going on with NIST’s cryptographic standard, SHA-3?" and that's the title I went with, saving the trouble of someone rewriting it without notification. But they rewrote it anyway. The title I would have chosen is "NIST's ability to do cry…

Look at the linked URL:

.../2409what-heck-going-nist%E2%80%99s-encryption-standard-sha-3

Re: What is going on with NIST’s SHA-3?

#44

Post by antihero »

rainsford wrote: post #32
msandford wrote: post #27

Earlier quoted context omitted.

Yeah I can't understand why everyone wants "fast" so badly. Something which deliberately can't be made fast is the way to ensure security. I don't really care if my SSL negotiation takes an extra 1ms or if my purchases on Amazon cost an extra $0.001 each because of the expense of the hash functions. I'd like security, thanks. When the price is so trivial, who really cares if it's 10x as expensive?

Because there are a lot of ways to make a fast thing slow in cases where "slow" improves security. And at the same thing you're not hurting performance in cases where a slow function doesn't significantly help security and performance might be important. Making your hash function twice as slow means you've halved the number of hash operations you can perform with fixed computational power. On the other hand, in many…

Would a simpler way to put it be that if you make something fast and do it lots of times, it's difficult to speed up. If you make something slow and it's done significantly less times, there's the risk that someone will make it a lot faster?

Re: What is going on with NIST’s SHA-3?

#45

Post by HansHarmannij »

I once had the opportunity to talk with Joan Daemen, one of the designers of Keccak, and also of AES. He said that he liked to do what he did, because it's fun, but he didn't really believe that it was very usefull. Because everything has backdoors. At that time I didn't think much of it, I just thought it was kinda funny that an important cryptographer had such views about his work. But in the light of the NSA developments it's a bit different. I have no idea what to think of it. Did he know about what the NSA did? Or was he just a bit pessimistic, but he turned out to be right?

This does of course not mean that he made backdoors in AES and Keccak for the NSA. If that were the case he probably would not be allowed to speak about it, and he did talk about it very non-chalantly.

Re: What is going on with NIST’s SHA-3?

#46

Post by Osmium »

afhof wrote: post #38
nly wrote: post #11

Earlier quoted context omitted.

> the collision and preimage resistances are the same. > The idea of a hash function which outputs 256 bits having only 128 bits of preimage resistance is unprecedented. But does the SHA-3 construction mean a collision attack will further enable a preimage attack? Most breaks in recent cryptographic hashes have been confined to collision attacks. Even MD5 (publicly) hasn't been shown to be vulnerable to a viable prei…

Its deeply troublesome when these kinds of comments come up for two reasons: first and lesser: its wrong; secondly: its inconspicuously wrong. Processor speeds double approximately every generation which we can estimate is once every two years. What do we have to count to: 2^128 = 3.402823669209385e+38 How many times can we count in a year with a 3GHz core: 3e9 * 3600 * 24 * 365.24 = 9.4670208e+16 In two years, when…

The Landauer limit [1] is relevant here. Even if you could theoretically make a processor that does it, it would take about 30 gigawatts of power for 1 year [2] to just do 2^128 bit flips (this is obviously a lower bound since it disregards the additional energy required to actually do the calculation). This is more than 1/100th of the world's current energy production. So it's not something that is going to be a concern for most people, and certainly not in the near future!

If the world had access to that kind of energy, I'm sure it'd be used for far more interesting things than finding a single hash collision.

[1] http://en.wikipedia.org/wiki/Landauer_limit [2] http://en.wikipedia.org/wiki/Brute-force_attack#Theoretical_...

Edit: and while we're on the subject of inappropriately extrapolating Moore's law, if current performance-per-watt continues to double every 18 months I'd be interested in how long it'd take to even reach the Landauer limit. I can't seem to find out how much energy it takes to do a single bit flip in a modern processor online, so I can't do the calculation.

Re: What is going on with NIST’s SHA-3?

#47

Post by pbsd »

marshray wrote: post #37
rainsford wrote: post #28

Earlier quoted context omitted.

I agree that it's a new design decision, but I think there is reasonable support for making it. Hash function history has pretty well demonstrated that most implementers don't understand the difference between pre-image security, hash output length and collision resistance. And the security margin is far from eliminated entirely. Not only is there significant margin in the round function itself over the full number o…

> SHA-3-512 truncated to 20 bytes of output At this point, your fellow software developers are pointing and laughing at you for "inventing your own cryptography". Your function doesn't come standard in any library. Every single 3rd party audit of your architecture raises a red flag about this and you have trouble finding any official documentation to back you up. (Ask me how I know about this :-) I'm not trying to sa…

Don't forget that NIST has mentioned they'll standardize variable-output-length SHA3: SHAKE512 with 20 byte output would be perfectly fine. They've also mentioned they might include MAC and AEAD standards, so I'm not convinced the situation is as bad as you make it.

Re: What is going on with NIST’s SHA-3?

#48

Post by ballard »

einhverfr wrote: post #34
ballard wrote: post #25

Earlier quoted context omitted.

Yea: s/encryption/hash function/ 'encryption' -> 'hash function' for those that dont grok sed

Right, but it is a cryptographic hash, so presumably it would be better to call it a "cryptographic standard."

You're trying to invent an argument based on depth of specificity, when both are equally valid.

The title was fixed.

Re: What is going on with NIST’s SHA-3?

#49

Post by NelsonMinar »

NelsonMinar wrote: post #30
dsl wrote: post #15

Can someone fix the title? SHA3 is not an encryption standard.

I've long since given up trying to give meaningful titles to Hacker News posts since the anonymous silent moderators rewrite them. The blog post I linked is titled "What the heck is going on with NIST’s cryptographic standard, SHA-3?" and that's the title I went with, saving the trouble of someone rewriting it without notification. But they rewrote it anyway. The title I would have chosen is "NIST's ability to do cry…

The blog's post was different originally and has been changed itself. I give up.

Re: What is going on with NIST’s SHA-3?

#50

Post by marshray »

pbsd wrote: post #47
marshray wrote: post #37

Earlier quoted context omitted.

> SHA-3-512 truncated to 20 bytes of output At this point, your fellow software developers are pointing and laughing at you for "inventing your own cryptography". Your function doesn't come standard in any library. Every single 3rd party audit of your architecture raises a red flag about this and you have trouble finding any official documentation to back you up. (Ask me how I know about this :-) I'm not trying to sa…

Don't forget that NIST has mentioned they'll standardize variable-output-length SHA3: SHAKE512 with 20 byte output would be perfectly fine. They've also mentioned they might include MAC and AEAD standards, so I'm not convinced the situation is as bad as you make it.

OK so NIST-SHAKE512-[0 But it's a) unwieldy to specify, and b) reveals the output of NIST-SHAKE512-[0 Note: I am definitely not saying this is the end of the world.
Post reply on HN