I see often in literature related to cryptographic protocols that MACs (Message Authentication Codes) are not included in protocol definitions.

For example:

A -> S: {TA, B}KAS
S -> A: {TS, KAB, B}KAS
S -> B: {T'S, KAB, A}KBS

Shouldn't it be defined as follows ? (Encrypt-then-MAC + using second key for MACs)

A -> S: {TA, B}KAS, [{TA, B}KAS]KAS'
S -> A: {TS, KAB, B}KAS, [{TS, KAB, B}KAS]KAS'
S -> B: {T'S, KAB, A}KBS, [{T'S, KAB, A}KBS]KBS'

Isn't integrity a concern, or do protocol analysts generally assume that cipher-text cannot be modified at this level of protocol abstraction? Do you exclude ciphertext-only attacks?


migrated from security.stackexchange.com May 9 '16 at 19:35

This question came from our site for information security professionals.


It depends on the protocol. In general IND-CPA secure ciphers are assumed. That would mean that confidentiality is taken care of by the cipher.

If integrity and/or authenticity are also required then it should be made explicit in the protocol. In that case it is however perfectly possible to use one key, e.g. by using an authenticated cipher such as GCM.

If ciphertext only attacks are excluded depends on the context.


as far as I know, MAC's can vary depending on implementation and/or situation, like in SSL certs. So standartizing a MAC hardly can mess things up, so that's why they're not included

  • $\begingroup$ A MAC is used within SSL certs? $\endgroup$ – Maarten Bodewes May 9 '16 at 20:07
  • $\begingroup$ in SSL certs digests are used, but no strict algo list, that's why you can encounter a weak SHA-1 ones even nowdays. It is - of course - for a referense. MAC's are doing - at the question's subject - exactly the same thing/playing exactly the same role as MAC's : the integrity management $\endgroup$ – Alexey Vesnin May 9 '16 at 20:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.