Russ, would these KDF registrations be separate-layer ones, as in “direct+KMAC128-KDF”, or somehow integrated with a key agreement operation like the “ECDH-?S+HKDF…” current algorithms are?
If you have any specific text in mind to start that would be helpful. I can also add you as a contributor to the Github repo (you can send your account name in a direct email if you like) and we can work on exact updates to the text. From: Russ Housley <[email protected]> Sent: Wednesday, November 20, 2024 11:50 AM To: Sipos, Brian J. <[email protected]> Cc: John Mattsson <[email protected]>; [email protected] Subject: Re: [COSE] [EXT] Re: AES-GMAC in COSE Brian: If you are willing to add KMAC128-KDF and KMAC256-KDF (see Section 5.2 of RFC 9688), then I'm happy to assist. Russ On Nov 20, 2024, at 9:16 AM, Sipos, Brian J. <[email protected] <mailto:[email protected]> > wrote: All, I now have a first non-internet-draft version of a GMAC and KMAC registration [1] available for browsing and initial feedback. After that feedback I can post this as a proper internet draft. Right now, the code point registrations follow existing AES-related parameters for 128, 192, 256 -bit keys and full-length tags. I don’t have particular interested in shortened tag lengths so didn’t put in allocations for them like some of the existing COSE MAC algos have. I also don’t have strong feelings about useful key lengths. John, I understand your comments about the IV uniqueness vs. randomness and if you have some specific language for Section 2.1 that is welcome. Otherwise I will add a requirement to forbid random IV values. Is there any stronger recommendation for how to generate non-random IVs? Russ, if you would like to be added as a coauthor and want to steer the KMAC details just let me know from where I can take your up-to-date contact details. Right now, this allocation does make use of the KMAC customization string similar to the IPsec draft. But if there is some guidance or benefit to avoiding the customization that would be useful to know. [1] https://briansipos.github.io/cose-gmac-kmac/draft-sipos-cose-gmac-kmac.html From: John Mattsson <[email protected] <mailto:[email protected]> > Sent: Thursday, October 31, 2024 12:47 PM To: Sipos, Brian J. <[email protected] <mailto:[email protected]> >; Russ Housley <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> Subject: Re: [COSE] Re: [EXT] Re: AES-GMAC in COSE APL external email warning: Verify sender [email protected] <mailto:[email protected]> before clicking links or attachments 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://datatracker.ietf.org/doc/rfc8692/ <https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd> 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> 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. < <mailto:[email protected]> [email protected]> Date: Thursday, 31 October 2024 at 16:56 To: Russ Housley < <mailto:[email protected]> [email protected]> Cc: <mailto:[email protected]> [email protected] < <mailto:[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] <mailto:[email protected]> > Sent: Friday, July 19, 2024 1:49 PM To: Sipos, Brian J. <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[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] <mailto:[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> https://www.iana.org/assignments/cose/cose.xhtml#algorithms [2] <https://datatracker.ietf.org/doc/html/rfc9044> https://datatracker.ietf.org/doc/html/rfc9044
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
