Hi, Specifying KMAC is a great idea, we (Ericsson) are planning to transition as much as possible to SHA-3/SHAKE/cSHAKE/KMAC in the transition to PQC, which ML-KEM and ML-DSA use internally. I am happy to help with any introduction of SHAKE and KMAC in IETF protocols. I assume the document will specify KMAC128 and KMAC256. A remaining question is what the tag length should be and if several tag lengths should be specified.
(Regarding the IPsec draft: I don’t see any use of HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512, these are very inefficient constructions. I don’t think there are any reasons to use anything else than KMAC. Similarly, the requirement on signature algorithms should be SHAKE. Also, NIST is soon disallowing SHA3-224.) https://datatracker.ietf.org/doc/rfc8692/ https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd Regarding AES-GMAC, I think AES-192 could be skipped. I agree the tag length should be 128-bits for GMAC. In addition to stating “Within the scope of any content-authentication key, the AES-GMAC nonce value MUST be unique.” I think the draft should explicitly state that random nonces MUST not be used. As I brought in my comments to NIST, SP 800-38C (CCM) states that the nonce shall be unique but there are still implementations that use CCM with a 11-byte random nonce as the default… https://csrc.nist.gov/csrc/media/Projects/crypto-publication-review-project/documents/initial-comments/sp800-38c-initial-public-comments-2024.pdf Cheers, John From: Sipos, Brian J. <[email protected]> Date: Thursday, 31 October 2024 at 16:56 To: Russ Housley <[email protected]> Cc: [email protected] <[email protected]> Subject: [COSE] Re: [EXT] Re: AES-GMAC in COSE Russ, I looked into KMAC and it seems like it can also be included as a set of fully specified algorithms parameterized like you mentioned. Other proposed uses in IPsec [3] do make use of different customization strings, which might apply in this situation but I’ll leave that detail to other experts. I have an initial draft going through internal release review. After that I can add you as coauthor if you’d like and can point me to (e.g. a recent draft that has) your contact info. Thanks in advance, Brian S. [3] https://datatracker.ietf.org/doc/draft-salter-ipsecme-sha3/ From: Russ Housley <[email protected]> Sent: Friday, July 19, 2024 1:49 PM To: Sipos, Brian J. <[email protected]> Cc: [email protected] Subject: [EXT] Re: [COSE] AES-GMAC in COSE Brian: I am willing to assist on the GMAC document. Any reason not to do KMAC as well? See RFC 8702. I would think that KMAC with SHAKE128 (outputs 256 bits with no customization string) and KMAC with SHAKE256 (outputs 512 bitswith no customization string). I am willing to consider other parameter choices if people see a need. Russ On Jul 19, 2024, at 11:28 AM, Sipos, Brian J. <[email protected]> wrote: All, I was looking in the COSE algorithms registry [1] for any existing allocations for GMAC uses but don’t see any. My reason for looking was that in some hardware-accelerated environments AES-GCM is faster than HMAC processing, so a GMAC would also benefit from the acceleration. I expect that a COSE use of AES-GMAC would look similar to the use in CMS [2] except that COSE algorithms typically combine options like authentication tag size into a single code point, so an initial thought would be max-length tags like: AES-GMAC 128/128, AES-GMAC 192/128, AES-GMAC 256/128 Would there be WG interest in allocating GMAC algorithms in the near-term time supporting max-length tags? Thanks, Brian S. [1] https://www.iana.org/assignments/cose/cose.xhtml#algorithms [2] https://datatracker.ietf.org/doc/html/rfc9044
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
