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

31–40 of 188 posts

Re: Maybe Skip SHA-3

#31

Post by mikeash »

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.

Re: Maybe Skip SHA-3

#32

Post by tptacek »

gcp wrote: post #29
tptacek wrote: post #10

Earlier quoted context omitted.

An authenticated cipher is usually just a composition of a cipher and a MAC.

Presumably, if you're using the composition, it's hardened against the length-extension attack in the first place, right? I mean the advantage seems to only be there when you're cobbling together your own constructions, i.e. doing what you shouldn't be doing.

Length extension attacks are idiosyncratic to hash functions with a particular underlying design (Merkle-Damgard compression). They are the reason we have HMAC. AEADs built on MACs that are not built on general-purpose hash functions don't have that problem.

Re: Maybe Skip SHA-3

#33

Post by dom0 »

JoshTriplett wrote: post #2

SHA-3 does seem to have relatively little to offer by way of incentives to switch. "Just as good" isn't motivation, and any notions of higher cryptographic strength haven't been extensively discussed. "Easier to implement in hardware" will be more compelling when such hardware exists. I'm curious about the statement that SHA-3 is slow; it links to https://www.imperialviolet.org/2016/05/16/agility.html , which doesn't…

> "Easier to implement in hardware" will be more compelling when such hardware exists.

Most things are software; from previous experience we know that it basically takes 10 to 15 years between introduction of a primitive (AES and SHA-2 both standardised around 2000; ISA extensions for mainstream CPUs introduced in 2010-2017). From the software PoV SHA-3 would be a rather large regression in performance with a "maybe it's fast by 2030 if Intel is really nice" attached. BLAKE2 on the other hand is an improvement in performance and offers a function that is more modern overall. (E.g. not length-extensible thus low-overhead keyed hash usage, flexible output sizes, tree hashing built-in)

Re: Maybe Skip SHA-3

#34

Post by aicez »

tptacek wrote: post #28
aicez wrote: post #25

Earlier quoted context omitted.

I suspect that the extra hardware support is not a major concern. This might be because any company that has a true security concern will eventually need to designated an area on its silicon for cryptographic purposes. This area will be security hardened to protect against any side-channel attacks. Also, sharing HW resource for cryptographic purposes is not possible for any device that needs to pass certain security…

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-submissions.html). I'm not sure how this will affect the overall usage of authenticated encryption in the industry, but this is currently one of the main topics of interest for cryptographic researchers.

"As someone who has done a number of audits for certified devices, I don't think your statement about shared hardware is accurate. Are you talking about FIPS 140?"

Yes. Is my understanding incorrect? I'd like to be informed if this is the case. Thanks.

Re: Maybe Skip SHA-3

#35

Post by klodolph »

tptacek wrote: post #26
klodolph wrote: post #24

Earlier quoted context omitted.

Well, technically you'd get a different result if you applied GMAC after using CTR mode, because the final stage of the GMAC would get a different length value, but the process would be very similar. From a different perspective, GMAC is just GCM without encryption. It's not like GMAC existed and then it was combined with AES to make AES-GCM, it was designed as authenticated encryption and has the ability to encrypt…

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.

Re: Maybe Skip SHA-3

#36

Post by klodolph »

dchest wrote: post #27
klodolph wrote: post #24

Earlier quoted context omitted.

Well, technically you'd get a different result if you applied GMAC after using CTR mode, because the final stage of the GMAC would get a different length value, but the process would be very similar. From a different perspective, GMAC is just GCM without encryption. It's not like GMAC existed and then it was combined with AES to make AES-GCM, it was designed as authenticated encryption and has the ability to encrypt…

It is a composition. Some examples of non-composition schemes are sponge-based Keyak and NORX.

Which MAC does AES-GCM use? It's not GMAC, because GMAC would give different results...

Re: Maybe Skip SHA-3

#37

Post by dom0 »

gcp wrote: post #8
snakeanus wrote: post #6

> SHA-3 did introduce something useful To me the most useful part of SHA-3 is that you don't need to use HMAC as it is not vulnerable to length extension attacks. Meaning that it's much faster than SHA-2 when used as a MAC construction.

But aren't we trying to get away from MACs into authenticated ciphers?

There are many applications for MACs and keyed hashes, not all involve encryption (e.g. hash-based deduplication). All mainstream AEAD constructions (AES-GCM, Chapoly, AES-OCB) also generate "only" 128 bit authentication tags, while EtM easily allows larger MACs; whether this is an actual advantage or simply satisfies "crypto paranoia" ... ;)

Not "crypto paranoia"; current mainstream AEAD tends to break both confidentiality and integrity at the same time when misused (e.g. nonce reuse). EtM doesn't do that.

Re: Maybe Skip SHA-3

#38

Post by CiPHPerCoder »

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.

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.

Re: Maybe Skip SHA-3

#39

Post by dchest »

klodolph wrote: post #36
dchest wrote: post #27

Earlier quoted context omitted.

It is a composition. Some examples of non-composition schemes are sponge-based Keyak and NORX.

Which MAC does AES-GCM use? It's not GMAC, because GMAC would give different results...

It uses a Carter-Wegman MAC variant.

Re: Maybe Skip SHA-3

#40

Post by klodolph »

CiPHPerCoder wrote: post #38
klodolph wrote: post #35

Earlier quoted context omitted.

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.

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 a special case of GCM, and GCM is not simply GMAC + CTR. This is supported by the NIST publication which defines them:

> If the GCM input is restricted to data that is not to be encrypted, the resulting specialization of GCM, called GMAC, is simply an authentication mode on the input data.

Again, GCM != CTR + GMAC, if you make this assumption you will fail to interoperate with correct implementations of GCM.

Post reply on HN