Subject: [CFRG] KMAC customization string

From: "Erik Andersen" <[email-masked]>
Date: Sat, 9 Apr 2022 17:20:29 +0200

Is the KMAC customization string something that is agreed in advance, or may
it be changed for each message sent? In other words, is it something like
the AES initialization vector needed to be transferred together with a KMAC
deployment?

Best regards,

Erik

---

From: John Mattsson <[email-masked]>
Date: Sun, 10 Apr 2022 08:31:47 +0000

Hi,

Accoring to NIST SP 800-185 the customization string S is optional so you can ignore it if you want. NIST 800-56C Rev2 defines the use of KMAC as a KDF and gives an example of how the customization string is intended to be used.

  "The “customization string” S shall be the byte string 01001011 || 01000100 || 01000110,
   which represents the sequence of characters “K”, “D,” and “F” in 8-bit ASCII. (This
   three-byte string is denoted by “KDF” in this document.)"

So if you use an customization string, both parties need to agree on the string. I don't think this is similar to IV as IV is typically derived from some keying material. NIST does not seem to forbid changing the customization string for each message or even letting an attacker control the customization string but I don't see any reason to do so.

Cheers,
John

From: CFRG <[email-masked]> on behalf of Erik Andersen <[email-masked]>
Date: Saturday, 9 April 2022 at 17:21
To: Cfrg <[email-masked]>
Subject: [CFRG] KMAC customization string
Is the KMAC customization string something that is agreed in advance, or may it be changed for each message sent? In other words, is it something like the AES initialization vector needed to be transferred together with a KMAC deployment?

Best regards,

Erik

---

From: Michael Sierchio <[email-masked]>
Date: Sun, 10 Apr 2022 07:41:42 -0400

On Sun, Apr 10, 2022 at 4:32 AM John Mattsson <john.mattsson=
[email-masked]> wrote:

>
> So if you use an customization string, both parties need to agree on the
> string. I don't think this is similar to IV as IV is typically derived from
> some keying material. NIST does not seem to forbid changing the
> customization string for each message or even letting an attacker control
> the customization string but I don't see any reason to do so.
>
>
>
>From John Kelsey (NIST) presentation on FIPS 202 and Keccak-Derived
Functions seems to indicate the purpose of intent of customization strings:

*Customization string: You can "name" an instance of any function*
*to domain-separate it from all other uses of SHA3-derived functions*

and

*All new Keccak-derived functions will support "customization strings"*
*to let users further domain-separate them.  We plan to introduce a*
*new SP to allow customization strings for Shakes and SHA3, too.*