RE: [TLS] Truncated HMAC recommendation

"Blumenthal, Uri" <uri.blumenthal@intel.com> Mon, 27 November 2006 19:27 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gom8x-0004UZ-4y; Mon, 27 Nov 2006 14:27:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gom8v-0004UA-3f for tls@ietf.org; Mon, 27 Nov 2006 14:27:53 -0500
Received: from mga09.intel.com ([134.134.136.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gom8q-0006xf-E6 for tls@ietf.org; Mon, 27 Nov 2006 14:27:53 -0500
Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga09.intel.com with ESMTP; 27 Nov 2006 11:27:45 -0800
Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by fmsmga002.fm.intel.com with ESMTP; 27 Nov 2006 11:27:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: i="4.09,464,1157353200"; d="scan'208"; a="20244652:sNHT18914499"
Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 11:27:45 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Truncated HMAC recommendation
Date: Mon, 27 Nov 2006 14:27:42 -0500
Message-ID: <279DDDAFA85EC74C9300A0598E704056FE74A3@hdsmsx412.amr.corp.intel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Truncated HMAC recommendation
thread-index: AccSWD6j7rsyhSPVR0S9tZ1Cd5YbAQAANmoA
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: Mike <mike-list@pobox.com>, tls@ietf.org
X-OriginalArrivalTime: 27 Nov 2006 19:27:45.0364 (UTC) FILETIME=[1D70D940:01C7125A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

>> MAC truncation is not done to save bytes over the wire.
>
>The spec says that "it may be desirable in constrained
>environments to save bandwidth by truncating the output
>of the hash function to 80 bits when forming MAC tags."
>
>If that weren't the case, why would you want to
>truncate the MAC?

*I* would want to truncate the MAC to make cryptanalytic job of my
adversary harder by forbidding him verification of his guesses of the
correct authentication key (as I do not provide the entire computed
MAC).

On the other hand, truncatng MAC makes the birthday paradox attacks
easier (the shorter the MAC - the fewer messages you need). So the
transmitted MAC size is a compromise between mitigating both of these
two threats.

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls