When do I need to use CBC and HMAC?
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
As I know CBC does not provide integrity for the message, thus HMAC is used to provide integrity for CBC message. Also, I hear about CBC-MAC which can provide integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
And when do I need to use CBC and HMAC?
aes hmac cbc cbc-mac
add a comment |Â
up vote
3
down vote
favorite
As I know CBC does not provide integrity for the message, thus HMAC is used to provide integrity for CBC message. Also, I hear about CBC-MAC which can provide integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
And when do I need to use CBC and HMAC?
aes hmac cbc cbc-mac
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
As I know CBC does not provide integrity for the message, thus HMAC is used to provide integrity for CBC message. Also, I hear about CBC-MAC which can provide integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
And when do I need to use CBC and HMAC?
aes hmac cbc cbc-mac
As I know CBC does not provide integrity for the message, thus HMAC is used to provide integrity for CBC message. Also, I hear about CBC-MAC which can provide integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
And when do I need to use CBC and HMAC?
aes hmac cbc cbc-mac
aes hmac cbc cbc-mac
edited Aug 13 at 16:49
asked Aug 13 at 16:37
Aymn Alaney
2268
2268
add a comment |Â
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
8
down vote
accepted
Also, there is CBC-MAC for providing integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
Generally, asking which one is better results in opinionated answers.
However, since CBC-MAC cannot be used for dynamically sized messages and may lead to compromise when the same key is used, HMAC definitely is less prone to abuse. Differently worded: CBC-MAC is more brittle than HMAC: it may break when abused.
That CBC-MAC it can still be used correctly is shown by the CCM authenticated mode of operation, which uses AES-CTR for confidentiality and AES-CBC-MAC for message integrity & authenticity. It is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.
[EDIT]: I completely read over the fact that this says "integrity and confidentiality". CBC-MAC is a MAC algorithm that has been derived from the CBC mode of operation, hence the name. It does not provide confidentiality itself, it provides just message integrity and message authentication. See Luis' answer for more details. This is also why it is unwise to pair CBC and CBC-MAC (see previous section).
And when do I need to use CBC and HMAC?
You could use it when message integrity and/or message authenticity is required on top of the confidentiality that CBC mode offers. That is: if you are afraid that the ciphertext can be altered by an adversary. Generally transport protocols require message integrity / authenticity.
However, generally we use a modern authenticated mode of operation for that. AEAD ciphers such as AES-GCM and EAX are more robust than putting CBC and HMAC together. For instance, it would be easy to forget to include the IV into the calculation of the authentication tag. If that's forgotten than the adversary can still alter the first block of ciphertext. Likewise, CBC requires an IV that is indistinguishable from random to the adversary, while most AEAD ciphers require a nonce (which could be random, but it could also be a counter).
EAX uses CMAC (or OMAC) as MAC internally. CMAC has been build on top of CBC-MAC to make it secure for dynamically sized messages. The earlier mentioned CCM mode that does use CBC-MAC is also secure, but as a packet mode cipher it can be hard to use (let alone implement, as I found out).
There is an RFC draft called Authenticated Encryption with AES-CBC and HMAC-SHA which tried to standardize CBC and HMAC as an AEAD cipher. That didn't succeed (most other modes are more efficient) but if you want to use CBC with HMAC then it shows a few best practices.
1
"Replacing CBC-MAC with CBC instead of CTR..." -- I'm not sure if it's me, but that part lost me completely.
â ilkkachu
Aug 13 at 20:14
1
@ilkkachu That's certainly a fair criticism, I've replaced that part with "Note that it is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.". If you have additional comments, please let me know!
â Maarten Bodewes
Aug 13 at 21:23
add a comment |Â
up vote
5
down vote
It sounds like you have one big misconception in your question:
Also, I hear about CBC-MAC which can provide integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
The first sentence reads like you misunderstand CBC-MAC to be an algorithm that provides two properties, integrity and confidentiality. But in reality, CBC-MAC can only provide integrity.
The second sentence rests precariously on this misunderstanding, because you're comparing these two alternatives that are not comparable:
- CBC-MAC
- CBC with HMAC
...when the correct comparison would be:
- CBC with CBC-MAC
- CBC with HMAC.
The name CBC-MAC is confusing; CBC-MAC is a MAC-only algorithm that is built off the same basic idea as the CBC encryption-only algorithm. CBC-MAC is a very tricky algorithm to use correctly, so I'd advice you against using it (and against rolling your own cryptography in general). HMAC, in contrast, is reasonably straightforward (for a crypto algorithm that is).
add a comment |Â
up vote
0
down vote
CBC provides message confidentiality, using a block cipher as the primitive.
CBC-MAC provides message integrity, using a block cipher as the primitive, provided one of the following applies:
- the message is of fixed size;
- the key is not reused;
- an appropriate padding mode is used (such as inserting the message size as the first block of the message; a unique counter also works).
HMAC also provides message integrity, using a MerkleâÂÂDamgÃÂ¥rd hash as the primitive.
When one wants message confidentiality and integrity using the above, one wants CBC and one of CBC-MAC or HMAC. That should be with encrypt-then-append-MAC (preferably), or append-MAC-then-encrypt (but with the later unverified data is handled longer, making it more prone to e.g. padding decryption oracle attacks), with in both cases the second-applied layer applied on the full result of the previous layer (exception: with single-use integrity key, the a CBC-MAC or HMAC can be applied on the plaintext and sent non-encrypted).
There is an additional catch when combining CBC and CBC-MAC: the same key must not be used for both confidentiality and integrity; using the same key opens to attacks.
The choice between CBC-MAC and HMAC depends on context. Using HMAC is the least tricky, but CBC-MAC can make sense if speed (especially for short messages) or memory size matters, and all the following applies:
- there is a fast and secure implementation of a block cipher at hand (e.g. AES-NI is available on the target CPU);
- the requirement of different keys for CBC and CBC-MAC can be met;
- the size of the message or a unique value can be inserted in the message's first block, or the CBC-MAC key is never reused (e.g. it is a session key).
Modern practice is block cipher operating modes that give both confidentiality and integrity, e.g. AES-GCM and friends, which (when correctly implemented and used) avoid the possible pitfalls with the CBC and CBC-MAC combination.
append-MAC-then-encrypt is dangerous - the Bleichenbecker attack leverages this. As Matthew Green says (roughly) in one of his blog postings "if the first cryptographic operation you do on a received message is not 'check the integrity', you are doing it wrong"
â Martin Bonner
Aug 14 at 9:11
@Martin Bonner: which Bleichenbecker attack are you refering to? The ones I know are on public-key signature or encryption, not MACs.
â fgrieu
Aug 14 at 9:49
I don't know what I was thinking of when I said that. The bit between the hyphen and the full stop is nonsense. (But the rest isn't - 'MAC then encrypt' is bad).
â Martin Bonner
Aug 14 at 12:02
@Martin Bonner: Indeed MAC-then-encrypt indeed has more failure modes than encrypt-then-MAC. However both are secure when done correctly.
â fgrieu
Aug 14 at 12:35
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
8
down vote
accepted
Also, there is CBC-MAC for providing integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
Generally, asking which one is better results in opinionated answers.
However, since CBC-MAC cannot be used for dynamically sized messages and may lead to compromise when the same key is used, HMAC definitely is less prone to abuse. Differently worded: CBC-MAC is more brittle than HMAC: it may break when abused.
That CBC-MAC it can still be used correctly is shown by the CCM authenticated mode of operation, which uses AES-CTR for confidentiality and AES-CBC-MAC for message integrity & authenticity. It is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.
[EDIT]: I completely read over the fact that this says "integrity and confidentiality". CBC-MAC is a MAC algorithm that has been derived from the CBC mode of operation, hence the name. It does not provide confidentiality itself, it provides just message integrity and message authentication. See Luis' answer for more details. This is also why it is unwise to pair CBC and CBC-MAC (see previous section).
And when do I need to use CBC and HMAC?
You could use it when message integrity and/or message authenticity is required on top of the confidentiality that CBC mode offers. That is: if you are afraid that the ciphertext can be altered by an adversary. Generally transport protocols require message integrity / authenticity.
However, generally we use a modern authenticated mode of operation for that. AEAD ciphers such as AES-GCM and EAX are more robust than putting CBC and HMAC together. For instance, it would be easy to forget to include the IV into the calculation of the authentication tag. If that's forgotten than the adversary can still alter the first block of ciphertext. Likewise, CBC requires an IV that is indistinguishable from random to the adversary, while most AEAD ciphers require a nonce (which could be random, but it could also be a counter).
EAX uses CMAC (or OMAC) as MAC internally. CMAC has been build on top of CBC-MAC to make it secure for dynamically sized messages. The earlier mentioned CCM mode that does use CBC-MAC is also secure, but as a packet mode cipher it can be hard to use (let alone implement, as I found out).
There is an RFC draft called Authenticated Encryption with AES-CBC and HMAC-SHA which tried to standardize CBC and HMAC as an AEAD cipher. That didn't succeed (most other modes are more efficient) but if you want to use CBC with HMAC then it shows a few best practices.
1
"Replacing CBC-MAC with CBC instead of CTR..." -- I'm not sure if it's me, but that part lost me completely.
â ilkkachu
Aug 13 at 20:14
1
@ilkkachu That's certainly a fair criticism, I've replaced that part with "Note that it is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.". If you have additional comments, please let me know!
â Maarten Bodewes
Aug 13 at 21:23
add a comment |Â
up vote
8
down vote
accepted
Also, there is CBC-MAC for providing integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
Generally, asking which one is better results in opinionated answers.
However, since CBC-MAC cannot be used for dynamically sized messages and may lead to compromise when the same key is used, HMAC definitely is less prone to abuse. Differently worded: CBC-MAC is more brittle than HMAC: it may break when abused.
That CBC-MAC it can still be used correctly is shown by the CCM authenticated mode of operation, which uses AES-CTR for confidentiality and AES-CBC-MAC for message integrity & authenticity. It is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.
[EDIT]: I completely read over the fact that this says "integrity and confidentiality". CBC-MAC is a MAC algorithm that has been derived from the CBC mode of operation, hence the name. It does not provide confidentiality itself, it provides just message integrity and message authentication. See Luis' answer for more details. This is also why it is unwise to pair CBC and CBC-MAC (see previous section).
And when do I need to use CBC and HMAC?
You could use it when message integrity and/or message authenticity is required on top of the confidentiality that CBC mode offers. That is: if you are afraid that the ciphertext can be altered by an adversary. Generally transport protocols require message integrity / authenticity.
However, generally we use a modern authenticated mode of operation for that. AEAD ciphers such as AES-GCM and EAX are more robust than putting CBC and HMAC together. For instance, it would be easy to forget to include the IV into the calculation of the authentication tag. If that's forgotten than the adversary can still alter the first block of ciphertext. Likewise, CBC requires an IV that is indistinguishable from random to the adversary, while most AEAD ciphers require a nonce (which could be random, but it could also be a counter).
EAX uses CMAC (or OMAC) as MAC internally. CMAC has been build on top of CBC-MAC to make it secure for dynamically sized messages. The earlier mentioned CCM mode that does use CBC-MAC is also secure, but as a packet mode cipher it can be hard to use (let alone implement, as I found out).
There is an RFC draft called Authenticated Encryption with AES-CBC and HMAC-SHA which tried to standardize CBC and HMAC as an AEAD cipher. That didn't succeed (most other modes are more efficient) but if you want to use CBC with HMAC then it shows a few best practices.
1
"Replacing CBC-MAC with CBC instead of CTR..." -- I'm not sure if it's me, but that part lost me completely.
â ilkkachu
Aug 13 at 20:14
1
@ilkkachu That's certainly a fair criticism, I've replaced that part with "Note that it is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.". If you have additional comments, please let me know!
â Maarten Bodewes
Aug 13 at 21:23
add a comment |Â
up vote
8
down vote
accepted
up vote
8
down vote
accepted
Also, there is CBC-MAC for providing integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
Generally, asking which one is better results in opinionated answers.
However, since CBC-MAC cannot be used for dynamically sized messages and may lead to compromise when the same key is used, HMAC definitely is less prone to abuse. Differently worded: CBC-MAC is more brittle than HMAC: it may break when abused.
That CBC-MAC it can still be used correctly is shown by the CCM authenticated mode of operation, which uses AES-CTR for confidentiality and AES-CBC-MAC for message integrity & authenticity. It is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.
[EDIT]: I completely read over the fact that this says "integrity and confidentiality". CBC-MAC is a MAC algorithm that has been derived from the CBC mode of operation, hence the name. It does not provide confidentiality itself, it provides just message integrity and message authentication. See Luis' answer for more details. This is also why it is unwise to pair CBC and CBC-MAC (see previous section).
And when do I need to use CBC and HMAC?
You could use it when message integrity and/or message authenticity is required on top of the confidentiality that CBC mode offers. That is: if you are afraid that the ciphertext can be altered by an adversary. Generally transport protocols require message integrity / authenticity.
However, generally we use a modern authenticated mode of operation for that. AEAD ciphers such as AES-GCM and EAX are more robust than putting CBC and HMAC together. For instance, it would be easy to forget to include the IV into the calculation of the authentication tag. If that's forgotten than the adversary can still alter the first block of ciphertext. Likewise, CBC requires an IV that is indistinguishable from random to the adversary, while most AEAD ciphers require a nonce (which could be random, but it could also be a counter).
EAX uses CMAC (or OMAC) as MAC internally. CMAC has been build on top of CBC-MAC to make it secure for dynamically sized messages. The earlier mentioned CCM mode that does use CBC-MAC is also secure, but as a packet mode cipher it can be hard to use (let alone implement, as I found out).
There is an RFC draft called Authenticated Encryption with AES-CBC and HMAC-SHA which tried to standardize CBC and HMAC as an AEAD cipher. That didn't succeed (most other modes are more efficient) but if you want to use CBC with HMAC then it shows a few best practices.
Also, there is CBC-MAC for providing integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
Generally, asking which one is better results in opinionated answers.
However, since CBC-MAC cannot be used for dynamically sized messages and may lead to compromise when the same key is used, HMAC definitely is less prone to abuse. Differently worded: CBC-MAC is more brittle than HMAC: it may break when abused.
That CBC-MAC it can still be used correctly is shown by the CCM authenticated mode of operation, which uses AES-CTR for confidentiality and AES-CBC-MAC for message integrity & authenticity. It is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.
[EDIT]: I completely read over the fact that this says "integrity and confidentiality". CBC-MAC is a MAC algorithm that has been derived from the CBC mode of operation, hence the name. It does not provide confidentiality itself, it provides just message integrity and message authentication. See Luis' answer for more details. This is also why it is unwise to pair CBC and CBC-MAC (see previous section).
And when do I need to use CBC and HMAC?
You could use it when message integrity and/or message authenticity is required on top of the confidentiality that CBC mode offers. That is: if you are afraid that the ciphertext can be altered by an adversary. Generally transport protocols require message integrity / authenticity.
However, generally we use a modern authenticated mode of operation for that. AEAD ciphers such as AES-GCM and EAX are more robust than putting CBC and HMAC together. For instance, it would be easy to forget to include the IV into the calculation of the authentication tag. If that's forgotten than the adversary can still alter the first block of ciphertext. Likewise, CBC requires an IV that is indistinguishable from random to the adversary, while most AEAD ciphers require a nonce (which could be random, but it could also be a counter).
EAX uses CMAC (or OMAC) as MAC internally. CMAC has been build on top of CBC-MAC to make it secure for dynamically sized messages. The earlier mentioned CCM mode that does use CBC-MAC is also secure, but as a packet mode cipher it can be hard to use (let alone implement, as I found out).
There is an RFC draft called Authenticated Encryption with AES-CBC and HMAC-SHA which tried to standardize CBC and HMAC as an AEAD cipher. That didn't succeed (most other modes are more efficient) but if you want to use CBC with HMAC then it shows a few best practices.
edited Aug 14 at 2:08
answered Aug 13 at 17:04
Maarten Bodewes
47.9k567178
47.9k567178
1
"Replacing CBC-MAC with CBC instead of CTR..." -- I'm not sure if it's me, but that part lost me completely.
â ilkkachu
Aug 13 at 20:14
1
@ilkkachu That's certainly a fair criticism, I've replaced that part with "Note that it is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.". If you have additional comments, please let me know!
â Maarten Bodewes
Aug 13 at 21:23
add a comment |Â
1
"Replacing CBC-MAC with CBC instead of CTR..." -- I'm not sure if it's me, but that part lost me completely.
â ilkkachu
Aug 13 at 20:14
1
@ilkkachu That's certainly a fair criticism, I've replaced that part with "Note that it is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.". If you have additional comments, please let me know!
â Maarten Bodewes
Aug 13 at 21:23
1
1
"Replacing CBC-MAC with CBC instead of CTR..." -- I'm not sure if it's me, but that part lost me completely.
â ilkkachu
Aug 13 at 20:14
"Replacing CBC-MAC with CBC instead of CTR..." -- I'm not sure if it's me, but that part lost me completely.
â ilkkachu
Aug 13 at 20:14
1
1
@ilkkachu That's certainly a fair criticism, I've replaced that part with "Note that it is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.". If you have additional comments, please let me know!
â Maarten Bodewes
Aug 13 at 21:23
@ilkkachu That's certainly a fair criticism, I've replaced that part with "Note that it is unwise to replace CTR mode with CBC in CCM mode because CBC with CBC-MAC is likely to introduce security vulnerabilities.". If you have additional comments, please let me know!
â Maarten Bodewes
Aug 13 at 21:23
add a comment |Â
up vote
5
down vote
It sounds like you have one big misconception in your question:
Also, I hear about CBC-MAC which can provide integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
The first sentence reads like you misunderstand CBC-MAC to be an algorithm that provides two properties, integrity and confidentiality. But in reality, CBC-MAC can only provide integrity.
The second sentence rests precariously on this misunderstanding, because you're comparing these two alternatives that are not comparable:
- CBC-MAC
- CBC with HMAC
...when the correct comparison would be:
- CBC with CBC-MAC
- CBC with HMAC.
The name CBC-MAC is confusing; CBC-MAC is a MAC-only algorithm that is built off the same basic idea as the CBC encryption-only algorithm. CBC-MAC is a very tricky algorithm to use correctly, so I'd advice you against using it (and against rolling your own cryptography in general). HMAC, in contrast, is reasonably straightforward (for a crypto algorithm that is).
add a comment |Â
up vote
5
down vote
It sounds like you have one big misconception in your question:
Also, I hear about CBC-MAC which can provide integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
The first sentence reads like you misunderstand CBC-MAC to be an algorithm that provides two properties, integrity and confidentiality. But in reality, CBC-MAC can only provide integrity.
The second sentence rests precariously on this misunderstanding, because you're comparing these two alternatives that are not comparable:
- CBC-MAC
- CBC with HMAC
...when the correct comparison would be:
- CBC with CBC-MAC
- CBC with HMAC.
The name CBC-MAC is confusing; CBC-MAC is a MAC-only algorithm that is built off the same basic idea as the CBC encryption-only algorithm. CBC-MAC is a very tricky algorithm to use correctly, so I'd advice you against using it (and against rolling your own cryptography in general). HMAC, in contrast, is reasonably straightforward (for a crypto algorithm that is).
add a comment |Â
up vote
5
down vote
up vote
5
down vote
It sounds like you have one big misconception in your question:
Also, I hear about CBC-MAC which can provide integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
The first sentence reads like you misunderstand CBC-MAC to be an algorithm that provides two properties, integrity and confidentiality. But in reality, CBC-MAC can only provide integrity.
The second sentence rests precariously on this misunderstanding, because you're comparing these two alternatives that are not comparable:
- CBC-MAC
- CBC with HMAC
...when the correct comparison would be:
- CBC with CBC-MAC
- CBC with HMAC.
The name CBC-MAC is confusing; CBC-MAC is a MAC-only algorithm that is built off the same basic idea as the CBC encryption-only algorithm. CBC-MAC is a very tricky algorithm to use correctly, so I'd advice you against using it (and against rolling your own cryptography in general). HMAC, in contrast, is reasonably straightforward (for a crypto algorithm that is).
It sounds like you have one big misconception in your question:
Also, I hear about CBC-MAC which can provide integrity and confidentiality. Which one is better CBC-MAC or CBC with HMAC?
The first sentence reads like you misunderstand CBC-MAC to be an algorithm that provides two properties, integrity and confidentiality. But in reality, CBC-MAC can only provide integrity.
The second sentence rests precariously on this misunderstanding, because you're comparing these two alternatives that are not comparable:
- CBC-MAC
- CBC with HMAC
...when the correct comparison would be:
- CBC with CBC-MAC
- CBC with HMAC.
The name CBC-MAC is confusing; CBC-MAC is a MAC-only algorithm that is built off the same basic idea as the CBC encryption-only algorithm. CBC-MAC is a very tricky algorithm to use correctly, so I'd advice you against using it (and against rolling your own cryptography in general). HMAC, in contrast, is reasonably straightforward (for a crypto algorithm that is).
answered Aug 13 at 23:31
Luis Casillas
8,98211135
8,98211135
add a comment |Â
add a comment |Â
up vote
0
down vote
CBC provides message confidentiality, using a block cipher as the primitive.
CBC-MAC provides message integrity, using a block cipher as the primitive, provided one of the following applies:
- the message is of fixed size;
- the key is not reused;
- an appropriate padding mode is used (such as inserting the message size as the first block of the message; a unique counter also works).
HMAC also provides message integrity, using a MerkleâÂÂDamgÃÂ¥rd hash as the primitive.
When one wants message confidentiality and integrity using the above, one wants CBC and one of CBC-MAC or HMAC. That should be with encrypt-then-append-MAC (preferably), or append-MAC-then-encrypt (but with the later unverified data is handled longer, making it more prone to e.g. padding decryption oracle attacks), with in both cases the second-applied layer applied on the full result of the previous layer (exception: with single-use integrity key, the a CBC-MAC or HMAC can be applied on the plaintext and sent non-encrypted).
There is an additional catch when combining CBC and CBC-MAC: the same key must not be used for both confidentiality and integrity; using the same key opens to attacks.
The choice between CBC-MAC and HMAC depends on context. Using HMAC is the least tricky, but CBC-MAC can make sense if speed (especially for short messages) or memory size matters, and all the following applies:
- there is a fast and secure implementation of a block cipher at hand (e.g. AES-NI is available on the target CPU);
- the requirement of different keys for CBC and CBC-MAC can be met;
- the size of the message or a unique value can be inserted in the message's first block, or the CBC-MAC key is never reused (e.g. it is a session key).
Modern practice is block cipher operating modes that give both confidentiality and integrity, e.g. AES-GCM and friends, which (when correctly implemented and used) avoid the possible pitfalls with the CBC and CBC-MAC combination.
append-MAC-then-encrypt is dangerous - the Bleichenbecker attack leverages this. As Matthew Green says (roughly) in one of his blog postings "if the first cryptographic operation you do on a received message is not 'check the integrity', you are doing it wrong"
â Martin Bonner
Aug 14 at 9:11
@Martin Bonner: which Bleichenbecker attack are you refering to? The ones I know are on public-key signature or encryption, not MACs.
â fgrieu
Aug 14 at 9:49
I don't know what I was thinking of when I said that. The bit between the hyphen and the full stop is nonsense. (But the rest isn't - 'MAC then encrypt' is bad).
â Martin Bonner
Aug 14 at 12:02
@Martin Bonner: Indeed MAC-then-encrypt indeed has more failure modes than encrypt-then-MAC. However both are secure when done correctly.
â fgrieu
Aug 14 at 12:35
add a comment |Â
up vote
0
down vote
CBC provides message confidentiality, using a block cipher as the primitive.
CBC-MAC provides message integrity, using a block cipher as the primitive, provided one of the following applies:
- the message is of fixed size;
- the key is not reused;
- an appropriate padding mode is used (such as inserting the message size as the first block of the message; a unique counter also works).
HMAC also provides message integrity, using a MerkleâÂÂDamgÃÂ¥rd hash as the primitive.
When one wants message confidentiality and integrity using the above, one wants CBC and one of CBC-MAC or HMAC. That should be with encrypt-then-append-MAC (preferably), or append-MAC-then-encrypt (but with the later unverified data is handled longer, making it more prone to e.g. padding decryption oracle attacks), with in both cases the second-applied layer applied on the full result of the previous layer (exception: with single-use integrity key, the a CBC-MAC or HMAC can be applied on the plaintext and sent non-encrypted).
There is an additional catch when combining CBC and CBC-MAC: the same key must not be used for both confidentiality and integrity; using the same key opens to attacks.
The choice between CBC-MAC and HMAC depends on context. Using HMAC is the least tricky, but CBC-MAC can make sense if speed (especially for short messages) or memory size matters, and all the following applies:
- there is a fast and secure implementation of a block cipher at hand (e.g. AES-NI is available on the target CPU);
- the requirement of different keys for CBC and CBC-MAC can be met;
- the size of the message or a unique value can be inserted in the message's first block, or the CBC-MAC key is never reused (e.g. it is a session key).
Modern practice is block cipher operating modes that give both confidentiality and integrity, e.g. AES-GCM and friends, which (when correctly implemented and used) avoid the possible pitfalls with the CBC and CBC-MAC combination.
append-MAC-then-encrypt is dangerous - the Bleichenbecker attack leverages this. As Matthew Green says (roughly) in one of his blog postings "if the first cryptographic operation you do on a received message is not 'check the integrity', you are doing it wrong"
â Martin Bonner
Aug 14 at 9:11
@Martin Bonner: which Bleichenbecker attack are you refering to? The ones I know are on public-key signature or encryption, not MACs.
â fgrieu
Aug 14 at 9:49
I don't know what I was thinking of when I said that. The bit between the hyphen and the full stop is nonsense. (But the rest isn't - 'MAC then encrypt' is bad).
â Martin Bonner
Aug 14 at 12:02
@Martin Bonner: Indeed MAC-then-encrypt indeed has more failure modes than encrypt-then-MAC. However both are secure when done correctly.
â fgrieu
Aug 14 at 12:35
add a comment |Â
up vote
0
down vote
up vote
0
down vote
CBC provides message confidentiality, using a block cipher as the primitive.
CBC-MAC provides message integrity, using a block cipher as the primitive, provided one of the following applies:
- the message is of fixed size;
- the key is not reused;
- an appropriate padding mode is used (such as inserting the message size as the first block of the message; a unique counter also works).
HMAC also provides message integrity, using a MerkleâÂÂDamgÃÂ¥rd hash as the primitive.
When one wants message confidentiality and integrity using the above, one wants CBC and one of CBC-MAC or HMAC. That should be with encrypt-then-append-MAC (preferably), or append-MAC-then-encrypt (but with the later unverified data is handled longer, making it more prone to e.g. padding decryption oracle attacks), with in both cases the second-applied layer applied on the full result of the previous layer (exception: with single-use integrity key, the a CBC-MAC or HMAC can be applied on the plaintext and sent non-encrypted).
There is an additional catch when combining CBC and CBC-MAC: the same key must not be used for both confidentiality and integrity; using the same key opens to attacks.
The choice between CBC-MAC and HMAC depends on context. Using HMAC is the least tricky, but CBC-MAC can make sense if speed (especially for short messages) or memory size matters, and all the following applies:
- there is a fast and secure implementation of a block cipher at hand (e.g. AES-NI is available on the target CPU);
- the requirement of different keys for CBC and CBC-MAC can be met;
- the size of the message or a unique value can be inserted in the message's first block, or the CBC-MAC key is never reused (e.g. it is a session key).
Modern practice is block cipher operating modes that give both confidentiality and integrity, e.g. AES-GCM and friends, which (when correctly implemented and used) avoid the possible pitfalls with the CBC and CBC-MAC combination.
CBC provides message confidentiality, using a block cipher as the primitive.
CBC-MAC provides message integrity, using a block cipher as the primitive, provided one of the following applies:
- the message is of fixed size;
- the key is not reused;
- an appropriate padding mode is used (such as inserting the message size as the first block of the message; a unique counter also works).
HMAC also provides message integrity, using a MerkleâÂÂDamgÃÂ¥rd hash as the primitive.
When one wants message confidentiality and integrity using the above, one wants CBC and one of CBC-MAC or HMAC. That should be with encrypt-then-append-MAC (preferably), or append-MAC-then-encrypt (but with the later unverified data is handled longer, making it more prone to e.g. padding decryption oracle attacks), with in both cases the second-applied layer applied on the full result of the previous layer (exception: with single-use integrity key, the a CBC-MAC or HMAC can be applied on the plaintext and sent non-encrypted).
There is an additional catch when combining CBC and CBC-MAC: the same key must not be used for both confidentiality and integrity; using the same key opens to attacks.
The choice between CBC-MAC and HMAC depends on context. Using HMAC is the least tricky, but CBC-MAC can make sense if speed (especially for short messages) or memory size matters, and all the following applies:
- there is a fast and secure implementation of a block cipher at hand (e.g. AES-NI is available on the target CPU);
- the requirement of different keys for CBC and CBC-MAC can be met;
- the size of the message or a unique value can be inserted in the message's first block, or the CBC-MAC key is never reused (e.g. it is a session key).
Modern practice is block cipher operating modes that give both confidentiality and integrity, e.g. AES-GCM and friends, which (when correctly implemented and used) avoid the possible pitfalls with the CBC and CBC-MAC combination.
edited Aug 14 at 9:48
answered Aug 14 at 7:06
fgrieu
72.9k6149310
72.9k6149310
append-MAC-then-encrypt is dangerous - the Bleichenbecker attack leverages this. As Matthew Green says (roughly) in one of his blog postings "if the first cryptographic operation you do on a received message is not 'check the integrity', you are doing it wrong"
â Martin Bonner
Aug 14 at 9:11
@Martin Bonner: which Bleichenbecker attack are you refering to? The ones I know are on public-key signature or encryption, not MACs.
â fgrieu
Aug 14 at 9:49
I don't know what I was thinking of when I said that. The bit between the hyphen and the full stop is nonsense. (But the rest isn't - 'MAC then encrypt' is bad).
â Martin Bonner
Aug 14 at 12:02
@Martin Bonner: Indeed MAC-then-encrypt indeed has more failure modes than encrypt-then-MAC. However both are secure when done correctly.
â fgrieu
Aug 14 at 12:35
add a comment |Â
append-MAC-then-encrypt is dangerous - the Bleichenbecker attack leverages this. As Matthew Green says (roughly) in one of his blog postings "if the first cryptographic operation you do on a received message is not 'check the integrity', you are doing it wrong"
â Martin Bonner
Aug 14 at 9:11
@Martin Bonner: which Bleichenbecker attack are you refering to? The ones I know are on public-key signature or encryption, not MACs.
â fgrieu
Aug 14 at 9:49
I don't know what I was thinking of when I said that. The bit between the hyphen and the full stop is nonsense. (But the rest isn't - 'MAC then encrypt' is bad).
â Martin Bonner
Aug 14 at 12:02
@Martin Bonner: Indeed MAC-then-encrypt indeed has more failure modes than encrypt-then-MAC. However both are secure when done correctly.
â fgrieu
Aug 14 at 12:35
append-MAC-then-encrypt is dangerous - the Bleichenbecker attack leverages this. As Matthew Green says (roughly) in one of his blog postings "if the first cryptographic operation you do on a received message is not 'check the integrity', you are doing it wrong"
â Martin Bonner
Aug 14 at 9:11
append-MAC-then-encrypt is dangerous - the Bleichenbecker attack leverages this. As Matthew Green says (roughly) in one of his blog postings "if the first cryptographic operation you do on a received message is not 'check the integrity', you are doing it wrong"
â Martin Bonner
Aug 14 at 9:11
@Martin Bonner: which Bleichenbecker attack are you refering to? The ones I know are on public-key signature or encryption, not MACs.
â fgrieu
Aug 14 at 9:49
@Martin Bonner: which Bleichenbecker attack are you refering to? The ones I know are on public-key signature or encryption, not MACs.
â fgrieu
Aug 14 at 9:49
I don't know what I was thinking of when I said that. The bit between the hyphen and the full stop is nonsense. (But the rest isn't - 'MAC then encrypt' is bad).
â Martin Bonner
Aug 14 at 12:02
I don't know what I was thinking of when I said that. The bit between the hyphen and the full stop is nonsense. (But the rest isn't - 'MAC then encrypt' is bad).
â Martin Bonner
Aug 14 at 12:02
@Martin Bonner: Indeed MAC-then-encrypt indeed has more failure modes than encrypt-then-MAC. However both are secure when done correctly.
â fgrieu
Aug 14 at 12:35
@Martin Bonner: Indeed MAC-then-encrypt indeed has more failure modes than encrypt-then-MAC. However both are secure when done correctly.
â fgrieu
Aug 14 at 12:35
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f61475%2fwhen-do-i-need-to-use-cbc-and-hmac%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password