3
$\begingroup$

The MAC size is reduced to 80 bits in truncated_hmac extension , which says "forging of MAC values cannot be done off-line: in TLS, a single failed MAC guess will cause the immediate termination of the TLS session."

Question 1 (main question): So can I reduce MAC size to something even smaller, say 32 bits?

Question 2: The truncated_hmac extension does not effect AEAD. Can I reduce the tag's size in AEAD, e.g. GCM or CHACHA-POLY?

$\endgroup$
  • 1
    $\begingroup$ csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/… $\;$ $\endgroup$ – user991 Jul 6 '15 at 6:21
  • 1
    $\begingroup$ Indeed, reducing the size of the MAC in GCM is a very bad idea $\endgroup$ – Richie Frame Jul 6 '15 at 6:51
  • $\begingroup$ The document says IPsec ESP GCM allows 64 bits tag. Can I use 64 bits for TLS? $\endgroup$ – Bingzheng Wu Jul 6 '15 at 7:20
  • $\begingroup$ If you want short MACs, use HMAC. GHash is quite fragile when used with short MACs, I certainly wouldn't go below 80 bits with GHash. $\endgroup$ – CodesInChaos Jul 6 '15 at 7:24
  • $\begingroup$ @CodesInChaos 80bits is smaller than 128bits also, and this is useful. By the way, how about the poly-mac in CHACHA-POLY? $\endgroup$ – Bingzheng Wu Jul 7 '15 at 3:46
1
$\begingroup$

You cannot change the hash size without altering TLS:

From: Appendix C. Cipher Suite Definitions

MAC       Algorithm    mac_length  mac_key_length
--------  -----------  ----------  --------------
NULL      N/A              0             0
MD5       HMAC-MD5        16            16
SHA       HMAC-SHA1       20            20
SHA256    HMAC-SHA256     32            32

So although the mac_length is part of the SecurityParameters structure, the sizes are still predetermined. The implementation on the other side may not support truncated MAC values.

For the AEAD/GCM cipher the size of the tag is determined in RFC 5116 "Authenticated encryption" (normative reference):

An authentication tag with a length of 16 octets (128 bits) is used.

RFC 5116 is a rather strict (too strict in my opinion) as it assumes that the authentication tag is part of the ciphertext. It doesn't allow alterations to the size of the authentication tag either.


You are of course free to alter the specification for your own purposes. In that case the question however simply: what size of authentication tag should I use for ciphertext of "2^14 bytes or less" - as $2^{14}$ is the maximum size of a (data) fragment for TLS 1.2. In that case it depends on the MAC construction used.

For GCM the minimum is 64 bit, but a higher tag size would be preferred. For the HMAC variants you might go lower, but you should only do so for small, infrequent messages. This in turn means you must make sure that an attacker cannot trigger you to use more / larger messages.

$\endgroup$
  • $\begingroup$ Thanks. I can define an extension, like truncated_hmac, to reduce the size. That's not a problem. $\endgroup$ – Bingzheng Wu Jul 6 '15 at 10:18
  • $\begingroup$ That's possible of course. If it is just overhead I would certainly first look at other options though, such as compression of the application data or removing the fragment overhead of SSL itself. Changing the size of the authentication tag should be one of the last measures you should consider. $\endgroup$ – Maarten Bodewes Jul 6 '15 at 12:00
  • $\begingroup$ Yes, it's for overhead. The data has been compressed. What do you mean of the fragment overhead of SSL? $\endgroup$ – Bingzheng Wu Jul 7 '15 at 3:49
  • $\begingroup$ Data in TLS divided up in records, each record carries some overhead. If the fragments are large this is not much of a problem. If you send many small fragments it might however carry too much overhead. $\endgroup$ – Maarten Bodewes Jul 7 '15 at 7:04

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.