I’m not deeply familiar with SHAKE, but can the length of the bstr containing the SHAKE hash serve as the length parameter?
LL > On Mar 1, 2019, at 11:01 AM, Jim Schaad <[email protected]> wrote: > > After sleeping on this I want to change what I said slightly. > > COSE does not support the same type of structure as the ASN.1 > AlgorithmIdentifier where the algorithm identifier and a set of parameters > are combined together into a single encodable entity. Instead parameters for > algorithms are defined and placed into a COSE structure either as protected, > unprotected or implicit attributes. Since the general structure I have been > telling people to use an array with an algorithm identifier and the hash > value with additional elements dealing with thing like how do you find it and > other sorts of things. > > Thus we could indeed define equivalent to the -len version by creating an > algorithm parameter. The question would be should we define some type of > COSE structure which is similar to AlgorithmIdentifier so that it can be > referenced and used in those cases where parameters should be included with > the algorithm number/string is placed. > > Jim > > > From: COSE <[email protected] <mailto:[email protected]>> On Behalf > Of Jim Schaad > Sent: Thursday, February 28, 2019 5:13 PM > To: 'Russ Housley' <[email protected] <mailto:[email protected]>> > Cc: 'cose' <[email protected] <mailto:[email protected]>> > Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document > > COSE does not support parameters so the later two cannot be supported by > themselves. Rather a new code point would be assigned for a fixed parameter > set. Thus we would need to decide what lengths should be supported for the > latter two options. > > Jim > > > From: Russ Housley <[email protected] <mailto:[email protected]>> > Sent: Thursday, February 28, 2019 4:48 PM > To: Jim Schaad <[email protected] <mailto:[email protected]>> > Cc: cose <[email protected] <mailto:[email protected]>> > Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document > > Jim: > > Four object identifiers for SHAKE128 and SHAKE256 hash functions are defined > by NIST [1]: > > id-shake128 > > id-shake256 > > id-shake128-len > > id-shake256-len > > The first two have no parameters, and the second two have an output length > parameter. > > These are the ones that should probably be included in a COSE-friendly manner. > > Russ > > > [1] > https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration > > <https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration> > > > >> On Feb 27, 2019, at 9:09 PM, Jim Schaad <[email protected] >> <mailto:[email protected]>> wrote: >> >> I have much less of a problem with just doing the hashes. >> >> So which SHAKE hashes do you think we should be defining? To match SHA-2 it >> would be SHAKE-128/64, SHAKE-128 and SHA-256. >> >> I don't know if there is a similar change in processing if you look at the >> difference between 32 and 64 bit processors which can be found with the >> SHA-2 implementations. This lead to putting in the SHA-512/256 registration >> that I put in the current draft. >> >> Jim >> >> >> >>> -----Original Message----- >>> From: Russ Housley <[email protected] <mailto:[email protected]>> >>> Sent: Wednesday, February 27, 2019 12:54 PM >>> To: Jim Schaad <[email protected] <mailto:[email protected]>> >>> Cc: cose <[email protected] <mailto:[email protected]>> >>> Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms >>> Document >>> >>> Jim: >>> >>> I as suggesting that SHAKE be added as a hash function. Sure, it might be >>> added to other documents as well, but I was not suggesting that. >>> >>> Russ >>> >>> >>> >>>> On Feb 27, 2019, at 3:44 PM, Jim Schaad <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> I am not sure that I completely agree with that. >>>> >>>> First adding SHAKE other than as a hash function would mean that this >>>> is not a standalone hash algorithm document. Second, I am not sure at >>>> this point of all of the different varieties and locations where SHAKE >> should >> >>> be added. >>> >>>> >>>> Hash Functions: Do we have just the two versions or do we have a >>>> truncated 64-bit version as well. Not sure about where the variant >>>> that had a small b would fall in here, but for now it might just be >> ignored. >> >>>> >>>> Signature Algorithms: At this point I don't know if there would need >>>> to be any RSA versions or not. Not sure what to say about DH >>>> versions. ECDSA maybe makes some sense. >>>> >>>> Message Authentication Algorithms: Do we put in a KMAC here or not? >>>> >>>> Key Derivation Functions: Do we just do HMAC with a KMAC drop in here >>>> or does NIST have a different recommended way to do KDF with SHAKE >>> functions? >>> >>>> We should definitely be able to get rid of HMAC when doing this as >>>> SHAKE already has length extension attacks solved. >>>> >>>> Key Agreement Functions: Since you need to have a combined key >>>> agreement algorithm and KDF for COSE, how many of these are we going >>> to define. >>> >>>> >>>> Encryption and Key Wrap algorithms: I sorta hope that this can be >>>> avoided for now, but I know that there are some AEAD algorithms which >>>> are built using Keccak as an underlying primitive and I am not >>>> personally ready to try and figure out how it works, but it is >>>> something that might need to be discussed here (and in CFRG). >>>> >>>> Given that the object is to get the hash algorithm assignments done >>>> for the SUIT developers, I am not sure that doing this work in this >>>> document makes sense. I will also note that the CMS work in LAMPS and >>>> CURDLE ignored the issues of new KDFs w/ SHAKE entirely so that maybe >>> groundbreaking work here. >>> >>>> >>>> >>>> Jim >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Russ Housley <[email protected] <mailto:[email protected]>> >>>>> Sent: Tuesday, February 26, 2019 7:04 AM >>>>> To: Jim Schaad <[email protected] <mailto:[email protected]>> >>>>> Cc: cose <[email protected] <mailto:[email protected]>> >>>>> Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms >>>>> Document >>>>> >>>>> Jim: >>>>> >>>>> It would probably be easy to add SHAKE now. The equivalent document >>>>> for CMS is draft-ietf-lamps-cms-shakes. >>>>> >>>>> Russ >>>>> >>>>> >>>>> >>>>>> On Feb 25, 2019, at 7:38 PM, Jim Schaad <[email protected] >>>>>> <mailto:[email protected]>> >>> wrote: >>> >>>>>> >>>>>> A version of what this document would look like can be found here >>>>>> https://tools.ietf.org/html/draft-schaad-cose-hash-algs-01 >>>>>> <https://tools.ietf.org/html/draft-schaad-cose-hash-algs-01> >>>>>> >>>>>> Jim >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: COSE <[email protected] <mailto:[email protected]>> On >>>>>>> Behalf Of Matthew A. Miller >>>>>>> Sent: Monday, February 25, 2019 4:16 PM >>>>>>> To: cose <[email protected] <mailto:[email protected]>> >>>>>>> Subject: [COSE] Call for Consensus: Standalone Hash Algorithms >>>>>>> Document >>>>>>> >>>>>>> This messages starts a call for consensus to separate the COSE hash >>>>>>> algorithms into a separate document, ending on 2018-03-10. >>>>>>> >>>>>>> In the virtual interim on 02-15, it was proposed to separate them >>>>>>> from draft- ietf-cose-x509, to allow the hash algorithm >>>>>>> registrations to stabilize more quickly than the rest of the X.509 >>>>>>> draft. If the working group agrees with separating the algorithms, >>>>>>> then a document will be published that consists of Section 4 (Hash >>>>>>> Algorithm >>>>>>> Identifiers) and Section 5.3 (COSE Algorithm >>>>>>> Registry) from draft-ietf-cose-x509. >>>>>>> >>>>>>> Please respond with whether or not you support separating the hash >>>>>>> algorithms into a separate document. If you do not support this, >>>>>>> please indicate why not. >>>>>>> >>>>>>> >>>>>>> - Ivaylo and Matthew >>>>>>> COSE Chairs >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> COSE mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://www.ietf.org/mailman/listinfo/cose >>>>>> <https://www.ietf.org/mailman/listinfo/cose> >>>> >> >> >> _______________________________________________ >> COSE mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/cose >> <https://www.ietf.org/mailman/listinfo/cose> > > _______________________________________________ > COSE mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/cose > <https://www.ietf.org/mailman/listinfo/cose>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
