5 ms·

> 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 attac

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

gcp 9y ago
But aren't we trying to get away from MACs into authenticated ciphers?
- tptacek 9y ago
  An authenticated cipher is usually just a composition of a cipher and a MAC.
  - klodolph 9y ago
    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.
    - tptacek 9y ago
      GCM is just a composition of CTR mode and GMAC.
      - klodolph 9y ago
        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.
        tptacek 9y ago
        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.
        klodolph 9y ago
        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.
        CiPHPerCoder 9y ago
        It's in the Wikipedia entry, even. https://en.wikipedia.org/wiki/Galois/Counter_Mode 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.
        klodolph 9y ago
        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.
  - gcp 9y ago
    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.
    - tptacek 9y ago
      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.
- deleted 9y ago
  [deleted]
- klodolph 9y ago
  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.
- dom0 9y ago
  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.
tptacek 9y ago
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.
- CiPHPerCoder 9y ago
  > BLAKE2 was a SHA-3 finalist, and thus by definition isn't vulnerable to length extension either. BLAKE2 wasn't, but BLAKE was. Aside: Most people should continue to use HMAC-SHA256 instead of worrying about LEAs and justifying a switch to non-HMAC H(secret || message) constructions.
- snakeanus 9y ago
  > BLAKE2 was a SHA-3 finalist I think you mean BLAKE. BLAKE2 was not part of the SHA3 competition.
- ngrilly 9y ago
  > the truncated SHA-2 variants (512/224 and 512/256) are also not susceptible to length extension Any link to some reference document on this topic?
  - fpgaminer 9y ago
    It's pretty straight forward. SHA-2 works by, after padding the message and appending the message's length, breaking the message into chunks. It sets up an initial state, and then sequentially iterates over the chunks updating the state as it goes. At the end, your state is your hash. In other words: state = INITIAL_STATE for chunk in chunks: state = SHA2 (state, chunk) hash = state So it's easy to see that an attacker can take that hash and keep running iterations after the fact. Truncated SHA-2 variants are immune because attackers aren't given state, they're given only a piece of state. They have no way of knowing the rest of state, so they can't continue iterating.

gcp 9y ago

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

tptacek 9y ago
An authenticated cipher is usually just a composition of a cipher and a MAC.
- klodolph 9y ago
  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.
  - tptacek 9y ago
    GCM is just a composition of CTR mode and GMAC.
    - klodolph 9y ago
      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.
      - tptacek 9y ago
        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.
        klodolph 9y ago
        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.
        CiPHPerCoder 9y ago
        It's in the Wikipedia entry, even. https://en.wikipedia.org/wiki/Galois/Counter_Mode 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.
        klodolph 9y ago
        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.
- gcp 9y ago
  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.
  - tptacek 9y ago
    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.
deleted 9y ago
[deleted]
klodolph 9y ago
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.
dom0 9y ago
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.

tptacek 9y ago

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.

CiPHPerCoder 9y ago
> BLAKE2 was a SHA-3 finalist, and thus by definition isn't vulnerable to length extension either. BLAKE2 wasn't, but BLAKE was. Aside: Most people should continue to use HMAC-SHA256 instead of worrying about LEAs and justifying a switch to non-HMAC H(secret || message) constructions.
snakeanus 9y ago
> BLAKE2 was a SHA-3 finalist I think you mean BLAKE. BLAKE2 was not part of the SHA3 competition.
ngrilly 9y ago
> the truncated SHA-2 variants (512/224 and 512/256) are also not susceptible to length extension Any link to some reference document on this topic?
- fpgaminer 9y ago
  It's pretty straight forward. SHA-2 works by, after padding the message and appending the message's length, breaking the message into chunks. It sets up an initial state, and then sequentially iterates over the chunks updating the state as it goes. At the end, your state is your hash. In other words: state = INITIAL_STATE for chunk in chunks: state = SHA2 (state, chunk) hash = state So it's easy to see that an attacker can take that hash and keep running iterations after the fact. Truncated SHA-2 variants are immune because attackers aren't given state, they're given only a piece of state. They have no way of knowing the rest of state, so they can't continue iterating.