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

81–90 of 188 posts

Re: Maybe Skip SHA-3

#81

Post by remcob »

tptacek wrote: post #71
remcob wrote: post #62

Earlier quoted context omitted.

True, the symmetric primitives are sort of interchangeable, but I'd like to see how to build an AEAD using hash functions that doesn't require you process the data twice. I don't think it can be easily done, if at all. It certainly won't do to combine a HMAC with a CTR-mode encryption. Keccak allows for very simple and efficient implementations of all these primitives. > H(key ‖ m) This is insecure for SHA2 (length e…

Why can't you just use a prefix MAC with SHA-2 512/224?

You can, and you just invented the Sponge construction in the process! :)

The key idea is to only expose part of the state to inputs/outputs.

Re: Maybe Skip SHA-3

#82

Post by tptacek »

baby wrote: post #76
tptacek wrote: post #53

Earlier quoted context omitted.

The track record on that design strategy is not good. We've been pursuing designs with cryptographic diversity built in for several decades, and the result has been decades of terrible vulnerabilities --- almost none of which have been mitigated by diversity!

Have we had some big crypto failures besides "everyone was using md5" and "everyone was using DES"?

Yes: for instance, the TLS BEAST vulnerability, which affected all the block ciphers in that version of TLS, because the protocol standardized interchangeable ciphers and a message encryption construction based on CBC as separate components.

Ironically, when the RC4 attack refinements were published, for awhile sites were forced to choose between a vulnerable CBC implementation and using the vulnerable RC4 cipher.

With the exception of MD5 in X.509 certificates and RC4 in TLS, has there been another cryptographic vulnerability that required the retirement of a cipher? SWEET32 is about as close as you come to that, right?

And, obviously, there have been many more problems, even just in TLS, than X.509 MD5 and RC4.

Re: Maybe Skip SHA-3

#83

Post by tptacek »

remcob wrote: post #81
tptacek wrote: post #71

Earlier quoted context omitted.

Why can't you just use a prefix MAC with SHA-2 512/224?

You can, and you just invented the Sponge construction in the process! :) The key idea is to only expose part of the state to inputs/outputs.

Sure, but SHA-2 512/224 predates SHA-3 and the Sponge construction by, what, a decade and a half?

And prefix MACs predate all these things by multiple decades (they just happen to be insecure in full-width-output MD hashes).

I don't think the ability to use Keccak as a simple prefix MAC is all that gamechanging. You can hash data once --- and much, much faster --- by using SHA-2.

Re: Maybe Skip SHA-3

#84

Post by tptacek »

ktta wrote: post #79

My suggestion after looking around for the best hash function is SHA-256. Not SHA-512, not SHA-512/256. Not even SHA-224 because it offers no performance benefits. BLAKE2 is a good candidate right now considering speed. But SHA-256 instructions will only get more prevalent which will take care of the speed issue. There have been speed comparisons between SHA-256 and BLAKE2 without SHA instructions[1]. BLAKE2 seems li…

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.

Re: Maybe Skip SHA-3

#85

Post by tptacek »

agl wrote: post #66
matt_wulfeck wrote: post #64

Why don't we use hash functions that combine the output of two discrete hashing functions and combine the results? It seems to me it's easy to break sha or md5, but what about breaking two fundemantally different algorithms at the same time ? Implementation seems as easy as concatenating the two hex outputs into a single string and comparing the results. I'm curious to what others think of this idea.

It turned out that breaking the combination is SHA-1 and MD-5 is much easier than people expected: https://www.iacr.org/archive/crypto2004/31520306/multicollis...

Shameless plug (this is one of Sean's, though):

http://cryptopals.com/sets/7/challenges/52

Re: Maybe Skip SHA-3

#86

Post by baby »

tptacek wrote: post #82
baby wrote: post #76

Earlier quoted context omitted.

Have we had some big crypto failures besides "everyone was using md5" and "everyone was using DES"?

Yes: for instance, the TLS BEAST vulnerability, which affected all the block ciphers in that version of TLS, because the protocol standardized interchangeable ciphers and a message encryption construction based on CBC as separate components. Ironically, when the RC4 attack refinements were published, for awhile sites were forced to choose between a vulnerable CBC implementation and using the vulnerable RC4 cipher. Wi…

Wasn't that more because we had not really thought of aead constructions? I mean we didn't even know we had to mac after encrypting.

If we had more stream ciphers at the time we would not have been stuck with beast or rc4.

Imo sweet32 was just the weak but well-marketed cherry on the top to get rid of the previous generation. We just had the sha-1 collision.

Re: Maybe Skip SHA-3

#87

Post by tptacek »

baby wrote: post #86
tptacek wrote: post #82

Earlier quoted context omitted.

Yes: for instance, the TLS BEAST vulnerability, which affected all the block ciphers in that version of TLS, because the protocol standardized interchangeable ciphers and a message encryption construction based on CBC as separate components. Ironically, when the RC4 attack refinements were published, for awhile sites were forced to choose between a vulnerable CBC implementation and using the vulnerable RC4 cipher. Wi…

Wasn't that more because we had not really thought of aead constructions? I mean we didn't even know we had to mac after encrypting. If we had more stream ciphers at the time we would not have been stuck with beast or rc4. Imo sweet32 was just the weak but well-marketed cherry on the top to get rid of the previous generation. We just had the sha-1 collision.

We had plenty of good ciphers available in TLS when this happened, but because the BEAST bug was in joinery and not in the cipher itself, it didn't help. Cipher agility didn't help, and in fact probably hurt us.

Re: Maybe Skip SHA-3

#88

Post by baby »

tptacek wrote: post #84
ktta wrote: post #79

My suggestion after looking around for the best hash function is SHA-256. Not SHA-512, not SHA-512/256. Not even SHA-224 because it offers no performance benefits. BLAKE2 is a good candidate right now considering speed. But SHA-256 instructions will only get more prevalent which will take care of the speed issue. There have been speed comparisons between SHA-256 and BLAKE2 without SHA instructions[1]. BLAKE2 seems li…

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.

But people don't know that. That's why it is best to just push people towards sha-3 and have the in-house cryptographer decide when sha-2/blake2/kangarootwelve might be relevant for speed purposes.

Re: Maybe Skip SHA-3

#89

Post by ktta »

tptacek wrote: post #84
ktta wrote: post #79

My suggestion after looking around for the best hash function is SHA-256. Not SHA-512, not SHA-512/256. Not even SHA-224 because it offers no performance benefits. BLAKE2 is a good candidate right now considering speed. But SHA-256 instructions will only get more prevalent which will take care of the speed issue. There have been speed comparisons between SHA-256 and BLAKE2 without SHA instructions[1]. BLAKE2 seems li…

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.

Re: Maybe Skip SHA-3

#90

Post by arghwhat »

tptacek wrote: post #57
arghwhat wrote: post #52

Earlier quoted context omitted.

A good and simple example of a Keccak benefit is the KMAC, which is a lot simpler than the construct HMAC needed by the Merkle-Damgård family of hashes. But the article is right that newer crypto, or more crypto, is not necessarily a good thing. It is also true that there is no need for people to rush to Keccak - SHA-256 and SHA-512 are not broken. It is mostly an interesting function for development of new cryptogra…

It is simpler, but how meaningful is that in practice? HMAC is universally available in crypto libraries, far more so than SHA-3 is, and since HMAC needs to interoperate (even more so than ciphers do), it's practically never botched in code. I sort of object to the idea that HMAC is complicated, also. It's more complicated than KMAC which barely deserves a name, but any intern can implement HMAC reliably from the dia…

People still occasionally implement HMAC as `H(K||msg)` or `H(msg||K)`, use defective AES modes, use IV's and nonces inappropriately, use ARC4, use MD5, and use SHA-1. Pretty sure a quick Wikipedia read would have stopped Adobe from DES encrypting passwords as well.

Simpler means less likely to misunderstand or fuck up, which is a good property to have.

I did also point out that it is mostly interesting for development of new constructs. There's very little point in replacing a working, properly implemented HMAC with a KMAC at this point.

... In the future, however, Keccak may be used for more constructs (aead, for example), at which point a shared "core" for all the crypto you use would be an interesting thing to have, reducing the amount of trusted constructs, sharing optimizations (handwritten asm or hw), and so forth. At that point, migrating would be a sensible thing to do.

Post reply on HN