Message Authentication Code (MAC) and Dual Signature in SET: Exam Explanation

"Message authentication code", "dual signature" and "computer security mechanisms" are three short-answer staples across the security subjects of TU BSc CSIT and BIT. The syllabus places them in Cryptography (CSC327) unit 4 "Cryptographic Hash Functions and Digital Signatures" and unit 5 "Authentication", Information Security (BIT303) unit 5 "Hash Functions and Message Authentication", E-Commerce (CSC381) unit 5 "Security in E-Commerce" and E-Commerce (BIT403) unit 5 "Secure Electronic Transactions and Protocols", where the SET protocol and its dual signature appear.

This guide explains the message authentication code (MAC) and the message authentication code algorithm in outline, compares MAC with hash and digital signature, covers HMAC and CMAC briefly, then explains the dual signature in SET with the construction written out, and ends with the list of security mechanisms from X.800. Notes for the units are on the CSC327 Cryptographic Hash Functions and Digital Signatures page and the BIT303 Hash Functions and Message Authentication page.

Message authentication code (MAC)

A message authentication code is a short fixed-size tag computed from a message and a secret key shared by sender and receiver. It protects data integrity and gives message authentication: the receiver can be sure the message was not changed and that it came from someone who knows the key.

The sender computes the tag and sends it with the message:

$T = \mathrm{MAC}(K, M)$

The receiver, who holds the same key $K$ , recomputes $\mathrm{MAC}(K, M')$ on the message received and compares it with the received tag. If the two are equal, the message is accepted as unaltered and authentic. If an attacker changes even one bit of $M$ , the tag no longer matches, and without $K$ the attacker cannot compute a valid new tag.

A MAC does not encrypt the message, so on its own it gives no confidentiality; encryption can be added on top. It also has no non-repudiation, because both parties know the key and either could have produced the tag.

MAC, hash and digital signature compared

Point	Hash function	MAC	Digital signature
Key used	None	One shared secret key	Private key to sign, public key to verify
Provides integrity	Yes, if the hash itself is protected	Yes	Yes
Provides authentication	No	Yes, of the key holder	Yes, of the signer
Non-repudiation	No	No	Yes
Key distribution problem	None	Yes, key must be shared securely	No secret sharing, needs public key trust
Speed	Fast	Fast	Slow (public key operations)

HMAC and CMAC

HMAC builds a MAC from an ordinary hash function $H$ such as SHA-256 and a key $K$ . With $\mathrm{opad}$ and $\mathrm{ipad}$ fixed padding constants, it is defined as

$\mathrm{HMAC}(K, M) = H\big((K' \oplus \mathrm{opad}) \,\|\, H((K' \oplus \mathrm{ipad}) \,\|\, M)\big)$

where $K'$ is the key padded to the hash block size. The nested construction avoids the length extension weakness of the simple form $H(K \| M)$ . HMAC is used in TLS and IPsec.

CMAC (cipher-based MAC) builds the tag from a block cipher such as AES in a chained mode: the message is split into blocks, each block is XORed into the encrypted previous block, and the final block is processed with an extra derived subkey, with the last cipher output (possibly truncated) as the tag. It is the standard choice when a block cipher is available but a hash function is not.

Dual signature in SET

Secure Electronic Transaction (SET) was designed for credit card payments. A customer sends two pieces of information with different readers: the order information (OI), which only the merchant should read, and the payment information (PI), which only the bank (payment gateway) should read. The merchant should not see the card number, and the bank should not see what was bought. Yet the two must be linked, so that a payment cannot be reused for another order. The dual signature achieves exactly this.

The customer computes a hash of each part, joins the two hashes, hashes the joined value and signs it with the private key:

$PIMD = H(PI), \qquad OIMD = H(OI)$

$POMD = H(PIMD \,\|\, OIMD)$

$DS = E_{KR_c}(POMD)$

Here $\|$ denotes concatenation, $POMD$ is the payment order message digest, $KR_c$ is the customer's private key and $DS$ is the dual signature. The customer sends the merchant $OI$ , $DS$ and $PIMD$ (but not $PI$ ), and sends the bank $PI$ , $DS$ and $OIMD$ (but not $OI$ ).

Merchant verification. The merchant computes $H(PIMD \| H(OI))$ using the $PIMD$ it received and the $OI$ it holds, then decrypts $DS$ with the customer's public key $KU_c$ and checks

$H\big(PIMD \,\|\, H(OI)\big) = D_{KU_c}(DS)$

Bank verification. The bank computes $H(H(PI) \| OIMD)$ from the $PI$ it holds and the $OIMD$ it received, and checks

$H\big(H(PI) \,\|\, OIMD\big) = D_{KU_c}(DS)$

If the equality holds, each party knows that the other half was signed by the customer in the same transaction, without ever seeing it. Since a hash cannot be reversed, $PIMD$ reveals nothing about the card details to the merchant, and $OIMD$ reveals nothing about the goods to the bank. This preserves privacy, integrity and non-repudiation while linking the order to the payment.

Computer security mechanisms (X.800)

The ITU-T X.800 recommendation lists the specific mechanisms used to provide security services:

Encipherment: converting data to a form that cannot be read without a key, giving confidentiality.
Digital signature: data appended to a message that proves the origin and integrity of the message and prevents repudiation.
Access control: mechanisms that enforce the rights of entities to resources.
Data integrity: mechanisms that ensure data units have not been altered, for example hashes and MACs.
Authentication exchange: a protocol by which two entities prove their identities to each other.
Traffic padding: inserting bogus data to hide traffic patterns.
Routing control: selecting physically secure routes, or changing routes when a breach is suspected.
Notarization: use of a trusted third party to assure properties of a data exchange.

How to write it in the exam

For "Explain message authentication code", define it, write $T = \mathrm{MAC}(K, M)$ , describe send and verify in two or three lines, state that it gives integrity and authentication but not non-repudiation or confidentiality, and add the comparison table if marks allow. For "What is a dual signature? Explain with SET", draw the customer, merchant and bank, write the three construction equations on separate lines, and explain both verifications. For "security mechanisms", list the eight X.800 mechanisms with one line each.

Related reading is the BIT403 Secure Electronic Transactions and Protocols notes and the CSC381 Security in E-Commerce notes. The full subject pages are CSC327 Cryptography and BIT303 Information Security.

"Message authentication code", "dual signature" and "computer security mechanisms" are three short-answer staples across the security subjects of TU BSc CSIT and BIT. The syllabus places them in Cryptography (CSC327) unit 4 "Cryptographic Hash Functions and Digital Signatures" and unit 5 "Authentication", Information Security (BIT303) unit 5 "Hash Functions and Message Authentication", E-Commerce (CSC381) unit 5 "Security in E-Commerce" and E-Commerce (BIT403) unit 5 "Secure Electronic Transactions and Protocols", where the SET protocol and its dual signature appear.

This guide explains the message authentication code (MAC) and the message authentication code algorithm in outline, compares MAC with hash and digital signature, covers HMAC and CMAC briefly, then explains the dual signature in SET with the construction written out, and ends with the list of security mechanisms from X.800. Notes for the units are on the CSC327 Cryptographic Hash Functions and Digital Signatures page and the BIT303 Hash Functions and Message Authentication page.

Message authentication code (MAC)

A message authentication code is a short fixed-size tag computed from a message and a secret key shared by sender and receiver. It protects data integrity and gives message authentication: the receiver can be sure the message was not changed and that it came from someone who knows the key.

The sender computes the tag and sends it with the message:

$$T = \mathrm{MAC}(K, M)$$

The receiver, who holds the same key $K$, recomputes $\mathrm{MAC}(K, M')$ on the message received and compares it with the received tag. If the two are equal, the message is accepted as unaltered and authentic. If an attacker changes even one bit of $M$, the tag no longer matches, and without $K$ the attacker cannot compute a valid new tag.

A MAC does not encrypt the message, so on its own it gives no confidentiality; encryption can be added on top. It also has no non-repudiation, because both parties know the key and either could have produced the tag.

MAC, hash and digital signature compared

Point	Hash function	MAC	Digital signature
Key used	None	One shared secret key	Private key to sign, public key to verify
Provides integrity	Yes, if the hash itself is protected	Yes	Yes
Provides authentication	No	Yes, of the key holder	Yes, of the signer
Non-repudiation	No	No	Yes
Key distribution problem	None	Yes, key must be shared securely	No secret sharing, needs public key trust
Speed	Fast	Fast	Slow (public key operations)

HMAC and CMAC

HMAC builds a MAC from an ordinary hash function $H$ such as SHA-256 and a key $K$. With $\mathrm{opad}$ and $\mathrm{ipad}$ fixed padding constants, it is defined as

$$\mathrm{HMAC}(K, M) = H\big((K' \oplus \mathrm{opad}) ,|, H((K' \oplus \mathrm{ipad}) ,|, M)\big)$$

where $K'$ is the key padded to the hash block size. The nested construction avoids the length extension weakness of the simple form $H(K | M)$. HMAC is used in TLS and IPsec.

CMAC (cipher-based MAC) builds the tag from a block cipher such as AES in a chained mode: the message is split into blocks, each block is XORed into the encrypted previous block, and the final block is processed with an extra derived subkey, with the last cipher output (possibly truncated) as the tag. It is the standard choice when a block cipher is available but a hash function is not.

Dual signature in SET

Secure Electronic Transaction (SET) was designed for credit card payments. A customer sends two pieces of information with different readers: the order information (OI), which only the merchant should read, and the payment information (PI), which only the bank (payment gateway) should read. The merchant should not see the card number, and the bank should not see what was bought. Yet the two must be linked, so that a payment cannot be reused for another order. The dual signature achieves exactly this.

The customer computes a hash of each part, joins the two hashes, hashes the joined value and signs it with the private key:

$$PIMD = H(PI), \qquad OIMD = H(OI)$$

$$POMD = H(PIMD ,|, OIMD)$$

$$DS = E_{KR_c}(POMD)$$

Here $|$ denotes concatenation, $POMD$ is the payment order message digest, $KR_c$ is the customer's private key and $DS$ is the dual signature. The customer sends the merchant $OI$, $DS$ and $PIMD$ (but not $PI$), and sends the bank $PI$, $DS$ and $OIMD$ (but not $OI$).

Merchant verification. The merchant computes $H(PIMD | H(OI))$ using the $PIMD$ it received and the $OI$ it holds, then decrypts $DS$ with the customer's public key $KU_c$ and checks

$$H\big(PIMD ,|, H(OI)\big) = D_{KU_c}(DS)$$

Bank verification. The bank computes $H(H(PI) | OIMD)$ from the $PI$ it holds and the $OIMD$ it received, and checks

$$H\big(H(PI) ,|, OIMD\big) = D_{KU_c}(DS)$$

If the equality holds, each party knows that the other half was signed by the customer in the same transaction, without ever seeing it. Since a hash cannot be reversed, $PIMD$ reveals nothing about the card details to the merchant, and $OIMD$ reveals nothing about the goods to the bank. This preserves privacy, integrity and non-repudiation while linking the order to the payment.

Computer security mechanisms (X.800)

The ITU-T X.800 recommendation lists the specific mechanisms used to provide security services:

Encipherment: converting data to a form that cannot be read without a key, giving confidentiality.
Digital signature: data appended to a message that proves the origin and integrity of the message and prevents repudiation.
Access control: mechanisms that enforce the rights of entities to resources.
Data integrity: mechanisms that ensure data units have not been altered, for example hashes and MACs.
Authentication exchange: a protocol by which two entities prove their identities to each other.
Traffic padding: inserting bogus data to hide traffic patterns.
Routing control: selecting physically secure routes, or changing routes when a breach is suspected.
Notarization: use of a trusted third party to assure properties of a data exchange.

How to write it in the exam

For "Explain message authentication code", define it, write $T = \mathrm{MAC}(K, M)$, describe send and verify in two or three lines, state that it gives integrity and authentication but not non-repudiation or confidentiality, and add the comparison table if marks allow. For "What is a dual signature? Explain with SET", draw the customer, merchant and bank, write the three construction equations on separate lines, and explain both verifications. For "security mechanisms", list the eight X.800 mechanisms with one line each.

Related reading is the BIT403 Secure Electronic Transactions and Protocols notes and the CSC381 Security in E-Commerce notes. The full subject pages are CSC327 Cryptography and BIT303 Information Security.

Keep studying

Solved past questions

Every TU CSIT, BIT and NEB subject, answered by unit.

NoteTok

30-second concept shorts from real exam questions.

Ask a question

Missing an answer? Submit it to the queue.