Re: [tcpm] Question on crypto algo usage for TCP-AO

Joseph Touch <> Wed, 04 August 2021 03:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D5B323A3F43 for <>; Tue, 3 Aug 2021 20:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qz5V7dOQvWMF for <>; Tue, 3 Aug 2021 20:18:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D889B3A3F39 for <>; Tue, 3 Aug 2021 20:18:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KQJIaMzGRvYUQ7QnrdqVmACtjKgedrF4OxVQ6URQu/Y=; b=c5rmXjJnGMYZfqFsUz2qymJDif rYLBWznCnd9XZTwAmxQm9P0hFxeysYgLKb9vRhhdnQsGoCAusv8c7l6jh0LjryUvO3ttOv6pDYfMn DbMKsPT4zGI17VdP784DM8iyDBjmsG6ZhhseMCjY84fHue5CW9Tj5WZCSMjnhjnS4T4QSdskjjCS1 yo/goUMXCL4CkM1zYpo/ws2Aj8YOcOmczWmDNUBMgMIRgADQMIf0rWCtd8XQ92DLwsPTw2fweDF/5 Nk5VjXp1oH2JA0ppxswJAJJa8T6KKOX3vZXqTiaf6ydsSk6C/IDOLzQ+0h4Sj8AgzVRLS1b0iWpP6 E6HbaJlw==;
Received: from ([]:54338 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1mB7Qj-001qIl-Eg; Tue, 03 Aug 2021 23:18:58 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_3840A6AD-71BA-4128-A80E-504B238846A9"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Tue, 3 Aug 2021 20:18:52 -0700
Cc: " Extensions" <>
Message-Id: <>
References: <>
To: Muthu Arul Mozhi Perumal <>
X-Mailer: Apple Mail (2.3654.
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tcpm] Question on crypto algo usage for TCP-AO
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Aug 2021 03:19:03 -0000

Hi all,

I would post this to the security area WG for better feedback, given it’s only transport in its use by TCP.

My view is that this is not particularly unambiguous, as noted below.


> On Aug 2, 2021, at 6:06 AM, Muthu Arul Mozhi Perumal <> wrote:
> Hi,
> Section 3.1.1 of RFC 5926 describes how to derive the traffic key of desired length to be used for the MAC calculation, especially when the KDF_alg produces fewer bits than the key length required for the MAC_alg.
> <snip>
>    The output of multiple PRF invocations is simply concatenated.  For
>    the Traffic_Key, values of multiple PRF invocations are concatenated
>    and truncated as needed to create a Traffic_Key of the desired
>    length.  For instance, if one were using KDF_HMAC_SHA1, which uses a
>    160-bit internal PRF to generate 320 bits of data, one would execute
>    the PRF twice, once with i=1 and once with i=2.  The result would be
>    the entire output of the first invocation concatenated with the
>    second invocation.  For example,
>   Traffic_Key =
>           KDF_alg(Master_Key, 1 || Label || Context || Output_length) ||
>           KDF_alg(Master_Key, 2 || Label || Context || Output_length)
>    If the number of bits required is not an exact multiple of the output
>    size of the PRF, then the output of the final invocation of the PRF
>    is truncated as necessary.
> </snip>
> The question I have is, what if the first invocation of the above PRF itself produces more bits than the key length required by the MAC calculation. Should the output of the first invocation be truncated?

In that case, the first invocation of PRF is also the “final” invocation, as mentioned in the last paragraph, because you have enough bits. So yes, then you truncate.

> For e.g. if one were to use AES-128-CMAC-96 as the MAC_alg and KDF_HMAC_SHA1 as the KDF_alg, should the output of the foll. be truncated to 128 bits (since it would produce a 160 bit output whereas AES-128-CMAC requires a 128-bit key)?
> KDF_alg(Master_Key, 1 || Label || Context || Output_length)

Yes; I don’t understand why this seems unambiguous.

> Regards,
> Muthu
> _______________________________________________
> tcpm mailing list