[tcpm] Question on crypto algo usage for TCP-AO
Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Mon, 02 August 2021 13:06 UTC
Return-Path: <muthu.arul@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 8A08D3A1CC6
for <tcpm@ietfa.amsl.com>; Mon, 2 Aug 2021 06:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id DGL645dc1RFm for <tcpm@ietfa.amsl.com>;
Mon, 2 Aug 2021 06:06:42 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com
[IPv6:2607:f8b0:4864:20::635])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id DEFE43A1CC5
for <tcpm@ietf.org>; Mon, 2 Aug 2021 06:06:42 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id t3so17411042plg.9
for <tcpm@ietf.org>; Mon, 02 Aug 2021 06:06:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=9gCd1mfBxJIg6qmd1zowClPfBeOV/m+cBvT7uYTshik=;
b=DeK7HzHLTGrTDxSxof01oF67ZkX8dfhg6i1iPjz+L5+Fo0tXNQpiqjXecJqHUSUxs1
YOGjtrDRf8cc9EV2g6oecukO/ItmrCIDpjDU0oTXLKmeFaaSj3Vbu8/twEfjnMybFLp4
4Z4ZOLWCRQkc3iUX65/jkXW8JKN4MTnVsZc/6qf/3IMZckk06Vge2f78yRh3g2PyEg0O
+52xWSM0+rLOPrD5orxDGsBcEHcuWtPAbkNMShf0AWDuNet2TUEvn0oUxdyZJd80+K7Y
GgLt6YtVY99uvooSL1ERWD6oOwhb21W5PMGyD5+iQLlW2qwdCSVskacsLobpudzsRcoR
thRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=9gCd1mfBxJIg6qmd1zowClPfBeOV/m+cBvT7uYTshik=;
b=Z6AAX9LTrgUvzPBppSpD39a3bisEMIu8eiymHQs8JGJClBOynwNqlPjvo49PkBJ5kM
VOSiXOXOSko/SranRwU3J6SWaBgXvJuRVHFjRzdWSp6MBRq44SXnlmRjpRJVHkESfyDO
hw2NcGIlhq2pQKCkrVJ3Cl3ITnDI6PPLRRXOePUPh5gpTJmdHMw58sfVlkVvHk0dIz3X
Wgt0W/wqb1mtmcI9J4UA393xwkzY9CZ4EDH+xxrsV5INuHQ8rlyumU6Q6SaQz+T0tIML
PtH9JmNWsuv6lrt8xBr0Ss/3Jg5NAt2nDsOXqotGEFMolZUFb28svXN8RLoeTRQwovZD
wnpg==
X-Gm-Message-State: AOAM533g2W/2k4ByIbUEegJZ0N02Aj/iN0ygUdVx+fswOWn0t0x5e45O
xQEiWTcblEnU5DxUZdqZBpRb3pljVtxxlD8zm0ud8XI6W2Y=
X-Google-Smtp-Source: ABdhPJwpPw/xdfOJWIou0qs904crY3ZxQpu8r02/ca6a3M1qq+YKbeWLEww/zVhJgUW5TaCnBhZqTS18y5fXSPo7XUw=
X-Received: by 2002:a65:5186:: with SMTP id h6mr2124894pgq.62.1627909601143;
Mon, 02 Aug 2021 06:06:41 -0700 (PDT)
MIME-Version: 1.0
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Date: Mon, 2 Aug 2021 18:36:29 +0530
Message-ID: <CAKz0y8x2NWLE1Nzmah5iwvbFRCh3YrMpGU6seudJZMWCJeOE2Q@mail.gmail.com>
To: tcpm@ietf.org
Content-Type: multipart/alternative; boundary="00000000000080ae9905c8933d14"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/RIFg9hOnoYaFB1iDzmDkeS9ySCM>
Subject: [tcpm] Question on crypto algo usage for TCP-AO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>,
<mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>,
<mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Aug 2021 13:06:48 -0000
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? 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)
Regards,
Muthu
- [tcpm] Question on crypto algo usage for TCP-AO Muthu Arul Mozhi Perumal
- Re: [tcpm] Question on crypto algo usage for TCP-… Joseph Touch
- Re: [tcpm] Question on crypto algo usage for TCP-… Muthu Arul Mozhi Perumal