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

161–170 of 188 posts

Re: Maybe Skip SHA-3

#161

Post by ReidZB »

ktta wrote: post #152
RcouF1uZ4gsC wrote: post #115

Earlier quoted context omitted.

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 b…

His idea is correct -- you're right, you don't know the entire internal state. But you can generate 2^32 possible internal states (because there are 32 bits of missing information), then perform the length extension process using each possible state.

If the system is using the hash function in such a way that length extension creates a vulnerability, you can then try the 2^32 different possible valid length extended hashes, and one of them will be correct (and that will be evident because the exploit would work). But you are also correct that, in isolation, there is no way to determine which of the 2^32 resultant digests is the correct.

Re: Maybe Skip SHA-3

#162

Post by ReidZB »

RcouF1uZ4gsC wrote: post #122
tptacek wrote: post #118

Earlier quoted context omitted.

224 is 512/224.

According to https://en.m.wikipedia.org/wiki/SHA-2 There is SHA 224 which has 256 bit internal state and SHA 512/224 which has 512 bit internal state. In my previous comment, I was referring to the former.

This is how it's defined in FIPS-180, more or less (SHA-224 is SHA-256/224). This confusion is why I like explicitly stating SHA-256/x or SHA-512/x.

Re: Maybe Skip SHA-3

#163

Post by [deleted] »

cperciva wrote: post #160
baby wrote: post #155

Earlier quoted context omitted.

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.

[deleted]

Re: Maybe Skip SHA-3

#164

Post by 15155 »

cperciva wrote: post #160
baby wrote: post #155

Earlier quoted context omitted.

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.

Why must MAC mean "HMAC RFC2104?"

Re: Maybe Skip SHA-3

#165

Post by cperciva »

15155 wrote: post #164
cperciva wrote: post #160

Earlier quoted context omitted.

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.

Why must MAC mean "HMAC RFC2104?"

It doesn't. I said MAC, not HMAC.

Re: Maybe Skip SHA-3

#166

Post by Dylan16807 »

agl wrote: post #22
simias wrote: post #19

A rather minor point but: >[The di­ver­sity of cryp­to­graphic prim­i­tives] con­tributes to code-size, which is a worry again in the mo­bile age In the "mobile age" we use embedded processors with gigabytes worth of RAM and several times the amount of NAND storage, I don't really think a SHA-3 implementation is going to tip the boat over. The author's other points seem very fair though.

I can confirm that the code size of BoringSSL is something that we worry about for mobile apps. A 50KB increase (which wouldn't be much for an optimised SHA-3) would raise questions. I admit that when I see the 100MB+ size of apps that I have to download, I do wonder why. But I assume that it would be even worse were people not worrying about this stuff.

> A 50KB increase (which wouldn't be much for an optimised SHA-3) would raise questions.

Can you elaborate on that? That's orders of magnitude bigger than a naive implementation, and wouldn't fit in L1 cache either.

Re: Maybe Skip SHA-3

#167

Post by SAI_Peregrinus »

ktta wrote: post #89
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.

You are right. I guess I'll rethink SHA-224. SHA-512/256 is faster in 64 bit computers but it can't really take advantage of the hardware instructions unlike SHA-224. Prefixing a MAC sounds like it'll work but I'm just wondering why complicate things.

Prefix MAC doesn't mean prefix the MAC. It means make a MAC by prefixing a key and concatenating that onto the data to be tagged. Basically what KMAC does: H(K+pad||message). The truncated hash functions aren't vulnerable to length extension attacks, so using SHA2-512/256 is faster than HMAC with no loss in security AFAIK.

Of course that "no loss in security" bit depends on a proper implementation. There are plenty of good library implementations of HMAC out there, and if you want a high speed MAC there's always Poly1305. But if all you have is SHA2 and don't need to interoperate with systems using HMAC, then this is a reasonably good way to go about it. It's certainly simpler than implementing HMAC on your own.

Re: Maybe Skip SHA-3

#168

Post by ktta »

ReidZB wrote: post #161
ktta wrote: post #152

Earlier quoted context omitted.

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 b…

His idea is correct -- you're right, you don't know the entire internal state. But you can generate 2^32 possible internal states (because there are 32 bits of missing information), then perform the length extension process using each possible state. If the system is using the hash function in such a way that length extension creates a vulnerability, you can then try the 2^32 different possible valid length extended…

Got it, thanks. So looks like it is possible, but infeasible in many cases.

This obviously wouldn't work over internet because of the number of tries required, so what is a possibility that this would actually be a possible vulnerability?

Re: Maybe Skip SHA-3

#169

Post by baby »

stouset wrote: post #159
baby wrote: post #135

Earlier quoted context omitted.

> 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 availab…

If your hash function behaves like a random oracle it should allow you to do h(key|data) hashing password requires more than a random oracle because of the input small entropy so your argument is moot.

The fact that sha-3 has received less analyzis has already been debunked Here:https://twitter.com/aarontoponce/status/869973259969675264 .

K12 has the advantage of the speed. See https://cryptologie.net/article/393/kangarootwelve/

Appeal to authority does nothing. Plenty of people are actually supporting or making use of keccak/sha-3 already. To begin with NIST's cryptographers chose it. David Leon Gil was into it. People talked about heavy usages of SHA-3 in Ethereum or Chain here. I can tell you that one of the originator of SHA-3 created AES (Daemen). Jp aumasson (creator or blake2), samuel neves and philipp jovanovic are using sponges woth NORX. Mike Hamburg is building Strobe based on keccak. I can name drop as well you see.

Plus I'll say that I support it as a wannabe cryptographer. That must count for something :D

Re: Maybe Skip SHA-3

#170

Post by baby »

cperciva wrote: post #160
baby wrote: post #155

Earlier quoted context omitted.

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.

1. Yes. And people do that. I'm nkt talking about me. I'm talking about things I see in my work (I'm a consultant).

2. People should be able to do that. If you're expecting your hash function to behave somehow like a random oracle there is no reason that h(key|data) doesn't work. I see people using sha-2 to derive keys all the time. Even this is unsafe depending on how you do it.

Post reply on HN