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

Maybe Skip SHA-3

imperialviolet.org

Post reply on HN
Print view View original

151–160 of 188 posts

Re: Maybe Skip SHA-3

#151

Post by baby »

yorwba wrote: post #147
baby wrote: post #132

Earlier quoted context omitted.

Indeed, the whole permutation is invertible and I'm not sure why either.

Permutations are always invertible. Otherwise several different inputs will be mapped to the same output, which needlessly reduces your state space. The inverse is also required for decryption: If you encrypt as ciphertext = permutation(plaintext + key) , decryption is plaintext = inverse(ciphertext) - key .

My question is why does Keccak not use a one-way function instead of a permutation.

> The inverse is also required for decryption: If you encrypt as ciphertext = permutation(plaintext + key), decryption is plaintext = inverse(ciphertext) - key.

This is not how encryption/decryption works with Keccak. Keccak is used to create a stream (it is then XORed with the plaintext or ciphertext).

Re: Maybe Skip SHA-3

#152

Post by ktta »

RcouF1uZ4gsC wrote: post #115
tptacek wrote: post #84

Earlier quoted context omitted.

The advantage to 224 or 512/256 is that they don't expose the full register state of the hash at output and thus, like Blake2 and SHA-3, aren't vulnerable to length-extension attacks: you can (though it would be idiosyncratic to do so) use a simple prefix MAC with them, rather than HMAC.

With SHA 224, there is only 32 bits worth of information that are lost. Isn't a LEA "feasible" by generating the ~ 4 billion messages and finding the 1 that validates. With 512/256 this is infeasible. Is this a real concern with 224 in practice?

I'm not a cryptographer, but looking at the attack a bit more closely, I don't think this will work. Someone let me know if I'm wrong.

For this attack to work, one needs to know the full 256 bits, so that they can continue with appending their own data to the hash's internal state to get a valid hash. But in this case, they don't have the complete internal state.

So they can't really continue because the missing 32 bits are required to continue. Even though it is just 32 bits, they can't just validate the hash in anyway because they don't even know the complete message, just the length of the message. So the validation process isn't really possible.

Why this works for non-truncated hashes is because the attacker knows that the hash is valid for secret+data and also the hash internal state (which is the hash itself), but if the complete internal state isn't known, there's no way to attack it.

Re: Maybe Skip SHA-3

#153

Post by baby »

oh_sigh wrote: post #124
remcob wrote: post #114

Earlier quoted context omitted.

A rotate operation is invertible, a logic shift by itself is not. Another fun one is x ^= x >> n with n some strictly positive constant, this is also invertible. It's used a lot in the murmurhash family of non-cryptograhic hash functions.

Why does invertibility matter? AND and OR are not invertible, but they are used?

Here's an answer: https://crypto.stackexchange.com/questions/47872/why-is-kecc...

1) it forces you to allocate more memory (to do the Davies-Mayer construction)

2) it complicates the security analysis because you get collisions (if you do not use a permutation, it means you have an injective construction)

Re: Maybe Skip SHA-3

#154

Post by tjalfi »

dfox wrote: post #134
snakeanus wrote: post #75

Earlier quoted context omitted.

I am quite surprised that CRC32 is slower than MD5. > I think the specific variant of BLAKE that directly competed with Keccack is slower BLAKE is slower than BLAKE2 indeed. BLAKE also has more rounds than BLAKE2.

CRC32 is slower because implementing it in software a way that exploits modern CPU's instruction level paralelism is non-trivial, also the obvious way how to implement CRC32 on 32bit byte oriented CPU isn't exactly cache friendly.

Are you referring to Intel's Slicing by 8 algorithm[0].

[0] https://static.aminer.org/pdf/PDF/000/432/446/a_systematic_a...

Re: Maybe Skip SHA-3

#155

Post by baby »

cperciva wrote: post #139
baby wrote: post #108

Earlier quoted context omitted.

I think your mis using "world use case". It's a hash function and so it is usable as a hash function. I'll repeat what was said elsewhere. SHA-2 of vulnerable to length extension attacks.

SHA-2 of vulnerable to length extension attacks. SHA2 is vulnerable to length extension attacks the same way as bread is vulnerable to being buttered. If you're using bread and you're worried about buttering, you fundamentally misunderstand what bread is.

I think you lost everyone here :D

Re: Maybe Skip SHA-3

#156

Post by ComputerGuru »

jasode wrote: post #148
dchest wrote: post #144

Earlier quoted context omitted.

If I recompile Wei Dai's code with optimization, it will make Crypto++ perform better and make blake2sp look slower. Just do it. If it's slower, you're doing something wrong. Which implementation of blake2sp are you measuring? It should be at least 1.5x as fast. Why? If you study the source code, you'll see a loop inside the hash update() function. Why does a loop outside that update() mean "less noise"? Why does add…

I think I found the issue. In terms of absolute (not relative) MB/sec performance, the main culprit is the slow cpu speed of 1.2GHz single threaded performance instead of 3.3GHz. The other investigations into "/O2 /O3" optimizations or 8k outer loop were red herrings. However, for relative MB/sec performance comparison to SHA256, it seems to point back to the blake2 official reference code (non SSE) being very slow.…

If your machine is throttling the CPU during benchmarks, all bets are off. You need to disable all power management and energy savings or else figure out why your machine is causing a throttle to kick in (likely thermal management). You can't compare any results (even relative to one another) until that issue is resolved.

Re: Maybe Skip SHA-3

#157

Post by krakensden »

baby wrote: post #155
cperciva wrote: post #139

Earlier quoted context omitted.

SHA-2 of vulnerable to length extension attacks. SHA2 is vulnerable to length extension attacks the same way as bread is vulnerable to being buttered. If you're using bread and you're worried about buttering, you fundamentally misunderstand what bread is.

I think you lost everyone here :D

Hash functions have a pigeonhole principle problem, but that is also the point.

Re: Maybe Skip SHA-3

#158

Post by stouset »

giovannibajo1 wrote: post #130
stouset wrote: post #112

Earlier quoted context omitted.

I said it's not a reasonable choice in the real world. Virtually anywhere you could use it, you would be better off be using a SHA-2 variant instead. Length extension attacks only apply in cases where you've chosen to use the wrong cryptographic primitive (a hash) for your purpose (a MAC).

Being resistant to common misuses is indeed a feature in real world cryptography. We saw that with DSA where you leak the private key if you happen to reuse a nonce; yes, you shouldn't do that, but it's better to choose an algorithm that doesn't suffer from this in the first place. I'm not rooting for SHA-3; I'm just saying that it's wrong to dismiss length extension attacks only because they're commonly effective ag…

As tptacek points out elsewhere, if this is a concern for you, just use SHA-512/256. It's just as misuse-resistant, practically guaranteed to be in any library that would bother to implement SHA-3, faster by a mile, and has been the target of significantly more cryptanalysis.

There are zero practical reasons to choose SHA-3.

Re: Maybe Skip SHA-3

#159

Post by stouset »

baby wrote: post #135
stouset wrote: post #112

Earlier quoted context omitted.

I said it's not a reasonable choice in the real world. Virtually anywhere you could use it, you would be better off be using a SHA-2 variant instead. Length extension attacks only apply in cases where you've chosen to use the wrong cryptographic primitive (a hash) for your purpose (a MAC).

> Virtually anywhere you could use it, you would be better off be using a SHA-2 variant instead I don't see why, unless you're google and you care about small performance improvement in hash implementations. My point of view is that SHA-3 (or Blake2/K12) are THE hash functions you should use virtually anywhere. > Length extension attacks only apply in cases where you've chosen to use the wrong cryptographic primitive…

A cryptographic operation making sense to you doesn't make it reasonable. H(password) makes sense to a lot of people, but we're not going to sub in Argon2 for every use of a hash function as a result.

I'm with you on BLAKE2 as a solid choice, but at least it has an advantage in some areas over SHA-2 (speed, margin of security). SHA-3 has no advantages over SHA-2 (particularly SHA-512/256, which is going to be available in any library that would bother to implement SHA-3).

SHA-3 is slower, has been the result of less cryptanalysis, has less battle-tested implementations, and is less widely supported. Practically the only thing it has going for it is a higher number.

You will be hard-pressed to find a respected cryptographer advocating general adoption of SHA-3 — being in the field, I'd wager you'll find 100 who encourage developers to choose SHA-2 for every one who backs SHA-3. Case in point, in this thread alone you have Colin Percival and Thomas Ptacek coming to the defense of SHA-2, not to mention Adam Langley authoring the original post.

Re: Maybe Skip SHA-3

#160

Post by cperciva »

baby wrote: post #155
cperciva wrote: post #139

Earlier quoted context omitted.

SHA-2 of vulnerable to length extension attacks. SHA2 is vulnerable to length extension attacks the same way as bread is vulnerable to being buttered. If you're using bread and you're worried about buttering, you fundamentally misunderstand what bread is.

I think you lost everyone here :D

If length extension attacks are a problem, you're using a hash function for something which a hash function is not intended to be used for; you probably wanted a MAC instead.
Post reply on HN