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

41–50 of 188 posts

Re: Maybe Skip SHA-3

#41

Post by dchest »

klodolph wrote: post #35
tptacek wrote: post #26

Earlier quoted context omitted.

I'm not sure what you're trying to argue here. Yes: you can in fact use GMAC without encrypting (technically, that's what "GMAC mode" is.) That's my point. We're not moving away from MACs, and most authenticated schemes are an encryption mode (usually CTR) composed with a MAC. I think the term "block cipher mode" is responsible for the confusion. It has no coherent meaning.

I think you're making a rather fine point here. You're saying that we haven't stopped using MACs because AES-GCM is a composition of a MAC with an encryption mode. But that's not true. There's no such MAC. A MAC was derived from GCM but that MAC is not used to authenticate encrypted GCM messages. If you can tell me which MAC is used for AES-GCM, go ahead, I'd like to know what it's called.

This MAC did not magically appear from GCM, it is a variant of Carter-Wegman MAC. It's in the same class as Poly1305 and UMAC, VMAC. It was combined with CTR mode to create GCM.

Poly1305 as used in NaCl (XSalsa20-Poly1305) or in TLS (ChaCha20-Poly1305) also will give different results, especially compared to the original proposal Poly1305-AES MAC, but this doesn't mean that those two are not compositions of a cipher and MAC.

Re: Maybe Skip SHA-3

#43

Post by smarx007 »

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 think it's more relevant for the IoT devices, which run or ARM M0/M4 (see http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentation... and https://realtimelogic.com/products/sharkssl/Cortex-M0/).

Re: Maybe Skip SHA-3

#44

Post by hdhzy »

mikeash wrote: post #31
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.

That massive storage is often still using a heavily constrained data connection. Apple, for example, won't let you download an app over 100MB over cellular data. You want to really try to keep your app under that limit, otherwise a lot of potential users will abandon the app if they discover it while they're not on WiFi.

I wonder why is that, I had a shared plan (3 numbers) that gave about 99 GB each month and Apple wouldn't let me download a 100 MB game through LTE?

Re: Maybe Skip SHA-3

#45

Post by remcob »

> SHA-3 did introduce something useful: extendable output functions

Much more than that!

Keccak (SHA-3) introduced the Sponge construction. This goes _way_ further than extendable output functions: It allows you to build all the symmetric cryptographic primitives from one basic element! This means: hashes, PRNGs, MACs, encryption, AEAD, etc. The only thing you need that looks like crypto code is a single permutation function. This significantly reduces the amount of security critical code to write. If you talk about hardware implementations, the permutation function takes less die space than SHA2, and optimizes all these primitives.

The sponge construction and all it's derivatives are proven secure assuming the permutation function is. And assuming SHA3 is secure, the permutation function is too. The alternative, the Merkle–Damgård construction, has a bunch of known problems. It's also used by pretty much every thing else, so it made sense to diversify.

Honestly, I'm a bit sad by the reputation SHA-3 is getting. It is an eye-opening elegant design that makes all previous crypto look overly complex.

Re: Maybe Skip SHA-3

#46

Post by oconnor663 »

hdhzy wrote: post #44
mikeash wrote: post #31

Earlier quoted context omitted.

That massive storage is often still using a heavily constrained data connection. Apple, for example, won't let you download an app over 100MB over cellular data. You want to really try to keep your app under that limit, otherwise a lot of potential users will abandon the app if they discover it while they're not on WiFi.

I wonder why is that, I had a shared plan (3 numbers) that gave about 99 GB each month and Apple wouldn't let me download a 100 MB game through LTE?

Part of the rule might be an incentive for developers to keep size under control.

Re: Maybe Skip SHA-3

#47

Post by kobeya »

remcob wrote: post #45

> SHA-3 did introduce something useful: extendable output functions Much more than that! Keccak (SHA-3) introduced the Sponge construction. This goes _way_ further than extendable output functions: It allows you to build all the symmetric cryptographic primitives from one basic element! This means: hashes, PRNGs, MACs, encryption, AEAD, etc. The only thing you need that looks like crypto code is a single permutation…

Replying here because you said most of the things I was going to say. This article just makes me sad -- Keccak was chosen for SHA-3 specifically because it turned out SHA-2 wasn't as broken as we feared, and although slow Keccak brings to the table cryptographic diversity and the slew of cool things that can be done with a sponge construction that are now possible using standard cryptographic primitives. NIST made clear that by the time of finalist selection, the point of SHA-3 was NOT to replace SHA-2. OP should know better.

Re: Maybe Skip SHA-3

#48

Post by tptacek »

aicez wrote: post #34
tptacek wrote: post #28

Earlier quoted context omitted.

It's already a problem. The most popular authenticated encryption construction is AES-GCM, which is/was difficult to implement safely on popular mobile platforms because their ARM ISAs required side-channel-prone table-based implementations to be performant. We had to select, in protocols, between Chapoly and GCM to get safety and performance on all those platforms. Most vulnerabilities in cryptosystems happen in the…

That's the reason why I said "suspect" =). I do not claim to know the exact reason for the selection. In any case, the standard is finalized. If you're concern about this being the problem for the next standard which will likely to affect the use of AES-GCM, I suggest you participate in the current cryptographic contest that would target authenticated encryption: CAESAR ( https://competitions.cr.yp.to/caesar-submissi…

There are FIPS certification levels where shared hardware footprint is an issue, but most commercial devices don't need to ship devices with that certification.

I really don't care about what the standards say; thankfully, the important standards, like TLS, aren't bound by what NIST standardizes.

Re: Maybe Skip SHA-3

#49

Post by tptacek »

klodolph wrote: post #40
CiPHPerCoder wrote: post #38

Earlier quoted context omitted.

It's in the Wikipedia entry, even. https://en.wikipedia.org/wiki/Galois/Counter_Mode GCM = CTR + GMAC If you're, elsewhere, using GMAC for some reason and getting a different result when you combine it with CTR mode: Well, that's weird. I'd have to have two implementations to compare to analyze further. But otherwise, this conversation is moot.

If you look at the block diagram in the GCM article you linked, you'll see that the second-to-last block of data added to the authentication tag is len(A)||len(C). These are 64-bit values, concatenated to form a single 128-bit value. So if you use GMAC, you'll have len(A) >= 0, and len(C) == 0. If you use GCM with encrypted data, you'll end up with len(C) > 0, which will give you different results from GMAC. GMAC is…

This is silly. You can call CTR + HMAC-SHA2 an AEAD (if you make allowances for extra data), and it will be one. But if you give two people the independent task to generate a CTR+HMAC-SHA2 AEAD construction, their results will not interoperate (which you might or might not care about). You're fixated on the fact that GCM is at pains to make sure it interoperates, and so specifies specific details about how to couple AES-CTR and GHASH. Every AEAD construction has to do that. That doesn't mean they're not compositions of ciphers and MACs.

Re: Maybe Skip SHA-3

#50

Post by richdougherty »

> As I've mentioned before, diversity of cryptographic primitives is expensive. ... exponential number of combinations ... limited developer resources ...

It's a good point that diversity is expensive. There's a counter-argument too: if we all decide to use one thing, but it goes wrong - then we're in serious trouble. If we have multiple approaches, then the damage is lessened if one of them turns out to have problems.

In other words, I think it's better to have a variety of approaches to manage risk, even if it does impose costs.

Post reply on HN