7 ms·

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

by gcp 9y ago

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.
        tptacek 9y ago
        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.
      - dchest 9y ago
        It is a composition. Some examples of non-composition schemes are sponge-based Keyak and NORX.
        klodolph 9y ago
        Which MAC does AES-GCM use? It's not GMAC, because GMAC would give different results...
        dchest 9y ago
        It uses a Carter-Wegman MAC variant.
        klodolph 9y ago
        A variant which only exists as part of the GCM standard, and has no name..
        tptacek 9y ago
        GHASH only exists in the GCM standard too, but does have a name. This, too, is a silly point.
- 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.

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

by 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.
        tptacek 9y ago
        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.
    - dchest 9y ago
      It is a composition. Some examples of non-composition schemes are sponge-based Keyak and NORX.
      - klodolph 9y ago
        Which MAC does AES-GCM use? It's not GMAC, because GMAC would give different results...
        dchest 9y ago
        It uses a Carter-Wegman MAC variant.
        klodolph 9y ago
        A variant which only exists as part of the GCM standard, and has no name..
        tptacek 9y ago
        GHASH only exists in the GCM standard too, but does have a name. This, too, is a silly point.
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.