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]> 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://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] <mailto:[email protected]>> > Date: Thursday, 31 October 2024 at 16:56 > To: Russ Housley <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> <[email protected] > <mailto:[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 > [2] https://datatracker.ietf.org/doc/html/rfc9044
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
