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

21–30 of 188 posts

Re: Maybe Skip SHA-3

#21

Post by klodolph »

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?

Not all authenticated messages need to be encrypted, or encrypted using the same key, etc.

For AWS, you authenticate calls to the API by authenticating each message with an HMAC. The call is encrypted over TLS, but TLS is only used to authenticate Amazon to the client, it's not used to authenticate the client to Amazon. There are some use cases where you wouldn't be able to just use client-side certificates anyway--for example, I can create a signature for a single S3 upload to a specific URI with an expiration date, and then send the signature to you, and then you can upload a file directly to my S3 account before the signature expires. (I suspect a big reason client-side certificates aren't used for AWS is because nobody knows how to use them, but they're also less flexible.)

Technically you could also do this using an authentication-only variant of authenticated ciphers, like GMAC, but at that point it would still be classified as a MAC.

Re: Maybe Skip SHA-3

#22

Post by agl »

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.

Re: Maybe Skip SHA-3

#23

Post by snakeanus »

tptacek wrote: post #9
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.

That's a good point, but the truncated SHA-2 variants (512/224 and 512/256) are also not susceptible to length extension, and are faster than SHA-3. BLAKE2 was a SHA-3 finalist, and thus by definition isn't vulnerable to length extension either.

> BLAKE2 was a SHA-3 finalist

I think you mean BLAKE. BLAKE2 was not part of the SHA3 competition.

Re: Maybe Skip SHA-3

#24

Post by klodolph »

tptacek wrote: post #15
klodolph wrote: post #13

Earlier quoted context omitted.

That's historically true, but these days I think GCM is the most common. GCM also has hardware support from the CLMUL instruction set available on Intel processors since 2010 and AMD processors since 2011.

GCM is just a composition of CTR mode and GMAC.

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 zero bytes while still authenticating other bytes.

So no, GCM is not just GMAC + AES.

Re: Maybe Skip SHA-3

#25

Post by aicez »

agl wrote: post #16
aicez wrote: post #11

The assessment that SHA-3's performance is bad completely disregard the results from hardware benchmarking (FPGAs and ASICs). All the hardware results have shown conclusively that Keccak is multiple times faster than SHA-2. While I can't say that the algorithm is going to be supported in HW, with enough usage it might be the case. Edit: Removed my comment regarding BLAKE as it was incorrect.

By selecting primitives designed for hardware (AES and GHASH) rather than primitives that use operations that are commonly applicable (ChaCha20 and Poly1305), we've ended up with extra hardware to support AES and GHASH. But it's not clear that was actually a good idea, or just path dependence. ChaCha20, Poly1305, BLAKE2 benefit from improvements that benefit a wide-range of applications, while SHA-3, AES and GHASH do…

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 certification.

Edit: Typo and additional comment

Re: Maybe Skip SHA-3

#26

Post by tptacek »

klodolph wrote: post #24
tptacek wrote: post #15

Earlier quoted context omitted.

GCM is just a composition of CTR mode and GMAC.

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.

Re: Maybe Skip SHA-3

#27

Post by dchest »

klodolph wrote: post #24
tptacek wrote: post #15

Earlier quoted context omitted.

GCM is just a composition of CTR mode and GMAC.

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.

Re: Maybe Skip SHA-3

#28

Post by tptacek »

aicez wrote: post #25
agl wrote: post #16

Earlier quoted context omitted.

By selecting primitives designed for hardware (AES and GHASH) rather than primitives that use operations that are commonly applicable (ChaCha20 and Poly1305), we've ended up with extra hardware to support AES and GHASH. But it's not clear that was actually a good idea, or just path dependence. ChaCha20, Poly1305, BLAKE2 benefit from improvements that benefit a wide-range of applications, while SHA-3, AES and GHASH do…

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 joinery. Anything we can do to eliminate joinery is going to make our cryptosystems more resilient. Selecting new primitives that will require hardware support to be performant seems like an own-goal.

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?

Re: Maybe Skip SHA-3

#29

Post by gcp »

tptacek wrote: post #10
gcp wrote: post #8

Earlier quoted context omitted.

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

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.

Re: Maybe Skip SHA-3

#30

Post by libeclipse »

aicez wrote: post #11

The assessment that SHA-3's performance is bad completely disregard the results from hardware benchmarking (FPGAs and ASICs). All the hardware results have shown conclusively that Keccak is multiple times faster than SHA-2. While I can't say that the algorithm is going to be supported in HW, with enough usage it might be the case. Edit: Removed my comment regarding BLAKE as it was incorrect.

Well if it's only strong in hardware then that means it's a poor choice for KD in software, as a potential attacker would have a significant advantage.
Post reply on HN